Router: Netgear R7800
Firmware: DD-WRT v3.0-r41328 std (10/15/19)
Kernel: Linux 4.9.196 #481 SMP Mon Oct 14 02:15:59 CEST 2019 armv7l
Mode/Status: Gateway / working
Issues/Errors: Everything working well EXCEPT Cannot print using USB to router connections.
Fresh install firmware upgrade from factory settings with recent factory upgrade.
Joined: 08 May 2018 Posts: 14246 Location: Texas, USA
Posted: Tue Oct 22, 2019 14:39 Post subject:
Kayakjack wrote:
Router: Netgear R7800
Firmware: DD-WRT v3.0-r41328 std (10/15/19)
Kernel: Linux 4.9.196 #481 SMP Mon Oct 14 02:15:59 CEST 2019 armv7l
Mode/Status: Gateway / working
Issues/Errors: Everything working well EXCEPT Cannot print using USB to router connections.
Fresh install firmware upgrade from factory settings with recent factory upgrade.
Router/Version: E3000 V1
File: dd-wrt.v24-41328_NEWD-2_K3.x_mega-e3000.bin
Kernel: Mode: AP
Status: Flash failed, bricked, TFTP doesn't work to unbrick.
I went from 41174. Unfortunately, flashing this version failed and the router is bricked. I've tried to flash using TFTP. If a small (4 M ) version is used, TFTP says transfer successful and ping responses continue but TTL never changes and it eventually stops responding.
Router: Netgear R7800
Firmware: DD-WRT v3.0-r41328 std (10/15/19)
Kernel: Linux 4.9.196 #481 SMP Mon Oct 14 02:15:59 CEST 2019 armv7l
Mode/Status: Gateway / working
Issues/Errors: Everything working well EXCEPT Cannot print using USB to router connections.
Fresh install firmware upgrade from factory settings with recent factory upgrade.
You see they just loosen the max. memory size limitations of TCP/UDP/socket connections. But any scripts modifying any queue sizes (e.g. netdev_max_backlog, tcp_max_syn_backlog) only make things worse.
Now I'm quite sure those TCP/UDP hangs in Wifi are related to the congestion control. There should be something conflicted or crashed/deadlocks inside somewhere of the congestion control working place.
Hangs usually happen when:
1. Suddenly huge amount of connections created at the same moment, whatever TCP or UDP or mixed, whatever how less amount of data each connection is actually transferring.
2. Any wifi devices newly connected (in link layer) to the AP or disconnected from the AP or shutdown.
3. Any wifi devices are woken up from sleep mode (e.g. turning on the screen of a phone) or wifi link speed changed (slower or faster than before, default auto Transmission Fixed Rate in DD-WRT)
4. Multiple wifi devices streaming videos or downloading large files at the same time.
I've tested about this for several weeks already, repeatedly proved that.
Usually images, video and audio connections hang much more than text or command connections.
Wifi reactions become longer latency, longer response time after devices repeatedly connect and disconnect from the AP for many times. But much less hangs when longer latency, longer response time.
Conclusion: when the wifi link speed changes or busy transportations which trigger the congestion control take places, transport layer (TCP/UDP) hangs occur in wifi.
Router/Version: ASUS RT-AC3100
File: asus_rt-ac3100-firmware.trx
Firmware: DD-WRT v3.0-r41328 std (10/15/19)
Kernel: Linux DD-WRT 4.4.196 #113 SMP Tue Oct 15 07:04:36 +04 2019 armv7l DD-WRT
CPU: Broadcom BCM4709
CPU Features: EDSP
CPU Frequency: 1400 MHz
Mode: Gateway/AP
TCP Congestion Control: Westwood
Status: reset / nvram cleared
My setup is very simple. AP, Port Forwarding, DDNS, Fixed 5Ghz channel (tested throughput VHT80-lower/lower-channel 149).
My clients have been consistently loosing connection with the 5Ghz band after 3-4 days; it used to be 1-2 days in recent builds. I agree with the behavior characterized by many of the posts in this thread wrt hangs. _________________ ASUS - RT-AC3100 - Build 41328
