WiFi clients are not visible to each other or to wired clients

[zackw]

My home network consists of two PCs and a fileserver with wired connections to the router that runs OpenWrt, plus several WiFi-only devices. One of the WiFi-only devices is a printer, so it's important that other clients be able to communicate with it. They can't.

Experimentation has revealed the following symptoms:

• All of the clients are known to the DHCP server on the router.

• ping from the router can reach all clients. tcpdump on the router sees mDNS announcements from all clients (the printer in particular).

• Wired clients can ping each other, but can only sometimes ping wifi clients. ARP queries issued by wired clients for wifi clients are not answered reliably, and tcpdump on a wired client does not reliably see mDNS announcements from the printer. (Whether these things work, with the printer as the target, seems to depend on how long it has been since I most recently power-cycled the printer: It works for a few minutes and then it stops working.)

• Wifi clients can ping wired clients, but are completely cut off from other wifi clients. ARP queries issued by wifi clients for wifi clients are not answered, and tcpdump on a wifi client does not see mDNS announcements from the printer.

All this suggests some kind of problem with bridging, such that traffic from the wired interfaces is not (reliably) being sent over to the wifi interface. It smells similar to Clients in same WLAN can't reach each other but that's an old thread talking about 17.x and 18.x, and I'm using 19.07.8. (Hardware is a Linksys WRT1900ACv1.) I did try setting option multicast_to_unicast 0 on all the interfaces in the bridge, but that seems to have been ignored (/sys/devices/virtual/net/br-lan/lower_wlan0/brport/multicast_to_unicast is still 1 after rebooting) and given that /sys/devices/virtual/net/br-lan/lower_wlan0/brport/isolate_mode doesn't even exist, I dunno if any of the potential workarounds from the old thread even make sense anymore.

/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 'fda6:401d:13b2::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.0.1'

config interface 'wan'
	option ifname 'eth1.2'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth1.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 5t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6t'

config interface 'iot'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.1.1'

/etc/config/wireless

config wifi-device 'radio_2g'
	option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:02.0/0000:02:00.0'
	option type 'mac80211'
	option hwmode '11g'
	option htmode 'HT40'
	option country 'US'
	option channel 'auto'

config wifi-iface 'if_2g_main'
	option device 'radio_2g'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option ieee80211w '1'
	option multicast_to_unicast '0'
	option wds '1'
	option wpa_disable_eapol_key_retries '1'
	option ssid 'shinynewinternets_2ghz'
	option key '[redacted]'

config wifi-iface 'if_2g_iot'
	option device 'radio_2g'
	option network 'iot'
	option mode 'ap'
	option encryption 'psk2'
	option ieee80211w '1'
	option multicast_to_unicast '0'
	option wpa_disable_eapol_key_retries '1'
	option ssid 'shiny-iot'
	option key '[redacted]'

config wifi-device 'radio_5g'
	option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:03.0/0000:03:00.0'
	option type 'mac80211'
	option hwmode '11a'
	option htmode 'VHT80'
	option country 'US'
	option channel '44'

config wifi-iface 'if_5g_main'
	option device 'radio_5g'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option ieee80211w '1'
	option multicast_to_unicast '0'
	option wds '1'
	option wpa_disable_eapol_key_retries '1'
	option ssid 'shinynewinternets'
	option key '[redacted]'

[dlakelan]

In my experience this was typical for mvebu based wifi drivers. Just turn the wifi off and get an actual properly supported wifi AP.

[zackw]

Dude, profoundly not helpful.

[dlakelan]

Let me rephrase that then so you understand what I was trying to say.... The mvebu drivers are permanently broken, unsupported, and abandoned by the manufacturer, and these are exactly the kinds of bugs that remain, that I experienced, and will never be fixed. I spent several years dealing with this baloney until I abandoned them and then all my problems with my home wifi system went away. I suggest you do the same before you waste as much time as I did. I tell you this to try to be very helpful in that you won't waste tons of time like I did.

[zackw]

Let me rephrase that then so you understand what I was trying to say. I am aware of the problems with the mvebu drivers. I have in fact already tripped over some of them myself -- for instance, it's "option wds 1" in the config I posted, instead of mesh mode, because of that. Your hypothesis that this is another such bug is plausible, although I rate it unlikely since there was no such issue with the vendor's firmware. (I'm currently assuming this is some sort of layer-2 or -3 configuration problem.)

However, hypotheses by themselves are useless. To be helpful, you need to suggest a way to test your hypotheses, preferably without having to go out and buy more gear.

Also, given how difficult it is to find out which drivers are used for which products, if you're going to tell people to go buy a new router, you should have the decency to name at least one consumer-facing product ID for something that you know works reliably.

[dlakelan]

with mvebu I consistently had problems with ARP, with ipv6 NDS (ipv6 multicast), and with maintaining wifi connections for devices that use power saving modes. Also as you mentioned WDS didn't work right. The issues manifested for example when incoming SIP calls would hit my router and then it couldn't either ARP or NDS the device, however from the device it believed it was still connected to the wifi.

as soon as I used literally any other OpenWrt supported chipset those problems went away. Archer C7, some slightly earlier TP-Link devices, anything by Gl-inet, Zyxel Armor, and also the TP-link omada APs (running stock firmware).

[zackw]

Upgrading to 21.0.2 seems to have fixed this.