I already did. Same results.
Thanks. I just tried the script Brume3-AddVLANs_inLANzone.sh, but it does not work. The results are the same I am experiencing.
This script keeps LAN1 just for VLAN1, and set LAN2 to be used as trunk (tagged and untagged). LAN1 keeps working (just untagged VLAN1) as expected. LAN2 that would be the trunk network with this script, does not work. VLAN1 (untagged) does not work in LAN2. Bottom line the same results I am experiencing.
This is what has been reported by some other people in Reddit. It seems that Brume3 is not able to keep VLAN1 untagged on the same port with tagged VLANs (basic trunking).
1 Like
Also:
1 Like
Thanks. My 25.12 build is about to finish, I will be testing it in the next hour or so. Since the RTL8366UB switch driver is not included, my expectations that VLAN will work with 25.12 are low. However, I would expect VLANs to be working with the GL.iNet firmware (which does not seem to be the case).
Yes, i’ve read your posts..
My apologies, my responses are quite late as, apparently, everything i’m posting is (still) moderated.
But having this funtionality working with the vendor fw at least would be my expectation also.
1 Like
The way the bug is described in the reddit post suggests that it will work if the untagged vlan is the higher vlan ID. You could try swapping out vlan 1 for a higher number and use that as untagged and then use lower numbers as tagged until a proper fix is available
As its untagged it doesn’t really matter which vlan tag you use on the Brume.
1 Like
Excellent observation. Right now I am finishing testing 25.12. My findings after some quick testing:
- As reported, clients connected to LAN1 are not able to connect to clients connected to LAN2, and vice-versa. However, routing from LAN1 and LAN2 to WAN works OK.
- VLAN is not working. Tagged packets are not going out to LAN1/LAN2. Only untagged packtes.
I will now revert back to factory firmware and try swapping VLAN 1 for a higher number.
2 Likes
I changed the untagged/default VLAN ID to “100”. Applied all changes, network connectivity remained as expected (screens 1 and 2 below).
As soon as I create a second tagged VLAN (now with ID 50, lower than 100) and apply the changes, I lose network connectivity on the untagged VLAN (screen 3 below).
These are the same results I observed previously, and unfortunately using a lower VLAN ID for the tagged VLAN did not solve the problem.
1 Like
BTW, my experience with VLAN tagging in OpenWrt is mostly post-DSA adoption.
I am not used to the old “swconfig” that Brume 3 firmware uses.
I find it a little confusing in the example that I replaced the default VLAN 1 by VLAN 100 using Luci Switch UI. However, eth0.1 is still showing up, despite of the new eth0.100 now being used by br-lan as shown in the two screens below.
It is even more confusing since swconfig dev switch0 show is showing VLAN 1 (original), VLAN 2 (unused?) and VLAN 100 (the one I created using Luci) - BTW, port 17 is CPU port:
root@GL-MT5000:~# swconfig list
Found: switch0 - RTL8366UB
root@GL-MT5000:~# swconfig dev switch0 show
Global attributes:
enable_vlan: 0
(...)
VLAN 1:
info: VLAN 1: Ports: '0117t', members=20003, untag=0003, fid=0
ports: 0 1 17t
VLAN 2:
info: VLAN 2: Ports: '117t', members=20002, untag=0002, fid=0
ports: 1 17t
VLAN 100:
info: VLAN 100: Ports: '0117t', members=20003, untag=0003, fid=0
ports: 0 1 17t
I will try to manually edit /etc/config/network and change eth0.1 to plain eth0 and see if VLAN 1 goes away.
EDITED: editing /etc/config/network and renaming device eth0.1 to plain eth0 didn't break anything (since I am already using VLAN 100), but VLAN 1 is still showing up in swconfig.
Oooof.. feel like I’m walking into the line of fire.. but as an openwrt greybeard, this thread hurt my eyes. Going to 1-by1 so you can all tell me to piss off.
First.. a lot of focus here on the wrong thing. Not a VLAN id order bug. Swapping ID order won’t do a damn thing. @dsouza showed it with (untagged 100 + tagged 50 = dropped path). The issue is with the switch chip. (fyi @dsouza- swconfig has been the owrt thing for ~18 yrs. DSA didn’t make mainstream outside marvell until covid-ish).
The LAN ports sit behind the RTL8366UB. The WAN (eth1) is on the SoC PHY and bypasses the switch entirely (whoosh). The LAN ports (0+1) trunk through the cpu port (eth0.1 > br-lan). There is NO 802.1q on the chip in any of the fw.
If you dig into 4.8.6 oem, the switch driver is the “rtl8366ub” swconfig module. The uci calls for the vlan: network.@switch[0].enable_vlan='1’
BUT.. there is zero in runtime code to do something with it. v4.8.6 receipts:
root@RTH-HOME:~# swconfig dev switch0 show | grep enable_vlan
enable_vlan: 0
root@RTH-HOME:~# swconfig dev switch0 set enable_vlan 1
root@RTH-HOME:~# swconfig dev switch0 show | grep enable_vlan
enable_vlan: 0
The “set” changes nada. There is no hw 802.1q from the userspace. In this version, there is zero untagged/tagged VLANs on a physical LAN port.
On the GL PR submit - it’s not a driver. It’s 4 files and not one of them a “.c”. The only functionality is WAN>LAN (zero switch). It’s mostly just a stub to get the device into the tree so it can be built on fully later by someone (hopefully upstream - let’s all get to it!).
TL;DR - until someone actually writes the driver (volunteers?) we get no VLAN trunking on any of the stable/beta/owrt firmware. No port isolation, no splitting a physical LAN port into vlans. Full stop.
Can’t say exactly why the PR is unmerged upstream as it just shows conflict, but i did some poking in the SDK and can make some guesses (and now my GL friends are going to hate me for calling them out):
Probably because the source isn't anywhere public (love you folks, but WTF with GPL?? - binary distribution requires source @bruce @will.qiu ). The opkg on the device says the package is kmod-rtl8366ub v5.4.281+1.0.0-1 - sourced from feeds/glinet/gl-rtl8366ub-driver, but that feed name isn't even declared in the MT5000 SDK's feeds.conf.default. << this is not okay, please prove me wrong.
In summary: GPL source publication > driver development > VLANS
8 Likes
To try and understand this better, does this mean the apparent tagging of vlan1 towards the SoC port is actually a lie?
Or that bit ‘works’ but is essentially useless as you can’t do anything with the physical lan ports anyway currently?
Is there no way the switch chip can just dumb flood frames and pass vlans tags even if it can’t be selective and filter per port? (I don’t have a spare device to play around with too much in this regard) or is the setup here not even allowing that?
@oorweeg - Good questions. I had to check. Unfortunately the Brume3s I have access to are remote and being used just as VPN servers so there's nothing currently connected on the LAN ports for me to verify against. Given we can't see the actual *source code* (separate reply incoming on that), then I'll post some tests that hopefully someone here could run to fully verify.
Is it a lie? Partially. Here's what I can see - the driver DOES push the VLAN setup to the chip at boot w/dmesg receipt:
[rtl8366ub_sw_set_vlan_ports] vid=1 , mem=20003,untag=3
What I can't tell you is whether the chip actually applies it when setting "enable_vlan: 0”. With no devices on my unit's LAN ports I have no RX to observe.
Can it dumb-flood & tags pass through transparently?
Most likely yes (again, can't physically test to verify). The standard swconfig on this chip should be VLAN-unaware port-based forwarding and the 802.1q should flow through untouched. So you can do pure Linux VLAN trunking on top of that (eth0.10/20) with separate bridges and fw zones. Since you can't split it on the LAN ports though (no isolation), you'd need an 802.1q aware downstream device to actually break these out to physical ports (managed switch) and make it practically useful.
If anyone here can test hands-on, here's what would help us settle it. These would be non-destructive and non-persistent methods (a quick reboot clears everything).
1 Broadcast baseline - plug regular clients into LAN1 & 2 and confirm they can ping each other as a sanity check.
2. Then, with a client on LAN1 generating traffic, test if the CPU port actually emits VLAN tags (run on router CLI):
# should show "off [fixed]":
ethtool -k eth0 | grep rx-vlan-offload
# packet dump:
tcpdump -e -nn -i eth0 -c 20
Then look for "ethertype 802.1Q" followed by "vlan 1" in the output headers. If this DOES exist then the chip honors the "network.vlan_lan.ports='0 1 17t'" setting from UCI. If this DOES NOT, then chip is in pure flood mode.
3. To test actual tagging passthrough, then plug a managed switch into the Brume LAN1 port and set it as a trunk carrying VLANs 10 + 20 and generate some tagged traffic.
tcpdump -e -nn -i eth0 vlan
Then look for "802.1Q" and "vlan 10 or 20". If this exists then the chip is passing the tags transparently (from LAN > CPU). To fully verify it's also flooding / broadcasting to the LAN2 you'd need to stick something on it to sniff as well, but it's probably a safe bet.
4. I am able to verify that Linux can push tags out to the CPU port.
root@RTH-HOME:~# ip link add link eth0 name eth0.99 type vlan id 99
root@RTH-HOME:~# ip link set eth0.99 up
root@RTH-HOME:~# ip addr add 192.0.2.1/30 dev eth0.99
root@RTH-HOME:~# tcpdump -e -nn -i eth0 vlan 99 -c 5
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:56:48.666 f6:61:65:fb:e5:5a > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 162: vlan 99, p 0, ethertype IPv4, 192.0.2.1.5353 > 224.0.0.251.5353: mDNS
22:56:48.917 f6:61:65:fb:e5:5a > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 162: vlan 99, p 0, ethertype
5. So now the last would be to see if the tags make it all the way out through the ports (CPU > LAN)? To fully verify, you'd need a sniffer (eg. a PC running tcpdump) attached to one of the LAN ports, then run the example below:
(Note - do not change this example to 192.168.8.x or any actual in-use subnet)
ip link add link eth0 name eth0.99 type vlan id 99
ip link set eth0.99 up
ip addr add 192.0.2.1/30 dev eth0.99
sleep 5
ip link del eth0.99
On the receiving PC, run "sudo tcpdump -e -i -w capture.pcap” and post up results here. This would be the full end-to-end receipt.
@bruce @will.qiu - tagging for awareness.
On the GPL topic.. I'm posting this separate b/c it's a GPL compliance issue that is worth calling out clearly after looking at the missing SDK source last night.
As it stands today. Every Brume3 being sold today is a GPL violation.
TL;DR: The shipped "rtl8366ub_mdio" is declared GPL by GL itself, yet the source isn't in any GL public source feed. That's a GPL Sect 3 obligation that isn't being met and no Realtek NDA can change or override it.
Receipt 1 - (pulled directly from a v.4.8.6 Brume3):
root@RTH-HOME:~# modinfo /lib/modules/5.4.281/rtl8366ub-mdio.ko
license: GPL
depends: swconfig
MODULE_LICENSE("GPL") - GL's own declaration.
Receipt 2 - swconfig itself exports its core API as GPL-only:
EXPORT_SYMBOL_GPL(register_switch);
EXPORT_SYMBOL_GPL(unregister_switch);
A non-GPL module physically can't link to those as the kernel will refuse at load. The rtl8366ub_mdio loads fine on every Brume 3, so the linux kernel agrees with what GL has declared.
No NDA can override the GPL.
Neither Realtek nor GL holds copyright on the upstream GPL code rtl8366ub_mdio is built on. The swconfig framework and the rtl83xx swconfig lineage are GPL by upstream copyright (the Linux & OpenWrt contributors). Modifying them produces a derivative work bound by GPL.
A private contract - NDA or otherwise - between two non-copyright-holders can't override the upstream GPL grant. The GPL actually covers this explicitly:
§6: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
§7: "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."
There is zero room about this. You cannot legally sell or distribute a single Brume3 without the source publication. There is no alternate path.
As an aside - there are limited cases where NDA-restricted binary blobs ARE legitimate, but that is only for on-chip firmware (wifi .bin files, regulatory tables, GPU shaders). Those run on separate hardware, not in the kernel. Linux-firmware handles this openly; but this exception covers ONLY the on-chip firmware. It does NOT cover host-side GPL kernel modules like the rtl8366ub.
Right now GL needs to either:
- Immediately (already way past due) publish the source in gl-inet/gl-feeds so the SDK pulls it, or
- post a written offer here or in release notes providing a written offer (valid 3+ years) to provide source upon request
If I'm missing something and one of these is already done, please show me, but this needs to stop happening. Violating linux copyright is both illegal and an extremely bad look.
8 Likes
I appreciate the long post (
) and found it really interesting, but I'm assuming if that happening with the brume3 I assume it's happening with all GL offerings too.
The elephant in the room it's whos going to enforce the right thing to do and how?
Okay, after hearing all those things, I may never consider buying GL.iNet products again.
1 Like
Now you backpedaled?
let see what admin/dev says.
GPL is flawed and always has been...
problem with it is that almost none is following it properly, and I still think they should, you don't want to become vulnerable to someone (1%) who claims up their rights and can freeze projects, due that grey area it is possible and that is bad.
There are so many router brands running a offshoot version of OpenWrt but they do not ship a verbatim of the license, nor point to the sources of the main project which often is noted in those clauses.
About the drivers I think I don't see a issue aslong it is threated as a extension part which it does, they aren't forced to do anything, it may does not have to comply, patching is also such thing.
But lets have those discussions on the OpenWrt forum please.
@xize11
“GPL is flawed and always has been..”
GPL is the reason linux runs ~80% of global compute infrastructure, the reason we have OpenWRT and the reason we have cool projects to play with (anyone use docker here?).
This is not a driver extension.. that would the binary blob part I mentioned. This is a driver built directly on others’ GPL’d code. Other vendors have done it, have been sued for it, or been publicly called out. The entire reason we have OpenWRT today it because Linksys got caught doing this with the WRT54G and Cisco/Linksys were getting buried by public shaming - so they released it.
GL also chose to build their company’s router stack on this exact work - so the irony of repeating the mistake would be **strong.**
I am a GL business partner and do a ton of router sales and deployment for GL products. It’s exactly why I want the dev department to be aware they can’t get lazy about it and cause a WRT54G episode for GL. I want them to continue to succeed. Transparency will always be a key part of that.
@gfondeur - it has happened in the past, and this is why I’m calling it out here now. It’s become tiring to continually have to request code piecemeal after reminding them. The devs need to get it together and realize they can’t ship a single router or put a firmware on the DL center without accompanying GPL source already being published or offered. I’m not going into other examples as I hope this is reminder enough to fix it. I honestly believe it’s just a misunderstanding of the GL devs that GL will easily fix soon.
2 Likes
And yet the problem lays here why I want to disagree.
If they download the source at compilation runtime defined from a Makefile only, it comes close to patching, we are talking about compilated data, same how binary blobs are offered, the end is a image with only the compilated data, and the source of the driver never was in their repo but only downloaded via the Makefile only present as external factor, this why I think it cannot be enforced that easily as it was not part of the source, but part of the process, you can't GPL only a text file with metadata and then over a external repo, that is why I make a comparison with patching.
Though i'd agree if the driver is GPL code which I don't know, that they should disclose it 100% agree on that.