Buster on PPC - wireless works 2nd time and onwards

[electrolux]

I am trying to use an unsupported platform, and so I know it is cheeky to even ask, but I think my problem is me, not Linux.

I'm just after a quick pointer on how to get an upgraded system to use predictable network interface names for the wireless.


My PPC G4 Mac Mini has been upgraded from Jessie official to Buster from Debian Ports. It now takes 5 minutes to boot, hanging on the networking service, and once systemd decides the network is not coming up and gives the login prompt, 7 minutes later the network does start working. Seriously, 12 mins after booting the wifi associates and works. systemd thinks the network is not working, and I haven't even looked to see if reliant services are up properly. Those will be checked and fixed once the basics are working.

The problem is with the wireless, as if that isn't specified in the interfaces file the machines boots quick with working ethernet. I am trying to get Buster to do what it should: give wlan0 a horrible name, as I think the hang at start up is caused by wlan0 being an unexpected name. Something cannot find the interface trying to be configured, but isn't moaning about it (or I can't find the message).

If I have wlan0 set up as manual, boot the machine, then do ifup wlan0 I get the hang. dmesg, journalctl, systemctl status etc. haven't said anything too specific. As my platform is unsupported I am not going to dump logs here as I am not asking for others to dig into this problem for me. I just need someone to pass me a spade

If I have the ethernet and wifi set up as auto, and wait the 12 minutes, then restart the networking service it restarts absolutely fine. So far I have determined that I have this problem only the first time the wifi tries to be used. Which is making tracking the problem down even more of a pain. It is intermittent, though I have narrowed that down a bit.

0001:10:12.0 Network controller: Broadcom Limited BCM4306 802.11b/g Wireless LAN Controller (rev 03)
b43 driver, firmware has been re-installed with a dpkg-reconfigure firmware-b43-installer, but didn't raise in version. I haven't tried installing a non-free package, though I'd imagine the FW in that would be the same as what dpkg-reconfigure firmware-b43-installer does when it downloads a binary and pulls out the FW.

This Mac I think has now been upgraded 3 Debian releases. It definitely did not have systemd when Debian was first put on it. As you can imagine, there could be crud hanging about. At the same time the machine has been fiddled with[1] professionally administered so much I'd rather fix it than do a fresh install and re-set up.

What have I missed that might be making the system name wlan0 as wlan0? I have got eth0 to be eth.... (goes and looks) enP2p32s15f0 by removing /etc/udev/rules.d/nn-persistent-names.rules. The kernel command line only has radeon stuff from when I fought and gave up with KMS and terrible graphical performance.

Again, I am rocking an unsupported arrangement, so what I am saying should not be taken as any indication of what Debian Buster is actually like. If this post is too much of a faux-pas, please delete the thread. I am facing the Windows fix of trying a fresh install, but I'd rather try for knowledge - unlike proprietary platforms in theory the only thing in the way is the user.

Thanks, and sorry for the internet-static.

[1]There's no strike-out? Has that joke format been banned here?

[Wheelerof4te]

See if this wiki page will help:
https://wiki.debian.org/bcm43xx

I personally would avoid using unsupported OS on your machine. If you really want to tinker with PPC, your option is to compile stuff from source. Upstream kernel and firmware comes to mind.

[bw123]

0001:10:12.0 Network controller: Broadcom Limited BCM4306 802.11b/g Wireless LAN Controller (rev 03)
b43 driver, firmware has been re-installed with a dpkg-reconfigure firmware-b43-installer, but didn't raise in version. I haven't tried installing a non-free package, though I'd imagine the FW in that would be the same as what dpkg-reconfigure firmware-b43-installer does when it downloads a binary and pulls out the FW.

Which ver of the firmware-b43-installer do you have? The jessie and stretch versions download different firmwares. The older ver did not work for me at all on kernels 4.x

https://packages.debian.org/search?keyw ... -installer

What have I missed that might be making the system name wlan0 as wlan0?

My b43 device has always been wlan0 and I noticed it never started using the new predictable names. Guessed it is because it is in a MiniPCI-E slot. It works fine though.

You should post your interfaces file, and maybe something in daemon.log would help someone spot something. I've been using allow-hotplug instead of auto, it lets me boot much quicker, instead of waiting for the wpasupplicant to start...

[electrolux]

Code: Select all

$ dpkg-query -s firmware-b43-installer
Package: firmware-b43-installer
Status: install ok installed
Priority: optional
Section: contrib/kernel
Installed-Size: 56
Maintainer: Daniel Echeverry <epsilon77@gmail.com>
Architecture: all
Source: b43-fwcutter
Version: 1:019-2
Replaces: firmware-b43-lpphy-installer (<= 1:015-14)
Depends: b43-fwcutter (>= 1:019-2), bzip2, wget
Breaks: firmware-b43-lpphy-installer (<= 1:015-14)
Description: firmware installer for the b43 driver
 This package downloads and installs the firmware needed by the b43
 kernel driver for some Broadcom 43xx wireless network cards.
 .
 Supported chipsets:
  * BCM4306/3;
  * BCM4311;
  * BCM4318;
  * BCM4321;
  * BCM4322 (only 14e4:432b);
  * BCM4312 (with Low-Power a.k.a. LP-PHY).
Homepage: http://wireless.kernel.org/en/users/Drivers/b43

When wlan0 is brought up, dmesg shows:

Code: Select all

[54074.621358] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)

Code: Select all

$ apt-get install firmware-b43-installer b43-fwcutter
Reading package lists... Done
Building dependency tree       
Reading state information... Done
b43-fwcutter is already the newest version (1:019-2).
b43-fwcutter set to manually installed.
firmware-b43-installer is already the newest version (1:019-2).
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.

What's that? Manually installed? The machine's backed up by image, so I can be brutal....

And have been, purged b43-fwcutter and firmware-b43-installer. Now, as ports has no contribs repository, there are no b43 packages to install. I guess I'll manually install the non-free firmware package from Buster. Those packages should be platform agnostic.

There is no Stretch for PPC, and so Jessie's B43 FW packages are the closest available if I need an executable.

There's unsupported, and then there's hack-tacular. I'm OK running somewhat of a house of cards, but this is getting a bit silly even by my standards

What have I missed that might be making the system name wlan0 as wlan0?

My b43 device has always been wlan0 and I noticed it never started using the new predictable names. Guessed it is because it is in a MiniPCI-E slot. It works fine though.

As I understand if you did a fresh install then the predictable names would come up, but I think if upgraded then old names are preserved.

Though if what you say is how it works, then in this mac the wifi card I think is connected by a Sonics Silicon Backplane. On the mac b43 depends on the ssb module. Now I think looking into the order of those loading at boot, or something like that, might be a worthwhile avenue.

[bw123]

I guess I'll manually install the non-free firmware package from Buster. Those packages should be platform agnostic.

The last time I checked, b43 firmware is not packaged for debian at all. please correct me if you find out different.

There is no Stretch for PPC, and so Jessie's B43 FW packages are the closest available if I need an executable.

I see now, there is no b43-fwcutter pkg for powerpc arch like on jessie. Well the 666.2 ver is the same as the one I have on stretch, so that's probably not the issue. My device is a lp-phy, and it actually uses three or four firmwares, there are a couple named lpinitvals and such, so if your device is loading several files, it still could be be a firmware mismatch with the current kernel.?

As I understand if you did a fresh install then the predictable names would come up, but I think if upgraded then old names are preserved.

That is the way I understand it should work also, but even a new install gives the device the name wlan0. It works fine. I don't think that is the issue either.

Why don't you post your interfaces file? And maybe a little bit of daemon log would help someone spot something... Maybe it's something simple in there. Also ifup has a -v verbose flag that might give you a clue.

[electrolux]

Code: Select all

$ dmesg | grep random
[    0.000000] random: get_random_u32 called from __kmem_cache_create+0x5c/0x544 with crng_init=0
[    5.551550] random: fast init done
[   10.580611] random: systemd: uninitialized urandom read (16 bytes read)
[   10.581603] random: systemd: uninitialized urandom read (16 bytes read)
[   10.582322] random: systemd: uninitialized urandom read (16 bytes read)
[  681.166052] random: crng init done
[  681.166136] random: 7 urandom warning(s) missed due to ratelimiting

680 seconds is 11 mins, 20 seconds. Plus POST time and yaboot or something looking at the CDROM, and that makes the 12 minute delay I mentioned.

With b43 blacklisted, wlan0 manual, straight after a reboot (about 50 seconds + POST etc.) I have tried things manually. The module loads fast, but then ifup -v wlan0 hangs until about a 12min uptime. Manually running wpa_supplicant as the scripts to, and it is just that program seeming to wait.

The Googles have then indicated this could be a kernel bug, but my dinner needs to come out the oven and so that needs looking at now

[oswaldkelso]

http://powerpcliberation.blogspot.com/2 ... pdate.html

https://lists.debian.org/debian-powerpc ... 00000.html

https://forums.macrumors.com/threads/po ... s.2128808/

[electrolux]

The last time I checked, b43 firmware is not packaged for debian at all. please correct me if you find out different.

That seems to be the case. There's a zip here
http://cdimage.debian.org/cdimage/unoff ... /20180903/
but it does not contain the b43 FW.

There is no Stretch for PPC, and so Jessie's B43 FW packages are the closest available if I need an executable.

I see now, there is no b43-fwcutter pkg for powerpc arch like on jessie. Well the 666.2 ver is the same as the one I have on stretch, so that's probably not the issue. My device is a lp-phy, and it actually uses three or four firmwares, there are a couple named lpinitvals and such, so if your device is loading several files, it still could be be a firmware mismatch with the current kernel.?

Yeap, mine loads several files.

Getting them back was fun! Ripped apart the firmware-b43-installer package to find where it gets the firmware off the internet, and how it uses b43-fwcutter. And got the source package for b43-fwcutter, compiled the binary with just a 'make', and manually used it to get the firmware files back into /lib/firmware.

As I understand if you did a fresh install then the predictable names would come up, but I think if upgraded then old names are preserved.

That is the way I understand it should work also, but even a new install gives the device the name wlan0. It works fine. I don't think that is the issue either.

Why don't you post your interfaces file? And maybe a little bit of daemon log would help someone spot something... Maybe it's something simple in there. Also ifup has a -v verbose flag that might give you a clue.

Just one mention of dmesg initially probably would have flagged things straight away, there was a clue staring at me all the time.

But that mention of the -v helped, that made it clear wpa_supplicant was just sitting there like a chump when ifup was run. And I was then able to manually recreate wpa_supplicant stalling, and realised the mention in dmesg of "[ 681.166052] random: crng init done" coincided with when wpa_supplicant woke up.

There isn't a kernel bug, a vulnerability has been fixed and now software that relies on random numbers early in the boot process can get stuck. Modern mainstream chips have hardware RNGs, but my Mac Mini's PPC G4 I am certain does not.

Just done a test of fresh reboot and manually bring up wlan0:

Code: Select all

$ time ifup -v wlan0

ifup: configuring interface wlan0=wlan0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/macchanger
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
wpa_supplicant: wpa-driver nl80211,wext (default)
wpa_supplicant: /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -D nl80211,wext -C /run/wpa_supplicant
Starting /sbin/wpa_supplicant...
wpa_supplicant: waiting for "/run/wpa_supplicant.wlan0.pid":  0 (max. 5)
wpa_supplicant: creating sendsigs omission pidfile: /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
wpa_supplicant: ctrl_interface socket located at /run/wpa_supplicant/wlan0
wpa_supplicant: configuring network block -- 0
wpa_supplicant: wpa-ssid "WOPR" -- OK
wpa_supplicant: wpa-psk ***** -- OK
wpa_supplicant: enabling network block 0 -- OK
/bin/ip addr add 192.168.23.11/255.255.255.0 broadcast 192.168.23.255     dev wlan0 label wlan0
/bin/ip link set dev wlan0   up

/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/bind9
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/wpasupplicant

real    14m4.846s
user    0m0.149s
sys     0m0.195s

Getting on for quarter of an hour!

But the wireless then associated within a few seconds of the RNG being full.

Code: Select all

[   77.220713] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[   77.352104] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  918.152930] random: crng init done
[  918.153015] random: 7 urandom warning(s) missed due to ratelimiting
[  920.649286] wlan0: authenticate with 00:0c:c6:62:12:9f
[  920.679983] wlan0: send auth to 00:0c:c6:62:12:9f (try 1/3)
[  920.685729] wlan0: authenticated
[  920.688046] wlan0: associate with 00:0c:c6:62:12:9f (try 1/3)
[  920.691719] wlan0: RX AssocResp from 00:0c:c6:62:12:9f (capab=0x431 status=0 aid=2)
[  920.692138] wlan0: associated
[  920.778622] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

I am certain I have tracked down this boot delay and networking service failure.

The rng-tools package is suggested elsewhere, but I don't think it will do much on PPC... it is so reduced in instructions, it has no features

Code: Select all

$ cat /proc/cpuinfo 
processor       : 0
cpu             : 7447A, altivec supported
clock           : 1416.666661MHz
revision        : 1.2 (pvr 8003 0102)
bogomips        : 83.24

timebase        : 41620997
platform        : PowerMac
model           : PowerMac10,1
machine         : PowerMac10,1
motherboard     : PowerMac10,1 MacRISC3 Power Macintosh 
detected as     : 287 (Mac mini)
pmac flags      : 00000010
L2 cache        : 512K unified
pmac-generation : NewWorld
Memory          : 1024 MB

I'm going to look into haveged, that may be able to supply the entropy.

Thanks so much for humouring this attempt at using near cutting edge, unsupported software, on legacy kit.

And thanks for the links oswaldkelso, just seen them as I am doing this post, will check them out.

[electrolux]

Installing haveged appears to have provided a working solution.

The system now has lots of random entropy available and wpa_supplicant no longer hangs for a long time at boot.

1 minute after boot:

Code: Select all

$ cat /proc/sys/kernel/random/entropy_avail
1813

It was 5 at that point without haveged installed!


Those links were good oswaldkelso, I had put some wear and tear on Google trying to find out about getting from Jessie to ports, never saw those and forged my own path. Turns out there are some, um, other adjustments to make