How would you implement config with a browser?

[peter-h]

The old way was that the product got shipped with a bit of paper telling you to go to 192.168.1.1 (or 1.0 etc). This means you cannot use a normally configured laptop, configured for DHCP. You have to go Control Panel / Networks / Adapter Settings / TCP/IP v4 / and set the IP to the same subnet e.g. 192.168.1.10.

A better way is for the product to have a DHCP server. Then the laptop will just work. But you don't want a DHCP server running on something connected to a factory or office LAN because it will end up serving DHCPs to random devices when freshly connected, and possibly other problems. So such a mode would need a button held down at startup, or some such.

Is there another way which would work with a laptop without needing to reconfigure it? AIUI, ethernet devices fall back to some "don't have an IP" IP of 169.254.*.* Does this actually work? The chances are that both your product and the laptop will end up on the same one.

[woofy]

I would let the device grab its IP from the network DHCP server. Shouldn't cause problems, the server will expire the IP anyway if its moved away. You can then configure it to the subnet of choice.
Don't forget a factory reset, or your customers WILL lose it at some point.

[retiredfeline]

Let the device get a DHCP assigned address and also set a distinctive hostname in the DHCP request. Then allow a laptop on the same subnet to connect.

Nali reminded me that some equipment displayed the IP address obtained on the front panel, the HP Laserjet 4s for example.

[nali]

The really old way to do it was to use ARP. Manually add an arp entry with <ip> & <mac> then ping that address. The network card would then see the incoming packets then pick out the IP address and start using it.

Zeroconf works but you'll still need a naming service unless you're displaying the IP adress on a LCD or something. We had a similiar requirement at my last company and they ended up using Apple's Bonjour. It wasn't me that did the s/w so I can't remember the reasoning but was probably the easiest "just works" option for Linux.

[peter-h]

I agree re using some DHCP server on the LAN instead, and yes the board does have a clear hostname, but you now have to dig around in the router diagnostics to find the assigned DHCP address, which is a right PITA. There is no LCD displaying the IP.

In this case, is there some discovery mechanism, other than starting at the bottom of the subnet (what is the easy way to discover the subnet?) and polling every address up from there?

I think lots of people have been up this road before, starting from when the RJ45 was invented and most decided to just fix it at 192.168.1.1 or some such, and then the laptop owner has the hassle of reconfiguring the laptop.

There is actually a USB-accessible filesystem with a config.ini file and in there is an option to specify the IP allocated if there is no DHCP. So maybe that is the easiest route to document.

[sleemanj]

mDNS with a unique hostname, but I think Windows is a bit behind the times there still, not sure.

If your device expects to have internet access you could have it phone home with it's local dhcp-given ip address and it's serial, then  the user hits yoursite.com/serial and it redirects them to the local ip.

Of course if your device has some sort of output device, even if it's a blinking led, you could give the dhcp-given ip address that way.

[sleemanj]

NB: Maybe a unique (serial #) hostname response for both mDNS (Linux, Mac) and LLMNR (Windows) might be best, if your device is capable.

https://en.m.wikipedia.org/wiki/Link-Local_Multicast_Name_Resolution
https://en.m.wikipedia.org/wiki/Multicast_DNS

[sleemanj]

And add NetBIOS as well for older Windows versions.

https://harizanov.com/2015/10/hostname/

[peter-h]

I am most concerned about the scenario where you connect a laptop directly to this box, so there is no 3rd party DHCP server available.

[nali]

Our requirement was that boxes would either be connected to the office LAN for testing / configuration in which case they would pick up an IP by DHCP, or direct one-to-one to a field engineer's laptop via Ethernet cable. In both cases the URL was the devices hostname.

We didn't want the field guys to be pissing about with changing IP addresses on their laptops when conecting to these units so we used dhcpclient to request an IP address, then zeroconf if it timed out. In normal operation Ethernet wouldn't be used as connectivity was via a cellular modem.

The only downside really was the extra wait for the dhcpclient timeout.

[peter-h]

That sounds like you implemented a DHCP server in your box.

The issue with that, as I posted further back, is that you don't want that to always be running.

Can anyone recommend a really simple DHCP client lib for a ST Cube IDE / ST 32F4 project?

I completely agree with your view on messing about with laptop config to make a 1-to-1 connection work.

[nali]

That sounds like you implemented a DHCP server in your box.

No we weren't, that's the last thing I wanted! One of our s/w devs did this on his laptop for a demo "because it was easy" (his work motto) then forgot about it and plugged in the the office LAN next day. Took us a little while to work out why some of us couldn't access servers etc (depending on which dhcp server they got their IP from)

If the dhcp client failed then zerconf provides a 169.254.*.* address.

[peter-h]

OK I think you must be referring to this

https://docs.microsoft.com/en-us/windows-server/troubleshoot/how-to-use-automatic-tcpip-addressing-without-a-dh

This works by the box allocating itself a fixed ip from the range 169.254.*.* AIUI, when Windows does this it allocates itself a random address, one of 64k possible addresses. So if you wait for your box to time out and allocate something random say 169.254.123.124 and wait for the laptop to time out and allocate say 169.254.211.87, and with the subnet mask being the whole 64k, it should work.

You still need some way to tell the laptop user which IP to go to, however. There are various broadcast methods I think, but you could just fix it and put it on a label. In the one I am working on, there is a USB accessible filesystem and in there one could put a file called ip.txt and put the IP in there.

If one assumes the laptop is Windows then one could always use 169.254.1.1 but I don't know what Macbooks do.

[RoGeorge]

IP of 169.254.*.* Does this actually work?

Yes, it works, and used often, for example my Western Digital NAS uses that and needs no configuration and no DHCP server to work.  https://en.wikipedia.org/wiki/Link-local_address

In case the device still must have yet another fix IP (because of some other constraints of the customer's network), a network adapter can have more than one IP at the same time, assign as many IP addresses as needed.  Only the MAC address stays the same, but it can have many IP, it can even have many IPv6 and many IPv4 simultaneous, doesn't matter.

Ways to reach a network device without configuration:
https://en.wikipedia.org/wiki/Zero-configuration_networking

[PlainName]

Could you use a multicast address (224.0.0.x) for initial setup (setting of an appropriate LAN address)?

https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

[peter-h]

On a quick look it seems the same idea as 169.254.*.* except they seem to have preassigned some addresses to specific manufacturers.

[PlainName]

I think the difference is that with 169 you wait for a connection to fail and it falls back to that, and you can't do it when already connected to a proper network. With 224 you can do it regardless of what you're connected to - it's a kind of broadcast address on top of your existing connection (if any).

[peter-h]

OK; yes. 169... takes quite a long time to time out and fall back. Typically a minute or two for the "have no DHCP" realisation to happen, and long enough to confuse a customer.

What 224... IP would one choose, for an industrial product which does not have a big profile?

[PlainName]

Ah, you might want to ask me in a couple of months - this is the approach I'll be taking for a project, but I've not got around to the details yet.

[SiliconWizard]

The old way was that the product got shipped with a bit of paper telling you to go to 192.168.1.1 (or 1.0 etc). This means you cannot use a normally configured laptop, configured for DHCP. You have to go Control Panel / Networks / Adapter Settings / TCP/IP v4 / and set the IP to the same subnet e.g. 192.168.1.10.

Yes. But I find this simple and less hassle overall than other solutions.

(Now if using a decent router, this is usually not much of a problem, because the router can easily bridge between subnets. But yes, that would assume a certain setup...)

I'll keep an eye on this thread though, because this is something I'm also interested in. And I agree with avoiding DHCP here as well for security reasons.

[David Hess]

The alternative to a fixed IP address that I have seen is for the device to use a DHCP client to grab an IP, and then monitor UDP broadcasts so that it can respond to a request to identify itself from the configuration program, which then launches the browser with the correct IP to connect.

[nightfire]

As a sysadmin that has also worked with lots of devices in the rather embedded environment I personally prefer the following approach:

- Try to get DHCP in factory default setting
- If possible, report some hostname to the DHCP which is unique (not only like "Devicename", but something like "Devicename-MACaddress"
- After timeout from DHCP, set whether APIPA or static IP
- Put static IP in a private IP range that is not commonly used (something like 192.168.0.x would be not nice because its usage is very common)
- depending on the intended environment, implement/accept the old way of setting the IP via ARP as described above
- Put a sticker on the device where MAC address and the fallback IP mechanism are explained for the next guy to deal with that after 10 years, where the manual will not exist anymore... (This also allows the admin to enter the MAC into a management system or DHCP server to hand out semi-static MAC/IP mappings or do some magic firewall stuff)