> 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,
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
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
This also allows you to learn from some very clear cues that we're not
handling, like a user manually switching to another network.