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

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