| Message ID | 1386752617-18904-1-git-send-email-guoqiang.liu@archermind.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Wed, Dec 11, 2013 at 05:03:37PM +0800, Guoqiang Liu wrote: > If AP change the ssid, wpa_suuplicant only remove the previous bss > enrty when the one not be included in scan result twice, as the > DEFAULT_BSS_EXPIRATION_SCAN_COUNT is 2. and it have enough time for > AP broadcasts new beacons frame with new ssid before the previous > bss removed, and then two bss will share a same bssid. > > If new ssid is connected before. it will auto connect it, which > will result in the previous bss enrty always in used, but it is > invalid, the root cause is that wpa_suuplicant only distinguish > different bsses base on bssid. but ssid shoud be check too. Please read the top level CONTRIBUTIONS file and add a Signed-hostap: tag into the commit message as described there. I'm not completely sure I understood what the real problem here is. Could you please clarify where this causes issues? > diff --git a/wpa_supplicant/bss.c b/wpa_supplicant/bss.c > static int wpa_bss_in_use(struct wpa_supplicant *wpa_s, struct wpa_bss *bss) > + if (os_memcmp(bss->bssid, wpa_s->bssid, ETH_ALEN) == 0 || > + os_memcmp(bss->bssid, wpa_s->pending_bssid, ETH_ALEN) == 0) { > + /* > + * It not enough to only compare bssid to distinguish a bss, > + * the case two bss share a same bssid can occurs if AP change > + * SSID. > + */ > + int ssid_len = wpa_s->current_ssid->ssid_len; This looks risky.. Couldn't wpa_s->current_ssid be NULL here?
This seems like it may be similar or the same to a question I posted "Question regarding BSSID table and hidden SSID" When using a hidden SSID, there are multiple entries in the BSS table for the same BSSID. One has a NULL for the SSID and the second entry contains the specific hidden SSID. Our problem is that the table value for the specific hidden SSID is never updated after the intial association. The problem that this causes is that any subsequent decisions on whether or not to roam from this AP are made based on incorrect signal strength values for the currently associated AP. Dan LaPointe Sr. Systems Engineer Prime Solutions, LLC Dan.LaPointe@primeso.com *Key People in Critical Places* On Sun, Dec 15, 2013 at 12:02 AM, Jouni Malinen <j@w1.fi> wrote: > On Wed, Dec 11, 2013 at 05:03:37PM +0800, Guoqiang Liu wrote: > > If AP change the ssid, wpa_suuplicant only remove the previous bss > > enrty when the one not be included in scan result twice, as the > > DEFAULT_BSS_EXPIRATION_SCAN_COUNT is 2. and it have enough time for > > AP broadcasts new beacons frame with new ssid before the previous > > bss removed, and then two bss will share a same bssid. > > > > If new ssid is connected before. it will auto connect it, which > > will result in the previous bss enrty always in used, but it is > > invalid, the root cause is that wpa_suuplicant only distinguish > > different bsses base on bssid. but ssid shoud be check too. > > Please read the top level CONTRIBUTIONS file and add a Signed-hostap: > tag into the commit message as described there. > > I'm not completely sure I understood what the real problem here is. > Could you please clarify where this causes issues? > > > diff --git a/wpa_supplicant/bss.c b/wpa_supplicant/bss.c > > static int wpa_bss_in_use(struct wpa_supplicant *wpa_s, struct wpa_bss > *bss) > > > + if (os_memcmp(bss->bssid, wpa_s->bssid, ETH_ALEN) == 0 || > > + os_memcmp(bss->bssid, wpa_s->pending_bssid, ETH_ALEN) == > 0) { > > + /* > > + * It not enough to only compare bssid to distinguish a > bss, > > + * the case two bss share a same bssid can occurs if AP > change > > + * SSID. > > + */ > > + int ssid_len = wpa_s->current_ssid->ssid_len; > > This looks risky.. Couldn't wpa_s->current_ssid be NULL here? > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap >
On Mon, 2013-12-16 at 11:03 -0500, Daniel Lapointe wrote: > This seems like it may be similar or the same to a question I posted > "Question regarding BSSID table and hidden SSID" When using a hidden > SSID, there are multiple entries in the BSS table for the same BSSID. > One has a NULL for the SSID and the second entry contains the specific > hidden SSID. Our problem is that the table value for the specific > hidden SSID is never updated after the intial association. The > problem that this causes is that any subsequent decisions on whether > or not to roam from this AP are made based on incorrect signal > strength values for the currently associated AP. Which kernel version is everybody using? We made some major improvements in this area in cfg80211 fairly recently. johannes
We are using v3.10-2-0-ga29c78e Dan LaPointe Sr. Systems Engineer Prime Solutions, LLC Dan.LaPointe@primeso.com *Key People in Critical Places* On Mon, Dec 16, 2013 at 11:27 AM, Daniel Lapointe <dan.lapointe@primeso.com>wrote: > We are using v3.10-2-0-ga29c78e > > Dan LaPointe > Sr. Systems Engineer > Prime Solutions, LLC > Dan.LaPointe@primeso.com > > *Key People in Critical Places* > > > On Mon, Dec 16, 2013 at 11:08 AM, Johannes Berg <johannes@sipsolutions.net > > wrote: > >> On Mon, 2013-12-16 at 11:03 -0500, Daniel Lapointe wrote: >> > This seems like it may be similar or the same to a question I posted >> > "Question regarding BSSID table and hidden SSID" When using a hidden >> > SSID, there are multiple entries in the BSS table for the same BSSID. >> > One has a NULL for the SSID and the second entry contains the specific >> > hidden SSID. Our problem is that the table value for the specific >> > hidden SSID is never updated after the intial association. The >> > problem that this causes is that any subsequent decisions on whether >> > or not to roam from this AP are made based on incorrect signal >> > strength values for the currently associated AP. >> >> Which kernel version is everybody using? We made some major improvements >> in this area in cfg80211 fairly recently. >> >> johannes >> >> >> >
On Mon, 2013-12-16 at 12:30 -0500, Daniel Lapointe wrote:
> We are using v3.10-2-0-ga29c78e
That should already be fixed for hidden BSSes, at least kernel-side.
johannes
Fixed by the version that we are using, or by a more recent update? Dan LaPointe Sr. Systems Engineer Prime Solutions, LLC Dan.LaPointe@primeso.com *Key People in Critical Places* On Mon, Dec 16, 2013 at 1:57 PM, Johannes Berg <johannes@sipsolutions.net>wrote: > On Mon, 2013-12-16 at 12:30 -0500, Daniel Lapointe wrote: > > We are using v3.10-2-0-ga29c78e > > That should already be fixed for hidden BSSes, at least kernel-side. > > johannes > > >
On Mon, 2013-12-16 at 13:59 -0500, Daniel Lapointe wrote:
> Fixed by the version that we are using, or by a more recent update?
Fixed *in* the version that you are using.
johannes
We are still seeing that a client will not properly roam because it has "old / incorrect" values for signal strength in the BSS table. Is there a corresponding fix or configuration option for the supplicant code that we need as well? Dan LaPointe Sr. Systems Engineer Prime Solutions, LLC Dan.LaPointe@primeso.com *Key People in Critical Places* On Mon, Dec 16, 2013 at 2:22 PM, Johannes Berg <johannes@sipsolutions.net>wrote: > On Mon, 2013-12-16 at 13:59 -0500, Daniel Lapointe wrote: > > Fixed by the version that we are using, or by a more recent update? > > Fixed *in* the version that you are using. > > johannes > > >
Can you tell me what patch the fix was incorporated into? Also, what function is used to update BSS table values for an actively associated AP? Thanks, Dan LaPointe On Mon, Dec 16, 2013 at 2:30 PM, Daniel Lapointe <dan.lapointe@primeso.com>wrote: > We are still seeing that a client will not properly roam because it has > "old / incorrect" values for signal strength in the BSS table. Is there a > corresponding fix or configuration option for the supplicant code that we > need as well? > > Dan LaPointe > > > > On Mon, Dec 16, 2013 at 2:22 PM, Johannes Berg <johannes@sipsolutions.net>wrote: > >> On Mon, 2013-12-16 at 13:59 -0500, Daniel Lapointe wrote: >> > Fixed by the version that we are using, or by a more recent update? >> >> Fixed *in* the version that you are using. >> >> johannes >> >> >> >
On Wed, 2013-12-18 at 09:19 -0500, Daniel Lapointe wrote: > Can you tell me what patch the fix was incorporated into? Also, what > function is used to update BSS table values for an actively associated > AP? Around here: commit 776b3580178f2065838fa0db0eb7a41b57495c0a Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 1 02:06:18 2013 +0100 cfg80211: track hidden SSID networks properly johannes
diff --git a/wpa_supplicant/bss.c b/wpa_supplicant/bss.c index df1a0c8..08b8224 100644 --- a/wpa_supplicant/bss.c +++ b/wpa_supplicant/bss.c @@ -277,9 +277,24 @@ static int wpa_bss_known(struct wpa_supplicant *wpa_s, struct wpa_bss *bss) static int wpa_bss_in_use(struct wpa_supplicant *wpa_s, struct wpa_bss *bss) { - return bss == wpa_s->current_bss || - os_memcmp(bss->bssid, wpa_s->bssid, ETH_ALEN) == 0 || - os_memcmp(bss->bssid, wpa_s->pending_bssid, ETH_ALEN) == 0; + if (bss == wpa_s->current_bss) + return 1; + + if (os_memcmp(bss->bssid, wpa_s->bssid, ETH_ALEN) == 0 || + os_memcmp(bss->bssid, wpa_s->pending_bssid, ETH_ALEN) == 0) { + /* + * It not enough to only compare bssid to distinguish a bss, + * the case two bss share a same bssid can occurs if AP change + * SSID. + */ + int ssid_len = wpa_s->current_ssid->ssid_len; + u8 *ssid = wpa_s->current_ssid->ssid; + if (bss->ssid_len == ssid_len && + os_memcmp(bss->ssid, ssid, ssid_len) == 0) + return 1; + } + + return 0; }
From: "guoqiang.liu" <guoqiang.liu@archermind.com> If AP change the ssid, wpa_suuplicant only remove the previous bss enrty when the one not be included in scan result twice, as the DEFAULT_BSS_EXPIRATION_SCAN_COUNT is 2. and it have enough time for AP broadcasts new beacons frame with new ssid before the previous bss removed, and then two bss will share a same bssid. If new ssid is connected before. it will auto connect it, which will result in the previous bss enrty always in used, but it is invalid, the root cause is that wpa_suuplicant only distinguish different bsses base on bssid. but ssid shoud be check too. --- wpa_supplicant/bss.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)