I have some comments on this issue. I don't think there is any loop going on, and I think the hysteresis check is probably the wrong way to deal with this.
First, I think the reason the reporter is seeing dhclient repeatedly obtaining and releasing is not because there is any kind of loop, but because there is simply a backlog of disconnect/reconnect actions. That is, wpa_supplicant generates a bunch of disconnect/reconnect events, wpa_cli processes them one at a time, executing wpa_action synchronously. Since wpa_action takes a while to finish (obtaining a lease), a bunch of events pile up while wpa_action is running. wpa_cli isn't smart enough to know that it really only has to process the latest event. So even when wpa_supplicant has stabilized and is not generating an more events, wpa_cli keeps calling wpa_action to bring the interface down and up. I don't think there are any "artificial" events as suggested in the comments to wpa_hysteresis_event and wpa_hysteresis_check (unless that is in reference to a different problem). I don't think that refusing to process events that come in quick succession is the answer at all. Unless you have a separate justification for that, I would get rid of it. What really needs to happen is that wpa_cli needs to understand that some of the events it gets obviate earlier events. If there are a bunch of disconnect/connect events queued, only act on the last. If you add in a short delay before processing a disconnect event, any connect events that come in during the the delay will result in the disconnect being ignored. Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
