Ok that's fine I suppose, if that works for you. We're going a little bit offtopic here so I think I'm going to leave it ok?
Yeah that's what I suspected. When you WiFi disable most devices will send a de-authenticate signal. So the accesspoint knows that a station is gone. And since mobile devices have to save their battery somehow they consistently go into deep-sleep and wake up when needed. There is an timeout so stations don't have to re initiate the connection in such cases and that's why the AP will wait. But still 5min is quite long.
never mind, this 5min seems to be the default I suppose:
Station inactivity limit
If a station does not send anything in ap_max_inactivity seconds, an
empty data frame is sent to it in order to verify whether it is
still in range. If this frame is not ACKed, the station will be
disassociated and then deauthenticated. This feature is used to
clear station table of old entries when the STAs move out of the
The station can associate again with the AP if it is still in range;
this inactivity poll is just used as a nicer way of verifying
inactivity; i.e., client will not report broken connection because
disassociation frame is not sent immediately without first polling
the STA with a data frame.
> default: 300 (i.e., 5 minutes)
The inactivity polling can be disabled to disconnect stations based on
inactivity timeout so that idle stations are more likely to be disconnected
even if they are still in range of the AP. This can be done by setting
> skip_inactivity_poll to 1 (default 0).
I will investigate this myself and see I can verify your results. Because I don't know what LEDE's default config is.
Because @MagicSimi tried this already and it did not seem to make any difference as he mentioned in his topic. Don't know why it does not work though.
Also since you are probably using it for some sort of Domotica application. Wouldn't pinging a client be an option? Just as a workaround. At least that's what I've been doing for quite some time, and ignoring low percentage of false-negatives I sometimes get because a station missed a ping packet it's working just fine.
Yeah I use openhab for my home automation but same thing, I did trying pinging device as an option but this was very hit and miss with my setup I think because the phones as you say go into deep sleep and become disassociated. To be honest this setup I have with the router sending associated stations has been flawless I've had no false presence detections for almost 5 months. Until I updated to the latest build.
Thanks for investigating this problem.
Do you think this inactivity polling was active in the r4707 build but isn't enabled in the latest build ?
I don't know yet, it could also be a parsing issue from LEDE's config files to Hostapd config files.
Ive just updated to the next update available to see if it might have been a bad build (r5201) however the bug is still present so I’ve just done digging into the base packages on davidc502 build page and discovered that the hostapd used in my stable (r4707) build is dated 2016-12-19
However it was updated in builds after (r5032) to 2017-08-24 so basically the last 4 builds
Do you think this is the reason for the bug ?
thats what i was thinking..having more than one controller was what i was suspecting. maybe just having hostapd-mini, it probably has it disabled by default.
Perhaps this commit for the mwlwifi drivers is related to the issue commented here:
I guess @davidc502 will update his build soon; for those running stock LEDE, you can try my packages from:
Have you talked with yuhhaurlin to get to him to include your changes that fix this issue?
But those are not my changes... I just pointed to a commit in yuhhaurlin's repo, and I package I prepared with those changes. I am just packaging whatever yuhhaurlin posts in his repo, I am not editing the code myself.