Hello,
Does anyone have a pcap trace of a DHCP session between the CM and the DHCP provisioning server for either docsis 2.0 or docsis 3.0?
We are working on a new DHCP server implementation to provision the CM. Several CM DHCP client implementations are reporting that a critical field is invalid, but no additional details are provided. A successful DHCP exchange would help us debug this further.
Here is a CloudShark trace of our current exchange. The CM appears to reject the final DHCPACK and restart.
https://www.cloudshark.org/captures/35a36e571e17
Regards,
--joe
Hi, sometimes some cable modem's models does not accept the Ip address provided because one service is not working fine at the provisioning server: time of day, dns for example. Please ensure all the requested services are up and running. I took a look of the parameters requested and being responded and it looks fine at first look.
What CM model is that one?, during the discover is not being identifying itself. Regards.-
Thanks for the tip. The CM in the previous trace is a Linksys CM100 docsis 2.0. I did see the same issue with several modems and I finally tracked down the problem. The CMTS is in a simple bridge mode and there is another DHCP server on an additional ethernet interface. This "other" DHCP server is sending a DHCP-NACK while the real server is sending a DHCP-ACK. The DHCP client on the CM should be ignoring the DHCP-NAK since the server identifier does not match. Once this second DHCP server is removed, everything comes right up.
Here are the two conflicting DHCP sessions:
https://www.cloudshark.org/captures/c2d41d93e354
Good to know the issue is solved. Regards.-