@MSGID: 3@dont-email.me> 4b8cb19a
@REPLY: 2@dont-email.me> d95f3a3c
@REPLYADDR pozz <pozzugno@gmail.com>
@REPLYTO 2:5075/128 pozz
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 3@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 2@dont-email.me> 2@dont-email.me>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.0
@TID: FIDOGATE-5.12-ge4e8b94
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 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 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

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.0
 * 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