[ElHeffe]

I have been running DD-WRT in AP mode on some WRT3200ACM devices for quite a few years. A few months ago, I updated them and the devices refused to allow me GUI access. Sometimes the pages would start to load but would never complete. This is also described in the thread Major problem with dd-wrt on Linksys WRT3200ACM.

I think this is a problem with some sort of lockout or rate limiting code.

The test:
SSH to the device and see that it works.
Exit the SSH session.
Now visit the HTTPS site in a browser. See the site perform badly in the browser with long timeouts. Use WireShark to observe tons of TCP retransmits, as if iptables or the server is dropping packets.
Now attempt to SSH to the device; the device now appears to drop the SSH packets and does not complete a connection.
Now, ssh to the device from another IP address, it will succeed immediately and you will get a shell over SSH.

I noticed this problem in a build from March 2021. I've since used SSH to upgrade to the May 21, 2021 build and the same problem still exists.

I suspect there is some new rate limit nvram parameter or setting that defaulted to zero and is blocking attempts to use the GUI.

I have looked through the recent changesets, but do not see any rate limiting (NOTE: I can trigger this code if I try hard enough in other ways, but it is likely not the problem as most of the time I do not see the log message "client %s is blocked, terminate connection".)

Is there an nvram setting that I can change to change this behaviour? I've looked through all 1563 NVRAM settings (`nvram show | wc -l`) but didn't see anything obvious.

Is there something I am missing?

[ElHeffe]

Beginning output of dmesg:

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.268 (root@server2) (gcc version 9.2.0 (OpenWrt
GCC 9.2.0 r10880-cb3c4c713d) ) #2608 SMP Thu May 20 06:06:39 +07 2021
[ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructio
n cache
[ 0.000000] OF: fdt:Machine model: Linksys WRT3200ACM


Short snippet of /var/tmp/messages (although there isn't much in there):
May 24 22:57:47 mainfloor_ap daemon.info ntpclient[24251]: Time set from pool.ntp.org [159.203.82.102].
May 24 22:57:47 mainfloor_ap daemon.info process_monitor[2186]: cyclic NTP Update success (servers pool.ntp.org)
May 24 23:21:29 mainfloor_ap daemon.err httpd[1796]: httpd : Request Error Code 408: Unexpected connection close in intitial request

`iptables -L` does not show anything interesting (I thought it would, so the rate limiting must be elsewhere...)

[Justanotherbrokenrouter]

[ElHeffe]

Thank you. I can't get to the GUI. How do I change channels from the command line? A doc link will suffice.

[foz111]

try SSH in and run stop and start command to see if that gets you in gui

[ElHeffe]

wlan0_channel2=0
wlan0_channel=5220
wlan0_channelbw=80

I can see the channel but I'm worried I will set an invalid value. I've done that before and been very disappointed in the results. Is there a table of known good values?

[ElHeffe]

[kernel-panic69]

Using https via LAN has always seemed quirky. It is discussed plenty in the forums here, but I am not going to google it and link every thread or wiki article about it (refer to the forum rules and quidelines). Now, that being said, two questions: Why would you want to access via wifi and why would you need https on the lan side of the router? There are options to either restrict access to only a single IP / MAC address, or only allow access via ethernet switch and not wireless.

[ElHeffe]

[kernel-panic69]

What I am saying is that you should probably look into locking out wireless access to the webUI (via ebtables, most likely) and locking out all but one specific IP or MAC address to access the webUI over wired ethernet. The https webUI access functionality is generally for accessing the router via the WAN, anyway. Secure password for webUI access always helps, too.

[ElHeffe]

I enabled http and the GUI performed better, but wireshark still shows multiple TCP retransmits and errors. There are enough browser errors that I would not trust it for a firmware update or any management tasks even over wired ethernet.

I do not have a WAN on these devices; they are in AP mode. I have the ethernet jack plugged into the bank of 4 LAN ethernet jacks. The IP address is manually configured on each device (although I do have static DHCP entries set up for each device on my DHCP server).

[kernel-panic69]

So then we have to consider 1) what browser you are using and 2) if you're co-mingling your webUI access with your internet browsing. Both are definitely involved here. If you're cruisin' the 'net with your webUI access in one of the tabs, not using private browsing or incognito mode, have extensions and add-ons loaded, etc., then that *will* contribute to issues, most guaranteed.

[ElHeffe]

I have tested Chrome Incognito, Brave, Safari and even command line links2 browser. All have had the same TCP retransmits that are easily visible in wireshark.

[kernel-panic69]

That is likely 'normal' behavior, I would have to ask BrainSlayer to be sure or look deep into the code. This is why it is advised to use a separate browser from your internet cruising and have zero extensions loaded.