Strange, im sure i've activated cams using that tool when my PC is on a different network range to the default 192.168.1.0/24 network. I just assumed it broadcast to 255.255.255.255. I'll have to check tomorrow. I've got another to activate so it will be a good excuse.
Wow this thread has moved on some since i last checked in. I'm not sure it's applicable now but i activated another cam last night from a PC with different network address and made notes as i went so here is what i saw for what its worth...
I did a quick litle traffic capture while i was activating my z12e camera which came from
@EMPIRETECANDY
I changed the IP address on my NIC to be
192.168.2.2/24. This network does not exist in my LAN. I purposely did not give a default gateway as there is no gateway to match the subnet anyway.
I also cleared the ARP table on my PC.
I plugged the cam into the same switch as the PC therefore same broadcast domain.
I noted that the cam was broadcasting multiple ARP requests for the IP address of 192.168.1.1. Obviously an attempt to locate a gateway off the network as many people assign the first octet in the network to the gateway.
I then fired up Dahua config tool and let it do a scan to locate cameras. It did locate the z12e camera which at this point in time had not been activated.
I noticed that when i initiated the scan an IGMP Join request was transmitted to a multicast address advertising a multicast IP address to use for communication. This was followed by three frames containing UDP traffic.
one frame transmitted to IP and Ethernet broadcast address with a source port of 5051 and destination port of 5050.
another frame transmitted to the IP Multicast address that the IGMP frame had advertised. Source port 37810 and destination port 37810. Contents of which where:
...DHIP........I.......I.......{ "method" : "DHDiscover.search", "params" : { "mac" : "", "uni" : 1 } }
a final frame also transmitted to the Multicast address with source port 37811 and destination port 8087. Contents of which were:
...DHIP........I.......I.......{ "method" : "DHDiscover.search", "params" : { "mac" : "", "uni" : 1 } }
This produced an interesting response as the new non-activated z12e camera responded to the UDP frames using UDP ports 5050 <-> 5051 and 37810 <-> 37810
Information contained in these frames were details such as Device name, MAC address, serial number, ipv6 address etc. I also received a response from a camera which is already activated and configured for a different network to 192.168.2.0/24 or 192.168.1.0/24 but again was on the same broadcast domain. This contained more information but i dont know if thats because its a different model of camera or if its because its activated and configured. Plus frankly i didnt want to go down a rabbit hole as this was meant to be a quick test.
================================================================================
UDP Conversations
Filter:ip.addr==192.168.2.2||ip.addr==192.168.1.108&&(!ssdp&&!nbns&&!mdns&&!llmnr)
| <- | | -> | | Total | Relative | Duration |
| Frames Bytes | | Frames Bytes | | Frames Bytes | Start | |
192.168.2.2:41305 <-> 239.255.255.251:37810 0 0 bytes 1 170 bytes 1 170 bytes 27.611151000 0.0000
192.168.1.108:37810 <-> 192.168.2.2:41305 0 0 bytes 1 739 bytes 1 739 bytes 27.622659000 0.0000
192.168.2.2:45578 <-> 239.255.255.251:37810 0 0 bytes 1 826 bytes 1 826 bytes 27.675493000 0.0000
192.168.1.108:37810 <-> 192.168.2.2:45578 0 0 bytes 1 160 bytes 1 160 bytes 27.797832000 0.0000
192.168.2.2:44567 <-> 239.255.255.251:37810 0 0 bytes 1 170 bytes 1 170 bytes 27.809224000 0.0000
192.168.1.108:60499 <-> 239.255.255.250:3702 0 0 bytes 1 1290 bytes 1 1290 bytes 27.819571000 0.0000
192.168.1.108:37810 <-> 192.168.2.2:44567 0 0 bytes 1 739 bytes 1 739 bytes 27.820787000 0.0000
192.168.1.108:48688 <-> 239.255.255.250:3702 0 0 bytes 1 1290 bytes 1 1290 bytes 27.838137000 0.0000
192.168.2.2:41168 <-> 239.255.255.251:37810 0 0 bytes 1 889 bytes 1 889 bytes 27.852219000 0.0000
192.168.1.108:37810 <-> 192.168.2.2:41168 0 0 bytes 1 164 bytes 1 164 bytes 29.400114000 0.0000
================================================================================
Following that, the camera broadcasts an arp request for the IP address of my PC, to which a response is sent.
I then initialised the camera in the config tool despite the message stating that i "
cannot initialize crossing LAN". This operation involved my pc transmitting traffic to the multicast address again whereby multiple single frame "sessions" (transmit > receive > close UDP port > repeat with new ephermeral port). This was encrypted so i dont know what was contained exactly. Following initialisztion i was able to configure the cameras IP address to the network range that i desired.
The above table shows all the frames involved in the above communication between the PC and camera. Its interesting to note that the PC always transmitts to the multicast address and the camera always responds directly to the PC's IP address.
This left me wondering if my choice of test network was a bad choice and that maybe i should have chosen a 10.0.0.0/24 network instead. I dont know what subnet mask the Dahua cameras arrive with as default along with their 192.168.1.108 address. Its possible that they are configured with a /16 subnet mask therefore putting it in the same network as 192.168.1.0 which would explain why the camera always responds direct to the PC.
Head scratcher alright. Someone much smarter than me probably knows all this but it was a fun little exersize for a Sunday evening. Anyway, now i have a z12e to play with and all the joy that capturing number plates involves. See you in the LPR section