James Carlson 已写入:
>As part of investigating the troubles behind CR 6764186, Pengcheng
>Chen found that dladm_wlan_scan can wipe out a connected interface
>rather unexpectedly.
>
>The current dladm_wlan_scan() code does this before starting the scan:
>
> status = do_get_linkstatus(linkid, &wl_status, sizeof (wl_status));
>
>and then this after completion:
>
> if (wl_status != WL_CONNECTED) {
> status = do_get_linkstatus(linkid, &wl_status,
> sizeof (&wl_status));
> if (status != DLADM_STATUS_OK)
> goto done;
> if (wl_status == WL_CONNECTED)
> (void) do_disconnect(linkid, buf, sizeof (buf));
>
>Variations on this logic appear to have been in the code since the
>very first integration as part of PSARC 2007/140. The effect of this
>code is that if we become connected while the scan is running, we
>immediately disconnect after the scan is done.
>
>
I guess these codes is tend to fix some automatic connection issue
on some old drivers when the first integration. Those old drivers
may connect to a AP automatically after scan complete.
>What isn't clear is why the code needs to do this. The questions this
>brings up are:
>
> - What was the original purpose of this code? Does anyone remember?
> I can't seem to find a CR related to this code.
>
> - Do (or should) the wireless drivers support running a scan at the
> same time that connect is requested? If not, then whose
> responsibility should it be to ensure serialization of these
> operations?
>
>
Yes, when a scan is running, if connect is requested, the "scan"
will be canceled, and "connect" will be executed.
See ieee80211_cancel_scan() of net80211 kernel module.
--
Quaker
>Any hints or pointers welcome.
>
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
