Thanks for this, I think I am seeing same thing; wish I saw this sooner.
I upgraded to SNAPSHOT r21753+10-2a3283643c yesterday AM (from a 5.10 version from november 2022)... I lost (what I though twas) was bridging between a wireless clients and a wired client that are in the same network, same vlan ( VLAN 20), same firewall zone. The wired client can't see the wireless clients. traceroute reports host unreachable and vice versa, wireless clients cant reach the wired client.
But (because I have some specific firewall routes VLAN 10), I can reach both the wired and wireless clients on VLAN 20 individually from VLAN 10. And yes, I also have isolation disabled on the VLAN 20 wireless.
I only have one wired client on that VLAN20, and since it can see the router I assumed there was something going on between the wired vlan port and the wireless network (both on the same br-vlan.20 device). I don't think I tried going from wireless client to wireless client on that vlan.
I assumed that this a was DSA VLAN configuration problem related to the bug fix on the switch (no longer acts like a hub with traffic on all ports) since the 5.10 based build worked with the same config. I was thinking maybe my config was working (by mistake) due to the hub behavior, and then broke when that got fixed).
I am also getting some different vlan debug prints (on a different vlan), so I was trying all kinds of VLAN and bridge changes yesterday to no avail. (Yes, to get around the other DSA bug, I only have one bridge with all the lan ports in it and all vlans assign in that one bridge.)
tonight I can check some of my other wireless clients (on different VLANS) to see if they are also isolated.
Hello and thanks for reporting, I only have one VLAN in place and is for WAN interface. I found that the behaviour is not consistent, I can reach some members of the wired network from wireless but most are inaccessible.
From my testing yesterday, it seemed like I could get a one time ping through from the wired client to the wireless clients (the first ping out of the 3 or 4 ping sequence); after that it was full fail. Ore a single traceroute would work, and after that it was host unreachable. And that first ping seemed to be only occasionally and maybe after I reset a device/interface/restarted a service (while I was trying config changes).
Hopefully something turns up or I may have to rollback as its pretty broke for that use case.
Anyone else seeing this client isolation issue? I went back and double checked, I upgraded to the current build from this build tracks r20932, circa 10-15-2022 which was still 5.10 kernel based. I've searched around for any possible similar posts/issues but not finding much.
I guess I can start downgrading through the list and see where it broke, but thats a process. But the impacted wireless client devices are not much use without connectivity to their wired controller.
Well, I tried the newly latest build from 1-19-23, and went back as far as whats in the build dir to r21388 (12-4-22), problem still exists. I was previously running r20932 circ 10-15-22, which was maybe 3rd or 4th last 5.10 based build.
You don't archive a larger list of your older builds somewhere do you? I can't try your last 5.10 build otherwise, but I guess its a decent assumption that the isolation issue came along with the 5.15 kernel; dang.
Yeah, thanks. Client communication also works on my primary lan (vlan=1) between wired and wireless clients. Im also using WRT1900ACS(V2)
The problem is on my iot VLAN and LAN to WLAN on that network. So maybe something more related to the multiple vlans on the switch bridge, and/or multiple ssids.
Yes! I have a WRT32X running the latest snapshot and I have this same issue. Like you, I have a couple VLANs running on the switch. I did a tcpdump on a wired device and I see that the VLAN id is not being untagged from the ethernet frame by the router. Interestingly, as you noted, the first frame is properly untagged but the remaining frames are not and so the wired device ignores the traffic. Packets which originate on the router do not have this issue. It only appears to affect wireless deices which are attempting to send data to wired devices in the same VLAN. I have not checked devices which communicate across different VLANs yet.
My "fix" was to use a managed switch to untag the frames so everything downstream would listen and respond.
Thanks for the confirmation. Wow, thats very interesting. Do you have enough detail captured to submit a bug for the issue?
What is also curious is that the issue is NOT occurring on my primary vlan (VLAN1) on br-lan.1, which also has wired and wireless clients Thats probably why a lot of people aren't seeing it, you need both wired and wireless clients, and for some reason, not on the lan.
Since the router primary ip address is directly on the lan, maybe thats difference since packets don't have to traverse another interface ip to the router (like my guest or iot vlans do).
I spent the weekend re-configuring and testing different settings and configs, cleaned out anything extraneous, to make sure it wasn't setup, but my config looks pretty straightforward and in line with other posted configs.
I've never submitted a bug before, so I need to look into what is involved. Honestly, I initially felt there was a new configuration change that I missed when upgrading from release to snapshot. Like you, I spent considerable time checking and re-checking config files. I need to systematically check each flow path and log what works and what does not. I find it very odd that a single packet will occasionally make it through unscathed.
I have a "Guest" network using VLAN3 and "Lan" using VLAN4. Each VLAN has a dedicated switch port (port 3 and 4 respectively) which should untag the traffic on the way out. Both networks have their own subnet and firewall rule assignments. Looking at it now, I think I can do what I need without VLANs, because I don't need combined VLANs on a single port. I need to sit down and work through it all.
I have confirmed an external managed switch this also fixes the issue for me.
Even though the physical port (lan 1) is set for egress untagged, packets are leaving the port tagged as you note. Attaching a managed switch between the lan 1 port and the wired client, with ports configured for that vlan and egress untagged, and things start to work.
The router still emits occasional untagged packet(s), still haven't seen the rhyme or reason here, unless there is something ageing out and re-failing itself after an untagged emission.
Until this gets fixed, I guess its a can't beat em, tag em situation. Next, I'll try just configuring the port as a full trunked (tagged port), and do all the vlan separating and untagging on the external managed switch.
I set this up tonight on the latest build, also works fine.
So there's something broken in 5.15 VLAN handling when physical lan port and wifi interfaces are in same network (and same vlan)... with exception of primary lan vlan 1... or primary lan in general.
Thanks for submitting. I just looked at your configuration. You lan network(vlan4) is the one thats broken, thats interesting.
Since your guest network doesn't have isolation enabled, are you able to check your guest network, assuming you can add a wired port on guest? Your guest vlan (3) is lower than your lan vlan(4). In my case, my lan vlan (1), which works properly, is lower than the problem vlan (20), so I'm curious if (only) the lowest/first in vlan works.
running the 19/jan r21861+12-5dee596501 build and it's really quite sweet..
Previous builds I tried wouldn't let me run various add-ons, but this one just works, and does it well...no rabbit holes so far!
I even managed to get pbr running straight from install..(not sure if that was a pbr or a new kernel thing, but either way, I'm thankful)
another thumbs-up for divested! (fyi, pbr is a utility that allows you to set Policy Based Routing)
none of the extra bells and whistles that should be available in this build have been tried, but it just dropped in nicely as an upgrade, so I'm a happy camper!
