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
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.
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
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?
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.
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?
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.
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).
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)
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?
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
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.
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.
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!
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.
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.
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.
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.
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).
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.
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.
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.
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)
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).
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
Il 07/09/2023 19:57, Don Y ha scritto:
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.
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 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)
[1] https://www.youtube.com/watch?v=NIiI1BIHfms
On 9/8/2023 12:41 AM, pozz wrote:
Il 07/09/2023 19:57, Don Y ha scritto:
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.
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).
And, then again, maybe you *do*! Regardless, the user has to be
aware of where the device *can* reside in his IP space. Do *you*
know which IP's you've already assigned, offhand?
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.
You would, instead, let each device negotiate a lease and
then register their chosen hostnames with a local DNS.
Thereafter, you'd talk to KitchenCamera or FrontDoorCamera
and forget all about the IP addresses.
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).
Everyone who uses this approach HOPEFULLY has a different default
address. The device I configured last week used 192.168.2.10.
(All of the devices on *my* networks are 10/8.)
So, I have to:
- reset the device (figure out HOW and how to VERIFY this)
- set up a laptop for a compatible 192.168.2/24 address
- connect to the device (TELNET, SSH, HTTP, ?)
- locate the STATIC IP address settings
- pick a 10/8 address
- reconfigure the laptop for a 10/8 address
- "refresh" the connection to the device (often not
straightforward)
- verify device is accessible in 10/8 (cuz I'd be pissed if
the device reverted to its default address)
- power down the device
- power up, again, to ensure the settings held
- move device to its intended network
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.
Unless something is already AT that address. E.g., my local DHCP
server (for this 'exposed" network) assigns leases in the 192.168.1.100-149 range so .108 can possibly be in use. You thus force me to use a separate *isolated* network just to configure your device (to get it to some other address that is compatible with my usage -- even if 192.168/16)
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).
Then the NVR is not using IP-based addressing. And, you've introduced another physical device into the mix.
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?
Make the device broadcast a RARP (or similar) request and have an
app that listens for those broadcasts "of a certain flavor"
(so they are recognized as THE devices of interest and not some
other device that just happens to be using RARP.
[Eschew broadcast protocols]
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.
If you don't mind the user having to install a tool for that purpose!
Is there an OSX version? Linux? Slowaris? Which OS version(s) are supported? Which hardware platforms?
[I.e., any time you have to develop a tool, you have to *support* that
tool]
Recall that bootstrapping a device (in theory) is a one-time
activity. So, anything that you "spend" (development resources,
recurring costs, UX, etc.) is only going to be seen "once".
[I wonder if SMB shares could work... push a settings file onto
a share published by the device using a unique name advertised
by the device. If the file parses correctly, a "Configured"
file appears in the share else "AwaitingConfiguration" or "DefaultConfiguration" presents. This is a rehash of my USB
mass storage device suggestion built on ethernet, instead]
(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)
[1] https://www.youtube.com/watch?v=NIiI1BIHfms
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.
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).
And, then again, maybe you *do*! Regardless, the user has to be
aware of where the device *can* reside in his IP space. Do *you*
know which IP's you've already assigned, offhand?
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.
You would, instead, let each device negotiate a lease and
then register their chosen hostnames with a local DNS.
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.
Thereafter, you'd talk to KitchenCamera or FrontDoorCamera
and forget all about the IP addresses.
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.
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).
Everyone who uses this approach HOPEFULLY has a different default
address. The device I configured last week used 192.168.2.10.
(All of the devices on *my* networks are 10/8.)
So, I have to:
- reset the device (figure out HOW and how to VERIFY this)
- set up a laptop for a compatible 192.168.2/24 address
- connect to the device (TELNET, SSH, HTTP, ?)
- locate the STATIC IP address settings
- pick a 10/8 address
- reconfigure the laptop for a 10/8 address
- "refresh" the connection to the device (often not
straightforward)
- verify device is accessible in 10/8 (cuz I'd be pissed if
the device reverted to its default address)
- power down the device
- power up, again, to ensure the settings held
- move device to its intended network
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.
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.
Unless something is already AT that address. E.g., my local DHCP
server (for this 'exposed" network) assigns leases in the 192.168.1.100-149 >> range so .108 can possibly be in use. You thus force me to use a separate >> *isolated* network just to configure your device (to get it to some other
address that is compatible with my usage -- even if 192.168/16)
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.
If you have multiple IPCams, connect them to modern NVRs from the sameThen the NVR is not using IP-based addressing. And, you've introduced
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). >>
another physical device into the mix.
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.
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?
Make the device broadcast a RARP (or similar) request and have an
app that listens for those broadcasts "of a certain flavor"
(so they are recognized as THE devices of interest and not some
other device that just happens to be using RARP.
[Eschew broadcast protocols]
Of course, there could be many ways, what I'm asking here is why we don't have
such a standard protocol.
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.
If you don't mind the user having to install a tool for that purpose!
Is there an OSX version? Linux? Slowaris? Which OS version(s) are
supported? Which hardware platforms?
[I.e., any time you have to develop a tool, you have to *support* that
tool]
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.
Recall that bootstrapping a device (in theory) is a one-time
activity. So, anything that you "spend" (development resources,
recurring costs, UX, etc.) is only going to be seen "once".
[I wonder if SMB shares could work... push a settings file onto
a share published by the device using a unique name advertised
by the device. If the file parses correctly, a "Configured"
file appears in the share else "AwaitingConfiguration" or
"DefaultConfiguration" presents. This is a rehash of my USB
mass storage device suggestion built on ethernet, instead]
(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)
[1] https://www.youtube.com/watch?v=NIiI1BIHfms
:
The DHCP server gives you a way to get *an* IP address into a device
so you can THEN talk to it -- presumably to set a (different) static
address (keeping in mind the pool of addresses set aside for the DHCP >service, the router itself, the broadcast address and any other
addresses already allocated in that subnet).
If you run a DNS, you likely have a place to "write these down".--- Synchronet 3.20a-Linux NewsLink 1.114
If not (if you do all addressing numerically), do you have a cheat sheet >someplace that you can consult to determine what's available?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 31:22:37 |
| Calls: | 12,169 |
| Calls today: | 1 |
| Files: | 186,521 |
| Messages: | 2,234,263 |