Configure network of an embedded device

I had the same issue some 15 years ago and I think I posted a similar question here. Back then the "IoT" phrase was not invented, so I am not sure if our netmca belongs... :) (

Anyway, the world has not changed much since, same issue same possible remedies. My initial one - which is still active on our devices - was to post the IP address on a specific web address under our domain once the device boots (it does so via ftp to a dedicated account we have for that); the address contains the device serial number which makes it specific, the user can locate it using a browser.

Nobody uses it. They all call before they even try to use that.

So we started shipping a router with each device; the router is set to give fixed IP addresses to each of the devices we ship to that customer (sometimes they are more than one). This has worked fine. Even if they try to stray from the router we have shipped they can verify things work with it and dig further themselves, look for help locally etc.

====================================================== Dimiter Popoff, TGI

There are several ways to do this.

If there's ethernet, it's not too complicated. When the device boots, make a DHCP request and provide your hostname as the device name plus a serial number. For example, supposing your product is called 'HomeBox' and the device's serial number (MAC address?) is 12:34:56:78:90:ab. Then make a DHCP request and specify your hostname as 'homebox90ab'. Use enough digits to minimise the changes of name collisions. A user can either look on the router for the 'homebox' device, or you print instructions telling the user to go to http://homebox90ab/ on a label. At that site they can configure the network settings if they want a fixed IP or whatever.

For wifi, it's harder because you need to preconfigure wifi settings before the device appears on the network.

One way is to include Bluetooth functionality, which is included on many wifi chipsets. An app is told the wifi config by the user, connects to the Bluetooth and sends the details that way. The device then connects to the wifi and may shut down the Bluetooth interface. To reconnect, a factory reset via a pinhole reset button will clear the wifi settings and re-enable Bluetooth.

If you don't have Bluetooth or a mobile app, another option is to power up in factory mode offering an access point with a default SSID, say 'homebox90ab', and no password. The user connects to the SSID and goes to a web page as the ethernet example. There they configure their wifi credentials and, once saved, the device reboots and tries to connect to that wifi network. If it fails, the user must do the pinhole reset and try again.

On an enterprise network, maybe expecting any kind of DHCP is too much. In which case the initial setup could be its own DHCP server: you plug in a laptop which gets an IP address handed out by the device, and go to http://192.168.1.1/ (or http://homebox90ab/) which is the device. From there you configure its IP address and other settings. Next time it reboots it uses the new settings. If it is no longer accessible, there's the pinhole reset procedure.

While it's possible for the device to answer at a specific hardcoded IP, it's a bit awkward from the user perspective - you have to configure your laptop with a particular static IP, netmask and so on. Many OSes make that annoying, and you can't easily switch to another network without going in and deleting all the settings (eg you want to search for help while configuring the device).

On IPv6, a lot of these problems go away if SLAAC is enabled: you know your network prefix, you know what the device's MAC address, so it's trivial to work out the device's static IP, or at least one IP that it'll respond to if you try to connect to it.

Theo

This isn't an option for typical users without technical knowledge.

Interesting. That URL has a simple hostname that must be resolved by the router. Is it guaranteed that the router is able to resolve the host in URL in the device with the same hostname? What happens if more than one device on the LAN make DHCP requests with the same hostname?

Are you thinking to have a DHCP server running *on* the embedded device? How does the device know if send a DHCP request (to receive an IP address from an external DHCP server) or launch a DHCP server? Maybe it can try a DHCP request a revert back to internal DHCP server if that fails.

We can say that in professional environment (enterprise network) it's simple to find experts with sufficient knowledge to set network configuration of a device.

It's very strange there isn't any protocol at MAC level that manages IP configuration. MAC addresses are unique in the LAN and they could be discovered or printed on a label. With this protocol, you could connect and power up all the devices and use a simple software to manage network IP configurations.

It's the way most consumer routers work, there's no guarantees that somebody doesn't have a different setup though. It is possible to use multicast DNS (aka mDNS aka Bonjour) in which case http://homebox90ab.local/ will be resolvable (since any .local address is resolved by sending out multicasts asking who has it, rather than asking a central DHCP server).

That's why you include a probably-unique hostname with a serial number. If they still clash, I imagine the DHCP server hands out a different address for device #2 and refuses to assign it a hostname already allocated.

Yes.

The device out of the box is a DHCP server. Once somebody logs into it and configures it, it reboots to become a DHCP client. To revert back to being a DHCP server again somebody has to hold down the factory reset button. (or equivalent physical signal, eg smart lightbulbs you have to turn them on and off several times in a predefined sequence of flashes)

That applies to pretty much any device you want local-only access: somebody has to configure it, whether via a web interface or a mobile app. It can't just work by being plugged in, unless it talks to the cloud to pick up its configuration.

If the admins have decided the devices on their network all need static configuration, they will need to use the device's config interface to set that up.

There is, it's called DHCP. Or IPv6 SLAAC, as below. As Don says, once you've done DHCP everything is configured, but you either need to have a UI to either the DHCP server or the device if you want to find out what happened. If it is specifically DNS you're interested in, there's mDNS, which also does service discovery - connect a printer to the network and it'll become available to devices like phones without any config; this is because the printer responds to mDNS queries from phones, laptops, etc saying what services it offers and the devices configure themselves automatically (the printer also says it accepts certain standard formats like raster or PDF so no need for drivers).

Theo

This is another point added to my approach "sell them a router you have set up". In fact I had exactly this at some point, a customer for our TLD readers decided to stray from the router we had delivered with the units they had purchased. The people who had to do the measurements (sometimes 1000+ a day) had no access to the corporate router so someone there had set some fixed IP addresses for our devices on their network, not behind the router we supplied. Things worked - until they did not. They started to call "your device won't boot at times". "Does the LED always indicate the unit did get an IP address?" "Yes it does." Well does it always boot behind the router we supplied? "Hmm let us test... Yes it does"

If a design can afford a cheap router just include one and save yourself all the headache (that to the OP). Other than that, you are stuck to my other solution, which works - just technically, I saw no evidence anyone used it ever. People either can do what it takes with their router/network or they use the router we supply.

In our case, this is easy. The customer gets a sheet of paper titled "quick start"; some of them write the IP addresses on stickers etc. Mind you, this is a solution to our operation where an MCA is not just a cheap gizmo you won't remember what/where it was after two days.

In this case it fits their needs perfectly. The router we supplied lives behind their router *and* the net behind our router is meant solely for what we have supplied. They can access the devices from their network, port forwarding does what it takes. Our devices can access the internet - if they want them to - so they can get live online support etc.

So how do I instruct the user where to find the IP address they have to enter after they start realVNC? Will the IP stay static so they can get just as many clickable options after they have entered the IP address the first time?

Your case is completely different, I don't even want to think what you would have at your plate if you had to predefine the entire network of your user. Me, I just set a few fixed IP addresses on the router, some ports get forwarded (they want sometimes to access the spectra via http) and that's it.

Including a display they can read the IP address on would have been a good idea which I may apply to our next version, not sure why I did not do it some 15 years ago.

====================================================== Dimiter Popoff, TGI

Well they get a router which is meant to be used only with the devices we supply; we set it with fixed IP addresses for each MAC address they get for their convenience, so far nobody has complained. Their laptops/phones whatever they use connect through a number of ways - wifi, Ethernet behind the router we give them, Ethernet in front of this router with port forwarding would be a next option (we don't supply this by default). All devices - our netMCA-s and their terminal units - go through DHCP, it is just that we have set the router to give some fixed addresses to certain MACs. Customers do have access to the router so if they know what they are doing they can change what they need. Can't think of a more flexible configuration nowadays; anything, any additional protocol you insert will only add problems without simplifying anything.

So what's wrong with them using their IP addresses as they want them and accessing our units through the router we have supplied via the IP address it has received via DHCP from their network. Many do exactly that, let realVNC remember the IP address/port numbers and just click on the one they want to talk to. We don't sell them a general purpose router so they build a home network, we sell them something to make their life easier with our products, perhaps just initially. That's all. There are *no* IP address conflicts which can possibly arise in this scenario.

What's wrong with DHCP telling the device which IP address it has to use, the ordinary way? How does bluetooth help here? (other than making things messier, perhaps way messier) Or do you mean our device has to tell their router which IP address to assign us via DHCP (what nonsense... I am sure you don't mean that).

====================================================== Dimiter Popoff, TGI

Exactly. Which is the purpose of the entire exercise. They get a router and some units, power everything up, look at the "quick start" paper, connect to the router and type in the IP address(es) to some laptop, often wifi connected to the router - we name its wifi usually "netMCA". You *cannot* simplify that, not in today's world.

By accessing the IP address the router we have supplied gets on their network to ports which have been forwarded to the IP sockets behind our router.You are familiar with port forwarding?

Not at all. The IP addresses on the net behind our router are fixed and unique. They can connect to that same subnet right away; if they want to access from their network they will have to set as many port forwarding pairs as there are devices on the network behind our router. In any case tuning their network to accommodate the one we have supplied is a second step. The first step is to install things and ensure they work - for which they don't need to even connect our router to their network. After that they know it is up to them, like once you have tested your new vacuum cleaner to work you don't call support if it needs a cable extender etc.

This sounds too generic to me, I don't understand how you will make a phone bluetooth simplify the DHCP protocol for a device you connect to a network. Then I don't think there are many phones with bluetooth and no wifi so what is stopping you to look at the router's DHCP list? You won't need another bluetooth device to pair with, software for the two to talk to each other etc., can't see any benefit out of this approach in the cases discussed so far.

Ok, but you can't set a static IP address through DHCP and you are forced to have an always on DHCP server on the LAN (maybe you don't want to have one for some reason).

If I wanted to have only static IP addresses on my LAN, I would be forced to change the IP configuration on each device, through proprietary mechanisms (display, web app, ...). And if you have 50 hosts (IPCams?), it is a waste of time.

Anyway I think Dahua (and maybe other IPCams manufacturers) doesn't use DHCP to auto-configure IPCams connected to its NVRs. IPCam usually starts by default with a unique static IP address (192.168.1.108).

If you have only one IPCam in the LAN, it's very simple for the user as pointing the browser to:

http://192.168.1.108. If you have multiple IPCams, connect them to modern NVRs from the same manufacturer and point the browser to the NVRs IP address. Through the web interface of the NVR, the user can see all the IPCams (even if they have the same IP address) and change their network configuration (DHCP or static IP) one-by-one or all together (assigning a range of IP address sequentially).

Even if you don't have NVR, you can use Dahua Config Tool software. It is able to discover and set network configuration of IPCams on the LAN[1]. How are they able to do this?

I suspect this isn't standard because someone said this works only if NVR and IPCams are from the same manufacturer. Even Config Tool software can discover IPCams only if they are Dahua.

I think this method is very simple for the user.

You plug your widget into your laptop directly, with a cable, or connect to its own wifi SSID. The network contains exactly two devices, the widget and your laptop (/desktop/phone/whatever). If you normally use that interface (ethernet or wifi) to connect to your LAN, you have explicitly unplugged so there is no connectivity to the LAN and no chance of things getting confused.

If you run both interfaces together (eg plug into the widget via ethernet, while having wifi running to the LAN) that will work as long as widget and routable LAN IP addresses don't overlap. This is safer with IPv6 since there's a much wider range of private addresses to choose from, so you pick a private range (from fd00::/8, ie 2^120 addresses) and chances are good it's not used by the LAN.

Offering a DHCP server likely requires administrator privileges, which the user may not have[*]. It will also mess up the LAN if they ever connect back to it while the DHCP server is running (since now there are two DHCPs on the LAN).

Theo

I agree with you, but IP standards allow to have a static address on the network adapter and don't force to have a DHCP server running on the LAN. In all these cases (just a few or many) you need to set the IP address one by one with whatever mechanism the device gives you.

It would be much more easier to have a standard protocol that would be able to discover and configure/change IP network configuration (even from/to DHCP) of a device on the LAN. It could use only MAC addresses that are usually printed on a label.

How to set the different names on each camera? You need to know the IP address of the camera installed in the kitchen by accessing the DHCP server status page, searching for the MAC address of the kitchen camera.

Again I agree with you. Anyway the approach of Dahua is valid in all the cases (90%?) where the network is 192.168.1.0/24 and .108 address is not used (the probability of a conflict is around 1/253=0.4%).

In the lucky scenario you run 192.168.1.0/24 and .108 is free, you can power up one camera at a time, access http://192.168.1.108 and set the final IP address or enable DHCP.

If you hit the "unlucky" scenario, you need to follow your long list of steps... except you have another standard tool, the new protocol I'm talking about.

We are saying the same thing. I agree with you. That approach works well in 90% of cases. For the rest, is a mess and the use of DHCP would have been simpler.

Just to say that NVRs have some internal magic that allows them to configure remotely IP addresses of connected IPCams, even if they have the same IP address. I'm wondering how this happens and why this approach can't be standard.

Of course, there could be many ways, what I'm asking here is why we don't have such a standard protocol.

DHCP is a protocol implemented in many softwares (for Linux, Windows, OSX, ...) and tools, but you don't care much about it. Of course, because it's a standard protocol, not proprietary, so there exist a multidue of implementation.

This could happen with the protocol used by Dahua Config Tool.

And any DHCP server worth its name will allow you to reserve a particular IP address for a particular MAC address. That gives you a centralized point of administration similar to DNS.

This will work even if DHCP is not available because the clients will continue to use their last assigned address. As long as there were no address conflicts when DHCP was operating, there still will be no conflicts when it isn't.