FS#36282 - [wpa_actiond] DISCONNECT/CONNECT not triggered for different networks with same ssid

Attached to Project: Arch Linux
Opened by Sebastian Wicki (gandro) - Friday, 26 July 2013, 12:08 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 06 July 2015, 04:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Since wpa_actiond uses the SSID to identify a network, a switch from one wpa_supplicant network to different network with the same SSID is not handled correctly: A REESTABLISHED event is triggered, instead of a DISCONNECT/CONNECT pair.

This leads to a bug in the upcoming version of netctl-auto, which allows the user to select a different network profile through the wpa_supplicant [1]: If two profiles have the same wireless SSID, but different IP configurations, a switch from one profile the the other does not trigger the action script with the CONNECT parameter and therefore the IP address is not reconfigured (although the id_str has changed).

I suggest to use the numerical network identifier of wpa_supplicant instead of the SSID. See the attached patch for more details about a possible implementation.

[1] https://github.com/joukewitteveen/netctl/pull/49
   0001-Use-the-numerical-networ... (3.8 KiB)
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 06 July 2015, 04:25 GMT
Reason for closing:  No response
Comment by Thomas Bächler (brain0) - Friday, 27 September 2013, 08:19 GMT
How does this handle large networks where more than one AP serves the same network?

I have a use case where several APs can be used to connect to the same network - sending a REESTABLISHED event makes sense in this case, even if the AP changed.
Comment by Sebastian Wicki (gandro) - Friday, 27 September 2013, 12:46 GMT
Each wpa_supplicant network id corresponds to a "network block" in the wpa_supplicant config. In a typical user configuration, there is one network block per ESSID. This network block is then used to connect to any AP which has the corresponding ESSID.

So with this patch the disconnect event is only triggered when you switch to another wpa_supplicant network. If you just switch the AP, the ESSID stays the same and therefore the network id does not change, so a REESTABLISHED event is triggered.

The only case where a AP switch within the same ESSID would cause the network id to change is when the current network config block does not match the new AP - i.e. when the user enforces a specific BSSID (MAC address of access point) for the network block or when the other AP has the same ESSID but uses different credentials.

If you just use one network block for all APs with the same ESSID (which is the normal case), then the behaviour is the same before, even with multiple APs.
Comment by Thomas Bächler (brain0) - Friday, 27 September 2013, 12:48 GMT
Ah, I see now. This seems like a sane approach. I didn't look at the code yet, but isn't old_ssid entirely unused now?
Comment by Sebastian Wicki (gandro) - Friday, 27 September 2013, 12:56 GMT
The variable is still used when action script is called with the DISCONNECT event.
Comment by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 15:37 GMT
Status?

Loading...