Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#19603 closed defect (not_a_bug)

dhcp from comcast fails after a reboot of the router - requires reboot of modem

Reported by: dtaht Owned by: developers
Priority: normal Milestone:
Component: packages Version: Trunk
Keywords: Cc: cyrus@…


running r45605, (and probably quite a few earlier versions), a reboot of the router results in failing to assign a ip address.

I DO see a dhcp request and reply happen in this capture here, but no further negotiation, so something is odd about the formatting of the reply...

Rebooting the cable modem after rebooting the router works... so I think that the cable modem is retaining some state that the router does not agree with on the reply.

Attachments (0)

Change History (9)

comment:1 Changed 3 years ago by anonymous

This is a capture of a working dhcpv4 process (after rebooting the modem)

And also has the ipv6 negotiation which only gets a /64 for some reason.

comment:2 Changed 3 years ago by cyrus

  • Cc cyrus@… added

The links appear to be the same (non-working and working capture) and i only see a non-working DHCP transaction. I assume the TP-LinkT-e5:64:c3 is your CPE.

We are using busybox's udhcpc as DHCPv4 client btw. let me check the changelog if I can see any potential issues there.

Last edited 3 years ago by cyrus (previous) (diff)

comment:3 Changed 3 years ago by anonymous

hmm? comcast_dhcp_issue.cap is the one that failed, issues is the one that succeeded. You can watch it go through the cable boot process (first assigning a 192 address,then a real one), in the issues.

I am so confused now as to the actual daemons in play these days. This is what I see

root@cake:/etc/config# ps | grep dhcp

1219 root 1176 S /usr/sbin/odhcpd
1644 root 1420 S udhcpc -p /var/run/ -s /lib/netifd/dhcp.script -f -t 0 -i eth0 -C -O 212
1646 root 804 S odhcp6c -s /lib/netifd/dhcpv6.script -P60 -t120 eth0
6739 root 1416 S grep dhcp

comment:4 Changed 3 years ago by anonymous

Ah one is issue.cap and the other issueS.cap got it now.

There is no difference between the one succeding and the one that doesn't. In the first PCAP there is no DHCP offer that matches the transaction ID of your DHCP discover at all, the offers there are to different discover's from other clients apparently.

comment:5 Changed 3 years ago by anonymous

Yea, I saw that. Sigh.

So the dhcp server on the modem is probably utterly ignoring new dhcp requests, even if they are generated by the same mac addr after the reboot of the downstream router. I saw this behavior the other day on an entirely different brand modem. (this one is an arris 760A configured for bridge mode)

It would explain a lot about some issues I have had lately with dynamic ip addrs elsewhere. My static ip boxes, of course, don't rely on dhcp at all. So I will say this one looks like a comcast issue for sure....

comment:6 Changed 3 years ago by anonymous

my only other thoughts are that it could be an endianess issue... or that a reboot requires a much longer waiting period to actually get a transaction through (only been waiting 5 minutes)... still... seems wrong to me.

comment:7 Changed 3 years ago by dtaht

Most people are not going to clue up on a need to reboot the cablemodem after a reboot or crash of the client router. No fun.

comment:8 Changed 3 years ago by cyrus

  • Resolution set to not_a_bug
  • Status changed from new to closed

Yeah, but there doesn't seem to be anything we could do. The discovery messages are identical aside from the random transaction ID so the issue is not on our side.

You could see if adding "option broadcast 1" to the dhcp-section makes a difference here but I doubt it.

comment:9 Changed 3 years ago by anonymous

tried that. no dice. Going to let it retry for an hour.

I have a call with comcast later today.

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.