2008-02-28 02:34:43 +01:00
|
|
|
/*
|
|
|
|
* wpa_supplicant - Temporary BSSID blacklist
|
|
|
|
* Copyright (c) 2003-2007, Jouni Malinen <j@w1.fi>
|
|
|
|
*
|
2012-02-11 15:46:35 +01:00
|
|
|
* This software may be distributed under the terms of the BSD license.
|
|
|
|
* See README for more details.
|
2008-02-28 02:34:43 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "includes.h"
|
|
|
|
|
|
|
|
#include "common.h"
|
|
|
|
#include "wpa_supplicant_i.h"
|
|
|
|
#include "blacklist.h"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* wpa_blacklist_get - Get the blacklist entry for a BSSID
|
|
|
|
* @wpa_s: Pointer to wpa_supplicant data
|
|
|
|
* @bssid: BSSID
|
|
|
|
* Returns: Matching blacklist entry for the BSSID or %NULL if not found
|
|
|
|
*/
|
|
|
|
struct wpa_blacklist * wpa_blacklist_get(struct wpa_supplicant *wpa_s,
|
|
|
|
const u8 *bssid)
|
|
|
|
{
|
|
|
|
struct wpa_blacklist *e;
|
|
|
|
|
2012-11-01 19:41:27 +01:00
|
|
|
if (wpa_s == NULL || bssid == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2008-02-28 02:34:43 +01:00
|
|
|
e = wpa_s->blacklist;
|
|
|
|
while (e) {
|
|
|
|
if (os_memcmp(e->bssid, bssid, ETH_ALEN) == 0)
|
|
|
|
return e;
|
|
|
|
e = e->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* wpa_blacklist_add - Add an BSSID to the blacklist
|
|
|
|
* @wpa_s: Pointer to wpa_supplicant data
|
|
|
|
* @bssid: BSSID to be added to the blacklist
|
2010-11-25 21:00:04 +01:00
|
|
|
* Returns: Current blacklist count on success, -1 on failure
|
2008-02-28 02:34:43 +01:00
|
|
|
*
|
|
|
|
* This function adds the specified BSSID to the blacklist or increases the
|
|
|
|
* blacklist count if the BSSID was already listed. It should be called when
|
|
|
|
* an association attempt fails either due to the selected BSS rejecting
|
|
|
|
* association or due to timeout.
|
|
|
|
*
|
|
|
|
* This blacklist is used to force %wpa_supplicant to go through all available
|
|
|
|
* BSSes before retrying to associate with an BSS that rejected or timed out
|
|
|
|
* association. It does not prevent the listed BSS from being used; it only
|
|
|
|
* changes the order in which they are tried.
|
|
|
|
*/
|
|
|
|
int wpa_blacklist_add(struct wpa_supplicant *wpa_s, const u8 *bssid)
|
|
|
|
{
|
|
|
|
struct wpa_blacklist *e;
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
struct os_reltime now;
|
2008-02-28 02:34:43 +01:00
|
|
|
|
2012-11-01 19:41:27 +01:00
|
|
|
if (wpa_s == NULL || bssid == NULL)
|
|
|
|
return -1;
|
|
|
|
|
2008-02-28 02:34:43 +01:00
|
|
|
e = wpa_blacklist_get(wpa_s, bssid);
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
os_get_reltime(&now);
|
2008-02-28 02:34:43 +01:00
|
|
|
if (e) {
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
e->blacklist_start = now;
|
2008-02-28 02:34:43 +01:00
|
|
|
e->count++;
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
if (e->count > 5)
|
|
|
|
e->timeout_secs = 1800;
|
|
|
|
else if (e->count == 5)
|
|
|
|
e->timeout_secs = 600;
|
|
|
|
else if (e->count == 4)
|
|
|
|
e->timeout_secs = 120;
|
|
|
|
else if (e->count == 3)
|
|
|
|
e->timeout_secs = 60;
|
|
|
|
else
|
|
|
|
e->timeout_secs = 10;
|
|
|
|
wpa_printf(MSG_INFO, "BSSID " MACSTR
|
|
|
|
" blacklist count incremented to %d, blacklisting for %d seconds",
|
|
|
|
MAC2STR(bssid), e->count, e->timeout_secs);
|
2010-11-25 21:00:04 +01:00
|
|
|
return e->count;
|
2008-02-28 02:34:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
e = os_zalloc(sizeof(*e));
|
|
|
|
if (e == NULL)
|
|
|
|
return -1;
|
|
|
|
os_memcpy(e->bssid, bssid, ETH_ALEN);
|
|
|
|
e->count = 1;
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
e->timeout_secs = 10;
|
|
|
|
e->blacklist_start = now;
|
2008-02-28 02:34:43 +01:00
|
|
|
e->next = wpa_s->blacklist;
|
|
|
|
wpa_s->blacklist = e;
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
wpa_printf(MSG_DEBUG, "Added BSSID " MACSTR
|
|
|
|
" into blacklist, blacklisting for %d seconds",
|
|
|
|
MAC2STR(bssid), e->timeout_secs);
|
2008-02-28 02:34:43 +01:00
|
|
|
|
2010-11-25 21:00:04 +01:00
|
|
|
return e->count;
|
2008-02-28 02:34:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* wpa_blacklist_del - Remove an BSSID from the blacklist
|
|
|
|
* @wpa_s: Pointer to wpa_supplicant data
|
|
|
|
* @bssid: BSSID to be removed from the blacklist
|
|
|
|
* Returns: 0 on success, -1 on failure
|
|
|
|
*/
|
|
|
|
int wpa_blacklist_del(struct wpa_supplicant *wpa_s, const u8 *bssid)
|
|
|
|
{
|
|
|
|
struct wpa_blacklist *e, *prev = NULL;
|
|
|
|
|
2012-11-01 19:41:27 +01:00
|
|
|
if (wpa_s == NULL || bssid == NULL)
|
|
|
|
return -1;
|
|
|
|
|
2008-02-28 02:34:43 +01:00
|
|
|
e = wpa_s->blacklist;
|
|
|
|
while (e) {
|
|
|
|
if (os_memcmp(e->bssid, bssid, ETH_ALEN) == 0) {
|
|
|
|
if (prev == NULL) {
|
|
|
|
wpa_s->blacklist = e->next;
|
|
|
|
} else {
|
|
|
|
prev->next = e->next;
|
|
|
|
}
|
|
|
|
wpa_printf(MSG_DEBUG, "Removed BSSID " MACSTR " from "
|
|
|
|
"blacklist", MAC2STR(bssid));
|
|
|
|
os_free(e);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
prev = e;
|
|
|
|
e = e->next;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
wpa_supplicant: Implement time-based blacklisting
wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
2020-06-11 23:11:16 +02:00
|
|
|
/**
|
|
|
|
* wpa_blacklist_is_blacklisted - Check the blacklist status of a BSS
|
|
|
|
* @wpa_s: Pointer to wpa_supplicant data
|
|
|
|
* @bssid: BSSID to be checked
|
|
|
|
* Returns: count if BSS is currently considered to be blacklisted, 0 otherwise
|
|
|
|
*/
|
|
|
|
int wpa_blacklist_is_blacklisted(struct wpa_supplicant *wpa_s, const u8 *bssid)
|
|
|
|
{
|
|
|
|
struct wpa_blacklist *e;
|
|
|
|
struct os_reltime now;
|
|
|
|
|
|
|
|
e = wpa_blacklist_get(wpa_s, bssid);
|
|
|
|
if (!e)
|
|
|
|
return 0;
|
|
|
|
os_get_reltime(&now);
|
|
|
|
if (os_reltime_expired(&now, &e->blacklist_start, e->timeout_secs))
|
|
|
|
return 0;
|
|
|
|
return e->count;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-02-28 02:34:43 +01:00
|
|
|
/**
|
|
|
|
* wpa_blacklist_clear - Clear the blacklist of all entries
|
|
|
|
* @wpa_s: Pointer to wpa_supplicant data
|
|
|
|
*/
|
|
|
|
void wpa_blacklist_clear(struct wpa_supplicant *wpa_s)
|
|
|
|
{
|
|
|
|
struct wpa_blacklist *e, *prev;
|
|
|
|
|
|
|
|
e = wpa_s->blacklist;
|
|
|
|
wpa_s->blacklist = NULL;
|
|
|
|
while (e) {
|
|
|
|
prev = e;
|
|
|
|
e = e->next;
|
|
|
|
wpa_printf(MSG_DEBUG, "Removed BSSID " MACSTR " from "
|
|
|
|
"blacklist (clear)", MAC2STR(prev->bssid));
|
|
|
|
os_free(prev);
|
|
|
|
}
|
|
|
|
}
|