epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 9:58 am

I’ve been fiddling with the micro-AP capability of the built in wireless interfaces on Pi on and off for a while. The general idea is to make onboarding easier esp. for users running their Pi headless for the first time on a new network. Wireless credentials can be wrong or the user may not be able to manage how to find the IP address of the Pi or find it via its zeroconf name.

With the current version of Raspios, and at least on a Pi 3B, I reckon the micro-AP unofficial feature can be made to work reliably. Wpa-supplicant can drive the AP, no need to depend on hostapd. The AP can operate over zeroconf/link-local, no need for a DHCP server (there isn’t one in busybox IIRC, adding one could be possible). The stock dhcpcd config can be used.
Enabling/disabling the micro-AP can be done at any time, for what I see, as long as the change is done in a temporary network namespace (similar to this.) All in all that should be enough to provide a rescue network that allows users to log in, examine the situation, run raspi-config, fix their configuration and reboot.

The AP is literally a backdoor to the machine, so control is a concern. Automated AP start in case network configuration has failed isn't great for various reasons. Adding a user-defined wireless password to protect the AP creates a usability problem. The only sane way of providing the feature is, I think, through positive, simple and local user input. Give me a dedicated button, and spawning an open AP wouldn't bother me at all.

Which brings me to the point. I've looked at the gpio-shutdown overlay and to me it's just what the doctor ordered: on demand, could be activated from a keyboard key combination or with a GPIO button.
However I suspect the power button to be a specific case. I'd like to know:
  • Which magic keyboard key to choose, and how to make the system(d) react to it? I'm looking for something that would work in both Desktop and Lite versions of Raspios.
  • Which GPIO pin for the physical button in absence of keyboard?

Thanks in advance.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

User avatar
thagrol
Posts: 5555
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 12:13 pm

In my experience, the shutdown part of the power button isn't a special case and can use any GPIO. The startup part is though and is specific to GPIO 3. That's probably because GPIO 3 has an external pull up and is next to a ground pin.

My guess is that gpo-shutdown defaults to GPIO 3 so both functions can be done with a single button.

One thought occurs: if you're going to have to write code that listens for a key event why not just listen for the GPIO edge event instead?
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
dickon
Posts: 2001
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, in Towcester

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 1:49 pm

epoch1970 wrote:
Thu Jul 29, 2021 9:58 am
With the current version of Raspios, and at least on a Pi 3B, I reckon the micro-AP unofficial feature can be made to work reliably.
Without wishing to hijack the thread, can somebody please point me at some documentation somewhere as to *why* the AP-as-a-second-interface thing is considered 'unofficial' and 'micro'? Having looked at the iw(8) source, AFAICS the reason for the '__ap' (as opposed to 'ap') in the commandline required to set it up is simply to stop iw erroring out with a message telling you to go and run hostapd instead.

It's not a bad idea, though. An AP-onna-button-press-at-boot, I mean. Not convinced by the IPv4 autoconf bit, though. IME it doesn't work very well, and there's a lengthy timeout before most OSes give up trying to obtain an address and drop to it.
As it is apparently board policy to disallow any criticism of anything, as it appears to criticise something is to criticise all the users of that something, I will no longer be commenting in threads which are not directly relevant to my uses of the Pi.

bls
Posts: 1683
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 2:03 pm

Interesting idea, @epoch. I built an simple "automatic AP" (https://github.com/gitbls/autoap) that uses wpa_supplicant and systemd-networkd (which has a nice built-in DHCP server) that you might find useful as a starting point. It comes up with wpa_supplicant in AP mode if it can't connect to a WiFi network. One way to trigger it via keypress (instead of automatically) would be to use triggerhappy, i'm sure there are others.

I agree with you that having it be fully automatic creates some security risks. I'm not as clear as to the value of the gpio-controlled shutdown, since you can connect to the Pi's AP via SSH and shut it down once the AP is up.
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 2:44 pm

thagrol wrote:
Thu Jul 29, 2021 12:13 pm
In my experience, the shutdown part of the power button isn't a special case and can use any GPIO. The startup part is though and is specific to GPIO 3. That's probably because GPIO 3 has an external pull up and is next to a ground pin.

My guess is that gpo-shutdown defaults to GPIO 3 so both functions can be done with a single button.

One thought occurs: if you're going to have to write code that listens for a key event why not just listen for the GPIO edge event instead?
The button could use GPIO 3, I don’t know how popular the shutdown overlay is. TBH I don’t know my way around GPIOs, I use them rarely so I don’t know which one would be “best”.

In the shutdown overlay, when the button closes the circuit, a PWR keyboard code is generated, nothing more. I like the idea of being able to use either a button or a keyboard. For the GPIO-challenged like myself, a special kbd key would be easiest.

I think the difficulty comes next: AFAIK, the PWR keyboard code is captured by systemd (systemd-logind or some such). But that is a special case and other codes are best interpreted elsewhere. I’d be happy to add a udev rule, but I don’t now if that is the politically correct thing to do, esp. in the Desktop case.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 3:00 pm

dickon wrote:
Thu Jul 29, 2021 1:49 pm
epoch1970 wrote:
Thu Jul 29, 2021 9:58 am
With the current version of Raspios, and at least on a Pi 3B, I reckon the micro-AP unofficial feature can be made to work reliably.
Without wishing to hijack the thread, can somebody please point me at some documentation somewhere as to *why* the AP-as-a-second-interface thing is considered 'unofficial' and 'micro'? Having looked at the iw(8) source, AFAICS the reason for the '__ap' (as opposed to 'ap') in the commandline required to set it up is simply to stop iw erroring out with a message telling you to go and run hostapd instead.

It's not a bad idea, though. An AP-onna-button-press-at-boot, I mean. Not convinced by the IPv4 autoconf bit, though. IME it doesn't work very well, and there's a lengthy timeout before most OSes give up trying to obtain an address and drop to it.
I think “micro” is its name In the vendor’s documentation. And it’s unofficial because basically it doesn’t perform very well and was a pig to setup. Apparently the firmware has made some progress, or maybe it is the Linux code. But in any case I think now it works reliably enough to make limited use of it.

IPv4ll (zeroconf/bonjour/APIPA) is a tricky one. For me it works perfectly well, but it might not work from some (old) computers. If you ditch autoconf you need DHCP, the busybox in Raspios doesn’t have udhcpd compiled in. The interface would need a static IP, but there is no guarantee someone doesn’t use 10.3.14.0/24 at home. So you need to add IP conflict detection, it gets complicated.
But of course if the AP is supposed to rescue users who can’t manage to connect via “raspberrypi.local”, serving them with more of the same might not be the best idea… I like the simplicity of zeroconf, though.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

User avatar
thagrol
Posts: 5555
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 3:36 pm

epoch1970 wrote:
Thu Jul 29, 2021 2:44 pm
thagrol wrote:
Thu Jul 29, 2021 12:13 pm
In my experience, the shutdown part of the power button isn't a special case and can use any GPIO. The startup part is though and is specific to GPIO 3. That's probably because GPIO 3 has an external pull up and is next to a ground pin.

My guess is that gpo-shutdown defaults to GPIO 3 so both functions can be done with a single button.

One thought occurs: if you're going to have to write code that listens for a key event why not just listen for the GPIO edge event instead?
The button could use GPIO 3, I don’t know how popular the shutdown overlay is. TBH I don’t know my way around GPIOs, I use them rarely so I don’t know which one would be “best”.
Personally, I'd stay away from GPIO 3 as it's one of the I2C pins. If it were me, I'd make it configurable with a default of 26. GPIO 26 (broadcom numbering) doesn't conflict with I2C, I2S, SPI, PWM, etc and is next to a ground pin. According to http://pinout.xyz at least.
In the shutdown overlay, when the button closes the circuit, a PWR keyboard code is generated, nothing more. I like the idea of being able to use either a button or a keyboard. For the GPIO-challenged like myself, a special kbd key would be easiest.

I think the difficulty comes next: AFAIK, the PWR keyboard code is captured by systemd (systemd-logind or some such). But that is a special case and other codes are best interpreted elsewhere. I’d be happy to add a udev rule, but I don’t now if that is the politically correct thing to do, esp. in the Desktop case.
I don't see why a udev rule would be politically incorrect.

Rather than write your own overlay you might want to investigate the gpio-key one. From /boot/overlays/README:

Code: Select all

Name:   gpio-key
Info:   This is a generic overlay for activating GPIO keypresses using
        the gpio-keys library and this dtoverlay. Multiple keys can be
        set up using multiple calls to the overlay for configuring
        additional buttons or joysticks. You can see available keycodes
        at https://github.com/torvalds/linux/blob/v4.12/include/uapi/
        linux/input-event-codes.h#L64
Load:   dtoverlay=gpio-key,<param>=<val>
Params: gpio                    GPIO pin to trigger on (default 3)
        active_low              When this is 1 (active low), a falling
                                edge generates a key down event and a
                                rising edge generates a key up event.
                                When this is 0 (active high), this is
                                reversed. The default is 1 (active low)
        gpio_pull               Desired pull-up/down state (off, down, up)
                                Default is "up". Note that the default pin
                                (GPIO3) has an external pullup
        label                   Set a label for the key
        keycode                 Set the key code for the button
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 3:56 pm

bls wrote:
Thu Jul 29, 2021 2:03 pm
Interesting idea, @epoch. I built an simple "automatic AP" (https://github.com/gitbls/autoap) that uses wpa_supplicant and systemd-networkd (which has a nice built-in DHCP server) that you might find useful as a starting point. It comes up with wpa_supplicant in AP mode if it can't connect to a WiFi network. One way to trigger it via keypress (instead of automatically) would be to use triggerhappy, i'm sure there are others.

I agree with you that having it be fully automatic creates some security risks. I'm not as clear as to the value of the gpio-controlled shutdown, since you can connect to the Pi's AP via SSH and shut it down once the AP is up.
Assuming you enable both SSH and the AP right at first install, the machine is wide open (default credentials) once the AP has started. A non-standard SSID password can mitigate the risk in case of time-limited auto start at boot, but some users will fail at selecting or using a password. The Imager could generate a “WiFi QR” for the user to flash in case of problem, but that is a complication and more or less requires a smartphone.

The risk doesn’t exist at all until the AP has started, that’s why I suggest a physical button to let the user start (and possibly stop) the AP. Given the limited capability of the built in wireless, an attacker would need to be in the vicinity. So the security recommendation becomes simple: “Don’t press the button to recover your Pi when you’re surrounded by shady characters. Good luck.”
And with that said, I suggest the AP could be totally password free. I think the uap can work in open mode regardless of the security used for the main client interface. Wpa-psk with a factory password is no different to open, basically.

I will look into systemd, as it’s very much present in raspios indeed. I think I have seen an ICS/hotspot mode somewhere in networkd, perhaps that can help sort the IPv4 conflict rigmarole. Passing “denyinterfaces uap0” to dhcpcd would be simple enough (although not my pref)

Edit. Forgot Triggerhappy. I'm not sure that's installed on Lite (never used it.) I'll take a look.
Last edited by epoch1970 on Thu Jul 29, 2021 4:51 pm, edited 1 time in total.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 4:04 pm

thagrol wrote:
Thu Jul 29, 2021 3:36 pm
Rather than write your own overlay you might want to investigate the gpio-key one.
That looks fantastic! I didn’t knew this existed.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 6:21 pm

Ok, so tiggerhappy looks to be running on my copy of raspios light and the manpage says
man thd wrote:... Triggerhappy is especially suited to hardware related switches like volume or wifi control ...
So I guess I'd better learn how to use it.

I have found a useful feature in systemd-networkd (...) Take a look:

Code: Select all

root@lab:/home/pi# ip -brief address 
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0             UP             192.168.1.217/24 fe80::9a2e:eef4:2b01:1dac/64 
wlan0            UP             192.168.1.216/24 fe80::80c0:3eaf:c503:1da5/64 
ap0              UP             10.0.0.1/24 fe80::ba27:ebff:fe54:437a/64 

root@lab:/home/pi# cat /etc/systemd/network/raspi_rescue_ap.network 
[Match]
Name=ap0

[Network]
DHCPServer=true
#MulticastDNS=true

[Address]
#Address=10.3.14.0/24
Address=0.0.0.0/24

In other words, when networkd is given an empty address assignment like "Address=0.0.0.0/24" it looks among the configured interfaces and picks by itself a non-conflicting subnet. It chose "10.0.0.1/24" for ap0 in this case, I connected a client and received 10.0.0.15 via DHCP. Nice.

For some reason I have to "systemctl start wpa_supplicant-nl80211@ap0" manually for now. And boot is now slow as molasses. Nevertheless, looks promising so far.

Also, here is the start-stop script I currently use. It just adds/removes the µAP interface "ap0" in a separate netspace. dhcpcd, and now systemd-networkd, do the rest.

Code: Select all

root@lab:/home/pi# cat /usr/local/bin/microap.sh 
#!/bin/sh -u
sta='wlan0'; uap='ap0'; phy=; act="${1:-usage}"

cleanup(){
	err=$?
	case "${err}" in
		0) true ;;
		*) echo "Error ${err} at $0"
		   grep --with-filename --line-number "exit ${err}" $0
		;;
	esac
	ip netns pids tmp-$$ 2>/dev/null | xargs --no-run-if-empty kill
	ip netns del tmp-$$ >/dev/null 2>&1
}
trap cleanup EXIT

[ "${act}" = 'usage' ] && echo "$(basename $0): missing argument \"start\" or \"stop\"" && exit 0
[ "$(id -u)" != '0' ] && echo "$(basename $0): must run as root. Exit." && exit 0
[ -e "/sys/class/net/${uap}" ] && [ "${act}" = 'start' ] && echo "$(basename $0): Nothing to do for ${act}. Exit" && exit 0
[ ! -e "/sys/class/net/${uap}" ] && [ "${act}" = 'stop' ] && echo "$(basename $0): Nothing to do for ${act}. Exit" && exit 0
phy="$(cat /sys/class/net/${sta}/phy80211/name 2>/dev/null)" || exit 1
ip netns add tmp-$$ || exit 2
iw "${phy}" set netns name tmp-$$ || exit 3

case "${act}" in
	'start') # add ap0
		echo "$(basename $0): start AP"
		ip netns exec tmp-$$ iw phy "${phy}" interface add "${uap}" type __ap || exit 4
	;;
	'stop')  # remove ap0
		echo "$(basename $0): stop AP"
		ip netns exec tmp-$$ iw dev "${uap}" del || exit 5
	;;
esac

ip netns exec tmp-$$ iw "${phy}" set netns 1 || exit 6

exit 0
Also also, the wpa_supplicant file I'm using for now

Code: Select all

root@lab:/home/pi# cat /etc/wpa_supplicant/wpa_supplicant-nl80211-ap0.conf 
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=FR
#ap_scan=2

network={
    ssid="µAP"
    mode=2
    key_mgmt=WPA-PSK
    proto=RSN
    group=CCMP
    pairwise=CCMP
    psk="thisisatest"
    # See https://en.wikipedia.org/wiki/List_of_WLAN_channels
#chan 6    frequency=2437
#chan 1    frequency=2412
#chan 11   frequency=2462
}
There is no "chan X" specified at all and this works fine it seems. The machine defaults to using channel 11 for ap0 when wlan0 is disconnected and the frequency used by wlan0 when it's connected.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

bls
Posts: 1683
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 7:00 pm

epoch1970 wrote:
Thu Jul 29, 2021 6:21 pm
Ok, so tiggerhappy looks to be running on my copy of raspios light and the manpage says
man thd wrote:... Triggerhappy is especially suited to hardware related switches like volume or wifi control ...
So I guess I'd better learn how to use it.

I have found a useful feature in systemd-networkd (...) Take a look:

Code: Select all

root@lab:/home/pi# ip -brief address 
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0             UP             192.168.1.217/24 fe80::9a2e:eef4:2b01:1dac/64 
wlan0            UP             192.168.1.216/24 fe80::80c0:3eaf:c503:1da5/64 
ap0              UP             10.0.0.1/24 fe80::ba27:ebff:fe54:437a/64 

root@lab:/home/pi# cat /etc/systemd/network/raspi_rescue_ap.network 
[Match]
Name=ap0

[Network]
DHCPServer=true
#MulticastDNS=true

[Address]
#Address=10.3.14.0/24
Address=0.0.0.0/24

In other words, when networkd is given an empty address assignment like "Address=0.0.0.0/24" it looks among the configured interfaces and picks by itself a non-conflicting subnet. It chose "10.0.0.1/24" for ap0 in this case, I connected a client and received 10.0.0.15 via DHCP. Nice.

For some reason I have to "systemctl start wpa_supplicant-nl80211@ap0" manually for now. And boot is now slow as molasses. Nevertheless, looks promising so far.

Also, here is the start-stop script I currently use. It just adds/removes the µAP interface "ap0" in a separate netspace. dhcpcd, and now systemd-networkd, do the rest.

Code: Select all

root@lab:/home/pi# cat /usr/local/bin/microap.sh 
#!/bin/sh -u
sta='wlan0'; uap='ap0'; phy=; act="${1:-usage}"

cleanup(){
	err=$?
	case "${err}" in
		0) true ;;
		*) echo "Error ${err} at $0"
		   grep --with-filename --line-number "exit ${err}" $0
		;;
	esac
	ip netns pids tmp-$$ 2>/dev/null | xargs --no-run-if-empty kill
	ip netns del tmp-$$ >/dev/null 2>&1
}
trap cleanup EXIT

[ "${act}" = 'usage' ] && echo "$(basename $0): missing argument \"start\" or \"stop\"" && exit 0
[ "$(id -u)" != '0' ] && echo "$(basename $0): must run as root. Exit." && exit 0
[ -e "/sys/class/net/${uap}" ] && [ "${act}" = 'start' ] && echo "$(basename $0): Nothing to do for ${act}. Exit" && exit 0
[ ! -e "/sys/class/net/${uap}" ] && [ "${act}" = 'stop' ] && echo "$(basename $0): Nothing to do for ${act}. Exit" && exit 0
phy="$(cat /sys/class/net/${sta}/phy80211/name 2>/dev/null)" || exit 1
ip netns add tmp-$$ || exit 2
iw "${phy}" set netns name tmp-$$ || exit 3

case "${act}" in
	'start') # add ap0
		echo "$(basename $0): start AP"
		ip netns exec tmp-$$ iw phy "${phy}" interface add "${uap}" type __ap || exit 4
	;;
	'stop')  # remove ap0
		echo "$(basename $0): stop AP"
		ip netns exec tmp-$$ iw dev "${uap}" del || exit 5
	;;
esac

ip netns exec tmp-$$ iw "${phy}" set netns 1 || exit 6

exit 0
Also also, the wpa_supplicant file I'm using for now

Code: Select all

root@lab:/home/pi# cat /etc/wpa_supplicant/wpa_supplicant-nl80211-ap0.conf 
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=FR
#ap_scan=2

network={
    ssid="µAP"
    mode=2
    key_mgmt=WPA-PSK
    proto=RSN
    group=CCMP
    pairwise=CCMP
    psk="thisisatest"
    # See https://en.wikipedia.org/wiki/List_of_WLAN_channels
#chan 6    frequency=2437
#chan 1    frequency=2412
#chan 11   frequency=2462
}
There is no "chan X" specified at all and this works fine it seems. The machine defaults to using channel 11 for ap0 when wlan0 is disconnected and the frequency used by wlan0 when it's connected.
Wow! Great find in systemd.network features!
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

bls
Posts: 1683
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 7:06 pm

epoch1970 wrote:
Thu Jul 29, 2021 6:21 pm
In other words, when networkd is given an empty address assignment like "Address=0.0.0.0/24" it looks among the configured interfaces and picks by itself a non-conflicting subnet. It chose "10.0.0.1/24" for ap0 in this case, I connected a client and received 10.0.0.15 via DHCP. Nice.
Confirmation of this: "Specify this key more than once to configure several addresses. Mandatory unless DHCP is used. If the specified address is 0.0.0.0 (for IPv4) or :: (for IPv6), a new address range of the requested size is automatically allocated from a system-wide pool of unused ranges."

From https://wiki.archlinux.org/title/systemd-networkd. Learning a lot today :)
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

cleverca22
Posts: 4366
Joined: Sat Aug 18, 2012 2:33 pm

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 8:54 pm

thagrol wrote:
Thu Jul 29, 2021 12:13 pm
In my experience, the shutdown part of the power button isn't a special case and can use any GPIO. The startup part is though and is specific to GPIO 3. That's probably because GPIO 3 has an external pull up and is next to a ground pin.
of note, the startup pin is also setup in software (bootcode.bin to be specific), and could be any pin

but yeah, it needs a pullup to prevent accidental startups, and the RPF just hasnt bothered adding the option to configure which pin

User avatar
thagrol
Posts: 5555
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: What about a keypress-enabled rescue micro-AP feature?

Thu Jul 29, 2021 11:18 pm

cleverca22 wrote:
Thu Jul 29, 2021 8:54 pm
thagrol wrote:
Thu Jul 29, 2021 12:13 pm
In my experience, the shutdown part of the power button isn't a special case and can use any GPIO. The startup part is though and is specific to GPIO 3. That's probably because GPIO 3 has an external pull up and is next to a ground pin.
of note, the startup pin is also setup in software (bootcode.bin to be specific), and could be any pin

but yeah, it needs a pullup to prevent accidental startups, and the RPF just hasnt bothered adding the option to configure which pin
Have they not bothered or is that all set up before config.txt is read?
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

cleverca22
Posts: 4366
Joined: Sat Aug 18, 2012 2:33 pm

Re: What about a keypress-enabled rescue micro-AP feature?

Fri Jul 30, 2021 12:06 am

thagrol wrote:
Thu Jul 29, 2021 11:18 pm
Have they not bothered or is that all set up before config.txt is read?
it does happen before config.txt is read
the reading could maybe be moved up, but then you may have to turn the sd card hw back off after reading the config...


for pi4, there is bootconf.txt on the SPI flash, which is read before doing the halt/shutdown, so that problem wont exist

User avatar
dickon
Posts: 2001
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, in Towcester

Re: What about a keypress-enabled rescue micro-AP feature?

Fri Jul 30, 2021 10:19 am

epoch1970 wrote:
Thu Jul 29, 2021 3:56 pm
I think the uap can work in open mode regardless of the security used for the main client interface.
I've used it pretty extensively since becoming aware of it some years ago, whether or not the machines in question actually need to use their wifi interfaces in client mode. As far as I can tell, there's no difference at all between plumbing a virtual interface in via 'iw dev wlan0 interface add uap0 type __ap' and passing hostapd uap0 as its interface, or sticking to wlan0 and using that. Performance only seems to suck if you actively use the two at the same time, and, of course, the usual issues with channels may also be problematic. AFAICT, most wifi chipsets support it to handle P2P stuff.
Wpa-psk with a factory password is no different to open, basically.
And WPA-PSK with a WPS button is no different to either... I can only think that someone in marketing was involved in the design of that thing.
As it is apparently board policy to disallow any criticism of anything, as it appears to criticise something is to criticise all the users of that something, I will no longer be commenting in threads which are not directly relevant to my uses of the Pi.

alphanumeric
Posts: 3001
Joined: Tue Jan 19, 2016 2:17 pm
Location: Sydney, Nova Scotia, Canada

Re: What about a keypress-enabled rescue micro-AP feature?

Fri Jul 30, 2021 10:25 am

Just a FYI, if i2c is enabled "dtoverlay=gpio-shutdown" will not work, it is ignored. However if you specify another GPIO pin, other than GPIO 3, it will work.
For example "dtoverlay=gpio-shutdown,gpio_pin=17,active_low=1,gpio_pull=up" works even if i2c is enabled.
I skimmed over some posts so if this was already mentioned my apologies.

User avatar
thagrol
Posts: 5555
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: What about a keypress-enabled rescue micro-AP feature?

Fri Jul 30, 2021 12:21 pm

cleverca22 wrote:
Fri Jul 30, 2021 12:06 am
thagrol wrote:
Thu Jul 29, 2021 11:18 pm
Have they not bothered or is that all set up before config.txt is read?
it does happen before config.txt is read
the reading could maybe be moved up, but then you may have to turn the sd card hw back off after reading the config...


for pi4, there is bootconf.txt on the SPI flash, which is read before doing the halt/shutdown, so that problem wont exist
So it's not that they haven't bothered but that it's a major change that few would need.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
thagrol
Posts: 5555
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: What about a keypress-enabled rescue micro-AP feature?

Fri Jul 30, 2021 12:22 pm

alphanumeric wrote:
Fri Jul 30, 2021 10:25 am
Just a FYI, if i2c is enabled "dtoverlay=gpio-shutdown" will not work, it is ignored. However if you specify another GPIO pin, other than GPIO 3, it will work.
For example "dtoverlay=gpio-shutdown,gpio_pin=17,active_low=1,gpio_pull=up" works even if i2c is enabled.
I skimmed over some posts so if this was already mentioned my apologies.
Yep. I'd expect the same with any other interface pin (SPI etc). That's why I suggested using pin 26, above.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Sat Jul 31, 2021 7:11 pm

I was quite pleased with my network setup solution...
  1. Systemd-networkd

    Code: Select all

    # cat /etc/systemd/network/rpi0.network 
    [Match]
    Name=rpi0
    Type=wlan
    WLANInterfaceType=ap
    
    [Network]
    DHCPServer=true
    MulticastDNS=true
    
    [Address]
    Address=0.0.0.0/24
  2. dhcpcd.conf

    Code: Select all

    # cat /etc/dhcpcd.conf 
    ....
    interface rpi0
    iaid dc:a6:32:00
    env wpa_supplicant_conf=/opt/raspios-rescue-ap/L2/wpa_supplicant-rpi0.conf
    noipv6rs
    static ip_address=
    static ip6_address=
    
... where dhcpcd manages wpa_supplicant when it sees rpi0 appear in the system, and "static ip_address=" instructs it to expect IP config to come from a third-party. Namely from networkd, once it sees the link has come up.

Unfortunately this solution is a bit slower than full management by systemd (more able to kill wpa_supplicant when needed I assume), and so:
  1. dhcpcd

    Code: Select all

    # cat /etc/dhcpcd.conf
    denyinterfaces rpi0
    ....
  2. udev

    Code: Select all

    # cat /etc/udev/rules.d/98-raspios-rescue-ap.rules 
    # Call the service when the interface appears. It stops when the device gets removed.
    # See: https://superuser.com/a/851966
    ACTION=="add", SUBSYSTEM=="net", ENV{DEVTYPE}=="wlan", KERNEL=="rpi0", \
      ATTRS{vendor}=="0x02d0", ATTRS{device}=="0xa9a6", \
      ENV{SYSTEMD_WANTS}+="raspios-rescue-ap.service"
  3. systemd

    Code: Select all

    # cat /etc/systemd/system/raspios-rescue-ap.service 
    # Based on wpa_supplicant-nl80211@.service and https://superuser.com/a/851966
    [Unit]
    Description=WPA supplicant daemon for RaspiOS rescue AP service
    BindsTo=sys-subsystem-net-devices-rpi0.device
    After=sys-subsystem-net-devices-rpi0.device
    Before=network.target
    Wants=network.target
    
    [Service]
    Type=simple
    ExecStart=/sbin/wpa_supplicant -i rpi0 -c /opt/raspios-rescue-ap/L2/wpa_supplicant-rpi0.conf
    
The elegance and simplicity of systemd never ceases to amaze...
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Sun Aug 01, 2021 6:04 pm

I reverted to management of wpa-supplicant via dhcpcd, which saves from installing 2 cryptic config files. In the interface control utility, adding an extra "sleep .5" after creating the uap interface was enough to let dhcpcd keep up.

Using gpio-key on GPIO 26 seems to work fine, currently it emits a key code that is captured by triggerhappy and launches the interface control utility. I imagined doing away with thd (requires a stupid custom systemd unit to stop dropping root privileges, requires a config file), toggling the AP on long key presses only, and also toggling some keyboard and Pi LED to indicate when the AP is on.
But all things considered I think I will leave that to someone else. It took me at least one hour figuring out why my full-size keyboard didn't have an "Fn" key and why I couldn't remap another key to it...

There are a few changes that would need to be made to raspi-config.
- in "list_wlan_interfaces()", in order to skip the uap interface and avoid bombing its supplicant config file with configuration pertaining to the main interface ^^.
- when adding SSID and password via raspi-config (typical rescue scenario) wpa_supplicant gets reconfigured, and that leaves the links in a bizarre state. No crash and recoverable from the console, though, so it should be a matter of handling wpa_supplicant a bit differently in raspi-config. I'll investigate a bit more.

Also I noticed in raspi-config the option to activate the GPIOs over the network. For those who don't mind a fair bit of lag from time to time, that could be another application for the uap.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Tue Aug 03, 2021 6:24 pm

I would appreciate if one or a few discerning owners of:
  • Pi 3B+
  • Pi3A+
  • Pi0w
  • Pi4B (any RAM size)
  • Pi400
running a reasonably recent version of Raspios, and using the built-in wireless interface as wlan0 (stock setup) could run the following command for me, and paste results in this thread:

Code: Select all

systemd-hwdb query "$(cat /sys/class/net/wlan0/device/modalias)" && vcgencmd otp_dump | grep '30:'
I'm interested in identifying the exact wireless chipset model, from the string "ID_MODEL_FROM_DATABASE".
(The otp_dump command is just here to confirm the model of Pi in case someone forgets to mention it in their message.)

To illustrate, this is what I get on a Pi 3B rev 1.2:

Code: Select all

$ systemd-hwdb query "$(cat /sys/class/net/wlan0/device/modalias)" && vcgencmd otp_dump | grep '30:'
ID_VENDOR_FROM_DATABASE=Broadcom Corp.
ID_MODEL_FROM_DATABASE=BCM43438 combo WLAN and Bluetooth Low Energy (BLE)
ID_SDIO_CLASS_FROM_DATABASE=Non-standard SDIO interface
30:00a02082
Thanks in advance!
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

bls
Posts: 1683
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: What about a keypress-enabled rescue micro-AP feature?

Tue Aug 03, 2021 6:29 pm

epoch1970 wrote:
Tue Aug 03, 2021 6:24 pm
I would appreciate if one or a few discerning owners of:
  • Pi 3B+
  • Pi3A+
  • Pi0w
  • Pi4B (any RAM size)
  • Pi400
running a reasonably recent version of Raspios, and using the built-in wireless interface as wlan0 (stock setup) could run the following command for me, and paste results in this thread:

Code: Select all

systemd-hwdb query "$(cat /sys/class/net/wlan0/device/modalias)" && vcgencmd otp_dump | grep '30:'
I'm interested in identifying the exact wireless chipset model, from the string "ID_MODEL_FROM_DATABASE".
(The otp_dump command is just here to confirm the model of Pi in case someone forgets to mention it in their message.)

To illustrate, this is what I get on a Pi 3B rev 1.2:

Code: Select all

$ systemd-hwdb query "$(cat /sys/class/net/wlan0/device/modalias)" && vcgencmd otp_dump | grep '30:'
ID_VENDOR_FROM_DATABASE=Broadcom Corp.
ID_MODEL_FROM_DATABASE=BCM43438 combo WLAN and Bluetooth Low Energy (BLE)
ID_SDIO_CLASS_FROM_DATABASE=Non-standard SDIO interface
30:00a02082
Thanks in advance!
Here's a Pi4B-8GB (Rev 1.4)

Code: Select all

ID_VENDOR_FROM_DATABASE=Broadcom Corp.
ID_MODEL_FROM_DATABASE=BCM43438 combo WLAN and Bluetooth Low Energy (BLE)
ID_SDIO_CLASS_FROM_DATABASE=Non-standard SDIO interface
30:00d03114
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

epoch1970
Posts: 6936
Joined: Thu May 05, 2016 9:33 am
Location: France

Re: What about a keypress-enabled rescue micro-AP feature?

Tue Aug 03, 2021 6:38 pm

Thanks! Suddenly I wonder if this is going to work according to plan.
A 4B doesn't have the same wifi chipset as a 3B... And yet the DB returns the same values.

I imagine this means the modalias string is the same? On my Pi3B:

Code: Select all

$ cat /sys/class/net/wlan0/device/modalias
sdio:c00v02D0dA9A6
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

bls
Posts: 1683
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: What about a keypress-enabled rescue micro-AP feature?

Tue Aug 03, 2021 7:02 pm

epoch1970 wrote:
Tue Aug 03, 2021 6:38 pm
Thanks! Suddenly I wonder if this is going to work according to plan.
A 4B doesn't have the same wifi chipset as a 3B... And yet the DB returns the same values.

I imagine this means the modalias string is the same? On my Pi3B:

Code: Select all

$ cat /sys/class/net/wlan0/device/modalias
sdio:c00v02D0dA9A6
From the same Pi4B-8GB:

Code: Select all

sdio:c00v02D0dA9A6
[/coe]
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

Return to “Raspberry Pi OS”