Show HN: Raspberry Pi Zero W Simultaneous AP and Managed (Client) Mode WiFi | Hacker News Reader

Show HN: Raspberry Pi Zero W Simultaneous AP and Managed (Client) Mode WiFi

blog.thewalr.us

101 pointsalbeec1323 comments

I've had a hard time finding resources on getting a Raspberry Pi Zero W to operate simultaneously as and AP and WiFi client. I pooled together whatever resources I found that failed me, but got part of the way there, and figured out the rest on my own. I figured it would be a good thing to share, since there appear to be a lot of people asking how to do it, and not a lot of solutions out there.

Great work. Would you provide more details about the requirements that led you to running Wifi as AP and a Client?

Thank you. To be totally honest, I don't have a plan fully fleshed out, but the gist of it is this. I'd like to use a few RPi Zero W's as part of a home automation setup, primarily for either monitoring temperature/motion or for remote switching of lights/powered devices using relays.

One way to allow those devices to communicate with each other is via a central server (which I already have available), but it would also be nice to allow devices to communicate directly to each other in an ad-hoc manner. For example, Amazon dash buttons can be used to run arbitrary scripts from a router using dnsmasq when they connect to their configured access point. With the Raspberry Pi running an AP and dnsmasq, the dash button can directly connect without having to go through the server first. However, having the RPi also connected to the WiFi allows for it to access the internet (say to upload logs of activity, or register it's services to a central IoT server on the LAN or WAN) without requiring me to have to script in tasks to bring the WiFi interface up and down to switch between AP/client modes. This would also mean it would always be available remotely.

One of the downsides of the RPi Zero W is that it doesn't have a wired ethernet interface, so having both a WiFi AP and Client mode running at the same time allows it to have LAN/WAN access, while still being able to directly connect with other devices. The added benefit is that since both interfaces are wireless, it can go almost anywhere within range of WiFi, without cable restrictions.

Finally, having the ability to route traffic through the RPi would mean they could potentially be set up in a daisy-chain manner to extend the range of available WiFi access.

When doing assigning you own fictional MAC I would recommend using locally administered addresses. It's basically just one bit flip: https://en.wikipedia.org/wiki/MAC_address#Universal_vs._loca...

  x2-xx-xx-xx-xx-xx
  x6-xx-xx-xx-xx-xx 
  (... etc)

And a question do you know why ap0 doesn't show up in you iw dev command? It seems you are only changing the addr not the device name.

Thanks for the info! I recall reading about that before, but forgot about it.

With respect to your question, I didn't post a log from iw dev after a reboot, but ap0 does appear after reboot.

Before proofreading my post, I originally included output from iw dev at the end to show everything working, but realized output from ip addr was more useful, since it shows actual network addresses and up/down connectivity. I may just re-add that for clarity. Thanks!

I recently did the same thing and have packaged it all up as an Ansible setup script [1]. We're using it for a Pi based robot arm [2], so having a built-in access point and a web interface to use for configuring the WiFi means you don't need to rely on the user plugging in any peripherals. Works well!

Incidentally, the framework (headlessPi [3]) we use to run "apps" in the browser and configure the system is all open source and easy to configure for your own use.

[1] https://github.com/headlessPi/headlessPi-setup [2] https://mime.co.uk/products/mearm-pi/ [3] https://github.com/headlessPi/headlessPi

Awesome project! I browsed through your headlessPi repo and saw how you configure hostapd and whatnot, but I'm having trouble seeing where you actually get the uap0 interface created. Have you tried this on a Pi Zero W yet?

That's great! One thing I've always wanted to build is an open source project to manage wifi on Raspberry Pis, with a similar user experience to Chromecast. It would be really useful as a base for hobby projects, as well as real products.

The idea is that if wifi is not configured or can't connect, then the Raspberry Pi would switch to AP mode. When you connect to the SSID, you would see a web page where you can configure your home wifi SSID and password, or choose a network from a list.

Does something like this already exist? I think it could be used in a lot of different projects, including RasPlex [1] and RetroPie [2]. I haven't looked at those projects for a while though, so maybe they already have that feature.

[1] http://www.rasplex.com/

[2] https://retropie.org.uk/

The resin.io team has made something like this called resin-wifi-connect[1]. It doesn't appear to be as simple as it could be, but it's prior art if you plan to make something more generalized.

[1] https://github.com/resin-io/resin-wifi-connect

The RaspAP web UI does not support this, yet.

https://github.com/billz/raspap-webgui/issues/21

That's as fantastic looking application! If I can find some time, maybe I'll consider helping out.

Very nice work! Just curious what the range is like (client and AP) and if you have noticed any performance decrease vs your normal internet connection.

Unfortunately, the antenna on the RPi is not great, due to it being a PCB-etched pattern antenna.

For client, the range seems really good, thought not nearly as good as something like a cell phone, probably by about half.

For AP mode, the uplink speeds from the device connected to the RPi seems to be almost completely uninhibited, while downlink is pretty bad. This is where the poor antenna comes into play, since the RPi can't broadcast its SSID very strongly, and really only works well within LOS of the device. From another room, download rates drop pretty low, to sub-5Mb.

It may not work very well for transmitting video or something, but it's certainly good enough for low-bandwidth applications.

does this behave sanely if the pi-zero is taken out of range of the AP it's connected to? Are the connections between the pi-zero and its' clients preserved in that case?

I'm just now finding this when i'm about to hit the hay -- so I lack the cognition to go through it -- but i'd like something like this for a project of mine that involves a pi-zero-w that needs to maintain a connection with my cellphone while on the go -- and dump data when within range of a known AP.

So I've tested it at home, where I have 2 different APs on 2 different channels (11 and 6, if that's of any consequence). I purposely rebooted the APs the RPi was using for internet access and it seamlessly switched over to the other AP without killing my laptop's connection to its own AP. I then rebooted the AP it was connected to after the first one had come back up, and it switched back again.

While this seems to behave sanely, you may run into issues where your device will drop session with the RPi AP due to "no internet connection". Assuming you're running Android, your device may ask if you want to remain connected to that AP, or it might just disconnect due to lack of internet. That's entirely device-dependent, but there's nothing inherently making this not work based on my instructions. It just might take some extra work on the device-side to make sure it doesn't try to drop the connection.

I am curious about the existing issue when running these two modes simultaneously. Is this related to the network chipset that makes it harder vs a common PC card?

Are you referring to the issues I had getting it working prior to my workaround script?

I would love to know as well. I mentioned it somewhere, but during boot, there are a few cryptic Broadcom driver errors which a Google search turned up little to know info on. It's hard to say, but it seems like something in the system has to stabilize before everything works.

This is fantastic! Thank you for sharing. I was going to start looking into this for IoT applications myself.

I need to have a fail-safe where one device will usually be connected to WiFi and other devices may not for a myriad of reasons.

Thanks! Hopefully it works for you. I've got it going on 2 RPi Zero W boards so far, and it seems pretty stable. I actually wrote most of that post last night while passing all my laptop traffic through the RPi with no issues for over 3 hours.

Thanks for the article this is very useful will try later on with Raspberry Pi 3 and the Raspberry Zero Zero W.

Thanks! Hope it works out for you. If so, I'll update the article to indicate it applies to RPi 3 as well (I don't have one to test with myself.)

This is fantastic and well documented.

Appreciate it!

Reply on news.ycombinator.com