<solved> not wpa_supplicant:2.10-r1 issue

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

I don't think this is arm64 specific, so posting here, feel free to move it to arm sub-forum if I'm wrong.

So over the past couple of weeks I set up an arm-64 rpi4b-8gb machine to serve as a binhost for a couple of other Pi's; I've only got one machine here on a wired connection, an old headless i3 that serves as my local portage mirror. everything else, including the i7 distcc helper for the pi binhost, is wifi-only so I'm a bit concerned to start fixing this before I really understand the problem. I'd rather get everything back up and running and set up a vm to work the problem later if necessary.

Last week I synced the local mirror and updated @world on the binhost machine which pulled in the subject wpa_supplicant, nothing seemed obviously amiss at the time, so the update rolled out to the other two pi's and the i7, so now all have this version installed. :/

As part of the binhost building process I moved from the raspberrypi-image I built this with initially; and set up a full toolchain and kernel, as the one installed was getting a bit old (5.10.63-v8 ). I tripped over this issue before I copied the newly cooked (5.15.32-r1) kernel into /boot. I updated the symlink to build the kernel, though, so at present /usr/src/linux is pointing to the new sources, but the old kernel is running still - in case that has any impact. I prefer to fix the below wifi issue before complicating it with a new kernel install (especially as it is the first built on this machine).

Last night I restarted wlan0 on the rpi binhost and lost wifi connection. fortunately the other units haven't been restarted yet. I'm concerned at least the pi's and probably the amd64 machine will lose wifi once they do - a situation I'd like to avoid as I have no easy wired lan options here.

Edit to add: wpa_supplicant starts, immediately goes inactive and ip a returns no device.

I hit the forums and have read the threads here relating to the behaviour of numerous wpa_supplicant installs that choked one way or another on this update, some due to the requirement for tkip on older hw, others due to the tkip flag being dropped, whilst tkip is referenced in the wpa_supplicant.conf. Neither of those apply in this case. The router is AEP and, as these aren't mobile devices, they have a simplified .conf to authenticate to only the home router, so tkip was never set there.

I tried rebuilding the subject with the tkip flag but no joy (wasn't expecting any tbh). From the threads here it seems also that something's been refactored and regressed in 2.10-r1.

So, I'd like to get my binhost back online, mask the update and downgrade everything to the last of the 2.9.x set of wpa_supplicant (as I don't have sources for 2.10 on any machine here). I have a binpkg of 2.9.r8 on the binhost fortunately, but have to admit I really have no idea how to install that manually, I've only interacted with binary packages via emerge -K, which obviously won't work in this case without some preparation. I assume I have to untar the wpa_supplicant-2.9.r8.tbz2 into /var/portage/distfiles, is that it?

Three questions then:

1. Have I missed something that might mitigate the issue for 2.10-r1 in the above scenario?
2. What is the correct way to manually extract and install the 2.9-r8.tbz2 file to rollback;
3. Was 2.10-r1 really ready for stabilisation?

Any other tips appreciated,
thx Ian

wless123 · n00b Joined: 27 Aug 2021 Posts: 40

Hi ian.au,
it seems not related to wpa_supplicant if that one is true:

NeddySeagoon · Posted: Sat Apr 23, 2022 11:16 am Post subject:

ian.au,

Do you need USE=tkip on wpa-supplicant ?
If so adjust you WAP so its not required. tkip is regarded as insecure.

There is a lot of this about just now
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

Hi Neddy,
AFAICT my ISP supplied modem doesn't require tkip, which wasn't ever referenced in my wpa_supplicant.config. I rebuilt 2.10-r1 with it to see if it made a difference only because I read a number of forum posts in search of a solution, some of which seemed to indicate that they lost connectivity without the flag set, even on routers set to AEP. I suppose I'll add it also to my wpa_config and see if that makes a difference, and I'll try that this morning, but I don't think it's the problem.

What I'd really like to do is roll back to 2.9-r8 and see if I can revert to a working state. Is that a simple matter of untarring the binpkg 2.9-r1.tbz into distfiles? I can't remember having to do this manually before.

@ wless123
Thanks. Once I'm in a position to wgetpaste my logs / dmesg from the problem machine the problem will have been solved

I could 'sneakernet' dmesg /logs over and post them, and if I can't resolve this soon I'll do that.

I don't think the firmware is an issue, as the new kernel and firmware were built, but haven't been copied over to boot. All required firmware/modules for the running kernel appear to be present.

I've rebooted since the problem started and the dmesg for this pi has exactly the same entries as two others that are successfully connected.

I'd like to start by rolling back to 2.9-r8 and see if I can move forward from there.

NeddySeagoon · Posted: Sat Apr 23, 2022 9:59 pm Post subject:

ian.au,

If you have the ebuild and the binpackage, its

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

Here's the debug log for wpa_supplicant on the broken machine, so far it doesn't really tell me much but I'm still digesting it.

https://pastebin.com/2aHBxQqE

wpa_supplicant.log has expanded to 103mb, so I'll hold off on posting that for the time being. I'll extract a section from when it was running on 2.9 vs 2.10-r1 in due course.

dmesg are virtually identical in respect of brcmfmac - I'm assuming the usbcore entry is in a different location because the one on the running system will have been from a cold boot, and on the inoperative machine from a restart of the device.

From the inoperative machine

NeddySeagoon · Posted: Sun Apr 24, 2022 11:48 am Post subject:

ian.au,

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

Thanks Neddy, I figured I must have been missing something wrt git. I should get around to learning it properly, I just haven't had the need to use it other than very basically.
I'll keep the information around for next time (or if the below proves not to be the cause).

I'm coming to the conclusion the problem was between chair and keyboard in this case, the tkip issue never applied to me, and the noise in the forums on it distracted me from the real cause.

I'm running through wless123's suggested checks and will try and make the stable version work first.

ian.au · l33t Joined: 07 Apr 2011 Posts: 600 Location: Australia

Thanks wless123 for the nudge, this was unrelated to wpa_supplicant as you suggested.

Thanks Neddy, for the tips assisting me with the git workflow etc. Whilst not needed this time I've saved for later.

Apologies devs, for the suggestion that wpa_supplicant may have been poorly stabilised.

Note to self, be more careful when working on two very similar systems in nested screen sessions :oops:

This was completely self inflicted and nothing to do with networking other than it being the only symptom of a botched arm64 upgrade, so I'll report the post for moving to the arm sub-forum.