WRT3200ACM: wifi devices don't get disconnected

I upgraded my Linksys WRT3200ACM to SNAPSHOT, r5216 (to fix the krack exploits). Now, wifi devices that are idle for a long time don't get disconnected anymore.

I tried to set "option max_inactivity '300' " in the "wifi-iface" sections of /etc/config/wireless, but that didn't change anything.

One thing I noticed, which might or might not have anything to do with this:

At bootup the time is far in the future. The timestamp of all devices in /dev shows "Dec 1 2036". After /etc/init.d/sysfixtime runs, the system time is set to a more reasonable value. hwclock returns: "Mon Dec 1 14:15:19 2036". I tried to change that with "hwclock -w -u -f /dev/rtc0", but no effect and no error message.

Any ideas or pointers?

kernel version: 4.9.58
hostapd version: v2.7-devel

1 Like

What happens if you use 17.01.4 instead of snapshot?

for me, the 5ghz radio wouldn't even enable. on snapshot and 17.01.4

I will test 17.01.4 and then report back.

Note that current stable is behind on the mwlwifi driver. You will probably want this, especially with the rango, but you will than have a more recent BLOB than what comes OOTB with a build based on current master.

I saw that too, but only with a realtek AC usb client adapter, in LUCI and syslog it will act like is still connected, but I repeat, only that client
Using latest master

I installed stable 17.01.4 and this bug doesn't occur there. Idle clients get disconnected after a certain time, as expected.

Side note: Timestamp of the devices is still set to "Dec 1 2036" but that seems to be irrelevant.

Anybody intereseted in debugging the disconnect problem in trunk? I still have trunk on the alternate partition, so it would be easy for me to run some tests there.

Sure. As there is no real-time clock with battery, there is no real time as the early boot.

sysfixtime sets the system time to "last known good time" (= latest file timestamp in /etc)
after you get internet connectivity, ntp fetches the correct time for system time.

with the same mwlwifi driver?
Or with the old 2017-06-06 driver in 17.01.4?

(is the bug in LEDE 17.01 vs master, or in the mwlwifi driver 2017-06-06 vs. 2017-08-10?)

I think it is the same mwlwifi driver. For the stable firmware (17.01.4), I installed eduperez' pre-compiled driver. For my trunk version, I didn't change anything about the mwlwifi driver.

kmod-mwlwifi - 4.4.92+10.3.4.0-20170818-cbb631e-1