Posted: Wed Nov 24, 2021 3:04 Post subject: [SOLVED] WLAN with VLAN bridge issues: MAC / HWaddr
Is there currently an issue related bridging VLANS and WLAN interfaces (eth1, eth2)? I couldn't find anything in the bug tracker (build: 47097).
Attempted to move eth1 and eth2 to a new br1. Assigned those in the ui; confirmed ifconfig and swconfig. Configured it no different than I would if it were on br0. Double and triple checked iptables and DNSmasq config.
However, I can't seem to get it to work. WLAN clients on br1 have connectivity. VLAN clients on br1 obtain an IP, but the DHCP server address returns x.x.x.0 instead of x.x.x.1... gateway and DNS servers are assigned correctly. No client connectivity, not even L2?
The alternative obviously, is to use VAPs, if it is indeed an issue. I could do some debugging, but it's taking longer than expected, and I need sleep.
Strangely, eth1 and eth2 sometimes disappear in the UI bridging config (under assigned interfaces), then reappear, sometimes 1 will disappear and not reappear in the UI again until reboot. Not sure what's up with that. Probably a UI-only issue.
Hmmm. It could be related the br0/eth0 and br1/vlan4 MACs. Can't remember if those need to be unique.
edit: I messed that up. Of course br0/br1 need unique HW addresses, since they are separate L2 interfaces. I was thinking of whether eth1/eth2 needed uniques vs. br1/vlan4, and they do as well, from recollection.
Last edited by testimap on Wed Nov 24, 2021 6:57; edited 4 times in total
I haven't tried shifting eth1 and eth2 back to br1 again, but I can confirm that bridged VLANs work.
The issue seems to be that the UI does not automatically assign a unique MAC (HW) address to new bridges.
In fact, the HWaddr field is not present until after the new bridge is created, and the page must be subsequently refreshed in order for the field to become editable.
The bridged VLAN which was created must also be manually updated with this new MAC address.
Well, I can now confirm that was the issue - eth1, eth2 and vlan4 currently bridged on br1 and working as intended.
Newly created bridges should always be assigned a new HWaddr. Since it's a UI issue, and not of immediate 'concern' - although, maybe 'priority' would be the more correct term.
Maybe drop a note in the create group to indicate that all bridges should be assigned unique MACs manually, and corresponding bridged physical (not wireless) interfaces updated accordingly, after refreshing the interface. It's quite easy to miss that since the UI is not immediately updated. Even if it were, I doubt anyone manually checks the MACs, or even knows how L2 works.
Last edited by testimap on Wed Nov 24, 2021 6:53; edited 1 time in total
Although, on the positive side, I'm glad to to report that nothing actually broke while I was messing around with the switching, bridging and VLAN UIs.
I'd also like to test that theory, or just rummage through the SVNs, but I need to research each build before attempting to flash it. I'm... currently busy as hell, not least with win10 printer issue which took 2 days to fix.
You could test it by simply adding a new bridge, and refreshing the page, and check whether it was assigned a new HWaddr. Doesn't seem like a BCM issue either.
If you can confirm the HWaddr is not unique on another device, then it should probably be classified as a bug and catalogued.
Although, you'd need a design a function to update its linked interfaces when the HWaddr is changed, and another to update an interface's assigned HWaddr when its bridged/unbridged radio is toggled. Caveat; wireless interfaces, maybe just VLANs.
