Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31998 > unrolled thread

Configure network of an embedded device

Back to article view | Back to comp.arch.embedded

Contents

  Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-05 10:37 +0200
    Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-05 13:43 +0300
      Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 11:03 -0700
    Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-06 21:56 +0100
      Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-07 09:54 +0200
        Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-07 19:40 +0100
          Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 13:19 -0700
          Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 13:30 -0700
            Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 00:14 +0300
              Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 14:31 -0700
                Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 14:34 -0700
                Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 00:53 +0300
                  Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 15:21 -0700
                    Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 02:05 +0300
                      Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 16:55 -0700
                        Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 04:26 +0300
                          Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 18:57 -0700
            Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-08 10:17 +0100
              Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 03:20 -0700
    Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 10:57 -0700
      Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-08 09:41 +0200
        Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 03:50 -0700
          Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-08 13:56 +0200
            Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 09:45 -0700
              Re: Configure network of an embedded device George Neuner <gneuner2@comcast.net> - 2023-09-08 16:50 -0400

Page 1 of 2  [1] 2  Next page →

#31998 — Configure network of an embedded device

Nowadays many Internet connected embedded devices are controlled by an 
external proprietary cloud service (for example Sonoff[1] or Shelly[2]). 
The installation in the final destination is very simple to the end user 
that ignores completely all the technical issues:

1. connect the device to the local Ethernet network (WiFi is slightly 
more complex)
2. pair his mobile app to the device (QR code or serial number)
3. start configuring and using

Most probably the device works with DHCP client enabled, hoping to find 
a DHCP server on the network and receive a suitable IP address to make 
outcoming connection to the Cloud server. This happens in 99.99% of 
cases and the user is super happy.

In other situations, if the gadget features a small/big display, the 
advanced user could enter a network configuration menu and set the 
desired configuration (DHCP or fixed IP address). This happens for 
desktop PCs or tablets or similar gadgets (even if the user keeps most 
of the time the DHCP default configuration).

I'm designian't beng a small embedded device that hasn't a display and c 
controlled by a cloud system. It will be controlled on the local network 
through a simple web browser pointed to the IP address of the gadget. 
Indeed, a web server runs in the device.

I'm thinking to start with a fixed IP address, for example 
192.168.1.123. In 90% of cases the IP address can be used immediately 
(written on a label on the gadget or in the quick start guide) and the 
user could access the web page pointing the web browser to 
192.168.1.123. In cases where the local network isn't 192.168.1.x, the 
user should use a PC configured temporarily with a compatible IP address 
(192.168.1.124), access the web page and change the network configuration.

The problem happens when the user wants to install several devices on 
the same network, for example 10 devices. Even if the network is 
compatible (192.168.1.x) with the default fixed IP address 
(192.168.1.123), he should connect one device at a time and change its 
configuration before connecting another device to avoid IP addresses 
conflicts.

So I'm wondering if there's a standard or quasi-standard way to manage 
network configuration of devices on the same LAN.

The situation isn't so uncommon. IPCams are network oriented devices 
that can be controller by a Cloud service from the manufacturer, but 
mainly from a web page. It usually happens that more than one IPCam are 
installed on the same LAN.

For example, Dahua IPCams usually start with the fixed IP address 
192.168.1.108. They have a software (Config Tool) that can be used[3] to 
manage network configuration of multiple IPCams, even if they are 
installed at the same time with the default IP address 192.168.1.108.

Is it a proprietary solution that uses only Ethernet frames (MAC 
addresses) and not IP packets? Is it a well known protocol that I don't 
know?



[1] https://sonoff.tech/
[2] https://www.shelly.com/en-gb
[3] https://www.youtube.com/watch?v=NIiI1BIHfms

[toc] | [next] | [standalone]

#31999

On 9/5/2023 11:37, pozz wrote:
> Nowadays many Internet connected embedded devices are controlled by an 
> external proprietary cloud service (for example Sonoff[1] or Shelly[2]). 
> The installation in the final destination is very simple to the end user 
> that ignores completely all the technical issues:
> 
> 1. connect the device to the local Ethernet network (WiFi is slightly 
> more complex)
> 2. pair his mobile app to the device (QR code or serial number)
> 3. start configuring and using
> 
> Most probably the device works with DHCP client enabled, hoping to find 
> a DHCP server on the network and receive a suitable IP address to make 
> outcoming connection to the Cloud server. This happens in 99.99% of 
> cases and the user is super happy.
> 
> In other situations, if the gadget features a small/big display, the 
> advanced user could enter a network configuration menu and set the 
> desired configuration (DHCP or fixed IP address). This happens for 
> desktop PCs or tablets or similar gadgets (even if the user keeps most 
> of the time the DHCP default configuration).
> 
> I'm designian't beng a small embedded device that hasn't a display and c 
> controlled by a cloud system. It will be controlled on the local network 
> through a simple web browser pointed to the IP address of the gadget. 
> Indeed, a web server runs in the device.
> 
> I'm thinking to start with a fixed IP address, for example 
> 192.168.1.123. In 90% of cases the IP address can be used immediately 
> (written on a label on the gadget or in the quick start guide) and the 
> user could access the web page pointing the web browser to 
> 192.168.1.123. In cases where the local network isn't 192.168.1.x, the 
> user should use a PC configured temporarily with a compatible IP address 
> (192.168.1.124), access the web page and change the network configuration.
> 
> The problem happens when the user wants to install several devices on 
> the same network, for example 10 devices. Even if the network is 
> compatible (192.168.1.x) with the default fixed IP address 
> (192.168.1.123), he should connect one device at a time and change its 
> configuration before connecting another device to avoid IP addresses 
> conflicts.
> 
> So I'm wondering if there's a standard or quasi-standard way to manage 
> network configuration of devices on the same LAN.
> 
> The situation isn't so uncommon. IPCams are network oriented devices 
> that can be controller by a Cloud service from the manufacturer, but 
> mainly from a web page. It usually happens that more than one IPCam are 
> installed on the same LAN.
> 
> For example, Dahua IPCams usually start with the fixed IP address 
> 192.168.1.108. They have a software (Config Tool) that can be used[3] to 
> manage network configuration of multiple IPCams, even if they are 
> installed at the same time with the default IP address 192.168.1.108.
> 
> Is it a proprietary solution that uses only Ethernet frames (MAC 
> addresses) and not IP packets? Is it a well known protocol that I don't 
> know?
> 
> 
> 
> [1] https://sonoff.tech/
> [2] https://www.shelly.com/en-gb
> [3] https://www.youtube.com/watch?v=NIiI1BIHfms


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... :) ( http://tgi-sci.com/tgi/nmca3.htm )

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             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#32003

On 9/5/2023 3:43 AM, Dimiter_Popoff wrote:
> 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... :) ( http://tgi-sci.com/tgi/nmca3.htm )
> 
> 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.

Essentially creating a (remote) UI to serve in place
of the "limited" UI on the instrument.  You rely on the
user to have something ELSE that can provide the interface
by leveraging other popular protocols.

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

As the device must then be routed, is there a risk of some
"outside agent" accessing the device?

> 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).

Can the user alter the "default" name to something friendlier?
Possibly an alias?

Presumably, the MAC (or serial number as that is likely friendlier)
is easily accessible on the device (and, the user is in proximity
to the device)?

> 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.

[toc] | [prev] | [next] | [standalone]

#32000

pozz <pozzugno@gmail.com> wrote:
> So I'm wondering if there's a standard or quasi-standard way to manage 
> network configuration of devices on the same LAN.
> 
> The situation isn't so uncommon. IPCams are network oriented devices 
> that can be controller by a Cloud service from the manufacturer, but 
> mainly from a web page. It usually happens that more than one IPCam are 
> installed on the same LAN.

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.

> For example, Dahua IPCams usually start with the fixed IP address 
> 192.168.1.108. They have a software (Config Tool) that can be used[3] to 
> manage network configuration of multiple IPCams, even if they are 
> installed at the same time with the default IP address 192.168.1.108.

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

[toc] | [prev] | [next] | [standalone]

#32001

Il 06/09/2023 22:56, Theo ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> So I'm wondering if there's a standard or quasi-standard way to manage
>> network configuration of devices on the same LAN.
>>
>> The situation isn't so uncommon. IPCams are network oriented devices
>> that can be controller by a Cloud service from the manufacturer, but
>> mainly from a web page. It usually happens that more than one IPCam are
>> installed on the same LAN.
> 
> 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, 

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


> or you print instructions telling the user
> to go to http://homebox90ab/ on a label.  

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?


> 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.
> 
>> For example, Dahua IPCams usually start with the fixed IP address
>> 192.168.1.108. They have a software (Config Tool) that can be used[3] to
>> manage network configuration of multiple IPCams, even if they are
>> installed at the same time with the default IP address 192.168.1.108.
> 
> 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.  

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.


> 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.

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.


> 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).

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.


> 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

[toc] | [prev] | [next] | [standalone]

#32004

pozz <pozzugno@gmail.com> wrote:
> Il 06/09/2023 22:56, Theo ha scritto:
> > pozz <pozzugno@gmail.com> wrote:
> >> So I'm wondering if there's a standard or quasi-standard way to manage
> >> network configuration of devices on the same LAN.
> >>
> >> The situation isn't so uncommon. IPCams are network oriented devices
> >> that can be controller by a Cloud service from the manufacturer, but
> >> mainly from a web page. It usually happens that more than one IPCam are
> >> installed on the same LAN.
> > 
> > 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, 
> 
> This isn't an option for typical users without technical knowledge.
> 
> 
> > or you print instructions telling the user
> > to go to http://homebox90ab/ on a label.  
> 
> 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? 

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).

> What happens if more than one 
> device on the LAN make DHCP requests with the same hostname?

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.

> > 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.  
> 
> Are you thinking to have a DHCP server running *on* the embedded device? 

Yes.

> 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.

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)

> > 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.
> 
> 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.

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.

> > 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).
> 
> 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.

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).

> > 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

[toc] | [prev] | [next] | [standalone]

#32005

On 9/7/2023 11:40 AM, Theo wrote:
>> 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.
> 
> 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.

For SOHO applications, one can likely gain access to the "clients list"
in the DHCP server.  But, that may not be the case in other scenarios
(e.g., enterprise).

It also ASSUMES you have a server running, locally (also common in SOHO).

I've seen applications that would listen for broadcasts from "their"
devices (recognized by OUI or content of the message packet) and
present lists of these devices to the user.  The user could then
contact the device directly (through the application) to query (or
modify) its configuration.

But, this (IMO) *raises* the bar for casual users.

You can also add some other "dedicated" point-to-point port on
the device that you use to talk to *it* (before it sits on the
wire).  E.g., Cisco APs, APC UPSs, etc. all have such a "console"
function.  But, again, you now expect the user to be more tech savvy.

A clever way of doing this for "one-off" units is to have a USB
interface and present to the host as a mass storage device with
an "autorun" that causes a *portable* app on the device to be invoked
so the software is part of the device instead of needing to be
"installed" on a phone, PC, etc.  The app then presents a configuration
interface for the user writing the configuration data back into
the device (before being disconnected).

[Perhaps a JS app could be more portable -- think Macs -- than
a binary]

The app could also give you a beachhead through which to install
updates in the device (if over-the-wire updates become a problem).

[I use an ethernet based version of this in my current design.
A "dedicated" port allows for secure configuration of "new" devices
prior to deployment.  It lets me install firmware, secrets,
configuration information, etc. -- as well as inventory the
devices encountered, to date]

> 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).

[toc] | [prev] | [next] | [standalone]

#32006

On 9/7/2023 11:40 AM, Theo wrote:
>> 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.
> 
> 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)

How do you address the case of your (GUI) client discovering some other
DHCP service running on the network?

If you could modify the *client* code, you could use something like
a different vendor magic to ensure only the server in the device
would be recognized.

You could flip this around; distribute an app that acts as a
special DHCP server.  Have the device only issue requests to
services offered by *that* server (even if another was
competing -- see above).

In addition to servicing DHCP requests, it could query any
*existing* DHCP service to obtain a lease FOR THE DEVICE
(acting as a proxy).  In that way, it learns the subnet that
the user's network would LIKE to be used (resolving RFC1918
ambiguities as well as *assigned* IP ranges)

This covers the case for no DHCP server present as well as
a competing DHCP service.  And, gives the user a handle
into the configuration process as a desired side effect.

But, it's yet another app -- hosted OUTSIDE the device -- that
has to be maintained  :<

And, you can't lose sight of the fact that the user has to
arrange for any sort of "persistence" that he may require...
in light of a network that may not inherently want to offer it!

[toc] | [prev] | [next] | [standalone]

#32007

On 9/7/2023 23:30, Don Y wrote:
> On 9/7/2023 11:40 AM, Theo wrote:
>>> 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.
>>
>> 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)
> 
> How do you address the case of your (GUI) client discovering some other
> DHCP service running on the network?

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"

[Most likely this was yet another sabotage against our devices at
this customer (they have no legit second dhcp server there so someone
must have set one up, the problems started some time after they changed
routers and well, they have a history of sabotage attempts there, there
was physical evidence for that).]

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.

[toc] | [prev] | [next] | [standalone]

#32008

On 9/7/2023 2:14 PM, Dimiter_Popoff wrote:
> On 9/7/2023 23:30, Don Y wrote:
>> How do you address the case of your (GUI) client discovering some other
>> DHCP service running on the network?
> 
> 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

That just brings up a different set of problems.
You have to pick a range of IPs for the router's clients.
How do you know that your choices won't conflict with other
hosts in their organization?

> 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"

There is ALWAYS an advantage to be had from having a known,
working configuration that you can coax the user back to
trying.

But, getting from there to something that fits *his* needs
can be problematic (as above).

> [Most likely this was yet another sabotage against our devices at
> this customer (they have no legit second dhcp server there so someone
> must have set one up, the problems started some time after they changed
> routers and well, they have a history of sabotage attempts there, there
> was physical evidence for that).]
> 
> 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.

I think the best approach for bootstrapping headless devices,
*today* would be to embed BLE (severely range constrained) or,
preferably, NFC in the device and kludge an interface that can
rely on something (app) present in all/most cell phones to bridge
the gap to a "familiar" UI.

But, this will still only address the one-off sites.  Handling
hundreds or thousands of devices (as is my bootstrap case) will
always be a challenge -- esp if no techies around to deal with it!

[toc] | [prev] | [next] | [standalone]

#32009

On 9/7/2023 2:31 PM, Don Y wrote:
> I think the best approach for bootstrapping headless devices,
> *today* would be to embed BLE (severely range constrained) or,
> preferably, NFC in the device and kludge an interface that can
> rely on something (app) present in all/most cell phones to bridge
> the gap to a "familiar" UI.

Think of how early home computers relied on things like the
Kansas City standard to provide mass storage in the days
before affordable disk drives.  Find something ubiquitous
and MISappropriate it!

[toc] | [prev] | [next] | [standalone]

#32010

On 9/8/2023 0:31, Don Y wrote:
> On 9/7/2023 2:14 PM, Dimiter_Popoff wrote:
>> On 9/7/2023 23:30, Don Y wrote:
>>> How do you address the case of your (GUI) client discovering some other
>>> DHCP service running on the network?
>>
>> 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
> 
> That just brings up a different set of problems.
> You have to pick a range of IPs for the router's clients.
> How do you know that your choices won't conflict with other
> hosts in their organization?

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.

> 
>> 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"
> 
> There is ALWAYS an advantage to be had from having a known,
> working configuration that you can coax the user back to
> trying.
> 
> But, getting from there to something that fits *his* needs
> can be problematic (as above).

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.

> 
>> [Most likely this was yet another sabotage against our devices at
>> this customer (they have no legit second dhcp server there so someone
>> must have set one up, the problems started some time after they changed
>> routers and well, they have a history of sabotage attempts there, there
>> was physical evidence for that).]
>>
>> 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.

> I think the best approach for bootstrapping headless devices,
> *today* would be to embed BLE (severely range constrained) or,
> preferably, NFC in the device and kludge an interface that can
> rely on something (app) present in all/most cell phones to bridge
> the gap to a "familiar" UI.

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?

> 
> But, this will still only address the one-off sites.  Handling
> hundreds or thousands of devices (as is my bootstrap case) will
> always be a challenge -- esp if no techies around to deal with it!
> 

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             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#32011

On 9/7/2023 2:53 PM, Dimiter_Popoff wrote:
>>> 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
>>
>> That just brings up a different set of problems.
>> You have to pick a range of IPs for the router's clients.
>> How do you know that your choices won't conflict with other
>> hosts in their organization?
> 
> 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.

Yes, but you're just kicking the can into their court.  If
the addresses you picked coincide with addresses they are
already using, then those hosts are inaccessible "across"
the router (regardless of which way you are going).

The advantage of an in-place DHCP server is that they,
presumably, set up the range of addresses served to be
compatible with their network design.

>>> 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"
>>
>> There is ALWAYS an advantage to be had from having a known,
>> working configuration that you can coax the user back to
>> trying.
>>
>> But, getting from there to something that fits *his* needs
>> can be problematic (as above).
> 
> 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.

Again, see above.
>> I think the best approach for bootstrapping headless devices,
>> *today* would be to embed BLE (severely range constrained) or,
>> preferably, NFC in the device and kludge an interface that can
>> rely on something (app) present in all/most cell phones to bridge
>> the gap to a "familiar" UI.
> 
> 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?

You would use it to TELL the device what IP it should use.
If they tell it something "bad", then that's their problem.

>> But, this will still only address the one-off sites.  Handling
>> hundreds or thousands of devices (as is my bootstrap case) will
>> always be a challenge -- esp if no techies around to deal with it!
>>
> 
> 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.

If it was just IP address assignment, it would be easy -- let
them all fight for leases and then DDNS so they're all resolvable
symbolically.

The problem comes from having to install (device-specific) secrets
in all of them.  If you don't have physical control/oversight of
the entire network, you can't know if someone hasn't eavesdropped
on the process.

> 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.

Displays cost money.  If you can leverage it for some OTHER
purpose ("Measurement in Progress"), then it's easier to justify
the expense.

If the user must be able to enter information, then the input
device(s) becomes another issue.

[I have a NAS that has a display and a means whereby the user can enter
initial configuration parameters -- e.g., IP/Mask/etc.  But, it is
incredibly brain-damaged:  scroll through menu to find item of interest;
SELECT item; scroll to select subitem of interest; SELECT subitem;
scroll through available values; SELECT value (advancing to next subitem
in the process).  So, configuring a network interface requires setting
12 items for an IP address (one for each of 4x3 digits), another 12
for a mask (ditto), and another 12 for DNS (or GW, I can't recall which).
The selected (sub)item flashes so that puts a limit on how fast you
can select subitems/values.  An error requires you to cycle through ALL
of the items/subitems until you loop around back to the item you munged.]

Engineers are typically penny-wise and pound-foolish in their
designs of fallback UIs!

[toc] | [prev] | [next] | [standalone]

#32012

On 9/8/2023 1:21, Don Y wrote:
> On 9/7/2023 2:53 PM, Dimiter_Popoff wrote:
>>>> 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
>>>
>>> That just brings up a different set of problems.
>>> You have to pick a range of IPs for the router's clients.
>>> How do you know that your choices won't conflict with other
>>> hosts in their organization?
>>
>> 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.
> 
> Yes, but you're just kicking the can into their court.  If
> the addresses you picked coincide with addresses they are
> already using, then those hosts are inaccessible "across"
> the router (regardless of which way you are going).

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.

> 
> The advantage of an in-place DHCP server is that they,
> presumably, set up the range of addresses served to be
> compatible with their network design.

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.

> 
>>>> 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"
>>>
>>> There is ALWAYS an advantage to be had from having a known,
>>> working configuration that you can coax the user back to
>>> trying.
>>>
>>> But, getting from there to something that fits *his* needs
>>> can be problematic (as above).
>>
>> 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.
> 
> Again, see above.

?

>>> I think the best approach for bootstrapping headless devices,
>>> *today* would be to embed BLE (severely range constrained) or,
>>> preferably, NFC in the device and kludge an interface that can
>>> rely on something (app) present in all/most cell phones to bridge
>>> the gap to a "familiar" UI.
>>
>> 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?
> 
> You would use it to TELL the device what IP it should use.
> If they tell it something "bad", then that's their problem.

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             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#32013

On 9/7/2023 4:05 PM, Dimiter_Popoff wrote:
>> The advantage of an in-place DHCP server is that they,
>> presumably, set up the range of addresses served to be
>> compatible with their network design.
> 
> 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.

You can't know which IP addresses they haven't already
used for their own hosts.  The router solution only
works on the subnet that *it* manages.

You pick some range of IP addresses.  Assume A.B.C.D is
one of them.  The WAN port of your router conects to
THEIR network and gets an IP address from their DHCP
server.

THEY have a host at A.B.C.D.  How do the devices on
the router's subnet access THAT host?  How do the
hosts on their existing network access *your* A.B.C.D?

The only way you can ensure that the addresses you
assign are unique if if you assign them under a domain
that you control (tgi-sci.com).

>>>> I think the best approach for bootstrapping headless devices,
>>>> *today* would be to embed BLE (severely range constrained) or,
>>>> preferably, NFC in the device and kludge an interface that can
>>>> rely on something (app) present in all/most cell phones to bridge
>>>> the gap to a "familiar" UI.
>>>
>>> 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?
>>
>> You would use it to TELL the device what IP it should use.
>> If they tell it something "bad", then that's their problem.
> 
> 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).

No, the problem with existing solutions is that they
don't give you an easy way to convey that information
to the *user* (unless you have a display capability
*in* the device or enough tech-savvy to know how
to talk to the DHCP server to figure out where the
device resides in the IP space).

I'm suggesting using a UI device that is reasonably
ubiquitous (a cell phone) as that interface.  This
is similar to using PDAs decades ago as UIs for
headless devices.

[toc] | [prev] | [next] | [standalone]

#32014

On 9/8/2023 2:55, Don Y wrote:
> On 9/7/2023 4:05 PM, Dimiter_Popoff wrote:
>>> The advantage of an in-place DHCP server is that they,
>>> presumably, set up the range of addresses served to be
>>> compatible with their network design.
>>
>> 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.
> 
> You can't know which IP addresses they haven't already
> used for their own hosts.  The router solution only
> works on the subnet that *it* manages.

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.

> 
> You pick some range of IP addresses.  Assume A.B.C.D is
> one of them.  The WAN port of your router conects to
> THEIR network and gets an IP address from their DHCP
> server.
> 
> THEY have a host at A.B.C.D.  How do the devices on
> the router's subnet access THAT host?  How do the
> hosts on their existing network access *your* A.B.C.D?

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?

> 
> The only way you can ensure that the addresses you
> assign are unique if if you assign them under a domain
> that you control (tgi-sci.com).

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.

> 
>>>>> I think the best approach for bootstrapping headless devices,
>>>>> *today* would be to embed BLE (severely range constrained) or,
>>>>> preferably, NFC in the device and kludge an interface that can
>>>>> rely on something (app) present in all/most cell phones to bridge
>>>>> the gap to a "familiar" UI.
>>>>
>>>> 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?
>>>
>>> You would use it to TELL the device what IP it should use.
>>> If they tell it something "bad", then that's their problem.
>>
>> 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).
> 
> No, the problem with existing solutions is that they
> don't give you an easy way to convey that information
> to the *user* (unless you have a display capability
> *in* the device or enough tech-savvy to know how
> to talk to the DHCP server to figure out where the
> device resides in the IP space).
> 
> I'm suggesting using a UI device that is reasonably
> ubiquitous (a cell phone) as that interface.  This
> is similar to using PDAs decades ago as UIs for
> headless devices.
> 

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.

[toc] | [prev] | [next] | [standalone]

#32015

On 9/7/2023 6:26 PM, Dimiter_Popoff wrote:
>> The only way you can ensure that the addresses you
>> assign are unique if if you assign them under a domain
>> that you control (tgi-sci.com).
> 
> 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

Exactly.  Did you not recall my comment that you were
"kicking the can into their court"?  The *ideal* way
to configure something is to have a DHCP server issue
an IP address that is compatible with THEIR network
addressing and register a symbolic name via DDNS.

But, this puts additional constraints on the user.

> 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.

>> No, the problem with existing solutions is that they
>> don't give you an easy way to convey that information
>> to the *user* (unless you have a display capability
>> *in* the device or enough tech-savvy to know how
>> to talk to the DHCP server to figure out where the
>> device resides in the IP space).
>>
>> I'm suggesting using a UI device that is reasonably
>> ubiquitous (a cell phone) as that interface.  This
>> is similar to using PDAs decades ago as UIs for
>> headless devices.
> 
> This sounds too generic to me, I don't understand how

You *want* something generic.  So, it can be applied to
many different products/scenarios.

> 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

You have to access the WiFi router.  What's the passphrase?
Who *controls* access?

If you're a small company/department, you can possibly
go your own way -- and avoid the eyes of little hitlers.
But, if you have to interface to a corporate infrastructure,
you may find just connecting your *device* to the network
requires vetting ("How do we know the device isn't
malevolent?")

> 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.

You can offer the FTP profile from your device over BT.
Then, just let the user retrieve a status page from
your device and.or *send* a configuration page to it.

The phone is just a display + keyboard/pad.  No special
apps (beyond the BT stack).

Because BLE is relatively short-range, you don't worry
about seeing every host in the department, etc.

Accessing the DHCP server's client list means you have to
have a DHCP server *and* have to have permission to access
it.  These are things outside of the scope of the device.

A "portable UI" that can talk directly to the device
doesn't require any cooperation from anyone to have
a service in place AND a means of accessing that service
(likely by an "unprivileged" user).

[Many larger organizations have IT departments that strictly
control what they allow on their networks (you've heard the
phrase BOfH?).  I've had to implement clandestine tunnels
under common protocols to get through the "policies"
(defined and implemented by folks with their own sense of
self-importance) that customers have had in place that
would prevent me from doing what I would have otherwise
done safely.  (escalating to upper management doesn't
make you any friends among the IT folks and, *if* there is
ever a problem with your device, you can be SURE they will
gleefully stand in your way of fixing it!)]

[toc] | [prev] | [next] | [standalone]

#32017

Don Y <blockedofcourse@foo.invalid> wrote:
> On 9/7/2023 11:40 AM, Theo wrote:
> >> 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.
> > 
> > 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)
> 
> How do you address the case of your (GUI) client discovering some other
> DHCP service running on the network?

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.

> If you could modify the *client* code, you could use something like
> a different vendor magic to ensure only the server in the device
> would be recognized.
> 
> You could flip this around; distribute an app that acts as a
> special DHCP server.  Have the device only issue requests to
> services offered by *that* server (even if another was
> competing -- see above).

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).

[*] setting a static IP on the interface also requires admin privs, so
schemes where the device responds at some fixed address like
http://192.168.33.99/ where you need to configure your laptop for
192.168.33.0/24 also require admin privs

Theo

[toc] | [prev] | [next] | [standalone]

#32018

On 9/8/2023 2:17 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 9/7/2023 11:40 AM, Theo wrote:
>>>> 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.
>>>
>>> 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)
>>
>> How do you address the case of your (GUI) client discovering some other
>> DHCP service running on the network?
> 
> 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

Ah, OK.  This is how I typically set up such devices -- I find it
annoying that I can't just plug into my existing network (which
is where it will ultimately reside) and access it with my normal
suite of tools.  E.g., figuring out where in the address space
I want it to reside, copying its MAC to ethers(4), making an
entry in the DNS, etc.

(I rarely use a laptop for anything OTHER than setting up network
access on devices)

Given a device that has a separate (e.g., EIA232) "console port",
I much prefer that means of initialization as I can just tip(1)
to the device and copy configuration data to and from the rest of
the network's configuration.

> (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.
> 
>> If you could modify the *client* code, you could use something like
>> a different vendor magic to ensure only the server in the device
>> would be recognized.
>>
>> You could flip this around; distribute an app that acts as a
>> special DHCP server.  Have the device only issue requests to
>> services offered by *that* server (even if another was
>> competing -- see above).
> 
> 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).

I have assumed using "bad magic" would keep other clients
off of THAT server.  You could also move it to an "unassigned"
port as you have control over the device's client(s).

> [*] setting a static IP on the interface also requires admin privs, so
> schemes where the device responds at some fixed address like
> http://192.168.33.99/ where you need to configure your laptop for
> 192.168.33.0/24 also require admin privs

Yes, it's annoying to have to change anything other than
the device in question when you're trying to set up the device
in question.  It tells the user that the device is their sole
focus, regardless of the rest of their existing network.

[And, means you have to deal with each device individually,
AT the device]

[toc] | [prev] | [next] | [standalone]

#32002

On 9/5/2023 1:37 AM, pozz wrote:
> Is it a proprietary solution that uses only Ethernet frames (MAC addresses) and 
> not IP packets? Is it a well known protocol that I don't know?

RARP gave way to BOOTP which gave way to DHCP for exactly this reason.

They all run *below* the IP layer so can be implemented (client-side)
relatively easily.  Assigning IP, hostname, gateway, nameserver,
timeserver, boot server, boot image, etc. are all done, there.

(You can operate an ethernet without IP at all!)

The problem is:
- having a suitable server present on the network
   (not all will have this -- though most SOHOs will)
- conveying the parameters that were assigned by
   the service to the *human* user (without requiring
   special knowledge of a special tool which would
   require more knowledge of the user's operating
   environment *or* having a UI on the device)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web