- User Since
- May 19 2017, 3:54 AM (179 w, 1 d)
Sep 27 2019
Been pretty busy lately, but ran a quick test tonight. Wireguard keys are properly moved in my VM.
Sep 19 2019
Already fixed manually, but I can test on yesterday's vm backup if needed.
Not sure what you mean by pre and post-commit config blocks.
The loading error is caused by bridging a l2tpv3 interface, didn't see the cause at first because of the other errors. Since the bridge is now created at priority 470, and l2tpv3 is 800, when before an interface would be added to the bridge as it is created.
After adding the vif to bridge member interfaces, I get a config load error on boot. Running config, load, commit, works. Something to do with the order the configs get applied?
Just noticed bridge has a member interface parameter now. The vif bridge-group config was not migrated.
Sep 5 2019
@hagbard I no longer have the hardware the issue was found on, or anything else with identical interfaces to bond at the moment.
Jul 20 2019
I wonder if the bgp daemon is being started before the hostname is changed by the config script. Seems possible since we added a lock so it executes later.
@zsdc Hostname is still showing as 'debian' in 1.2.0-rolling+201907191807
Jul 18 2019
Jul 15 2019
Noticed this today. Possibly another related bug, seems to have appeared the same time the previous ones were fixed. Hostname in bgp is showing up as 'debian', the hostname command, /etc/hostname, /etc/resolv.conf show the correct hostname.
Jul 11 2019
Jul 8 2019
Had a long 4th of July weekend, but the issue appears to be resolved in 1.2.0-rolling+201907080337.
Jul 3 2019
Possibly a related problem here in T1497, we're still chasing an issue where disable-dhcp-nameservers isn't working on startup.
Jul 2 2019
Yeah, that's the one I just installed.
Still using the dhcp servers on 1.2.0-rolling+201907022116. Will post back in a few hours if the one with a bunch of lines happens again.
Not sure when the messed up one with all the lines happens, it wasn't right after commit, seemed to be after sitting for a few hours, but it was broken again when I tried to add system image just now.
@UnicronNL yes. On boot it creates the resolv.conf with DHCP nameservers and missing the domain/search options. If I commit, it generates one with my configured servers and the domain/search options.
Updated to latest rolling, 1.2.0-rolling+201907020337
Jul 1 2019
IPv6 is all static - he.net tunnels. Will try the rolling when it's up.
It's at&t's dhcp server, I have no idea what they run.
Jun 30 2019
The difference might be because my IPv6 server is first, but I'm also experiencing the non-update when I try to add 188.8.131.52 to see if having an IPv4 server first helps.
Jun 29 2019
Jun 26 2019
I think there's still an issue in the latest rolling. The hostname is not being set to the one in the config.
Jun 25 2019
Trying to figure out how to do this via xml. Seems like it generates the .def files from the xml Does it require rebuilding the whole image to test?
Jun 21 2019
Jun 16 2019
Mar 28 2019
Not sure if the l2tp/vti modification merits inclusion - that depends on personal configuration of which tunnel is inside the other. I think the original config is correct for the more common use case of having l2tp secured by ipsec.
That worked, thanks. Had to set it to 901, the vpn node was 900. Added a sed to the preconfig script so it survives updates.
Mar 27 2019
I switched to a L2TPv3 tunnel for better performance than OpenVPN, still will not come up at boot if it depends on the vti interface.
Mar 26 2019
Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.
Oct 7 2018
I also have ipsec/vti.
I rechecked the solarflare card - issue still exists. Didn't catch it last time because my config got a little messed up with all the image swapping.
Oct 3 2018
Finally got back up here to test. Swapped out the Mellanox NIC with a Solarflare card on latest, works. 201807292210 image with Mellanox card, works. Latest image and different Mellanox card, broken. Definitely looks like a driver issue, the new kernel seems to have a far older version. No virtualization involved.
Sep 19 2018
I've tried the oldest build, but it still has the issue. Is there any way to extract an image from another router? The timing does line up for it being a driver issue, I'm going to see if swapping to a different NIC helps next time I drive over, debugging remotely atm, so no rebooting allowed for a few days.
Does anyone know where I can find a build on the old kernel? I deleted mine swapping images at some point. Starting to think that might be when it started.
It's what Windows does when you first assign an IP address - checks if it's in use and refuses to use it if it is. Linux boxes don't so they have working IPv4.
IPv6 is all on different subnets, and I actually have working IPv6 networking while IPv4 is broken. v6 uses NDP instead of ARP so shouldn't be able to cause this.
Sep 18 2018
Config's pretty huge, here's the LAN interface. Need to go through and sanitize the rest. No proxy arp or similar anywhere, "arp" doesn't appear in the config at all. Issue occurs on all vlans.
Sep 9 2018
Do you have a copy of 1.2.0-rolling+201808230337 to share? I'd like to get wireguard working, but need L2TP working as well. It's no longer on the download page.
Sep 8 2018
Aug 7 2018
Aug 2 2018
Looks like it was merged, closing, thanks :)
Jul 30 2018
Jul 28 2018
Jul 27 2018
As far as I could tell before, it was triggered by my unique attempt to bridge a vlan to openvpn.
Finally had some down time I could to use to debug this, but it appears to be fixed in the latest revisions. Going back to 201806151501 still breaks it though.
Jun 20 2018
Little more testing..
relevant parts below. The interfaces seem to be added to the bridge, but the bridge interface is not assigned an ip address.