WRT3200ACM: Unstable wireless LAN connections again

Installing and Using OpenWrt
1

Environment:
Hardware: WRT3200ACM
Firmware: OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch (git-19.308.10993-a32190c)
Packages: sqm-scripts (piece of cake)
Type: wireless

Drivers (latest): opkg list-installed | grep mwlwifi
kmod-mwlwifi - 4.14.131+10.3.8.0-20181210-31d9386-31d93860-1
mwlwifi-firmware-88w8964 - 10.3.8.0-20181210-31d9386-31d93860-1

Problem summary: after a while, I cannot connect the other internal machines/printers in the same LAN. However, if I ssh'ed to the router, all machines are accessible from the router. Restarting the router would temporarily solve the issue.

PS: I saw this issue before, and was able to solve it with a newer driver with LEDE Reboot 17.01. No luck this time.

Attempt #1: upgraded to the latest driver:
kmod-mwlwifi_4.14.131+10.3.8.0-20181210-31d9386-31d93860-1_arm_cortex-a9_vfpv3.ipk
and
mwlwifi-firmware-88w8964_10.3.8.0-20181210-31d9386-31d93860-1_arm_cortex-a9_vfpv3.ipk

Attempt #2: updated the firewall rule:

config rule
        option name 'Printer'
        option src 'lan'
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_ip '192.168.1.111'

Any suggestion or comment is much appreciated!

2

Why do you need a firewall rule between two machines in LAN?

3

It's just a try after I saw the issue. The firewall rule does not cause the problem, or solve it.

4

When you say "cannot connect" or "are accessible", what are you referring to, exactly?

5

In general, ping
Also for printer, printing anything
For Raspberry Pi, SSH login

Thanks!

6

Just to clarify: when you boot the router, any device in your network can PING each other, and after a while you can only PING some wireless devices from the router, is this correct?

Do you have wired and wireless devices? Can wired devices reach wireless devices?

7

Let's say the network contains the router R, and devices A and B.

When newly boot the router, any device and router can ping each other. That is, R or A or B can ping R or A or B.

After a while:

  1. The router can ping any device; that is ,R can ping A and B.
  2. Any other device can ping router, but cannot see/ping each other. That is, A and B can ping R, but A cannot ping B, and B cannot ping A.

I only have wireless devices. I am not a network engineer. But my guess is, the issue come from the routing table.
1st . The router was restarted 10 h ago;

2nd. I opened my computer, connect to route in wireless, tried to ssh to my pi, but failed.
ssh pi@192.168.1.211
ssh: connect to host 192.168.1.211 port 22: Operation timed out

I checked the routing rules with "netstat -nr":

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc          417        0     en0
......

No item for the pi 192.168.1.211.

3rd, I connect the router with WIRE, tried and failed again with the same error message. But the routing table contains one item:

192.168.1.211      link#8             UHRLWI          0        7     en4     11

4th, I pinged the router:

ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.297 ms

And the pi is ping-able now:

ping 192.168.1.211
PING 192.168.1.211 (192.168.1.211): 56 data bytes
64 bytes from 192.168.1.211: icmp_seq=0 ttl=64 time=8.094 ms

ssh pi@192.168.1.211
The authenticity of host '192.168.1.211 (192.168.1.211)' can't be established.
RSA key fingerprint is xxx

Then I checked the route table. It contains:

192.168.1.211      AA:AA:AA:AA(mac address)   UHLWIi          1       22     en4   1196

5th, however, when I unplug the wire and switched back to wireless connection, the route changed to:

192.168.1.211      link#4             UHRLWI          0        6     en0     16

It's not working again. And "ping 192.168.1.1" did not help this time.

8

Wifi to wifi communication goes directly through the wifi chipset on the router. It does not reach the internet switch, and much less the CPU; this cannot be retarded to the firewall or the routing on the router.

Routes on the devices should not change with time, and those routes should only contain an entry for the local network and a default route.

ARP tables (on the devices) could be problematic, for example if you have more than one device with the same IP address.

Also, the wireless can be configured to isolate clients, and the results are exactly what you are experiencing. But it would be always active, it is not something that can creep in silently.

1 Like
9

Have you enabled "802.11w Management Frame Protection"?

10

Where can I check that setting? I went through the Luci, but didn't find any related settings. Thanks!

11

Network > Wireless > Edit (SSID 5G/ 2.4G) > Under the sub section "Interface Configuration" > Wireless Security > "802.11w Management Frame Protection"

Disable that. It's implementation in mwlwifi is not good.

Other tips include not using channels between 52-144. DFS channels on mwlwifi introduce a lot of problems.

Furthermore, what frequencies are you operating at? 20/40/80/160MHz?

1 Like
12

This is not the only route your routing table has. There is one more with Destination 192.168.1.0 Mask 255.255.255.0 which is for the LAN and includes .211

This is ARP table, as it has the MAC to IP bindings.

As all of these are in the same network, routing plays no role. You should check client isolation as @eduperez already told you and verify that ARP requests are forwarded.

13

Thanks for the help. However, I did not see that opinion in wireless security section:

4G
2.4G.png965×1086 103 KB

5G
5G.png968×1089 104 KB

14

You must be running the full version of wpad/hostapd for support.

15

Sorry for my bad knowledge in network, how can I make sure the ARP request are forwarded correctly? It seems to be the issues?

16

@eduperez @ParanoidZoid @anomeome

Installed hostapd, and get the result as:

image
image.png955×475 45.8 KB

Management Frame Protection is disabled.

17

Run a tcpdump and verify that requests and answers are exchanged.
tcpdump -i any -vvn arp
Then you can verify on each host that there is an arp entry for the other hosts arp -a or just arp in OpenWrt.

18

The ARP seems problematic:

$ sudo tcpdump -i any -vvn arp
Password:
tcpdump: data link type PKTAP
tcpdump: listening on any, link-type PKTAP (Packet Tap), capture size 65535 bytes
13:36:49.989536 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.170 tell 192.168.1.106, length 28
13:37:00.558418 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:37:00.558463 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:37:25.682938 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:37:25.682956 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:37:33.817236 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.232 tell 192.168.1.106, length 28
13:37:42.235682 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 0.0.0.0, length 28
13:37:44.057261 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 0.0.0.0, length 28
13:37:46.105933 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 192.168.1.211, length 28
13:37:47.948172 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 192.168.1.211, length 28
13:37:50.553727 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:37:50.553743 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:38:15.805814 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:38:15.805831 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:38:42.405823 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:38:42.405836 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:39:10.721723 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:39:10.721740 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:39:17.650873 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.170 tell 192.168.1.106, length 28
13:39:38.001394 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:39:38.001410 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:40:05.517835 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:40:05.517852 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:40:33.431246 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:40:33.431264 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:41:00.641722 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:41:00.641736 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:41:29.134872 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:41:29.134885 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:41:50.023947 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.170 tell 192.168.1.106, length 28
13:41:56.235081 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:41:56.235098 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:42:23.407511 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.221 tell 192.168.1.233, length 28
13:42:23.413413 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.218 tell 192.168.1.233, length 28
13:42:23.414244 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.220 tell 192.168.1.233, length 28
13:42:23.415111 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.219 tell 192.168.1.233, length 28
13:42:23.415990 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.222 tell 192.168.1.233, length 28
13:42:23.416862 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.223 tell 192.168.1.233, length 28
13:42:23.422243 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.228 tell 192.168.1.233, length 28
13:42:23.423061 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.229 tell 192.168.1.233, length 28
13:42:23.426710 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.230 tell 192.168.1.233, length 28
13:42:23.427576 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.231 tell 192.168.1.233, length 28
13:42:23.428476 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.224 tell 192.168.1.233, length 28
13:42:23.429363 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.225 tell 192.168.1.233, length 28
13:42:23.430254 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.239 tell 192.168.1.233, length 28
13:42:23.432782 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.235 tell 192.168.1.233, length 28
13:42:23.433756 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.236 tell 192.168.1.233, length 28
13:42:23.434835 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.234 tell 192.168.1.233, length 28
13:42:23.435716 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.238 tell 192.168.1.233, length 28
13:42:23.436615 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.237 tell 192.168.1.233, length 28
13:42:23.437503 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.241 tell 192.168.1.233, length 28
13:42:23.438539 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.240 tell 192.168.1.233, length 28
13:42:23.441346 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.242 tell 192.168.1.233, length 28
13:42:23.442225 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.245 tell 192.168.1.233, length 28
13:42:23.443097 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.244 tell 192.168.1.233, length 28
13:42:23.445015 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.246 tell 192.168.1.233, length 28
13:42:23.445887 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.247 tell 192.168.1.233, length 28
13:42:25.040995 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:42:25.041045 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:42:52.650403 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:42:52.650412 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
13:42:55.153682 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 0.0.0.0, length 28
13:43:00.699802 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 192.168.1.211, length 28
13:43:02.727978 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.211 tell 192.168.1.211, length 28
13:43:20.088463 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.133 tell 192.168.1.1, length 28
13:43:20.088480 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.133 is-at [MAC-REDACTED], length 28
^C^C
66 packets captured
32019 packets received by filter
0 packets dropped by kernel

The reply only contains the info for 192.168.1.133

Besides, it was good with LEDE 17.01.X. And I upgraded to OpenWRT 18.06.X in middle 2019. Not sure if it's related.

Thanks!

19

If the ARP is really the root issue, do you have any suggestion to fix it? Thanks!

20

Can we see your config files, please?