* Which APs to disregards from in inputting into the bss list
@ 2009-03-13 3:09 Luis R. Rodriguez
2009-03-13 3:14 ` Sujith
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Luis R. Rodriguez @ 2009-03-13 3:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Dan Williams, Jouni Malinen, Johannes Berg
Do we want to ignore certain APs if we determine they are bogus? An
example is 11n APs with WEP/TKIP. Would we rather not even store then
in our bss list so that way we wont' get reports from users not being
able to connect to such APs. Other examples might be if 11n APs have
HT IEs but their lengths are not right, or if the AP is HT40 and our
regulatory domain does now allow HT40.
The benefit I see with these early checks we won't get complaints
about not being able to connect to bogus APs or APs you shouldn't be
connected to anyway.
Luis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Which APs to disregards from in inputting into the bss list
2009-03-13 3:09 Which APs to disregards from in inputting into the bss list Luis R. Rodriguez
@ 2009-03-13 3:14 ` Sujith
2009-03-13 4:18 ` Luis R. Rodriguez
2009-03-13 8:03 ` Jouni Malinen
` (2 subsequent siblings)
3 siblings, 1 reply; 9+ messages in thread
From: Sujith @ 2009-03-13 3:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Dan Williams, Jouni Malinen, Johannes Berg
Luis R. Rodriguez wrote:
> Do we want to ignore certain APs if we determine they are bogus? An
> example is 11n APs with WEP/TKIP.
They are not bogus, we just fall back to legacy association.
Sujtih
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 3:14 ` Sujith
@ 2009-03-13 4:18 ` Luis R. Rodriguez
2009-03-13 4:43 ` Sujith
0 siblings, 1 reply; 9+ messages in thread
From: Luis R. Rodriguez @ 2009-03-13 4:18 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless, Dan Williams, Jouni Malinen, Johannes Berg
On Thu, Mar 12, 2009 at 8:14 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Luis R. Rodriguez wrote:
>> Do we want to ignore certain APs if we determine they are bogus? An
>> example is 11n APs with WEP/TKIP.
>
> They are not bogus, we just fall back to legacy association.
What if its HT only.
Luis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 4:18 ` Luis R. Rodriguez
@ 2009-03-13 4:43 ` Sujith
2009-03-13 5:50 ` Luis R. Rodriguez
0 siblings, 1 reply; 9+ messages in thread
From: Sujith @ 2009-03-13 4:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Dan Williams, Jouni Malinen, Johannes Berg
Luis R. Rodriguez wrote:
> On Thu, Mar 12, 2009 at 8:14 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> > Luis R. Rodriguez wrote:
> >> Do we want to ignore certain APs if we determine they are bogus? An
> >> example is 11n APs with WEP/TKIP.
> >
> > They are not bogus, we just fall back to legacy association.
>
> What if its HT only.
>
It should deny association, since we send only legacy capabilities
in our assoc request. But I doubt that HT-only APs exist.
Sujith
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 4:43 ` Sujith
@ 2009-03-13 5:50 ` Luis R. Rodriguez
0 siblings, 0 replies; 9+ messages in thread
From: Luis R. Rodriguez @ 2009-03-13 5:50 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless, Dan Williams, Jouni Malinen, Johannes Berg
On Thu, Mar 12, 2009 at 9:43 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Luis R. Rodriguez wrote:
>> On Thu, Mar 12, 2009 at 8:14 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
>> > Luis R. Rodriguez wrote:
>> >> Do we want to ignore certain APs if we determine they are bogus? An
>> >> example is 11n APs with WEP/TKIP.
>> >
>> > They are not bogus, we just fall back to legacy association.
>>
>> What if its HT only.
>>
>
> It should deny association, since we send only legacy capabilities
> in our assoc request. But I doubt that HT-only APs exist.
Well I have some, when I feel greedy I set my AP to HT-only.
Luis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 3:09 Which APs to disregards from in inputting into the bss list Luis R. Rodriguez
2009-03-13 3:14 ` Sujith
@ 2009-03-13 8:03 ` Jouni Malinen
2009-03-13 14:57 ` John W. Linville
2009-03-13 8:47 ` Johannes Berg
2009-03-13 10:48 ` Holger Schurig
3 siblings, 1 reply; 9+ messages in thread
From: Jouni Malinen @ 2009-03-13 8:03 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Dan Williams, Johannes Berg
On Thu, Mar 12, 2009 at 08:09:53PM -0700, Luis R. Rodriguez wrote:
> Do we want to ignore certain APs if we determine they are bogus?
Only if we can be sure that there is no chance of that AP working (e.g.,
someone running a program that sends random Beacon frames just to annoy
people). Even in the case of apparently bogus AP, I'm not sure I would
like to remove it from the scan results in any other case than the
attack with huge number of random beacons/probe response frames.
> An
> example is 11n APs with WEP/TKIP. Would we rather not even store then
> in our bss list so that way we wont' get reports from users not being
> able to connect to such APs.
That is not an example of an AP we would not be able to talk to (with
legacy rates; and as far as HT-only configuration is concerned, we would
likely only learn about that after having tried to associate).
> Other examples might be if 11n APs have
> HT IEs but their lengths are not right, or if the AP is HT40 and our
> regulatory domain does now allow HT40.
I would be careful about IE lengths since many IEs can be extended in
the future. As far as HT40 is concerned, we could try to associate with
HT20 and anyway, I would like to see that AP in the scan results.
> The benefit I see with these early checks we won't get complaints
> about not being able to connect to bogus APs or APs you shouldn't be
> connected to anyway.
Those would be replaced with complaints about not seeing APs, scan
being broken, and not being able to connect to APs that we should be
able to connect to..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 3:09 Which APs to disregards from in inputting into the bss list Luis R. Rodriguez
2009-03-13 3:14 ` Sujith
2009-03-13 8:03 ` Jouni Malinen
@ 2009-03-13 8:47 ` Johannes Berg
2009-03-13 10:48 ` Holger Schurig
3 siblings, 0 replies; 9+ messages in thread
From: Johannes Berg @ 2009-03-13 8:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Dan Williams, Jouni Malinen
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
On Thu, 2009-03-12 at 20:09 -0700, Luis R. Rodriguez wrote:
> Do we want to ignore certain APs if we determine they are bogus?
I would think that the extra code complexity and potential for bugs
tilts the scale much in favour of not doing this.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 3:09 Which APs to disregards from in inputting into the bss list Luis R. Rodriguez
` (2 preceding siblings ...)
2009-03-13 8:47 ` Johannes Berg
@ 2009-03-13 10:48 ` Holger Schurig
3 siblings, 0 replies; 9+ messages in thread
From: Holger Schurig @ 2009-03-13 10:48 UTC (permalink / raw)
To: linux-wireless
Cc: Luis R. Rodriguez, Dan Williams, Jouni Malinen, Johannes Berg
> Do we want to ignore certain APs if we determine they are
> bogus?
I don't have problems with discarding bss entries for the work
case of association. For sure should the association logic check
if it can associate at all.
However, if I do "iwlist XXX scan" or the equivalent "iw"
command, I don't want that mac80211 silently discards entries.
After all, I want to see "what is in the air", e.g. to find out
why I cannot connect.
If we would simply delete entries from the list you'd get
complaints from users "I cannot see AP xyz, but it must be
there, because my laptop with operating system ABC can connect
to it".
Okay, I could probably run kismet or wireshark to see "what is in
the air", but I can imagine a fair number of users that would
see this as intimidating.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Which APs to disregards from in inputting into the bss list
2009-03-13 8:03 ` Jouni Malinen
@ 2009-03-13 14:57 ` John W. Linville
0 siblings, 0 replies; 9+ messages in thread
From: John W. Linville @ 2009-03-13 14:57 UTC (permalink / raw)
To: Jouni Malinen
Cc: Luis R. Rodriguez, linux-wireless, Dan Williams, Johannes Berg
On Fri, Mar 13, 2009 at 10:03:59AM +0200, Jouni Malinen wrote:
> On Thu, Mar 12, 2009 at 08:09:53PM -0700, Luis R. Rodriguez wrote:
> > The benefit I see with these early checks we won't get complaints
> > about not being able to connect to bogus APs or APs you shouldn't be
> > connected to anyway.
>
> Those would be replaced with complaints about not seeing APs, scan
> being broken, and not being able to connect to APs that we should be
> able to connect to..
My thoughts exactly...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-13 15:00 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-13 3:09 Which APs to disregards from in inputting into the bss list Luis R. Rodriguez
2009-03-13 3:14 ` Sujith
2009-03-13 4:18 ` Luis R. Rodriguez
2009-03-13 4:43 ` Sujith
2009-03-13 5:50 ` Luis R. Rodriguez
2009-03-13 8:03 ` Jouni Malinen
2009-03-13 14:57 ` John W. Linville
2009-03-13 8:47 ` Johannes Berg
2009-03-13 10:48 ` Holger Schurig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.