DHCP client fails with new ISP

Networking
1

IPFire (IPFire 2.25 (x86_64) - Core Update 147) has been working fine with old ISP using DHCP client for several weeks

I switched to a new ISP today and DHCP client is timing out after sending REQUEST, apparently after not receiving an ack. The address in the OFFER is legit.

Jul 30 18:22:22 ipfire dhcpcd[21373]: red0: sending DISCOVER (xid 0x11dc23ce), next in 4.9 seconds
Jul 30 18:22:22 ipfire dhcpcd[21373]: red0: offered 121.200.23.16 from 121.200.20.1
Jul 30 18:22:22 ipfire dhcpcd[21373]: red0: sending REQUEST (xid 0x11dc23ce), next in 3.6 seconds
Jul 30 18:22:25 ipfire dhcpcd[21373]: red0: sending REQUEST (xid 0x11dc23ce), next in 7.0 seconds
Jul 30 18:22:32 ipfire dhcpcd[21373]: red0: sending REQUEST (xid 0x11dc23ce), next in 16.0 seconds
Jul 30 18:22:48 ipfire dhcpcd[21373]: red0: sending REQUEST (xid 0x11dc23ce), next in 31.9 seconds
Jul 30 18:23:15 ipfire dhcpcd[24647]: sending signal ALRM to pid 21373

With previous ISP the REQUEST is acknowledge right away:

Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: sending DISCOVER (xid 0x3244b48c), next in 4.0 seconds
Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: offered 144.132.0.192 from 172.18.52.155
Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: sending REQUEST (xid 0x3244b48c), next in 3.2 seconds
Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: acknowledged 144.132.0.192 from 172.18.52.155
Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: probing address 144.132.0.192/19
Jul 30 18:17:54 ipfire dhcpcd[21373]: red0: probing for 144.132.0.192

I plugged a windows 10 laptop into the ethernet port for new ISP and it grabbed a dynamic address without problems so the ISP is functional, at least with the laptop.

Any ideas on how to go about cracking this?

2

I would try a few troubleshooting measures first. Is there any cloned MAC address or VLAN configuration left over from the old ISP?

Another thing to try, if you are hot-plugging the connection and not rebooting IPFire when connecting to the new ISP, you may want to try to restart networking services by running the following command at an SSH shell after you plug the WAN port in to the new ISP:
/etc/init.d/network restart

3

Did you restart the modem? I suppose you are using cable internet ( DOCSIS ).
Some ISPs bind the connection to the client MAC address ( loosely ). A new client gets an IP after a restart of the modem. Until then only the registered ( through DHCP request ) client gets an IP, the same or another.

4

It is a vanilla setup, no VLAN, no clone mac addresses.

I have hit /etc/init.d/network restart many times :wink: as well as rebooting.

5

I have cycled the power on the modem a few times - it is a new modem, the old ISP has its own.

6

I plugged it into an ethernet port on a Fedora 32 box and it connected right away. I was running wireshark and so far the only thing I can see that is a little odd (not being a protocol expert) is that option (53) DHCP Message type ACK is not the first option in the DHCP Ack packet.

Fedora 32 maybe doesn’t use ISC dhcpcd and Windows will have its own.

I will run tshark on the ipfire box, just gonna a need a bit more research since I can’t run it on an intrface (red) until it is up (unlike wireshark) so I will have to figure out a capture filter.

7

So when I do dhclient -d -v red0 it gets the ack but I still can’t start the interface with /etc/init.d/networking/red start - dhcpcd fails to start.

I can see the DHCP ACK from the command line dhclient invocation but it doesn’t show with /.../red start

Is there something I need to do to flush firewall rules which could be blocking the ACK on the new ISP’s net?

8

I was not able to resolve this after spending a day with tshark, resetting modems and rebooting (I also tried a reinstall). so sadly I had to switch to a different firewall which connected right away.

For anyone coming here:

  • tp_link modem, windows laptop, fedora workstation and opnsense all connected to the ISP without drama. I could not get ipfire to connect to the new ISP.

  • ipfire gave errors with the dhcpcd script when trying to bring up red0 - there was no ack detected at the end of the DHCP handshake and dhcpcd timed out. dhclient -r red0 worked fine from the command line so (I am just guessing) maybe there is a race condition with firewall rules that are tickled with this particular ISP/modem.

9

Could you see, whether the request packets are identical for dhclient and dhcpcd?
I am aware of a similiar problem. RENEWS aren’t answered ( dhcpcd doesn’t see them ), thus dhcpcd tries a REBIND, which succeeds if the connection to the ISP is okay. In case of a loss for a certain time, dhcpcd can’t re-establish the lease.