On Sun, 2019-08-11 at 02:08 +0000, James Nylen wrote:
In 5.x it's still possible for `ieee80211_scan_results` (`iwlist
scan`) to fail when too many wireless networks are available. This
code path is used by `wicd`.
Previously: https://lkml.org/lkml/2017/4/2/192
This has been known for probably a decade or longer. I don't know why
'wicd' still insists on using wext, unless it's no longer maintained at
all. nl80211 doesn't have this problem at all, and I think gives more
details about the networks found too.
I've been applying this updated patch to my own kernels since 2017 with
no issues. I am sure it is not the ideal way to solve this problem, but
I'm making my fix available in case it helps others.
I don't think silently dropping data is a good solution.
I suppose we could consider applying a workaround like this if it has a
condition checking that the buffer passed in is the maximum possible
buffer (65535 bytes, due to iw_point::length being u16), but below that
-E2BIG serves well-written implementations as an indicator that they
need to retry with a bigger buffer.
Please advise on next steps or if this is a dead end.
I think wireless extensions are in fact a dead end and all software
(even 'wicd', which seems to be the lone holdout) should migrate to
nl80211 instead.
johannes
I suppose we could consider applying a workaround like this if it has a
condition checking that the buffer passed in is the maximum possible
buffer (65535 bytes, due to iw_point::length being u16)
This is what the latest patch does (attached to my email from
yesterday / https://lkml.org/lkml/2019/8/10/452 ).
If you'd like to apply it, I'm happy to make any needed revisions.
Otherwise I'm going to have to keep patching my kernels for this
issue, unfortunately I don't have the time to try to get wicd to
migrate to a better solution.
On 8/11/19, Johannes Berg [off-list ref] wrote:
On Sun, 2019-08-11 at 02:08 +0000, James Nylen wrote:
quoted
In 5.x it's still possible for `ieee80211_scan_results` (`iwlist
scan`) to fail when too many wireless networks are available. This
code path is used by `wicd`.
Previously: https://lkml.org/lkml/2017/4/2/192
This has been known for probably a decade or longer. I don't know why
'wicd' still insists on using wext, unless it's no longer maintained at
all. nl80211 doesn't have this problem at all, and I think gives more
details about the networks found too.
quoted
I've been applying this updated patch to my own kernels since 2017 with
no issues. I am sure it is not the ideal way to solve this problem, but
I'm making my fix available in case it helps others.
I don't think silently dropping data is a good solution.
I suppose we could consider applying a workaround like this if it has a
condition checking that the buffer passed in is the maximum possible
buffer (65535 bytes, due to iw_point::length being u16), but below that
-E2BIG serves well-written implementations as an indicator that they
need to retry with a bigger buffer.
quoted
Please advise on next steps or if this is a dead end.
I think wireless extensions are in fact a dead end and all software
(even 'wicd', which seems to be the lone holdout) should migrate to
nl80211 instead.
johannes