From: Marcel Holtmann <marcel@holtmann.org>
To: Grant Erickson <gerickson@nuovations.com>
Cc: connman@lists.linux.dev, Denis Kenzior <denkenz@gmail.com>
Subject: Re: Clarifying ConnMan Configuration Multi-technology Feature Fusion and Online/Ready Transitions
Date: Wed, 8 Nov 2023 19:41:38 +0100 [thread overview]
Message-ID: <A297893B-FD81-42AB-82DB-AFA22387A28A@holtmann.org> (raw)
In-Reply-To: <C03F5DCF-9E72-40BB-AC52-04BBAB498BF9@nuovations.com>
Hi Grant,
>>> I’ve done more testing on this front with some unexpected results using the configuration below:
>>>
>>> * I have an Ethernet cable connected to the device under test (DUT) to an eight port desktop Ethernet switch which, in turn, is connected to another local switch which is yet another switch hop away from the backbone and the router.
>>> - If I leave the DUT connected to the desktop switch but disconnect the desktop switch from its parent switch and then monitor, I eventually see repeated WiSPR failures over Ethernet (404) but I never see Ethernet cede the default route to W-Fi and Wi-Fi transition from “Ready” to “Online”.
>>> - How many back-to-back WiSPR failures are expected until another technology / service takes over the default route?
>>>
>>> I also did a test in which I changed:
>>>
>>> * EnableOnlineToReadyTransition=false
>>> * SingleConnectedTechnology=true
>>>
>>> relative to the below. In this situation, Wi-Fi went crazy with its link transitioning many times a second from associating to configuration to ready to offline. The console became unusable with repeated:
>>>
>>> IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>>>
>>> messages.
>>
>> Hmm. I would really prefer you abandon wpa_supplicant and you use iwd. Some things that wpa_supplicant does and various hardware drivers are doing is insane and we paper over it. Only when starting with iwd, we can address things properly.
>
> Marcel,
>
> I’d like to make that move; unfortunately, for the current project I am engaged on, I am locked on linux-4.9.212, glibc-2.28, and GCC 8.x. Unfortunately, with that combination, the latest version of ELL I can get to build is 0.28 and the latest version of IWD won’t compile against it. In parallel, the latest version of ELL fails with a number of errors (I’ll follow up on those later per Denis) and the version of ELL included with IWD fails with an overlapping but also unique set of errors.
this is the second time this week someone talks about a 4.x kernel. Your kernel is almost 4 years old. And the original 4.9 is 7 years old. I would be running around scared if I had to deploy such an old kernel. So just ugh.
> Unfortunately, untangling all of that is more than the client is willing to take on at the moment. I’ve recommended that they pursue IWD after a kernel, glibc, toolchain update in a later effort.
I get that part, but the real problem is that wpa_supplicant is a real mess. Look at its release cadence and or the lack of it. Denis and I have solely focused on iwd in the last 7 years and never even tried to fix anything in wpa_supplicant anymore. That might give you an idea on what you are getting into there.
Lets get ELL compile your kernel of choice. I am surprised it fails to build, but I also don’t have any 4.x nor 5.x kernel flying around anymore ;)
Regards
Marcel
prev parent reply other threads:[~2023-11-08 18:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 3:37 Clarifying ConnMan Configuration Multi-technology Feature Fusion and Online/Ready Transitions Grant Erickson
2023-10-14 1:05 ` Grant Erickson
2023-11-08 14:46 ` Marcel Holtmann
2023-11-08 15:30 ` Grant Erickson
2023-11-08 16:03 ` daniel antoine
2023-11-08 18:41 ` Marcel Holtmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A297893B-FD81-42AB-82DB-AFA22387A28A@holtmann.org \
--to=marcel@holtmann.org \
--cc=connman@lists.linux.dev \
--cc=denkenz@gmail.com \
--cc=gerickson@nuovations.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).