@MSGID: 2@dont-email.me> d95f3a3c
@REPLY: 2@dont-email.me> b05b819d
@REPLYADDR Don Y <blockedofcourse@foo.invalid>
@REPLYTO 2:5075/128 Don Y
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 2@dont-email.me>
@TZUTC: -0700
@PID: Mozilla/5.0 (Windows NT 6.1; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.2.2
@TID: FIDOGATE-5.12-ge4e8b94
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


 --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441