Piaware SD card image ver 6.1 - WiFi config issue

(1) After writing image, and while microSD card was still plugged into Windows Desktop, in file /boot/piaware-config.text added wifi SSID and Password and saved. Also created a text file in /boot and named SSH

image

 

(2) Ejected microSD card from Desktop, slipped into RPi Model 4, and powered up. No WiFi. Cannot SSH

(3) Connected network wire and could SSH, got the following notice:

image

 

(4) Shutdown Pi, slipped out microSD card, plugged into Windows Desktop, opened drive for microSD card, opened the file piaware-config.txt in Notepad and at the end added rfkill no and wirless-country CA, as shown in screenshot below.

image

 

(5) Slipped microSD card in RPi Model 4, powered up, still no WiFi.

(6) Connected network wire, gave command sudo raspi-config , added WiFi country, SSID, WiFi Password and Rebooted. WiFi started working. :slightly_smiling_face: . Disconnected network wire.

image

 

rfkill man | Linux Command Library

$ rfkill unblock wlan

I realized that @abcd567 was referring to the parameter
rfkill - yes or no in:

Not the rfkill command itself.

2 Likes

@obj
Before it was very easy. While the microSD card was still plugged into Desktop/Laptop, just adding wifi ssid & password in file /boot/piaware-config.txt was enough to enable WiFi right from first boot. Now it requires a wired connection and sudo raspi-config. What happened, why this change?

Shouldn’t have changed as far as I’m aware. What hardware?

Computer: Raspberry Pi Model 4 - 4 GB Ram
OS: piaware-sd-card-6.1.img (downloaded today PiAware - ADS-B and MLAT Receiver - FlightAware).

I’ve have the same issue, but I have no way to use a wired connection. I am stuck on Buster until this issue is resolved.
RPi 4b 4gb
Image 2021-10-30-raspios-bullseye-armhf.zip

But the piaware sdcard image is buster-based, not bullseye based.

This is Raspi OS from raspberrypi.org, NOT a piaware SD card image from Flightaware.
The image from raspberrypi.org require to add file wpa_supplicant.conf in /boot folder immediately after writing the image and while the microSD card is plugged into Desktop/Laptop.

I cannot reproduce this on a Pi 4 1GB (fresh 6.1 image, only changes were to create /boot/ssh to enable ssh and modify /boot/piaware-config.txt to set wireless-ssid and wireless-password)

$ ssh pi@192.168.1.107
The authenticity of host '192.168.1.107 (192.168.1.107)' can't be established.
ECDSA key fingerprint is SHA256:0H693IXXZgj8+wDieNd8BZf70A727GgpukmrsLIPLak.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.107' (ECDSA) to the list of known hosts.
pi@192.168.1.107's password: 
Linux piaware 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please type 'passwd' to set a new password.

pi@piaware:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether dc:a6:32:00:a3:88 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:a6:32:00:a3:89 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.107/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 86373sec preferred_lft 75573sec
    inet6 2406:3003:2007:2723:f75b:34b2:dedc:aa2f/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 147283sec preferred_lft 147283sec
    inet6 fe80::16e8:1aca:db1a:7efe/64 scope link 
       valid_lft forever preferred_lft forever

I also have another RPi Model 4 - 1 Gb, and it’s PiawareSD card did not give any such issue when I downloaded & wrote that image immediately after ver 6.1 was released.

OK I will again write the today’s downloaded image on a spare microSD card and try that card in both Model 4 RPis (1 Gb & 4 Gb) to see if it is the image or RPi which is causing the problem.

I wonder if it is that your 4GB has an unusual mac address. The rfkill support scripts in the piaware image will unblock wifi when it sees what looks like a Pi’s wireless interface, but it does this by looking at mac address prefixes, maybe something is going wrong there.

What does ip addr look like on the problem Pi?

The problem RPi (4 GB Ram) is feeding Station 76000.

The no-problem RPi (1 GB Ram) is feeding Station 5252.

Today morning I switched it to Piaware SD Card image. Before today, for last two days I was operating it on 2021-10-30-raspios-bullseye-armhf-lite.zip, and before that for more than a month on DietPi Bullseye. Never faced this issue.

pi@piaware:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether e4:5f:01:1a:0f:a8 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:1a:0f:a9 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.23/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 169437sec preferred_lft 147837sec
    inet6 2607:fea8:4d00:7a00::8b01/128 scope global dynamic noprefixroute
       valid_lft 601433sec preferred_lft 601433sec
    inet6 2607:fea8:4d00:7a00:bc51:27ed:d29f:cf75/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 300sec preferred_lft 300sec
    inet6 fe80::dacc:a974:e57b:d13f/64 scope link
       valid_lft forever preferred_lft forever
pi@piaware:~ $

Yep, mac address is the problem. Looks like they have switched to a new OUI.

DC:A6:32 Raspberry Pi Trading Ltd (piaware knows about this one)
E4:5F:01 Raspberry Pi Trading Ltd (piaware doesn’t know about this one)

For PiAware 7 I’ll teach it about the new OUI, and I think also unwind the default-to-rfkill-off behaviour that exists in the base raspbian image that we start from.

3 Likes

Thanks @obj for clarifying.
Anyway I am now writing a spare microSD card with Piaware SD Card image ver 6.1 and after adding ssid & password in `/boot/piaware-config.txt, will try this card in both the RPi’s, and report back.

Wrote a spare microSD card with Piaware SD Card image ver 6.1 and after adding SSID & PASSWORD in `/boot/piaware-config.txt, tried this card in both the RPi’s, Results as follows:

WiFi did not work on RPi Model 4 with Mac e4:5f:01
WiFi worked OK on RPi Model 4 with Mac dc:a6:32

1 Like

 

@obj
Has this been resolved in today’s ver 7.0 SD card release?

Should be: Teach set-rfkill about additional OUIs used on newer Pis · flightaware/piaware-support@5660e83 · GitHub

1 Like

sorry to resurrect this, but I’m having the same problem with the piaware 7.2 image on a Pi 3. I have put “wireless-country CA” in /boot/piaware-config.txt but neither the internal nor a USB WiFi adapter are recognized. The USB adapter appears in lsusb, but sudo iwconfig says no WiFi adapters are found. In wpa_supplicant.conf, it reads “country=00”. This should be CA, should it not? When I insert the same card in a Mdl 4, then country=CA appears in wpa_supplicant.conf.

I’ve been running the Piaware image 6.1 for quite some while on a Pi 3. Interestingly, the country in wpa_supplicant.conf is 00 but both the internal and USB wifi work fine.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.