R7800 data corruption when in Accesspoint mode

[kamoj]

Can anyone using the WAN-port for AP, run these commands and see if the behaviour change (e.g. error rate changes), please?:

ethtool -K ethwan rx on  tx on  sg on  tso on  gso on gro on  lro on  tx-nocache-copy off
ethtool -K brwan rx on  tx on  sg on  tso on  gso on gro on  lro on  tx-nocache-copy off
ifconfig ethwan txqueuelen 1000
ifconfig brwan txqueuelen 1000

 

[sfx2000]

What SW build?

If I recall - current Production is 1.0.2.62

 

[kamoj]

If you mean the commands I posted above to manipulate the switch ports, they can be run with all Netgear or Voxel FW.

 

[ablatt]

On my R7800 with the latest beta .63 stock firmware, the transmit errors show up regardless of whether the LAN or WAN port is used in Access Point Mode.

 

[pato]

Ablatt, can you test the above posted commands in a telnet session?

 

[ablatt]

Ablatt, can you test the above posted commands in a telnet session?

Maybe I would if I knew what they did, whether there was a downside, whether they were permanent, and if I knew what the defaults were and how to revert to them.

 

[pato]

Typically those commands get reset on a reboot, but I home @kamoj can offer more information.
The commands enable / disable various flags for the lan interfaces, which have an impact on how the driver works.

 

[e38BimmerFN]

After letting my R7800 run for a few days in AP mode behind my main host router. WiFi disable on the R7800.
I found that Errors were reading zero while Dropped increased in value:
System Version Information Linux R7800 3.4.103 #1 SMP Wed Jul 17 15:17:16 UTC 2019 armv7l IPQ8065 / WiFi-driver:3.4.103+10.4-4.0.1756.382-1 / (Voxel) V1.0.2.68SF
System Uptime 3 days 2 hours 42 min 11 seconds (Tue Oct 1 14:47:08 GMT 2019 -0800)

ethlan Link encap:Ethernet HWaddr C5:9D
inet6 addr: c59d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:845732 errors:0 dropped:290 overruns:0 frame:0
TX packets:2419450 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:269961887 (257.4 MiB) TX bytes:645973249 (616.0 MiB)
Interrupt:2

ethwan Link encap:Ethernet HWaddr C5:9E
inet6 addr: c59e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2716451 errors:0 dropped:87 overruns:0 frame:0
TX packets:2042296 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:727526766 (693.8 MiB) TX bytes:490017199 (467.3 MiB)
Interrupt:255

I've now applied Kamoj's code and will check results in a few more days.

Can anyone using the WAN-port for AP, run these commands and see if the behaviour change (e.g. error rate changes), please?:

ethtool -K ethwan rx on  tx on  sg on  tso on  gso on gro on  lro on  tx-nocache-copy off
ethtool -K brwan rx on  tx on  sg on  tso on  gso on gro on  lro on  tx-nocache-copy off
ifconfig ethwan txqueuelen 1000
ifconfig brwan txqueuelen 1000

 

[e38BimmerFN]

A few hours after running Kamoj's code:
br0 Link encap:Ethernet HWaddr C5:9D
inet addr:192.168.0.78 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: c59d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2269889 errors:0 dropped:1543 overruns:0 frame:0
TX packets:1101160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:467385252 (445.7 MiB) TX bytes:202516822 (193.1 MiB)

ethlan Link encap:Ethernet HWaddr C5:9D
inet6 addr: c59d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:854104 errors:0 dropped:296 overruns:0 frame:0
TX packets:2502938 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:271126673 (258.5 MiB) TX bytes:669190232 (638.1 MiB)
Interrupt:2

ethwan Link encap:Ethernet HWaddr C5:9E
inet6 addr: c59e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2798253 errors:0 dropped:727 overruns:0 frame:0
TX packets:2083763 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:751008009 (716.2 MiB) TX bytes:496077712 (473.0 MiB)
Interrupt:255

 

[kamoj]

Thank you for trying it out!

Also this might be a way of dropping the drop count:

ifconfig ethlan promisc
ifconfig ethwan promisc

I found these blogs to be of help to understand and modify the network behaviour:
http://blog.hyfather.com/blog/2013/03/04/ifconfig/

https://www.suse.com/support/kb/doc/?id=7007165

Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:

Softnet backlog full -- (Measured from /proc/net/softnet_stat)
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6

If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.

https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/

I'm sorry I'm too busy to be able to do my own investigation.
But I don't see why Dropped packages should result in data corruption...

Anyone know what is Netgear's view of the problem?

 

[pato]

Netgears view of the problem is "we are looking into it" since the beginning of this year.

 

[e38BimmerFN]

I'll give this a try and see what I find.
Been busy as well. I'm keeping the R7800 in AP mode on my desk as a reminder to fiddle with it when I get a chance.

I lasted talked to NG and they said they were working with engineering and reproduction of this issue. That was middle of last month.

Thank you for trying it out!

Also this might be a way of dropping the drop count:

ifconfig ethlan promisc
ifconfig ethwan promisc

I found these blogs to be of help to understand and modify the network behaviour:
http://blog.hyfather.com/blog/2013/03/04/ifconfig/

https://www.suse.com/support/kb/doc/?id=7007165

https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/

I'm sorry I'm too busy to be able to do my own investigation.
But I don't see why Dropped packages should result in data corruption...

Anyone know what is Netgear's view of the problem?

 

[kamoj]

Thank you very much for all your support and attitude in the community!
You must be one of the few that actually get any response from NG!

(I actually solved a problem with a certain embedded HW thing that had a limited stack implemented,
after using the promiscuous setting!)

I'll give this a try and see what I find.
Been busy as well. I'm keeping the R7800 in AP mode on my desk as a reminder to fiddle with it when I get a chance.

I lasted talked to NG and they said they were working with engineering and reproduction of this issue. That was middle of last month.

 

[e38BimmerFN]

Try to help out as best as I can.

I'll give this a go after work and report my findings.

 

[e38BimmerFN]

Ok, So here's my results after applying your last suggested code:
br0 Link encap:Ethernet HWaddr C5:9D
inet addr:192.168.0.78 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: c59d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3002069 errors:0 dropped:24418 overruns:0 frame:0
TX packets:1477994 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:648990250 (618.9 MiB) TX bytes:250735265 (239.1 MiB)

ethlan Link encap:Ethernet HWaddr C5:9D
inet6 addr: c59d/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:889679 errors:0 dropped:301 overruns:0 frame:0
TX packets:3368572 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:277993615 (265.1 MiB) TX bytes:898342616 (856.7 MiB)
Interrupt:2
I see this is the only dropped item that has not increased since the code change. Possible due to that I don't have a wired PC connected to a LAN port?

ethwan Link encap:Ethernet HWaddr C5:9E
inet6 addr: c59e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:3660140 errors:0 dropped:10034 overruns:0 frame:0
TX packets:2497657 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:981058200 (935.6 MiB) TX bytes:558229734 (532.3 MiB)
Interrupt:255

 

[kamoj]

The Dropped figures might be of pure random chance.
As I said before, Dropped packages should not cause data corruption.
Corrupt packages should be re-sent!

It's could e.g. just be a way of seeing that the firewall is working!
Here is an example where I moved a lot of files in my network with router in router mode.
I have checksum on all files, and non are corrupt after copying between different ports and devices:

ethlan    Link encap:Ethernet  HWaddr
          inet6 addr: /64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:817931705 errors:0 dropped:134240202 overruns:1759379712 frame:0
          TX packets:1416810674 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:108602122769 (101.1 GiB)  TX bytes:1831627287501 (1.6 TiB)
          Interrupt:2

So I think your/mine/these tests are of no big value unless we check the data corruption as well!
But thank you again for all your invaluable help!!!

 

[e38BimmerFN]

I did notice that after re-connecting my R7800 up in AP mode, that i'm not seeing any errors like when I first confirmed this issue with the other poster. Makes me wonder if there was a bad cable or possible connection I had before was causing this rather something with in the FW code.

Glad to be of help.

 

[mr-b]

Ok I'm running :
Nighthawk(R) X4S R7800
Router Firmware Version (Voxel) V1.0.2.76.1SF
Kamoj Add-on V5.2b2-4
and as an AP but in router mode and my current connection is into a LAN port.

So which stats should I be monitoring? The prev posts with stats aren't clear which cmds were used, nor what the other cmds (ethtool & ifconfig) do.

Also do I need to configure the router in AP mode? I'd prefer not to as it'll need manual reconfig ... Isn't that effectively just a UI tweak?

 

[kamoj]

If you shall test you must connect it to WAN port in AP-mode and the test transferred files for checksum-errors.
(The commands can not show bad packages.)

 

[pato]

If you use Windows, install the freeware HashTab by implbits. This tool adds a menu to the file properties.
Then simply copy a large file from one PC to another (for example NAS) and then right click -> properties on the file and compare the checksums.
Repeat this a few times. The checksum must always stay the same.