Perhaps someone can give me a hint. After updating from 154 to 155 there is no blue0 interface anymore. blue0 is missing.
System has two physical NICs, green and red, blue0 is mapped on green0 as VLAN10.
“Zone configuration” shows the correct config, network CLI setup for blue is correct (and didn’t change)
/var/log/messages gives a dhcpd warning that there is no subnet declaration for blue0 (no IPv4 addresses), which is correct cause the interface isn’t created.
No other warning ablut blue0.
On another machine with four NICs but the same blue0 VLAN10 config everything went fine with the update.
/var/ipfire/ethernet/settings is pretty much standard:
Did you ever figure out this issue? I just realized I’m also experiencing this issue on 3 different ipfire devices, where my guest wifi dhcp (blue network) won’t issue ip addresses and I get the same error “No subnet declaration for blue0 (no IPv4 addresses)”. Like you, everything looks normal for me and I’ve touched nothing (except for updating).
Spent a lot of time on this yesterday, and confirmed that because the Blue0 interface is not tied directly to a nic via ‘setup’, and is only configured to a vlan, it’s not starting the interface. Ran the below command to manually start the blue network and got the following output.
“/etc/rc.d/init.d/networking/blue start”
Bringing up the blue0 interface…
Interface blue0 doesn’t exist. [FAIL]
These settings have been like this for years and have worked right up till recently. I don’t personally use the guest network and due to covid I haven’t had a lot of guests over, but my guess is that the issue started back on (or around) update 155.
I’m not 100% sure if this is a “bug” or if a change happened and I just need to update my configuration somehow, but I’d love to have @ms or one of the other developers take a look.
I am no expert on this and I have no idea why it would have worked before but looking at your zone config I see that you have both the Green and the Blue zone lined up with eth0 with Green on Native and Blue on VLAN. As far as I am aware to make two zones work on one interface you have to have one of them in bridge mode but you have them both in Default mode.
However you have a spare interface card at eth1, so I would move the Blue zone to eth1 and set that entry to VLAN 1003.
You might need to go to the setup mode and assign eth1 to the Blue interface.
Hopefully other people can either confirm or correct what I have said.
No, unfortunately I didn’t. The according system is still running without the blue0 interface. Therefore no WLAN in this part of the office.
I don’t have a spare port on the box, so VLAN is necessary in this setup.
Further a lot of other things like Asterisk etc. are running on this machine, so I didn’t have time to reinstall it completely.
Meanwhile it’s updated to core 158, but the problem didn’t disappear.
I should probably explain my topology a little better, my wireless AP runs multiple networks, One wireless network for my green and one for my blue guest (the blue network is on VLAN 1003). The one AP Plugs into my managed switch, and my switch (with all devices) connects to my firewall box where you see the green Network on eth0. Though I could set eth1 to blue, would loose green wifi and blue network would still need to be VLAN’d (so it’s basically the same thing as I have now).
Based on what I see, I would venture to guess that something was changed in the interface startup code, and whether or not they require a physical port to be assigned as part of their startup checks. You have the ability to leave an interface unassigned as part of the “setup” process (which is what we have), but this issue appears to contradict that option as it wont start without one.
Ok, went deeper and started looking at the code on github. I’m not 100% sure where the blue interface gets set other than in ‘setup’ as it doesn’t appear that ‘zone config’ checks/cares if it’s set, however, because the networking/any script (see below) checks and does a validation, this fails because the blue interface is not set via the “ip link” command…
Which is verified with below commands and non-existance of blue0
“ip link show blue0”
Device “blue0” does not exist.
“ip link show green0”
2: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:0d:b9:49:be:dc brd ff:ff:ff:ff:ff:ff
“ls /sys/class/net/”
eth1 green0 lo red0
This confirms that failure is due to a network adapter not being configured for the blue interface (which we basically already knew, but at least it’s confirmed).
I spent a few hours going through the commits looking for where the code was changed that could have affected this outcome, and other than a move of some functions to the network-functions.pl file, I’m not seeing anything specific (keep in mind there are a LOT of commits and I have no idea which file(s) is the cause or when it was modified). The Devs know this code inside and out and i’m sure would be able to pinpoint how to either prevent the validation of the vlan network from failing, or to register it as an interface somehow. I’m tempted (and may) modify my config files to force the blue interface into a state where it won’t fail and will launch, but doing so doesn’t mean it’ll work… so… I’m hoping someone with more knowledge of what’s going on can take a look.
Also, as a side-note… I think I found another “bug” (or at least a duplication of code) as part of my poking around ( @ms, @bonnietwin, or others). In same linked file above, lines 30 & 34 (plus additional lines under each other colored interfaces), the “DEVICE=”${******_DEV}" lines are duplicated.
I’ve come to the pretty obvious conclusion that this is an undesired software configuration, so I’ve submitted a bug report for it. Hopefully we can get that functionality restored again. https://bugzilla.ipfire.org/show_bug.cgi?id=12676
@gitarman94 , thanks a lot for your analysis.
Yes this is a strange bug and as far as I noticed it, it was not directly introduced by an update.
After an update I always do a basic system check and I’m sure I would have noticed a non functional WLAN. It just happend so time after, but it seems related to core 155 and above.
So, I really don’t know what the cause might be, perhaps some kind of race condition during startup.
Hey @marco, I think we may have found and fixed the issue. I’d love to have you test the solution that Michael had me do over in the bug report. You can read the entire thread, but basically, you’ll probably have to replace a file on your system with a fresh copy from the git repository.
So, the contents of the file found (here) needs to replace the contents of the same file on your system. The file in question (“network-hotplug-vlan”) is found in the ‘/lib/udev/’ directory). Once contents replaced, you’ll then need to have one of the lines additionally modified to match the directions Michael gave in comment #3. Once the update has been made, you could start the blue interface manually, or reboot the device (I would probably just reboot it). Your system should now be fixed, but please test and let us know what actually happens so we can confirm if that’s the solution to the issue.
