DD-WRT :: View topic - Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

DD-WRT Forum Index -> Broadcom SoC based Hardware

View previous topic :: View next topic

Author

Message

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Tue May 08, 2018 8:27 Post subject: Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

Hi all,

I have set up a Netgear R7000P in client bridge mode on 5 GHz. The AP is a Netgear R7000. In this scenario, the R7000P seems to ignore incoming packets to the broadcast address on the 5 GHz device "most of the time". This breaks, e.g. ARP and DHCP. The ARP problem could be worked around by setting static ARP records in all other hosts which want to communicate with the R7000P or any clients behind it. This is not an option. For the DHCP problem I don't see any work-around besides setting up another DHCP or an DHCP forwarder on the R7000P. Nevertheless, both work-arounds do not solve the fundamental problem itself...

My question to the owners of an R7000P: Does anybody else run a similar configuration, especially the R7000P in client bridge mode on its 5 GHz device?

So far, I have tried v3.0-r35550M kongac and DD-WRT v3.0-r35030M kongac. Both versions show the same problem.

In the meantime, I've found that producing unicast traffic on the 5 GHz device seems to make the device sensitive for broadcasts. So permanently pinging the AP might be a possible (in my opinion a dirty one) work around for the problem.

For me it seems that the Broadcom driver has a problem, maybe it goes to a deep power-save mode and doesn't detect incoming broadcasts correctly. The driver which is used is:

Code:

root@wl-ap-eg:~# wl -i eth2 ver
7.14 RC89.21
wl0: May 1 2017 12:43:53 version 10.10.122.301 (r658909) FWID 01-1ebebd8a
root@wl-ap-eg:~# wl -i eth1 ver
7.14 RC89.21
wl0: Mar 28 2018 09:54:51 version 7.14.89.21 (r524987)

On "eth1" (2.4 GHz) there is no problem, it only occurs on "eth2" (5 GHz). This leads me to the next bunch of questions:

Are there any debug possibilities on MAC or PHY level for "eth2"? Trying to activate the monitor mode disconnected the R7000P from the R7000.
Are there any possibilities to deactivate features like power-saving or offloading on "eth2"? I tried "wl", but there are tons of options any many of them are not applicable.
Why does "iwconfig" show "eth1", but not "eth2"?
Why does "cat /proc/net/wireless" list only "eth1", but not "eth2"?
Are there any plans of releasing newer drivers for the BCM4365E chip (which is used for "eth2" according to the Wiki)?

I've also added a comment to a bug report about this problem as someone seems to have a similar problem with an RT-AC88U: http://svn.dd-wrt.com/ticket/6195#comment:2.

I would be very glad for any helpful answers. Thank you very much in advance!

Kind regards,
Steffen

Sponsor

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Fri May 11, 2018 15:16 Post subject: Re: Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

Steffen M. wrote:

A little update:

I've tested further older and newer, both Kong and BrainSlayer builds (e.g. v3.0-r35531) and always get the same behavior.

When watching with "tcpdump -i any", I can see that after a reboot everything works fine at first. After about 2 hours of operation, the 5 GHz device of the R7000P (in client bridge mode) begins to ignore incoming broadcasts. While unicasts still come through without any problems, packets to FF:FF:FF:FF:FF:FF on the 5 GHz device start to get neglected - the incoming broadcasts just don't appear in "tcpdump" anymore. There is neither a message in the kernel ring buffer (dmesg) nor any preceding event.

I've permanently produced ARP requests (one per second) by pinging a non-existant IP adress. For about two hours, I saw all of them as incoming ARPs on the R7000P. Suddenly, it stopped.

After this, only from time to time a few ARP requests do come in, I'd guess that about 98% are lost. After a reboot of the R7000P, everything is fine again for about two hours.

I don't see any kinds of log messages.

Perhaps I am making it too easy, but as I've produced traffic permanently, I don't think that a energy saving mechanism is causing the problem.

Kind regards,
Steffen

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Sun May 13, 2018 23:42 Post subject: Re: Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

Steffen M. wrote:

A little update:

I've tested further older and newer, both Kong and BrainSlayer builds (e.g. v3.0-r35531) and always get the same behavior.

Same behavior with BS build v3.0-r35916 and with KONG build v3.0-r35900M kongac...

Steffen M. wrote:

When watching with "tcpdump -i any", I can see that after a reboot everything works fine at first. After about 2 hours of operation, the 5 GHz device of the R7000P (in client bridge mode) begins to ignore incoming broadcasts. While unicasts still come through without any problems, packets to FF:FF:FF:FF:FF:FF on the 5 GHz device start to get neglected - the incoming broadcasts just don't appear in "tcpdump" anymore. There is neither a message in the kernel ring buffer (dmesg) nor any preceding event.

I've permanently produced ARP requests (one per second) by pinging a non-existant IP adress. For about two hours, I saw all of them as incoming ARPs on the R7000P. Suddenly, it stopped.

After this, only from time to time a few ARP requests do come in, I'd guess that about 98% are lost. After a reboot of the R7000P, everything is fine again for about two hours.

A reboot is not required to bring the intended behavior back. It is sufficient to restart the 5 GHz link (e.g. by reconfiguring the WLAN device on the R7000P or by reconfiguring or rebooting the access point). But again, after about 2 hours of link, the R7000P starts to ignore packets to the ethernet broadcast address. I still don't see any logs. I would be very pleased to support the developers with all information they might need.

I've attached various status output (dmesg, cpuinfo, mtd, lsmod, lspci, etc.).

Kind regards,
Steffen

R7000P.tar

Description:

Status output R7000P after occurrence of ignoring broadcast packets.

Download

Filename:

R7000P.tar

Filesize:

50 KB

Downloaded:

153 Time(s)

Last edited by Steffen M. on Mon May 14, 2018 14:25; edited 1 time in total

jwh7
DD-WRT Guru

Joined: 25 Oct 2013
Posts: 2670
Location: Indy

Posted: Mon May 14, 2018 14:23 Post subject:
Do you have syslog enabled? Also attach: /var/log/messages _________________ # NAT/SFE/CTF: limited speed w/ DD # Repeater issues # DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo # OPNsense x64 5050e ITX\|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353, WRT54G{Lv1.1,Sv6}@250\|FreshTomato: F7D8302@532\|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Mon May 14, 2018 14:24 Post subject:

jwh7 wrote:

Do you have syslog enabled? Also attach: /var/log/messages

Not yet, I'll enable it today and attach it.

Kind regards,
Steffen

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Mon May 14, 2018 23:32 Post subject:

jwh7 wrote:

Do you have syslog enabled? Also attach: /var/log/messages

I've enabled it and attached "/var/log/messages".

I haven't expected interesting information from the /var/log/messages, because I have supposed the culprit to be in the driver/kernel, so if there was interesting information, we should have already found it in the kernel ring buffer output (dmesg). As far as I see, there is no interesting information, but maybe someone else detects something of interest.

Nevertheless, it was really worth trying it, because working with real time stamps allowed me to find out for how long the R7000P actually answers broadcasts.

The R7000P was rebooted at May 14, 22:00.

I continuously sent ARP (broadcast) requests which the R7000P has received via its eth2 device. This can be seen in the tcpdump log:

root@wl-ap-eg:~# tcpdump -Q inout -e -u -i any -n not port 23

[...]

23:07:53.904609 00:1e:e5:fe:5d:59 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 398: 192.168.1.67.1900 > 239.255.255.250.1900: UDP, length 356
23:07:53.906395 00:1e:e5:fe:5d:59 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 349: 192.168.1.67.1900 > 239.255.255.250.1900: UDP, length 307
23:07:53.908268 00:1e:e5:fe:5d:59 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 358: 192.168.1.67.1900 > 239.255.255.250.1900: UDP, length 316
23:07:53.910226 00:1e:e5:fe:5d:59 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 405: 192.168.1.67.1900 > 239.255.255.250.1900: UDP, length 363
23:07:53.927673 00:1e:e5:fe:5d:59 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.66, length 46
23:07:53.929444 1c:1b:0d:9f:5a:c5 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 403: 192.168.1.111.1900 > 239.255.255.250.1900: UDP, length 361
23:07:54.046940 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.71 tell 192.168.1.1, length 28
23:07:54.322250 1c:1b:0d:9f:5a:c5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.90 tell 192.168.1.111, length 46
23:07:54.585119 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype ARP (0x0806), length 42: Reply 192.168.1.1 is-at e4:f4:c6:12:93:f3, length 28
23:07:54.588552 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 3832:3866, ack 1816, win 175, options [nop,nop,TS val 4056784938 ecr 137551793], length 34
23:07:54.670050 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.250 tell 192.168.1.1, length 28
23:07:54.969625 1c:1b:0d:9f:5a:c5 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 419: 192.168.1.111.1900 > 239.255.255.250.1900: UDP, length 377
23:07:54.991738 1c:6f:65:3c:86:1e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.249 tell 192.168.1.101, length 46
23:07:55.060235 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.71 tell 192.168.1.1, length 28
23:07:55.669133 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.250 tell 192.168.1.1, length 28
23:07:55.994315 1c:6f:65:3c:86:1e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.249 tell 192.168.1.101, length 46
23:07:56.055912 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.71 tell 192.168.1.1, length 28
23:07:56.563723 1c:1b:0d:9f:5a:c5 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 431: 192.168.1.111.1900 > 239.255.255.250.1900: UDP, length 389
23:07:56.668396 e4:f4:c6:12:93:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.250 tell 192.168.1.1, length 28
23:07:56.873002 9e:3d:cf:42:02:fb > 9c:3d:cf:42:02:fb, ethertype Unknown (0x886c), length 205:
0x0000: 8001 00eb 0000 1018 0001 0002 0000 0000 ................
0x0010: 0019 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0083 e4f4 c612 93f3 6574 6832 0000 0000 ........eth2....
0x0030: 0000 0000 0000 0000 0000 0203 007f 0213 ................
0x0040: 8200 0000 0000 0000 0000 0300 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 00c7 562a 094d ............V*.M
0x0070: 0a37 4b20 7127 557d 2928 8b00 0000 0000 .7K.q'U})(......
0x0080: 0000 0000 0000 0000 0000 00dc c4b4 62b4 ..............b.
0x0090: 9b93 f23e f9dd 225b b0f9 2200 204d 7109 ...>.."[.."..Mq.
0x00a0: c44b 4c4a 0e02 fa59 6ff5 b40a e3c9 582b .KLJ...Yo.....X+
0x00b0: 4be3 8546 f14b cfda cfac a980 cb00 00 K..F.K.........
23:07:56.874784 e4:f4:c6:12:93:f3 > 9c:3d:cf:42:02:fb, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
23:08:22.197276 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [.], ack 1852, win 175, options [nop,nop,TS val 4056812507 ecr 137552537], length 0
23:08:22.275251 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 3866:3900, ack 1852, win 175, options [nop,nop,TS val 4056812625 ecr 137552537], length 34
23:08:49.845678 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [.], ack 1888, win 175, options [nop,nop,TS val 4056840196 ecr 137553167], length 0
23:08:49.854614 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 3900:3934, ack 1888, win 175, options [nop,nop,TS val 4056840205 ecr 137553167], length 34
23:08:54.862794 1c:6f:65:3c:86:1e > 9c:3d:cf:42:02:f8, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.240 (9c:3d:cf:42:02:f8) tell 192.168.1.101, length 46
23:09:18.601002 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 3934:3968, ack 1924, win 175, options [nop,nop,TS val 4056868951 ecr 137553670], length 34
23:09:47.585718 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 3968:4002, ack 1960, win 175, options [nop,nop,TS val 4056897936 ecr 137554136], length 34
23:09:52.606545 1c:6f:65:3c:86:1e > 9c:3d:cf:42:02:f8, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.240 (9c:3d:cf:42:02:f8) tell 192.168.1.101, length 46
23:10:15.599878 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 100: 74.125.133.188.5228 > 192.168.1.31.54379: Flags [P.], seq 4002:4036, ack 1996, win 175, options [nop,nop,TS val 4056925951 ecr 137554533], length 34
23:10:18.373414 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 216.58.206.10.443 > 192.168.1.31.57972: Flags [F.], seq 3682, ack 1243, win 178, options [nop,nop,TS val 2697914085 ecr 137544510], length 0
23:10:18.375201 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 216.58.207.74.443 > 192.168.1.31.53711: Flags [F.], seq 3765, ack 2406, win 194, options [nop,nop,TS val 2891686807 ecr 137544304], length 0
23:10:18.376643 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 172.217.21.238.443 > 192.168.1.31.35683: Flags [F.], seq 1127, ack 1421, win 182, options [nop,nop,TS val 3646723042 ecr 137544233], length 0
23:10:18.378050 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 172.217.21.232.443 > 192.168.1.31.51035: Flags [F.], seq 3693, ack 908, win 175, options [nop,nop,TS val 2024105478 ecr 137545043], length 0
23:10:18.379456 e4:f4:c6:12:93:f3 > c4:f0:81:96:a7:c3, ethertype IPv4 (0x0800), length 66: 172.217.23.170.443 > 192.168.1.31.44338: Flags [F.], seq 1253, ack 1262, win 176, options [nop,nop,TS val 2076960990 ecr 137544426], length 0

Besides other traffic, you can see the ARP requests for the MAC addresses of 192.168.1.249 and 192.168.1.250. My workstation (192.168.1.101) asks for 192.168.1.249 and the AP (R7000, 192.168.1.1) asks for 192.168.1.250. This went on from 22:00 until 23:07:56 (I left out most of the parts here).

At 23:07:56, the R7000P receives an EAPoL key (3) v2 frame, maybe it's related to a WPA2 key change. After this event, the R7000P receives -as you can see- other unicast traffic, but it doesn't see frames to FF:FF:FF:FF:FF:FF anymore... This is where the problem begins.

Doing tcpdump in parallel on the AP, I don't see any change. It still seems to produce the broadcasts.

Other client bridges (WRT600N) connected to the same AP and the same 5 GHz device don't show the problem. Their IP address can still be resolved and DHCP clients "behind" them do still work. Therefore I suppose that the problem lies in the R7000P's driver. Lacking tcpdump on the smaller DD-WRT images of the old WRT600N, I cannot provide a parallel "tcpdump" from their perspective.

So at the moment I can narrow it down to the following working hypothesis: After the R7000P receives an EAPoL frame, it stops detecting any ethernet broadcasts.

Maybe the problem would be gone if I deactivated WPA2...

Thank you very much for looking into this in advance!

Kind regards,
Steffen

tcpdump.txt

Description:

Download

Filename:

tcpdump.txt

Filesize:

125.08 KB

Downloaded:

361 Time(s)

messages.txt

Description:

Download

Filename:

messages.txt

Filesize:

33.4 KB

Downloaded:

324 Time(s)

Last edited by Steffen M. on Tue May 15, 2018 16:50; edited 1 time in total

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Tue May 15, 2018 9:46 Post subject:

Hi all,

does anyone out there have an idea how to increase the log level (up to debug mode) of...

...the NAS daemon (/usr/sbin/nas), which is responsible for EAPoL and other WPA-related stuff,
...the Linux kernel in general and
...especially the Broadcom DHD driver for BCM4365E?

I'd especially like to know why an EAPoL packet causes the observed behavior. Which IOCTLs are fired by NAS daemon to the driver?

As I don't want to work without WPA2, I've just increased the session key renewal time and observe further. Switching from WPA2+AES to WPA+AES didn't solve the problem.

Many thanks in advance!

Kind regards,
Steffen

Steffen M.
DD-WRT User

Joined: 23 Jan 2008
Posts: 50
Location: Ulm, Germany

Posted: Tue May 15, 2018 17:35 Post subject:

Steffen M. wrote:

As I don't want to work without WPA2, I've just increased the session key renewal time and observe further.

About six hours ago, I changed the key renewal interval at the AP from 3600 s to 86400 s (= 24 h). Up to now, the R7000P (client bridge) still answers broadcasts perfectly. I expect that the problem will reoccur in about 18 hours.

I think it is getting clear that the session key renewal "somehow" puts the WiFi driver into an odd state.

Kind regards,
Steffen

jwh7
DD-WRT Guru

Joined: 25 Oct 2013
Posts: 2670
Location: Indy

Posted: Tue May 15, 2018 20:15 Post subject:

Have you tried using WDS instead of CB?

From the RB wiki (applies to CB as well):

RB wiki wrote:

Repeater Bridge on Broadcom is generally not a good solution, as it is not a true bridge. It should be fine for internet access with few clients, but more clients or more complicated networking is likely to cause trouble, since MAC addresses will not traverse its bridge. In contrast, WDS is a transparent bridge and useful for these things. Also, the primary host router's log can be full of arp spoofing attempts if it has ARP Spoofing Protection enabled in its security.

_________________
# NAT/SFE/CTF: limited speed w/ DD # Repeater issues # DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo #
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4

Display posts from previous:

Page 1 of 1

DD-WRT Forum Index -> Broadcom SoC based Hardware

All times are GMT

Navigation

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum

Log in

Netgear Nighthawk R7000P in Client Bridge Mode on 5 GHz

Quick Links

Log in