| Summary: | wpa_supplicant behavior in shaky network environment | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Antti Mäkelä <zarhan> |
| Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Sounds like a good idea. However, this would have to be implemented in wpa_supplicant or wpa_cli and not the script. I don't have the time to look into this right now, so patches welcome :) (In reply to comment #1) > However, this would have to be implemented in wpa_supplicant or wpa_cli and not > the script. Taking a look at wpa_cli.c it's certainly feasible to patch that. Grabbing some ideas from ifplugd.c at least. Slight problem is that unlike ifplugd which parses the status from input and executes the action separately (allowing the delay), in wpa_cli.c everything (parsing the status and executing the script) happens all in static void wpa_cli_action_process(const char *msg) - so there's no possibility to just start a timer, return to master loop and wait for the timer to go off..This will be requiring a bit more restructuring. If you do write this patch, send it upstream please. Or re-open this bug. |
In wired environments, and wireless too, when using ifplugd, there is a "delay down"-option: -d | --delay-down= SECS Specify delay for deconfiguring interface (default: 5) This allows for a brief hysteresis in case there is only a momentary lapse in connection. I'm currently working in an environment that is flooded with wireless networks - there must be like 50 SSIDs showing up on scan. The network is very congested - however, things still work ok as there is not much of actual traffic, it's just a bunch of beacons. However, what happens is that occasionally (every few minutes or so), my wireless gets disconnected for a while - few seconds that is. Unfortunately, when this happens, /etc/wpa_supplicant/wpa_cli.sh is called with "DISCONNECTED" option which causes the entire wireless interface - and all dependendant services - to go down with it. This included, amongst other things, VPN client daemon and sshd. In addition, since having interface go down kills DHCP and clears the interface address, all my ongoing connections to the outside world (web surfing etc) break and have to be re-established (pressing reload on browser). I'd like to have some sort of "threshold timeout" with the wpa_supplicant information handling so that if there is only a brief disconnect, stuff doesn't immediately break - like I can have with ifplugd. I could fix the shutting-down of services by changing the {EXEC} stop to {EXEC} pause instead of stop, but losing all my web-browsing sessions still happens.. Anyway, my wpa_cli logs look right now like this: <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0f:24:d4:0c:22 (SSID='testwlan' freq=0 MHz) <2>Associated with 00:0f:24:d4:0c:22 <2>CTRL-EVENT-CONNECTED - Connection to 00:0f:24:d4:0c:22 completed (reauth) [id=8 id_str=] The connection is still fine for most part - as a matter of fact, I'm writing this bug report over it - but the constant breakages kinda make it annoying to all the time reload webpages (ie. reset TCP sessions from scratch). Anyway, I'd like to propose a following edit to the wpa_supplicant action script: On Disconnect, start timer from 0. When timer reaches a certain value, default = 5 secs, stop (or pause) interface and set timer to -1. On Connect, check timer. If 0 < timer <5, check if SSID is same as previous SSID. If SSID's match, there has been no change in the network. Return without doing nothing. If timer not between 0-5, or the SSIDs differ, start interface normally (since you need a new IP address and so on). Has something like this already been committed to baselayout 1.13? If not then I can cook up the SSID-matching logic...only thing is that I don't really know how to implement that timer while still being able to receive new events from wpa_supplicant...needs a separate background process.