Raspberry Pi3 as AP and WiFi Client (Station)

hotspot
raspberrypi3
network
wifi

#1

Note: I’m not sure this belongs in this category, but based on my overview of the other categores I think this makes the most sense. Feel free to redirect.

Overview

I’m wondering if it’s possible to have a WiFi network USB adapter simultaneously host an access point (hotspot) and connect to another WiFi network for internet connection. Details of the specific architecture in which this must work is described below in “Use Case”.

Use Case

I often see the “use case” question asked so I figured I would preemptively answer it. I have a raspberry pi 3 (R Pi3) inside a big metallic box. This box will need to use a WiFi network USB adapter with an antenna that exists outside of the metallic enclosure to get any viable network connection capabilities.

The “device” (raspberry pi + metallic box + some other things) will need to serve a hotspot that users can connect to. Once connected to the hotspot, we will have some sort of iptables configuration that will route users to a local web server running on the Pi (figuring out how to set these iptable rules for each device automatically is still being determined - can we do this on a docker container and have it apply to the host OS?). This web server will allow users to manually configure networks via the DBUS API to Network Manager (very similar to what the WiFi Connect project does).

As of now, users will configure two networks:

  • 1x ethernet connection
  • 1x WiFi connection

One of the two networks will need to connect to the internet. The other will be to connect to some internal network not worried about the internet.

This hotspot needs to stay active at all times so that anytime a user wants to change network configuration details, they can just connect to the hotspot and hit the local web server that facilitates this configuration. We need to support the use case where we have a hotspot always running on the wlan* adapter as well as possibly using that same adapter to connect to some other WiFi network with
or without internet access.

At this point, I’m mainly wondering if it’s possible given the specifics of the architecture:

  • Potentially hosting the AP and WiFi network on one adapter
  • While using Resin OS with a local web server that hits an API that implements the DBUS API for Network Manager to create / manage all these connections
  • These things have to be configured “on the fly” / “in the field”… i.e. we can’t manually do things to each device as we roll them out
    • unless we somehow edit the Resin OS iso so that it has some default network stuff baked in beneath the Docker layer
    • I’m not sure how or if we could even do something like this.

I think that covers all the details.

Research

I’ve done some research into this:

The problem with the research thus far is:

  • I’m getting mixed responses in terms of what’s possible and what is not possible. People describe different outcomes based on their own experience levels / implementations
    • The mixed bag of respones and the various means in which people are doing this made me want to hit this forum to make sure it’s possible given all the particulars described above.
  • I’m seeing tutorials that go about implementing these things with different mechanisms other than the DBUS Network Manager API
    • I.e. hostapd, manually editing network configuration files, etc…

It may be possible that we can configure the hotspot via some other mechanism that is not the DBUS Network Manager API, but with regards to configuring the other two networks, I feel we have to use Network Manager API to keep it dynamic / user configurable.

I’ve also read the Resin Documentation pages for networking and some other misc. articles in terms of just understanding the architecture, etc…

Background

I have limited experience dealing with Network “stuff” and working directly on the RPi3. So far, I’ve managed to create a boot script in Go that creates a hotspot connection (if one does not already exist) and activates the connection (if not already activated). This works as expected and is running on a RPi3 with Resin OS.

I’ve used the godbus binding and the Network Manager API as described above. Here are links:

The process of integrating with the API, from the perspective of someone who never had to work with DBUS before and is used to using RESTful APIs, has been painful to say the least :laughing:

The large amount of domain specific knowledge with regards to networks coupled with the “rough edges” of the DBUS API has proven to be a challenge. Combine this with the specifics of the architecture and use cases we are shooting for and you should understand why I’m proactively reaching out to see if this is possible / gain insight before we go too deep.

System

Resin OS 2.7.8+rev1 (dev)




Any insight is appreciated !
Thanks !!


#2

@nathan I am interested in this as well, since we are also planning on making WiFi Connect being able to run in both AP and client mode whenever possible. I have never tried doing that, but I am looking forward to trying this.

I will start looking into this tomorrow and post some updates here.

You are correct that using the NetworkManager D-Bus API is a bit hard. Quite often objects will change their paths, e.g. a connection profile being activated will change its path multiple times, and this makes hard operating through the D-Bus API. We have to guard against those cases in WiFi Connect, so it is indeed tricky.


#3

I managed to dedicate some time today and did some initial research on the topic.

The solutions I could find all disable NetworkManager for the particular wireless device and delegate AP management to hostapd. The reason probably is that NetworkManager supports AP mode much more recently.

My next task is to get a wireless device running in STA+AP mode under NetworkManager with a recent kernel and NM versions. I will report how that goes tomorrow.


#4

I spend some more hours on this in the last couple of days, but I could not get NetworkManager to support STA+AP out of the box. Tried with a few different WiFi devices without success. Next I am going to try to compare the differences with the standard hostapd approach on a driver level, but it will take a bit more time. I will report back as I make progress.


#5

Sounds good! Thanks for keeping me updated.


#6

@nathan So currently NetworkManager cannot create an AP with the device being in STA+AP mode. It has a fixed flow for how to handle newly added interfaces. To enter STA+AP mode a virtual interface of type __ap has to be added like this: iw dev wlan0 interface add ap0 type __ap. After the interface is added NetworkManager forces the interface to enter station/client mode, which does not work, since the interface is created with AP type.

That said, the usual hostapd approach can still be used with Resin. Probably the easiest way is to start with the https://github.com/oblique/create_ap script. As can be seen from its source that it tells NetworkManager to not manage the virtual AP interface, so that hostpad can be used instead. The station/client interface can still be managed by NetworkManager, and create_ap takes care of a lot of details like bridging and DNS.

Resin applications are run in Balena/Docker containers and the guidelines from our networking documentation has to be followed. Specifically DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket has to be set.

The create_ap script uses nmcli, which is part of NetworkManager. If installed in the application container, systemctl mask NetworkManager.service has to be added in the application Dockerfile.template, so that the NetworkManager instance installed in the container does not interfere with the one running in the host OS. nmcli uses the same D-Bus API internally, so communicating directly with NetworkManager is also possible.

Please let me know if you have any questions.


#7

@majorz Thanks for keeping me informed. I think for now, our approach will be to just toss another network interface into our system and put one connection per device. This is inefficient, but we don’t have the time / resources to dive into this alternate path at this time. Down the road I’m sure we’ll come back to this issue and try to optimize our solution.


#8

@nathan I forgot to mention that when the device is in STA+AP mode it shares the same channel for both STA and AP, so there will be performance penalty. And since the mode is also not that popular there could be driver or firmware instabilities depending on the device type.


#9

Interesting. That makes it less likely for us to worry about “optimizing” our current multi-antenna solution. Thanks for keeping me informed. Hopefully this post can help others now that we have some definitive investigation completed.