Re: [PATCH] station: Move netconfig_reset() to common path

[Denis Kenzior <denkenz at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Hi Andrew,

>> Now, maybe some elements of what the connect failed path does might be needed in
>> this failure case.  But to determine that we would need to know why the
>> disconnect happens? How often? Is it every time? Sometimes? Once in a blue moon,
>> etc.
> 
> Unfortunately this applies to most failure modes in a connection (at
> 802.11 level or at IP level -- for the user they're the same thing)

I agree, but details matter.  So what is it you're proposing exactly?

> and I think the binary blacklisted/not blacklisted model we use
> doesn't really work.  IIRC my initial patches used a different model
> where the blacklist was a kind of penalty list where BSSes and/or
> networks that fail more often are pushed further in the priority list.

I remember, but we have since moved on from that model of autoconnect.  We 
autoconnect networks now, not individual BSSes.  Eventually we will move to a 
network priority model in the future where the user will specify the priority of 
a given network for autoconnect.  Blacklisting within the network is a different 
topic.  Also note that we have two levels of blacklisting, so it isn't quite as 
simple as you describe.

> In the end when we've tried all the BSSes in range we have nothing to
> lose by retrying some of the ones we've already tried, we just don't
> want to put them before other BSSes.  This can be done in a way that

We do that already.

> over time the list converges to sorted by how often a network/bss
> fails.
> 
> This also allows you to learn from some very clear cues that we're not
> handling, like a user manually switching to another network.

Regards,
-Denis