* Initial choice of network should consider RSSI?
@ 2023-04-09 11:33 Cedric Sodhi
2023-04-09 16:47 ` Denis Kenzior
0 siblings, 1 reply; 4+ messages in thread
From: Cedric Sodhi @ 2023-04-09 11:33 UTC (permalink / raw)
To: iwd
Hello,
I have a permanent problem with IWD when multiple known networks (different SSIDs) are in range: With a large probably (although it is most likely just random, depending on when the beacons fire) IWD manages to connect to a network with an unusable low RSSI while better networks are available.
I suspect there is currently no logic in place which would somehow work in favor of making a "good" choice? RoamThreshold, for example, doesn't seem to apply and InitialPeriodicScanInterval seems to have no effect either, given that the (initial) connection to the (bad) network happens immediately before InitialPeriodicScanInterval passed, and that choice does not seem to be revised even if the better network becomes visible within InitialPeriodicScanInterval.
Would it possible to either extend the meaning of InitialPeriodicScanInterval or introduce another option which would allow IWD to connect to a better, different SSID (thus not covered by roaming) within an initial period?
Cedric (please CC)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Initial choice of network should consider RSSI?
2023-04-09 11:33 Initial choice of network should consider RSSI? Cedric Sodhi
@ 2023-04-09 16:47 ` Denis Kenzior
[not found] ` <CAPv5Ue6KEZVxT2Mb15bBH_8n53abvJbu_+aCTHJgP9ODU3AT5Q@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Denis Kenzior @ 2023-04-09 16:47 UTC (permalink / raw)
To: Cedric Sodhi, iwd
Hi Cedric,
On 4/9/23 06:33, Cedric Sodhi wrote:
> Hello,
>
> I have a permanent problem with IWD when multiple known networks (different SSIDs) are in range: With a large probably (although it is most likely just random, depending on when the beacons fire) IWD manages to connect to a network with an unusable low RSSI while better networks are available.
>
> I suspect there is currently no logic in place which would somehow work in favor of making a "good" choice? RoamThreshold, for example, doesn't seem to apply and InitialPeriodicScanInterval seems to have no effect either, given that the (initial) connection to the (bad) network happens immediately before InitialPeriodicScanInterval passed, and that choice does not seem to be revised even if the better network becomes visible within InitialPeriodicScanInterval.
Periodic scans are attempted every N seconds, with exponentially increasing N if
no connectable network was found. InitialPeriodicScanInterval simply sets the
initial timeout N. It isn't that iwd scans constantly during that period.
Once a periodic scan completes, and there's something to connect to, iwd
attempts to do so. If there are multiple somethings to connect to, then iwd
prioritizes networks based on estimated throughput (this is where the RSSI is
taken into account) and which network was most recently used. There are some
other factors.
>
> Would it possible to either extend the meaning of InitialPeriodicScanInterval or introduce another option which would allow IWD to connect to a better, different SSID (thus not covered by roaming) within an initial period?
If you have a more concrete proposal please share it. And patches are always
welcome :)
Regards,
-Denis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Initial choice of network should consider RSSI?
[not found] ` <CAPv5Ue6KEZVxT2Mb15bBH_8n53abvJbu_+aCTHJgP9ODU3AT5Q@mail.gmail.com>
@ 2023-04-10 6:04 ` Cedric Sodhi
2023-04-10 14:59 ` James Prestwood
0 siblings, 1 reply; 4+ messages in thread
From: Cedric Sodhi @ 2023-04-10 6:04 UTC (permalink / raw)
To: James Prestwood; +Cc: Denis Kenzior, iwd
Hello and thank you for the responses.
Denis, perhaps I misunderstood something, my description wasn't clear or/and (most likely, after I looked at iwd -d), my diagnosis was wrong in the first place, but I thought that the problem was that iwd will connect to a network as soon as a network can be connected to and it will not _revise_ that decision (connect to a better network afterwards). That would become a problem if a "bad" network becomes known moments before the "good" network becomes known.
Looking at iwd -d, however, I get the following list, before it attempt to connect to BAD_NETWORK
src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:25:f4:71' with SSID: BAD_NETWORK, freq: 5220, rank: 736, strength: -7200, data_rate: 90.0
src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK" security psk
src/station.c:station_add_seen_bss() Processing BSS '68:72:51:48:72:c2' with SSID: GOOD_NETWORK, freq: 2412, rank: 492, strength: -5400, data_rate: 72.2
src/station.c:station_add_seen_bss() Added new Network "GOOD_NETWORK" security psk
src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:24:f4:71' with SSID: BAD_NETWORK, freq: 2462, rank: 472, strength: -7300, data_rate: 57.8
src/station.c:station_add_seen_bss() Processing BSS 'cc:2d:21:5d:dd:95' with SSID: BAD_NETWORK3, freq: 5240, rank: 443, strength: -7600, data_rate: 65.0
src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK3" security psk
src/station.c:station_add_seen_bss() Processing BSS 'cc:2d:21:5d:dd:91' with SSID: BAD_NETWORK2, freq: 2417, rank: 197, strength: -7400, data_rate: 28.9
src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK2" security psk
src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:24:f4:73' with SSID: BAD_NETWORK, freq: 2462, rank: 90, strength: -8300, data_rate: 11.0
src/station.c:station_add_seen_bss() Processing BSS 'd8:32:14:ee:a3:d1' with SSID: BAD_NETWORK2, freq: 2422, rank: 37, strength: -8500, data_rate: 5.5
so from what you write James, I think the problem lies in the estimated data rate, given how it appears high on the network with bad RSSI.
I suspect the recommended course of action at this point is just blacklist the station which seems to yield a "misleading high" data rate!
Unless my assumption about how iwd doesn't "revise" network choices during an initial scan period is somehow valid or related to my probelem, I suppose this is an issue with the particular station then and has nothing to do with iwd's behaviour, so thanks for the help!
Cedric
On Sun, Apr 09, 2023 at 10:07:34AM -0700, James Prestwood wrote:
> Hi Cedric,
>
> On Sun, Apr 9, 2023, 9:58 AM Denis Kenzior <[1]denkenz@gmail.com> wrote:
>
> Hi Cedric,
>
> On 4/9/23 06:33, Cedric Sodhi wrote:
> > Hello,
> >
> > I have a permanent problem with IWD when multiple known networks
> (different SSIDs) are in range: With a large probably (although it is
> most likely just random, depending on when the beacons fire) IWD manages
> to connect to a network with an unusable low RSSI while better networks
> are available.
> >
> > I suspect there is currently no logic in place which would somehow
> work in favor of making a "good" choice? RoamThreshold, for example,
> doesn't seem to apply and InitialPeriodicScanInterval seems to have no
> effect either, given that the (initial) connection to the (bad) network
> happens immediately before InitialPeriodicScanInterval passed, and that
> choice does not seem to be revised even if the better network becomes
> visible within InitialPeriodicScanInterval.
>
> Periodic scans are attempted every N seconds, with exponentially
> increasing N if
> no connectable network was found. InitialPeriodicScanInterval simply
> sets the
> initial timeout N. It isn't that iwd scans constantly during that
> period.
>
> Once a periodic scan completes, and there's something to connect to, iwd
> attempts to do so. If there are multiple somethings to connect to, then
> iwd
> prioritizes networks based on estimated throughput (this is where the
> RSSI is
> taken into account) and which network was most recently used. There are
> some
> other factors.
>
> >
> > Would it possible to either extend the meaning of
> InitialPeriodicScanInterval or introduce another option which would
> allow IWD to connect to a better, different SSID (thus not covered by
> roaming) within an initial period?
> If you have a more concrete proposal please share it. And patches are
> always
> welcome :)
>
> It would also be helpful to see the debug logs too see why IWD chose the
> network it did. This would answer questions I have like:
> Did the scan only see one network?
> What was the estimated data rate of both networks?
> How good/bad was the RSSI between the two networks in question?
> Thanks,
> James
>
> Regards,
> -Denis
>
> References
>
> Visible links
> 1. mailto:denkenz@gmail.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Initial choice of network should consider RSSI?
2023-04-10 6:04 ` Cedric Sodhi
@ 2023-04-10 14:59 ` James Prestwood
0 siblings, 0 replies; 4+ messages in thread
From: James Prestwood @ 2023-04-10 14:59 UTC (permalink / raw)
To: Cedric Sodhi; +Cc: Denis Kenzior, iwd
Hi Cedric,
On 4/9/23 11:04 PM, Cedric Sodhi wrote:
> Hello and thank you for the responses.
>
> Denis, perhaps I misunderstood something, my description wasn't clear or/and (most likely, after I looked at iwd -d), my diagnosis was wrong in the first place, but I thought that the problem was that iwd will connect to a network as soon as a network can be connected to and it will not _revise_ that decision (connect to a better network afterwards). That would become a problem if a "bad" network becomes known moments before the "good" network becomes known.
>
> Looking at iwd -d, however, I get the following list, before it attempt to connect to BAD_NETWORK
>
> src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:25:f4:71' with SSID: BAD_NETWORK, freq: 5220, rank: 736, strength: -7200, data_rate: 90.0
> src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK" security psk
> src/station.c:station_add_seen_bss() Processing BSS '68:72:51:48:72:c2' with SSID: GOOD_NETWORK, freq: 2412, rank: 492, strength: -5400, data_rate: 72.2
> src/station.c:station_add_seen_bss() Added new Network "GOOD_NETWORK" security psk
> src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:24:f4:71' with SSID: BAD_NETWORK, freq: 2462, rank: 472, strength: -7300, data_rate: 57.8
> src/station.c:station_add_seen_bss() Processing BSS 'cc:2d:21:5d:dd:95' with SSID: BAD_NETWORK3, freq: 5240, rank: 443, strength: -7600, data_rate: 65.0
> src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK3" security psk
> src/station.c:station_add_seen_bss() Processing BSS 'cc:2d:21:5d:dd:91' with SSID: BAD_NETWORK2, freq: 2417, rank: 197, strength: -7400, data_rate: 28.9
> src/station.c:station_add_seen_bss() Added new Network "BAD_NETWORK2" security psk
> src/station.c:station_add_seen_bss() Processing BSS '24:5a:4c:24:f4:73' with SSID: BAD_NETWORK, freq: 2462, rank: 90, strength: -8300, data_rate: 11.0
> src/station.c:station_add_seen_bss() Processing BSS 'd8:32:14:ee:a3:d1' with SSID: BAD_NETWORK2, freq: 2422, rank: 37, strength: -8500, data_rate: 5.5
>
> so from what you write James, I think the problem lies in the estimated data rate, given how it appears high on the network with bad RSSI.
>
> I suspect the recommended course of action at this point is just blacklist the station which seems to yield a "misleading high" data rate!
>
> Unless my assumption about how iwd doesn't "revise" network choices during an initial scan period is somehow valid or related to my probelem, I suppose this is an issue with the particular station then and has nothing to do with iwd's behaviour, so thanks for the help!
Yes, as I suspected the "BAD NETWORK" just advertises better
capabilities which then ranks it higher. I think for the short term, if
you don't want to connect to "BAD NETWORK" automatically you can add
AutoConnect=false in the network profile, or remove it completely if you
never want to connect.
This unfortunately is one of the downfalls of heavily weighting data
rate to network selection. Maybe something we need to look into more or
possibly set (or allow to configure) hard limits on RSSI. We are also
open to suggestions.
Thanks,
James
>
> Cedric
>
> On Sun, Apr 09, 2023 at 10:07:34AM -0700, James Prestwood wrote:
>> Hi Cedric,
>>
>> On Sun, Apr 9, 2023, 9:58 AM Denis Kenzior <[1]denkenz@gmail.com> wrote:
>>
>> Hi Cedric,
>>
>> On 4/9/23 06:33, Cedric Sodhi wrote:
>> > Hello,
>> >
>> > I have a permanent problem with IWD when multiple known networks
>> (different SSIDs) are in range: With a large probably (although it is
>> most likely just random, depending on when the beacons fire) IWD manages
>> to connect to a network with an unusable low RSSI while better networks
>> are available.
>> >
>> > I suspect there is currently no logic in place which would somehow
>> work in favor of making a "good" choice? RoamThreshold, for example,
>> doesn't seem to apply and InitialPeriodicScanInterval seems to have no
>> effect either, given that the (initial) connection to the (bad) network
>> happens immediately before InitialPeriodicScanInterval passed, and that
>> choice does not seem to be revised even if the better network becomes
>> visible within InitialPeriodicScanInterval.
>>
>> Periodic scans are attempted every N seconds, with exponentially
>> increasing N if
>> no connectable network was found. InitialPeriodicScanInterval simply
>> sets the
>> initial timeout N. It isn't that iwd scans constantly during that
>> period.
>>
>> Once a periodic scan completes, and there's something to connect to, iwd
>> attempts to do so. If there are multiple somethings to connect to, then
>> iwd
>> prioritizes networks based on estimated throughput (this is where the
>> RSSI is
>> taken into account) and which network was most recently used. There are
>> some
>> other factors.
>>
>> >
>> > Would it possible to either extend the meaning of
>> InitialPeriodicScanInterval or introduce another option which would
>> allow IWD to connect to a better, different SSID (thus not covered by
>> roaming) within an initial period?
>> If you have a more concrete proposal please share it. And patches are
>> always
>> welcome :)
>>
>> It would also be helpful to see the debug logs too see why IWD chose the
>> network it did. This would answer questions I have like:
>> Did the scan only see one network?
>> What was the estimated data rate of both networks?
>> How good/bad was the RSSI between the two networks in question?
>> Thanks,
>> James
>>
>> Regards,
>> -Denis
>>
>> References
>>
>> Visible links
>> 1. mailto:denkenz@gmail.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-04-10 14:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-09 11:33 Initial choice of network should consider RSSI? Cedric Sodhi
2023-04-09 16:47 ` Denis Kenzior
[not found] ` <CAPv5Ue6KEZVxT2Mb15bBH_8n53abvJbu_+aCTHJgP9ODU3AT5Q@mail.gmail.com>
2023-04-10 6:04 ` Cedric Sodhi
2023-04-10 14:59 ` James Prestwood
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.