bridge0 LAN IP not present
-
@stephenw10 The description is NOT there and is consistent with your observations.
I had created the first set of text by editing the second set and failed to remove the description line when I removed the inet line. I was doing it in this manner as I had no LAN access in the first instance, only VGA console.
Sorry for the oversight, that was sloppy on my part.
Ted Quade
-
I am having the same issue on my SG-1100 where I had bridged the two internal (LAN OPT) interfaces. I am awaiting tomorrows snapshot to see if this fixes the issue from the redmine issue.
-
It is not fixed. The cause is not know yet.
At least we are seeing the same thing though, it appears to not be applying the config at all.
Any of you also seeing the delay in completing boot on the logs? In my case it can be seen more clearly at the console where it waits for 10mins during boot.
-
@stephenw10 Boot time for me at VGA console is 56 seconds. Nothing inordinate in the OS boot log.
Ted Quade
-
OK, thanks. Yeah, looks like that was something somehow related to what pfBlocker was doing and you don't have that installed.
Still digging... -
@stephenw10 WiFi configuration problem resolved in todays snapshot.
Ted Quade
-
Yeah, @jimp found and fixed that before I'd finished reporting it!
-
@stephenw10 Do you know if this issue also affects LAGG interfaces in the same way? I am unable to get any network traffic to pass through a LAGG vlan with the 11-18 snapshot.
-
With an IP address on the lagg directly? It comes up the same way, no ip config on it?
I haven't seen that but I'm not sure I have anything testing it directly right now...yet
-
Actually I do have an assigned LACP lagg on the same test box that's hitting this issue with the bridge and it comes up fine.
-
@tedquade Are you able to upload any config or logs from the system you have hitting this?
If so please do so here: https://nc.netgate.com/nextcloud/s/7rdEWfnigQWKdTN
Steve
-
@stephenw10 I can.
What specific config do you need? The XML backup or system config files? If the latter, provide me with the exact path.
As for logs, what do you need, ie OS boot log, etc. and specific system path as appropriate.
Ted Quade
-
The full config backup would be ideal if it's a test box you're able to do that with.
The boot logs may also show something.
The redacted status_output file from <your_firewall_IP>/status.php would be useful if you can't use the full config.
Steve
-
@stephenw10 XML config backup and OS Boot log uploaded.
Ted Quade
-
Thanks!
-
Are you able to test booting with the OpenVPN server disabled?
We think we've found where this is happening but it would be good to get another data point to confirm it because it's not a simple fix.
Steve
-
@stephenw10 You have the additional data point.
Bridge0 came up configured on reboot with OpenVPN server disabled.
Now for the real fun by the sounds of it!
Ted Quade
-
Yes, the 'correct' fix for this is.... non-trivial!
Thanks for confirming.
-
@stephenw10 With this mornings build, the problem is resolved.
FreeBSD 14.0-CURRENT #0 plus-devel-main-n255990-b4bd6673756: Thu Dec 1 06:29:16 UTC 2022
Ted Quade
-
Excellent! Thanks for the feedback.
I tested every combination of bridges, vlans, qinqs and openvpns I could think of there and it looks good. There are a lot of possible combos though so let me know if you find anything.
One thing this exposed is that the bridge interfaces handling in FreeBSD 14 does a few things differently. The MTU setting especially has changed. Setting the MTU on the bridge should now propagate that to all members. And conversely it will override any setting on a member interface. So in the current snapshot you should find interfaces that are bridge members have the MTU field greyed out.
Steve
