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.
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”.
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.
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…
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
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.
Resin OS 2.7.8+rev1 (dev)
Any insight is appreciated !