Br-lan behaviour hinders Wifi Roaming

Dear All,

I have a problem with with roaming Wifi clients and I nailed down the cause, but I need advice for the best solution. So here is the current situation of my Omnia Turris 2020, starting of with my network config:

# cat /etc/config/network
config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix xxxxxxxx::/48'

config interface 'lan'
    option type 'bridge'
    option proto 'static'
    option ip6assign '60'
    option gateway '192.168.5.254'
    list dns '192.168.5.254'
    option _turris_mode 'managed'
    list ipaddr '192.168.5.1/24'
    option ifname 'eth2 lan0 lan1 lan2 lan3 lan4'

# cat /etc/config/wireless
config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option macaddr '04:f0:21:42:1c:b2'
    option htmode 'VHT80'
    option country 'DE'
    option channel '48'

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11g'
    option macaddr '04:f0:21:45:b9:da'
    option htmode 'HT20'
    option channel '6'

config wifi-iface 'wifinet0'
    option ssid 'WiFiName-5G'
    option device 'radio0'
    option mode 'ap'
    option network 'lan'
    option key 'WiFiPassword'
    option encryption 'psk2+ccmp'

config wifi-iface 'wifinet1'
    option ssid 'WiFiName'
    option device 'radio1'
    option mode 'ap'
    option network 'lan'
    option key 'WiFiPassword'
    option encryption 'psk2+ccmp'

This should be a pretty basic configuration. If a wifi client is directly connected to this device, the bridge forwarding table (FDB) looks like this (I grep’ed for a specific MAC of a wireless client):

# bridge fdb | grep 99\:d5
26:41:45:15:99:d5 dev wlan0 master br-lan

Nothing special here, simply shows that client communicates over interface wlan0 with my Omnia. Now, if this device leaves the room and roams over to another access point, the FDB looks like this:

# bridge fdb | grep 99\:d5
26:41:45:15:99:d5 dev lan1 master br-lan
26:41:45:15:99:d5 dev lan1 vlan 1 self

This transition to the next AP works seemlessly. The other AP is connected port “lan1”, so this is also fine. But as you can see, this introduces the additional “dev lan1 vlan 1 self” line. The real problem occures, if the wifi client walks back to the omnia, because the FDB then looks like this:

# bridge fdb | grep 99\:d5
26:41:45:15:99:d5 dev lan1 vlan 1 self
26:41:45:15:99:d5 dev wlan0 master br-lan

As you can see, the new introduced line stays as it is, while the other line goes back to what it should. The wireless clients has no connectivity at all for about ~250 seconds. After that, the “dev lan1 vlan 1 self” line disappears and the clients starts working again. So this line has a timeout of some sort.

My question now is, why I see this behavior and how can I fix it? Can you guys tell me, what this line even means and why it is talking about “vlan 1”, although there is no vlan configured?

Thank you very much in advance!

vlan 1 is the default vlan so consider it no vlan.

Thank you for your answer! It must have been almost the same time when I found a solution, but I cannot explain, why it helps. The solution was to add the following interface to “br-lan”: eth1.1
This adds vlan 1 to the eth1 interface. I choose eth1, because the lan1-port, which the other AP is connected to, sits behind eth1. Where did I find that out? Check this command:

# ip link | grep " lan"
5: lan0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
6: lan1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
7: lan2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
8: lan3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
9: lan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000

So I do not know, if the documentation really shows, how OpenWRT/TurrisOS works: https://docs.turris.cz/hw/omnia/omnia/#network-interfaces
eth0 and eth1 seem to be equal, but TurrisOS gives me a different impression. What backs my theory up, is that in Recovery Mode 5 (ssh access at 192.168.1.1) you can only connect, if you plug the cable into lan4. This makes sense, because this port has a dedicated backend (eth0) on the SoC.

Anyway, this is my currently working br-lan from /etc/config/network:

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ip6assign '60'
        option gateway '192.168.5.254'
        list dns '192.168.5.254'
        option _turris_mode 'managed'
        list ipaddr '192.168.5.1/24'
        option ifname 'eth1.1 eth2 lan0 lan1 lan2 lan3 lan4'

I started a topic with (I belive the same issue) here:

Could you please check your connectivity BETWEEN DEVICES connected with cable using simple ping command? Do you get pings >10ms on the cable and possible timeouts?

Client1 (Win10) <–> Turris1 <–> Turris2 <–> Client2 (Ubuntu 16.04)

Client1 to Client2:

ping -n 10 192.168.5.105
Ping wird ausgeführt für 192.168.5.105 mit 32 Bytes Daten:
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.5.105: Bytes=32 Zeit<1ms TTL=64
Ping-Statistik für 192.168.5.105:
    Pakete: Gesendet = 10, Empfangen = 10, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Client2 to Client1:

ping -c 10 192.168.5.161
PING 192.168.5.161 (192.168.5.161) 56(84) bytes of data.
64 bytes from 192.168.5.161: icmp_seq=1 ttl=128 time=0.603 ms
64 bytes from 192.168.5.161: icmp_seq=2 ttl=128 time=0.671 ms
64 bytes from 192.168.5.161: icmp_seq=3 ttl=128 time=0.791 ms
64 bytes from 192.168.5.161: icmp_seq=4 ttl=128 time=0.746 ms
64 bytes from 192.168.5.161: icmp_seq=5 ttl=128 time=0.681 ms
64 bytes from 192.168.5.161: icmp_seq=6 ttl=128 time=0.581 ms
64 bytes from 192.168.5.161: icmp_seq=7 ttl=128 time=0.762 ms
64 bytes from 192.168.5.161: icmp_seq=8 ttl=128 time=0.731 ms
64 bytes from 192.168.5.161: icmp_seq=9 ttl=128 time=0.715 ms
64 bytes from 192.168.5.161: icmp_seq=10 ttl=128 time=0.733 ms

—- 192.168.5.161 ping statistics —-
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.581/0.701/0.791/0.068 ms

For me, pings seem fine…

Coud you ping between Omnias?

Pings from and to both Omnias are around 0.4 ms.