Hi all. I have a two-device setup with a main router and a dumb AP. There are three VLANs, LAN, IOT, and Guest, and all three have associated Wireless channels on the two routers. WLAN roaming is set up and works perfectly.
I have phones, tablets, and a Chromecast on the Guest network, and as it happens, the TV room sits almost equidistant from the two routers. That means that devices switch from one router to the other frequently and a little unpredictably.
It seems to be the case that when a tablet and the Chromecast both happen to be connected to the same router, everything works fine, but when one of them decides to roam to the other router, they lose connection, even though they're on the same VLAN. I didn't quite expect this, but I suppose the ability to see other devices on a wifi connection is limited to devices which are connected to the same actual router, irrespective of the VLAN/roaming situation.
Is this to be expected? If so, has anyone else encountered the problem and found a workaround? I'm thinking of either turning off the Guest network on the dumb AP or perhaps decreasing its radio power so that there's one obvious winner in the TV room.
Roaming should be transparent and if you've got things properly configured, it should all happen on the same L2 network.
How are the two routes connected to each other physically (LAN > LAN, or LAN > WAN)?
Please share the configs from each device (make it clear which is the main router and which is the dumb AP; only the network and wireless files are required for the dumb AP):
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I'll post configs when I get home tonight. The roaming itself works seamlessly; as I move between one router and the other, I get a clean transition. The only oddity is that devices lose contact with the Chromecast if they roam to the other device, even though they're on the same VLAN.
The two devices are connected over a single trunk carrying all three VLANs. The VLANs are all working perfectly (connecting devices get the right IPs for the right networks), and devices on the Guest wifi get IPs on the same subnet irrespective of which router they're connected to.
Is there a reason you've enabled vlan_filtering? It should probably be disabled unless there is a specific need.
Remove the option type 'bridge' line from your IOT network
eth0 should not be part of the bridge... only eth0.3. Remove eth0 and also delete bridge_empty
Same deal here... remove eth0, bridge_empty and vlan_filtering (unless the filtering is needed).
I would highly recommend turning off 802.11r. Many devices just don't play well with this standard. But you can do this as a last resort after fixing the other issues.
You're missing country codes on both radios... and for the 2G radio, you should use channels 1, 6, and 11. Don't use channel 5 or any of the intermediate channels.
You have wifi client isolation turned on for your lan... if both the Chromecast and your phone are on this AP, they will not be able to communicate. Turn isolation off.
Now, on the dumb AP...
remove eth0 and bridge_empty from these bridges:
Typically, the non-management networks (i.e. the guest and IOT in your case) do not have an address. Change them to proto none (i.e. unmanaged) and remove the hostnames.
This is overlapping with the other AP when using VHT80. Take a look at the channel assignments and make sure you select non-overlapping ranges. You should also try to avoid DFS channels in your location.
I need to map these settings to the LUCI configuration so I understand what I got wrong. The only place I can find "Bridge VLAN filtering" in LUCI is the configuration of each of the six bridge devices (three on each router), and in LUCI they all show as off, so I don't see how that config is set in the config file. Is there somewhere else in LUCI that would turn it on?
I followed One Marc Fifty's videos and some other tutorials for OpenWrt 21 to set things up, assuming that since the devices are Archer C7s that don't support DSA, I would have do do things the old way using bridges. The interface setup in LUCI requires you to choose a Device, and I understood that a bridge device should be set up for the VLAN and that should then be chosen as the device in the Interface setup; I don't know how the option type 'bridge' setting relates to the LUCI interface there. My basic understanding was that VLAN functionality requires:
The VLAN setup itself on the switch, along with port assignment and tagging as needed;
A bridge device for the wired ports;
An interface mapped to the bridge device; and
A wireless network attached to the interface.
And this is working very well for all three VLANs and for wifi, except for the problem with the devices on the Guest network losing track of each other. But if there's a simpler way to do it for these C7 devices (I have two v5s, two v4s and a v2), then I'd be glad to know how.
bridge_empty I guess comes from the setting "Bring up empty bridge", which I figured couldn't do any harm and might do some good; the explanation "Bring up the bridge interface even if no ports are attached" suggested to me that I should do that for any bridge device that didn't have any physical ports mapped to it (which, except for the trunk port, is the case for the Guest network).
The recommendation to use 802.11r is at the heart of One Marc Fifty's tutorial on setting up WLAN roaming, and it is working with the devices I've tested with, but it's possible it's problematic for the old Chromecast. I can experiment with that.
I'm very puzzled about the option isolate '1' setting, because in LUCI, the LAN wifi does not have this option selected on either router. More importantly, neither does Guest on either router. So there's something screwy going on here. LUCI settings don't appear to be reflected in the config files unless there's some other place to set this that I haven't been able to find.
The only place I know of in LuCI for this setting is Network > Interfaces > Devices > Configure < Bridge VLAN Filtering -- make sure it is off for all of your devices.
DSA uses bridge-vlan as its method or handling the ports. But swconfig just uses the switch stanzas to define the VLANs themselves. If you'll be associating a network interface with more than one physical device (i.e. ethernet + wifi or two wifi interfaces), you need to setup a bridge with list ports 'ethx.y'. Then, the interface will use the newly defined bridge device.
The option type 'bridge' option should not be used anymore in a network interface stanza. I'm not sure where the LuCI option is for that, so I'm not sure how it ends up in some users' config files.
802.11r (and k and v) are not required for high performance roaming. Proper tuning of your wifi radios is required, though. And this is true regardless if you use 802.11k/r/v or not. I like this video that explains the process (it's done with Unifi, but the same concepts apply to all wifi APs as long as the settings are exposed to the user). The additional standards are supposed to improve the performance... and sometimes they do. But other times they cause problems when a client device doesn't have the features implemented (or if they are poorly implemented).
AFAIK, it's pretty hard to get LuCI out of sync with the underlying config files, but I presume it could happen under certain circumstances. You can direcctly edit the text files and/or use UCI syntax on the command line to fix issues for which you cannot find the LuCI option.
Thank you again for all this really helpful info. I'll spend a few hours at the weekend experimenting to see what effects each of the changes make, and report back on what I learn in case anyone else is in the same situation.
@psherman This solved my problem. I'm not sure which of the changes was the crucial one, but I worked through each of them. The only thing I didn't change was the setting for vlan_filtering, because a) although it's set to on in the configuration files, it's not checked in the LuCI interface. I'm not sure exactly what it does, so I don't know whether I need it or not. I found another post on the forum in which a user suggested that this setting in was decoupled from the LuCI interface (Luci VLAN filtering), so I suspect this is a bug.
If anyone knows of a good explanation of what vlan_filtering actually does, I'd be glad to know; then I can decide if I need it or not.