Got a set of 335Le cameras this week to evaluate, and when setting them up I noticed that they won’t accept DHCP addresses. Packet sniffing showed that this was because the DHCP server was sending a NAK to the camera’s REQUEST packet. I.e. the packet flow went DISCOVER, OFFER, REQUEST, NAK.
Digging further, this appears to be because the camera does not include the DHCP server IP in the REQUEST packet.
For example, here is the Wireshark dissection of one of its REQUEST packets it sent in reply to an OFFER packet on the same transaction ID (so it should be in the SELECTING state, not INIT-REBOOT). Note that there are no options indicating the server IP:
Dynamic Host Configuration Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xacce405a
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: Orbbec3DTech_23:e8:89 (54:14:fd:23:e8:89)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: Orbbec3DTech_23:e8:89 (54:14:fd:23:e8:89)
Option: (50) Requested IP Address (172.31.19.149)
Length: 4
Requested IP Address: 172.31.19.149
Option: (255) End
Option End: 255
Reviewing RFC 2131 confirms that the client is REQUIRED to fill in this information in this state: §4.3.2 and Table 4 (§4.3.6) : a client in SELECTING state (i.e., replying to a DHCPOFFER) MUST populate the ‘server identifier’ option (option 54) in the resulting DHCPREQUEST with the IP address of the server whose offer it is accepting.
Clients send DHCPREQUEST messages as follows:
DHCPREQUEST generated during SELECTING state:
Client inserts the address of the selected server in ‘server
identifier’, ‘ciaddr’ MUST be zero, ‘requested IP address’ MUST be
filled in with the yiaddr value from the chosen DHCPOFFER.
Ergo I conclude this is a bug in the camera firmware, not the DHCP server software.