Access point configuration problem

jefdriesen · January 17, 2020, 9:21am

I have followed the openwrt user guide to configure one of my Turris Omnia's as an access point.

In a nutshell, I bridged the WAN (eth2) and LAN ports (lanX). The resulting lan interface is configured to receive an IPv4 and IPv6 address from the main router with DHCP. I use DHCP instead of a static address because that allows me to manage all static IP address inside my network on the main router.

# cat /etc/config/network 

config globals 'globals'
        option ula_prefix 'fdc7:5c1d:c6a2::/48'

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option type 'bridge'
        option proto 'dhcp'
        option hostname 'accesspoint'
        option ifname 'eth2 lan0 lan1 lan2 lan3 lan4'

config interface 'lan6'
        option proto 'dhcpv6'
        option ifname '@lan'
        option reqaddress 'try'
        option reqprefix 'auto'

config interface 'guest'
        option enabled '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '10.111.222.1'
        option netmask '255.255.255.0'
        option bridge_empty '1'
        option auto '0'

This works fine, except for one thing: When I'm connected to the main router, I can't access the luci web interface of the access point. It only works when I'm connected to the access point itself. What am I doing wrong?

In the next step, I would like to add a guest wifi to the access point. My main router already has a guest network, so the plan is to configure two VLAN's on the WAN port of the access point (LAN=1 and GUEST=2), and change the configuration of the access point to:

config interface 'lan'
        option type 'bridge'
        option proto 'dhcp'
        option hostname 'accesspoint'
        option ifname 'eth2.1 lan0 lan1 lan2 lan3 lan4'

config interface 'guest'
        option type 'bridge'
        option proto 'static'
        ...
        option ifname 'eth2.2'

Which protocol should I use for the guest interface? The access point itself should not be accessible from the guest network.

trendy · January 17, 2020, 10:27am

Check the firewall and the httpd configuration if they are blocking traffic incoming from eth2.1

You could leave it as 'none' then. You only need to use a different vlan on eth2 to trunk the guest network to the main router.

Hegabo · January 17, 2020, 11:21am

Why would you bridge the WAN and the LAN? Wouldn't it be more straightforward to make the WAN port a part of the LAN VLAN? This should solve the first problem I think.

jefdriesen · January 17, 2020, 11:52am

I have the firewall disabled:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

And lighttpd is listening on all interfaces:

# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4521/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      5700/kresd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3281/sshd
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4521/lighttpd
tcp        0      0 :::80                   :::*                    LISTEN      4521/lighttpd
tcp        0      0 :::53                   :::*                    LISTEN      5700/kresd
tcp        0      0 :::22                   :::*                    LISTEN      3281/sshd
tcp        0      0 :::443                  :::*                    LISTEN      4521/lighttpd

I didn't know 'none' existed. The eth2.1 VLAN in the guest network was a typo. I corrected that in my original post.

jefdriesen · January 17, 2020, 11:57am

That's exactly what I did, right? I bridged the WAN and LAN ports in the lan interface.

Hegabo · January 17, 2020, 12:57pm

Check this Does OpenWrt support transparent bridge function? - #8 by Hegabo

jefdriesen · January 17, 2020, 1:38pm

The Turris Omnia is using the DSA driver to manage the switch, and not swconfig. Thus there is no swconfig based switch configuration. With the DSA driver, each switch port shows up as a normal network interface: eth2 for WAN port, and lan0..4 for the five LAN ports.

Even if the Turris Omnia used swconfig (as in the older 3.x firmware), then this wouldn't work. The WAN port is connected directly to the cpu, and not to the switch:
https://openwrt.org/toh/turris/turris_omnia#switch_ports_for_vlans

anon45274024 · January 17, 2020, 1:52pm

Is only TCP (http | https) connectivity impaired or also ICMP?

mk24 · January 17, 2020, 2:00pm

Make sure the DHCP server set up by default on lan is turned off. Check the IP addresses you're getting to see if they make sense. Your PC should get the same IP whether it is connected to a LAN port on the Omnia or to some other port "on the main router" since it is all the same network.

brctl show should show that the eth2 port is in br-lan.

jefdriesen · January 20, 2020, 11:29am

Trying to ping the access point fails too, so ICMP is also affected. Basically every kind of connection (ping, ssh, http, etc). Strange thing is that sometimes it works just fine, and sometimes it doesn't.

I have been experimenting a bit this weekend, and it looks like the problem is related to switching between the two wireless networks. When connected to the access point everything works fine. But when switching to the wireless network of the main router, ping starts fails.

The log file below shows the ping output (with a timestamp prefixed), while switching between the two wireless networks:

$ ping -I wlp2s0 192.168.0.6 | awk '{ print strftime("[%s]"), $0; fflush(); }'

Connected to main router

[1579514238] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=1 ttl=64 time=5.01 ms
[1579514239] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=2 ttl=64 time=6.64 ms
[1579514240] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=3 ttl=64 time=5.55 ms
[1579514241] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=4 ttl=64 time=6.38 ms
...
[1579514249] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=12 ttl=64 time=6.37 ms
[1579514250] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=13 ttl=64 time=4.98 ms
[1579514251] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=14 ttl=64 time=2.52 ms
[1579514252] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=15 ttl=64 time=3.12 ms

Switching to access point

[1579514263] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=26 ttl=64 time=4.31 ms
[1579514264] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=27 ttl=64 time=1.78 ms
[1579514265] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=28 ttl=64 time=1.74 ms
[1579514266] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=29 ttl=64 time=3.38 ms
...
[1579514278] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=41 ttl=64 time=2.30 ms
[1579514279] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=42 ttl=64 time=3.64 ms
[1579514280] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=43 ttl=64 time=4.95 ms
[1579514281] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=44 ttl=64 time=4.64 ms

Switching back to main router

[1579514539] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=296 ttl=64 time=7.01 ms
[1579514540] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=297 ttl=64 time=5.11 ms
[1579514541] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=298 ttl=64 time=4.96 ms
[1579514542] 64 bytes from 192.168.0.6 (192.168.0.6): icmp_seq=299 ttl=64 time=3.89 ms

When switching to the access point there is no response for about 11 seconds. That's expected because the network went down, and re-associating with another wireless network takes a few seconds. But when switching back to the main router, there is no response for about 258 seconds (4.3 minutes)! So it looks like it works in the end, but it just takes a very long time. I don't understand why this happens.

If connect directly to the wireless of the main router, without being connected to the access point before (e.g. after having the wifi disconnected for a while), it works immediately too. With a wired connection to the main router, there is also no problem.

anon45274024 · January 20, 2020, 11:55am

Did you post the same question on the downstream forum ^[1] or this just being an odd coincidence, considering that it sounds somewhat familiar? If not it might be an indication of some sort of generic problem if observed by different users.

^[1] https://forum.turris.cz/t/lan-ports-arent-accessible-for-wifi-client-for-the-first-250-330-seconds-after-connection/12071

jefdriesen · January 20, 2020, 12:12pm

That's from another user. Looks very similar indeed.

anon45274024 · January 21, 2020, 12:18pm

Is STP (Spanning Tree) enabled on the bridge?

There seems to be a bug ^[2] related to mcast_last_member_interval which may or may not could compound the issue.

^[2] [bridge STP] potential syntax error -> last_member_interval

jefdriesen · January 21, 2020, 1:04pm

STP is not enabled.

anon45274024 · January 21, 2020, 1:20pm

Apparently some sort of timing issue with the AP, either:

in the bridge device, or
in the communication between bridge device and WLan device, or
in the WLan device

Since the issue does not exhibit on the Lan port the bridge device could likely be ruled out.

The time frame seems pretty distinctive considering that it matches the case reported on the other user forum. But neither seems to mention the frequency band that happens with, e.g. 2.4GHz or 5 GHz or both?

If it is only on the 5 GHz band then it might be caused by Dynamic Frequency Selection (DFS) scan. Not sure if client association is permitted during the scan but it certainly blocks traffic during such scan.

jefdriesen · January 21, 2020, 1:53pm

I have both 2.4 and 5 GHz networks with the same SSID. I didn't pay attention to which one I was connecting. I just tried with 5 GHz disabled, and it shows the same problem. So it's probably not the DFS scan. Note that during the time where pinging the access point fails, I can access the internet just fine (and also ping the main router). So it's not like I have no connectivity at all.

Note: the lan port was connected permanently. I didn't try to disconnect and reconnect there. That's not really a use-case in practice. With a wired network you're not going to roam between the two accesspoints like you do with wifi.