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 interfaceAh, 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 privsYes, 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]
Configure network of an embedded device
Started by ●September 5, 2023
Reply by ●September 8, 20232023-09-08
Reply by ●September 8, 20232023-09-08
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
Reply by ●September 8, 20232023-09-08
Il 08/09/2023 12:50, Don Y ha scritto:> 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.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 networkAgain 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 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.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
Reply by ●September 8, 20232023-09-08
On 9/8/2023 4:56 AM, pozz wrote:>>>> 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. InOf course! My office network is 100% static routed (~50 hosts). But, that means *I* have to assume responsibility for ensuring the addresses are unique -- something most SOHOs likely wouldn't want to do. 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". If not (if you do all addressing numerically), do you have a cheat sheet someplace that you can consult to determine what's available?> 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.DHCP/BOOTP/RARP do that. You can configure the DHCP service to make leases semi-permanent. Or, to bias the server's choice of IP address for a particular MAC (effectively creating a static address). But, now the user is maintaining a DHCP service...> > 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.You operate a Dynamic DNS service that allows name bindings to be installed "dynamically". Each host's IP (from the DHCP server) is registered along with a name suggested by the host (or the DHCP service). "KitchenCamera" is unlikely to be suggested by a COTS camera. But, "PozzCamera123456" (where 123456 are the last three octets of the MAC in your OUI). Thereafter, you can recognize this (because of the MAC printed on the camera) and add an alias for that 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%).No. You have no idea how the existing address space has been used. E.g., this (exposed) network assigns IP's from a block of 50 addresses starting at 192.168.1.100. So, in addition to .1 being set aside for the router, .100 -- .103 are pretty likely to be the first four *wired* connections to the router. If I plug in some other host, "temporarily", it will claim another address (and the DHCP server will likely let it KEEP that address for a full 24 hours, even if I put the device back into the closet and pull out *another* device -- which will similarly claim another address). If I enable the radio, then likely each phone would claim an address.> 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.Does the client observe the policy of verifying the address is currently not in use (which is done by checking to see if anything responds to it -- so, anything that is powered down can't defend its address). What does the user do if there is a conflict? Why can't the *device* fix the problem? [Else, you go to the ARTIFICIAL 2-device network that Theo spoke of.]> 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.Most users likely have a DHCP server on hand. What's missing is having a DNS as well -- so the user can "find" the device without having to hunt for a specific IP (or MAC in a clients list). And, they still need to configure the device (anything beyond IP addressing)>>> 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. > > 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.You use MAC addresses. But, the user has told the NVR what range of addresses *it* can use. In essence, the user is configuring a specialized DHCP service that resides *in* the NVR -- and is designed FOR those particular cameras. Put a printer on that network and the NVR likely will ignore its pleas for an IP address. Put *two* NVRs on the same subnet and wonder...>>> 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.Internetworking is a technology driven from technologists down to end users. Protocols evolve. Why was BOOTP created when RARP did (some of) the same thing? Why DHCP when BOOTP did (some of) the same thing? Thankfully, appliances, nowadays, make this a lot easier to manage than editing all sorts of (ahem) "text databases" in a server!>>> 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.But users don't NEED it. I have no idea what the *local* IP address of this machine is, NOW. Nor do I care about the printer sitting under it. "It just works". AND, I don't have to DO anything besides plug things in! The NVR supplier realized that they would have a higher bar for their consumers *if* they required the consumer to do all of this maintenance. So, they implemented their own service *in* their appliance -- instead of having to provide instructions for how a user could set up and configure a DHCP service, name server, etc. to allow their devices (recorder + cameras) to interoperate. They've no concern over making life easier for other camera makers or NVR makers or IP speaker makers or... YOU could write an app (that runs on a phone or a PC or a specialized appliance!) that gives these same services to the user. At the expense of having to develop and maintain that app/appliance.>> 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 >
Reply by ●September 8, 20232023-09-08
On Fri, 8 Sep 2023 09:45:15 -0700, Don Y <blockedofcourse@foo.invalid> wrote:> : >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).And any DHCP server worth its name will allow you to reserve a particular IP address for a particular MAC address. That gives you a centralized point of administration similar to DNS. This will work even if DHCP is not available because the clients will continue to use their last assigned address. As long as there were no address conflicts when DHCP was operating, there still will be no conflicts when it isn't.>If you run a DNS, you likely have a place to "write these down". >If not (if you do all addressing numerically), do you have a cheat sheet >someplace that you can consult to determine what's available?
