<solved> not wpa_supplicant:2.10-r1 issue

[ian.au]

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]

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

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

It's more likely that either the firmware or the module aren't loaded correctly. Maybe sys-kernel/linux-firmware was emerged too?

Assuming you're starting your wifi as kernel module:

1) check if the module is still present (/lib/modules/<kernel_version>/...)
2) check if the required firmware is still present (/lib/firmware/...)
3) check if the module is loaded (lsmod)
4) check if firmware is loaded or any other error occurs (dmesg)
5) reload the module (rmmod/insmod, note that the module cannot be in use so all modules which use it have to be unloaded too)


Which kernel module/firmware is used depends on your raspberry and if you're using internal wifi or an external device.

If you need more help post the output of dmesg/lsmod/lsusb/lspci separate on pastebin or sth like this and posts the lnks.

It all might be solved with a restart but can't tell it for sure.

Hth

[NeddySeagoon]

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

[ian.au]

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]

ian.au,

If you have the ebuild and the binpackage, its

Code: Select all

emerge -1K =<pacxage-ver>

-K is use the binpackage or fail.

The ebuild will be in git if its gone from the repo.

[ian.au]

ian.au,

If you have the ebuild and the binpackage, its

Code: Select all

emerge -1K =<pacxage-ver>

-K is use the binpackage or fail.

The ebuild will be in git if its gone from the repo.

It seems the only ebuilds in git are 9999 and 2.10-r1 unfortunately

[ian.au]

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

Code: Select all

[    8.982254] brcmfmac: F1 signature read @0x18000000=0x15264345
[    9.003174] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.258916] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.259059] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.266483] usbcore: registered new interface driver brcmfmac
[    9.271189] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan  4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[   14.760974] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[  423.392396] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[36214.691855] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[110899.715542] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

From another Pi which is connected still

Code: Select all

pi64-01 /usr/src/linux # dmesg |grep brcmfmac
[    9.072981] brcmfmac: F1 signature read @0x18000000=0x15264345
[    9.087740] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.090495] usbcore: registered new interface driver brcmfmac
[    9.331289] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.331420] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    9.342008] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan  4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[   14.602574] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

[NeddySeagoon]

ian.au,

It seems the only ebuilds in git are 9999 and 2.10-r1 unfortunately

All the ebuilds that were ever in CVS or git are in git now. Back to 2002 anyway.
See HOWTO Update Old Gentoo for the method to expose the ebuild you need.
Once you have your git clone,

Code: Select all

git log -- net-wireless/wpa_supplicant

will tell you about all the commits to wpa_supplicant. Pick one you like then

Code: Select all

git checkout <commit_number>

will get you the repo as it was when that was the last commit to the repo.

Extract your ebuild and put it in your local overlay.

That guide assumes you want to use an entire ::gentoo repo, you don't, just pick the ebuild you need.

[ian.au]

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]

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

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.