Ath79 client mode unwell/broken

#1

Recent snapshot ath79 for wr842n v1 and archer c7 v3 appears to be broken.
My primary AP wr842n v3 works with laptop, android and older snapshot wr703 with no obvious issues.
I first noticed this with client wds mode and thought it was an issue with vlans due to some other configuration I was using but noticed the same issue today with a new archer c7 v3 with todays snapshot.

AP log shows

Thu May  9 14:13:17 2019 daemon.notice hostapd: ap1: WDS-STA-INTERFACE-ADDED ifname=ap1.sta1 sta_addr=b0:be:76:e9:d4:47
Thu May  9 14:13:17 2019 kern.info kernel: [11074.049392] br-lan: port 4(ap1.sta1) entered blocking state
Thu May  9 14:13:17 2019 kern.info kernel: [11074.055244] br-lan: port 4(ap1.sta1) entered listening state
Thu May  9 14:13:19 2019 kern.info kernel: [11076.132112] br-lan: port 4(ap1.sta1) entered learning state
Thu May  9 14:13:21 2019 kern.info kernel: [11078.211994] br-lan: port 4(ap1.sta1) entered forwarding state
Thu May  9 14:13:21 2019 kern.info kernel: [11078.217946] br-lan: topology change detected, propagating
Thu May  9 14:13:26 2019 daemon.info hostapd: ap1: STA b0:be:76:e9:d4:47 IEEE 802.11: deauthenticated due to local deauth request
Thu May  9 14:13:26 2019 kern.info kernel: [11082.850945] device ap1.sta1 left promiscuous mode
Thu May  9 14:13:26 2019 kern.info kernel: [11082.856048] br-lan: port 4(ap1.sta1) entered disabled state
Thu May  9 14:13:26 2019 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=b0:be:76:e9:d4:47 ifname=ap1 **vlan_id=0**) failed: -2 (No such file or directory)
Thu May  9 14:13:26 2019 daemon.notice hostapd: ap1: WDS-STA-INTERFACE-REMOVED ifname=ap1.sta1 sta_addr=b0:be:76:e9:d4:47

Note the vlan_id=0 in the disconnect log. Relevance is unknown but observed to be different to successful client disconnect.

#2

It seems that if you try and bridge a wifi client (or client wds) to a physical interface the wifi connections fails.
I've just created a standalone interface and attached it to the wireless client device and a wifi link is established and remains up.
Suggests that somewhere the wireless interface is picking up vlan tagged data from the cpu(?) As though there is a missing config to untag the wifi data.
Latest testing has been on the archer c7 v5. Will try a similar test on the wr842 v1 tomorrow. And raise a bug report.

#3

I've been troubleshooting the same problem in recent master builds, although in my case the wds (4addr) client that can't connect is a ramips device (Netgear EX2700).

This device was problem free with my previous build, so I've been testing various images to work out where the problem was introduced. It seems to have been introduced with the bump to kernel 4.14.114, and specifically by this upstream commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.117&id=a1a9b69e2605db1edea34bb3a6051cf845b26bc1

OpenWRT has a patch (150-bridge_allow_receiption_on_disabled_port.patch) that partially acts on the same code. If I build an image that selectively reverts the upstream commit (and reverts the openwrt patch to its pre-4.14.114 bump state), the wds client is able to connect without any problems again.

I'm afraid that's about as far as my lack of programming skills allows me to take things, but hopefully it is helpful to someone with the skills to work out what the actual problem is here! :slight_smile:

1 Like