DCHP on Ethernet Interface and WiFi Access Point

Product support balenaOS
,
1

I’m working on a product that needs to connect to IP cameras and needs to provide them an IP address via DCHP. At the same time I need to be able to access our web server via WiFi in access point mode.

For the WiFi part I think WiFi connect will be able to do this but I’m not sure.

As for the DCHP part I’m not sure where to begin.

Thanks,

2

Hello @WestCoastDaz ,

Could you explain a bit more how you’re trying to connect the device? WiFiConnect allows the balena device to connect to a WiFi network of your choosing. The device would connect as any other device would, so if DHCP is enabled on that network, the device will get an IP assigned via DHCP.

Cheers,
Nico.

4

@ntzovanis

I need to connect to IP cameras via Ethernet and have our device which is based on an RPI 4B+ provide the cameras with IP addresses using DHCP.

I then want to be able to serve our web app up on the WiFi interface in the following 2 ways:

  1. When there is no wireless network available, our user needs to be able to connect to the our RPi’s SSID and then be able interact with the web app.
  2. When a wireless network is available, connect the RPi to that network and then interact with the web app.

Please let me know if you need more details.

Thanks,

7

Hey @westcoastdaz, why the need for DHCP? Could mDNS or zeroconf work instead? You could potentially run a DHCP server in a container in host networking mode, and only bind the server to the eth0 interface.

The Wifi Connect project will broadcast an SSID when the existing known Wifi network is not found. It will present a captive portal and allow you to choose a new SSID to connect to. I think this solves for case 2 above.

For case 1, I think your web app would conflict with the Wifi Connect app since they both run on port 80 when the Wifi is disconnected. Perhaps if you accessed your web app via another port they could both run in parallel?

  1. connect to RPi’s SSID and access web app on port 8080
  2. optionally connect to Wifi Connect on port 80 and choose a local AP SSID to use going forward

Does this cover your scenario? I’m only filling in the gaps because in case 2 you suggested that the Pi would connect to a local Wifi network but didn’t indicate how it would know which one to connect to or which credentials to use. This is what the captive portal page of Wifi Connect will solve.

I only wonder if the captive portal of Wifi Connect will prevent accessing your web app on the alternate ports. I don’t think so but something you could test for sure!

13

@klutchell

I’m not super familiar with mDNS and Zeroconf as this type of networking is outside of my previous experience with small self contained embedded systems.

I think it maybe best to back up and explain the use case instead of me trying to come up with a solution :slight_smile: Note: Our hub is based on RPi 4B+ and eventually the CM4.

We have a the following scenarios to cover:

  1. Internet is not available and the customer will connect IP camera(s) to an Ethernet backbone via a switch and connect the switch our RPi hub. The customer then needs to be able to interact with our hub via WiFi using a browser.

  2. Internet is not available and the customer will connect IP camera(s) to the RPi WiFi. The customer then needs to be able to interact with our RPi hub via WiFi using a browser.

  3. Internet is available via WiFi through a router. The customer will connect IP camera(s) via Ethernet with a via switch. The customer then needs to be able to interact with our hub via WiFi using a browser.

  4. Internet is available via Ethernet through a router. The customer will connect IP camera(s) via Ethernet with a via switch. The customer then needs to be able to interact with our hub via WiFi using a browser.

Thoughts,

15

Hey @westcoastdaz, thanks for laying out your scenarios in detail! It sounds like a cool project you have planned!

My question now is regarding scenario 3:

Internet is available via WiFi through a router. The customer will connect IP camera(s) via Ethernet with a via switch. The customer then needs to be able to interact with our hub via WiFi using a browser.

If Internet is available via WiFi through a router, how will the RPi know to connect to that SSID with credentials?
This is the purpose of the captive portal in the Wifi-Connect block, it will serve a captive portal via RPi WiFi AP and when connecting to that portal with a browser you can choose which local WiFi router AP for the RPi to connect to. Then the RPi will disable the onboard AP and connect to the router instead. This captive portal mode is enabled automatically when there is no existing Internet connection available.

This could work well for your scenario 3, but there may be an issue:

  • When Wifi-Connect is running in captive portal mode via RPi AP, port 80 is required and your web services will not be available. This unfortunately breaks scenario 2.
  • If you don’t use the Wifi-Connect block to avoid conflicts, you need some other method to tell the RPi which local WiFi router SSID/password to connect to while it is offline.

There may be a workaround though, what if you attached a USB WiFi adapter in addition to the onboard WiFi? This way you could create a NetworkManager connection profile to have one WiFi device always in AP listening mode, and the other always trying to connect to local WiFi routers. This avoid having to switch AP modes but obviously requires extra hardware.

Will these devices be moving around or will they be fixed on site once installed? Perhaps the local WiFi router SSID and credentials could be configured ahead of time?

18

@klutchell What if we removed scenario 2 for now. Having an additional WiFi interface isn’t ideal and I would like to avoid it for now.

Thanks,
Darren

21

I don’t want to start removing scenarios quite yet if we don’t have to.

  • Can we clarify for scenario 3 how you would like the users to connect the device to the local WiFi router? Is the captive portal of Wifi-Connect what you had in mind or will these be provisioned on site once and can have Wifi credentials added one time via the API or SDK or during provisioning?

  • Do we expect the device to dynamically change scenarios? For example will the RPi be moved from a site with a WiFi router to a location without WiFi and be required to figure it out and start it’s own AP for scenario 1 or 2? Knowing whether the device will be in a fixed scenario or may switch between them could affect our implementation.

  • How will we know whether to run DHCP on one of the interfaces? Is it expected that the RPi will determine whether another DHCP server exists and start one if required? This is possible but includes inherent risk when connecting it to existing networks.

I’d also like to break down the 4 scenarios into core network interface requirements:

  1. RPi DHCP server on Ethernet, RPi Wifi in AP mode
  2. RPi DHCP server on WiFi, RPi Wifi in AP mode
  3. No DHCP server to avoid router conflicts, RPi Wifi in client mode
  4. No DHCP server to avoid router conflicts, RPi Wifi in client mode or unused

So based on the above it’s going to make a big difference if the scenarios are static or not. Turning the DHCP server on/off on different interfaces, and automatically switching between AP and client mode are the main complexities here, but not unsolvable.

It may be easier if some of the above features were exposed as configuration options via environment variables in your app.

  • For example, DHCP_INTERFACE= could be unset, eth0, or wlan0 and can be set via the balenaCloud Dashboard (assuming the device is connected to Internet at some point).
  • Similarly, AP_SSID= could be unset, or true if you want to start the RPi WiFi AP with a specific SSID.

Making these modes configurable is not nearly as automatic and requires device access at some point to set the env vars, but it would simplify your implementation during initial development and additional features could be added later?

23

@klutchell

Some further background, our device (hub) will be installed in some cases where customers have no internet. In other cases they may have internet (WiFi most likely) at their location and then head out into an area that is doesn’t have internet. Think of WiFi and home and then leaving with the device to an area with no WiFi. In either case the customer needs to be able to access the client running on our hub via WiFi.

Here are the answers to your questions:

  1. Yes, I assumed that users would set up connection with the captive portal.
  2. Yes, as I discussed above. A WiFi router may be present initially and then not for some period of time and then present again.
  3. Ideally yes, but I’m open to options/ideas being new to these types of devices.

Does this help further the conversation?

24

Thanks for taking the time to provide the additional context, every little bit helps! I apologize if I’m not always able to reply immediately!

Wifi-Connect definitely solves your captive portal scenarios. If the device moves to a new location with new Wifi, or is disconnected from Wifi for some period of time, Wifi-Connect will enable the captive portal until a user connects directly and chooses a local network for connections. My main question here that I can’t answer without testing, is whether that captive portal prevents accessing services on other ports. For example, it might be ideal to have the captive portal listening on port 80 for Wifi setup, but also have your web services listening on port 8080 to use the device without a local Wifi router. I suspect it would be possible, but I haven’t tried it myself.

DHCP for the IP cameras might not be required as by default many devices without a DHCP server will use zeroconf. It would be nice to avoid running a DHCP server as it will cause real issues if connected to an existing network with a DHCP server.

I think the real question is how are the cameras discovered & provisioned in your app? Does the user need to know the IP that is assigned to the camera? Is that to be displayed via your web app in some way? Or are the cameras discovered automatically via some kind of multicast protocol? Of course this is less of an issue when using an existing network, but if the cameras are wired to the Ethernet port (or connected to the Pi Wifi) this will matter.

25

@klutchell

Thank you for taking the time to work through this with me.

For WiFi-connect, would I be able to have the captive portal on another port besides 80? I ask because it would be better if users could connect to our client at port 80 if they don’t have local WiFi or if they have local WiFi.

The cameras we will be using do seem to support Bonjour/Zeroconf. Ideally we don’t want the user to have to know anything about the camera IP at all.

26

For WiFi-connect, would I be able to have the captive portal on another port besides 80

It looks like the port can be customized by setting PORTAL_LISTENING_PORT.

Ideally we don’t want the user to have to know anything about the camera IP at all.

If the users don’t know anything about the cameras, how does your application discover and provision them? Whether they have DHCP or zeroconf or static addresses, your app must have some way to “find” them? Maybe you’ve already solved this problem and it’s not really something balenaOS would be able to help with anyway :smiley:

28

Hi westcoastdaz,

Did klutchell’s response answer your question or are there still open parts to the question?

29

Hi @rosswesleyporter,

Unfortunately I’m still lost as to how I can make this work.