Disable WiFi when car powered off

[MelGrubb]

I see that Dongle Mode seems to be an attempt to detect whether the car is on or not by looking for the car's hands-free mode. Would it be possible to use this as a signal to enable/disable the WiFi? My car's Android Auto USB port never turns off, which means I have a car in my driveway broadcasting an SSID that my phone knows about, and will try to connect to rather than connecting to the home WiFi. If the Raspberry Pi (or other SBC) WiFi could be toggled off when aa-proxy can tell that the car itself is off, then that would be a win for both security and stand-by power draw.

I like the idea that my tiny Pi Zero W is only drawing 100mA, but is ready to go as soon as I turn on the car. I could hack some solution by chopping the +5 from one cable to make a data-only cable and then run a second cable to an adapter in the switched lighter, and that would effectively let my car go "radio silent" when it's not turned on, but now I have the whole pesky boot time problem. I'd love an "awake, but silent" mode instead.

I considered wiring up something to a GPIO pin (after dropping the voltage) to let a pi sense when the accessory power is on and then call rfkill or something like that, but that requires Python and now I have multiple services running on an original Pi Zero... not ideal. This seems like something that would work better as a first-class feature to me.

[manio]

This is actually a well-known issue with many cars - especially Kia/Hyundai models that keep the USB port powered all the time. It also happens with some EVs while they're charging, since the car's electronics periodically wake up, which creates a very similar situation.

The known workarounds are (you've already mentioned some of them):

1. Use a USB Y-split cable and power the Raspberry Pi from the cigarette socket. In most cars, that socket is switched off when the car goes to sleep, so the Pi powers down as well.

2. Use MITM mode together with stop-on-disconnect. When you disconnect Android Auto from your phone, it not only disconnects the AA session but also stops trying to reconnect until the Raspberry Pi is rebooted or you manually reconnect. I personally use this when my car is charging and my phone is still within Wi-Fi range.

3. A bit of a workaround, but I know someone shared a script that continuously scans for nearby Wi-Fi networks. If it detects your home Wi-Fi, it disconnects the Android Auto connection automatically.

[MelGrubb]

1. Yeah, hardware hack. I was hoping to avoid the "wait for reboot" delay. Leaving the dongle awake but silent would be ideal.
2. For me, this doesn't do anything, really. I'd be turning the car off and leaving, so I'd be forced to unplug the pi to force a reboot. That's arguably worse in my case.
3. The third option would kill the ability to get the maps running in your own driveway.

It sounds like the split cable is the only sure-fire solution, and I just have to accept the boot delay.

[manio]

If you've got any ideas, I think it could be fun to play around with them and implement them - for example, handling a button on a GPIO, or something similar. If you can figure out through CAN - or your own way - that the car is turned off, that should probably work too. Python isn't really needed - all of this can be done in Rust. I've already got GPIO handling sorted out...

[MelGrubb]

I had just read about the "dongle mode" stuff and thought that sounded ideal as an "is it on" detection that wouldn't require any additional hardware or reliance on GPIO in general. If that signal is reliable enough, then it could work in some cases. Maybe not all, but at least some.

This will be my second attempt at setting up a wireless AA dongle with a Pi, and the first on this project. I found my way here because I was searching for a solution to exactly this problem, found your modern, rust-based version of this idea, and saw what looked to be a useful signal for enabling/disabling things. I suppose the Bluetooth has to remain on in order to detect the head unit, but that's not as big of a security target as WiFi is.

For GPIO, my thought was to put a USB adapter in the lighter which would give a cleaner 5V signal. That's still higher than the 3.3V the Pi wants, so now we're building in some resistors, and it becomes less of a freebie. Same with switches. The strategy of detecting the head unit via Bluetooth sounded like the path of least resistance for the end user though. Maybe it doesn't work in ALL cars, but it could work in some, anyway. I'll be burning an image and trying it out in "always on" mode later this week. If that works out, then I'll try the y-cable approach. I think I have one around somewhere already and should only need to cut the 5V line on the main plug. Seems simple enough.

[manio]

I had just read about the "dongle mode" stuff and thought that sounded ideal as an "is it on" detection that wouldn't require any additional hardware or reliance on GPIO in general. If that signal is reliable enough, then it could work in some cases. Maybe not all, but at least some.

I wouldn't connect dongle mode with any of this at all - it's meant for a completely different use case. Also, I think we should probably remove it since it's outdated and no longer supported in origin hardware, which is Motorola MA1. There's more info here.

I suppose the Bluetooth has to remain on in order to detect the head unit, but that's not as big of a security target as WiFi is.

We thought about that too - i.e. checking from the RPi whether the HU is advertising its Bluetooth. But there are two problems - first, it's very unreliable. Second, it doesn't work like Wi-Fi where you just scan for a list of APs - you actually have to try connecting to it to know for sure.

[MelGrubb]

Well, that's too bad. And I suppose there's no reliable way to detect if there's anything (other than power) on the other end of the USB cable or that would have been done already. It sounds like it's down to either getting power from somewhere that's switched and incurring the start-up time penalty or using a GPIO pin to detect a switched power line by dropping either the car's own 12V or a 5V USB adapter down to 3.3V.

Thanks for the explanation.

[MelGrubb]

I think this issue can be either closed or turned into a general request for GPIO support for enabling/disabling wireless. That seems to be the most universal fix because it could work on any vehicle as long as you have access to a switched power line. For what it's worth, you could even just create a switch that shunts that GPIO pin to one of the 3.3V lines on the same header and make yourself an on/off switch that leaves the Pi powered but disables the wireless, effectively putting the system to "standby" mode.

One thing I still need to look into is whether my USB port retains its power when starting the car. If it gets interrupted during cranking, then all of this is for nothing anyway. The whole point of this was to try to find a way around the somewhat significant boot delay, after all.

[manio]

I understand. In that case, let's see how it behaves. Personally, I'd lean toward turning this into a more general feature request for GPIO-based wireless enable/disable support, since it would likely be useful for a wider range of setups...

[Snirpo]

MA1 actually still does "dongle mode" (Bluetooth name == AndroidAuto-xxxxx == dongle mode). The only thing dongle mode does it only startup AA when the handsfree of the car is connected to the phone. It triggers logic in AA which "bonds" the handsfree of the car to the dongle.