DHCP client on red0 won't reassign IP upon reconnection

Networking
16

Same here - I have no switch between the modem and Red0 interface. In the log I posted, there are “carrier lost” and “carrier acquired” events when service was lost and regained. I’ve also in the past tried physically disconnecting and reconnecting the Red0 Ethernet cable in this case, as well as removing and restoring power to the modem, but did not see any recovery.

Also, the cable modem is giving out extremely short leases - only 20 seconds. That’s the only reason that I hypothesized that as a problem. I could see that as the type of corner case that might have escaped testing.

At any rate, thanks for looking at this. If there’s any more information I can gather - increased log verbosity or otherwise - let me know and I’ll be glad to help.

17

Just checked the problem with low level of coax signal ( hope so, I don’t an instrument to measure the level without amplifier ).
Nearly same behaviour. unbound throws errors. A network restart red helps.
Didn’t try to restart dhcpcd only.

18

The issue has happened again. red0 lost its IP lease for whatever reason and didn’t reacquire automatically. I had to issue dhcpcd red0 to get a new lease. Core 145 does NOT solve the issue.

19

Some days ago I had the same issue. My modem/the CMTS decided to give IPFire a new IP address. dhcpcd tried to get the old IP, without success. :wink:
Because of the time elapsed since the address change ( about 01:00h in the night ) until my discovery ( about 09:30 ) I did a restart of IPFire. Thus I can’t report exactly which erroneous behaviour showed up.

BTW: Since a year I notice dhcpcd can’t renew his IP. After some time the demon decides to rebind. This rebinding succeeds, maybefor the same IP but not for different value.
Since beginning of this year, I think, is a discussion about issues resembling ours. Didn’t follow this in depth, but maybe there a patch for this problem under way.
Possibly a core developer working on this module knows more.

20

Log into your ISP modem, and find the setting to reserve an IP address, for the MAC Address of your Red Interface in IP Fire. Do it so that it is out of your DHCP range on your ISP Modem.

Example.
Set the DHCP Range on your modem from 192.168.1.2 to 192.168.1.240

Then that leaves you 241 to 254 - 13 addresses you can use as a manual assignment.

Heck, you only need 1 for your task, so that will be way more than enough.

Once the Modem Reboots, you should automatically have IPFires Red Interface polling for a connection. It would be at this time that the Modem sees the Static…Dynamic MAC address assignment for the IP you give Red0, which for example might be 192.168.1.241. This will keep you from having to deal with DHCP anything on your Red Interface.

21

Eric,

your explanation is only for a DOCSIS router ( with own NAT ). A real DOCSIS modem just passes through the communication with the DHCP server at the ISP ( modem works as bridge). The modem has its own local IP at 192.168.100.1 ( the net 192.168.100.0/24 is used by the modem’s DHCP server in case of failures on the cable side ).

My experience is, that the actual DHCP client ( dhcpcd ) in IPFire has some problems with DHCP servers not responding correctly to his requests and thus doesn’t notice a change in the assigned public IP address.

EDIT/UPDATE: This change of IP happened again this night. No internet connection. A
dhcpcd -k red0 ( release interface red0 )
dhcpcd -n red0 ( rebind interface red0 )
solved the issue.

22

I have the exact same issue - even a reboot of my Cable modem reproduces the issue and until I either reboot IPFire or restart the daemon it doesn’t reacquire the IP address from my ISP.

I’ve attached the relevant messages from last night when it happened.

Also, when this happens, I can’t even reboot IPFire correctly from the console - it simply hangs on trying to release the red0 IP address that it claims it lost (line 49 of the log).dhcp.000.log.gz (869 Bytes)

23

Just to close this out, I believe the update to Core Update 147 has fixed this issue for me. I did a little digging and found that there was an issue in dhcpcd that could have caused this, and that was resolved in version 9.1.2 (which was part of the 147 update).

After updating to 147, I attempted to reproduce the issue by disconnecting the RF cable from my cable modem, waited for the new internal IP to be assigned, and then reconnected it. Dhcpcd was able to handle the change in link status and re-request the external IP.

Thanks again to everyone who looked into this.

24

Im using IPFire 2.25 (x86_64) - Core Update 158 and Im having this issue. Sub par cable modem provider has equipment that goes down or has signal loss when it rains.
this causes my router to do the exact same thing. Ive been manually rebooting the whole thing until i found this thread on how to do the dhcp renew manually.

Im hoping that maybe an old bug got reintroduced for some reason? This is really annoying though. anyone else still having this issue with cable modems?

1 Like
25

Facing similar issues since I switched to cable. I wrote a small script and a cron check every 10 minutes. The script pings two domains and If none is reachable dhcpdc gets killed and started again.

IPs=(“bbc.com” “startpage.com”);
IPs_present=0;

for IPs in “${IPs[@]}”
do
ping -c 1 $IPs &>/dev/null && IPs_present=1
done

if [[ $IPs_present -eq 1 ]]; # Inet ok
then
exit
else # not ok
dhcpcd -k red0 # kill red
sleep 60
dhcpcd -n red0 # start red
exit
fi
fi
done
exit

1 Like
26

I’ve got a brand new ipfire installation (Core 162) and I had a power failure followed by a cable service outage thanks to some downed lines that helped me test automatic recovery. The bad news is that my red0 interface did not re-acquire any IP via DHCP after the cable modem re-acquired link.

Sequence of events:

  • power fails, so ipfire box and cable modem are off
  • power restored
  • cable modem turns on but can’t connect to the ISP because the line is down in the neighbourhood
  • ipfire turns on at the same time, and green network works fine, but because the bridged cable modem has no link to the ISP, no DHCP responses happen, of course
  • cable lines are repaired and the modem automatically comes online successfully (untouched)
  • ipfire red0 remains in the same state, without an IP assigned.
  • ipfire requires a reboot in order to retry a lease on red0

I run my cable modem in bridge mode and just switched to ipfire a couple of days ago after manually running a “normal” Linux system as a firewall for over 20 years. I’ve never had this problem with the isc-dhcp-server service in Debian which has handled many similar events for decades.

My symptoms seem the same as those in this thread, where the DHCP client service in ipfire just isn’t even (re-)trying to get a lease.

I haven’t customized ipfire at all other than normal things in the UI except for a tiny custom file in /etc/unbound/local.d/ to override some irrelevant DNS results.

I will see what other information I can gather.

1 Like
27

I didn’t see the logs for today at first because grep was skipping the rest of /var/log/messagesafter seeing some bytes that convinced it that it was a binary file. Anyway, I’ve overcome that and now I see what happened:

Jan 8 11:00:00 approximate time of power and cable service loss

Power restored, cable service not restored

Jan  8 12:12:17 fw dhcpcd[1793]: dhcpcd-9.4.1 starting
Jan  8 12:12:17 fw dhcpcd[1796]: DUID 00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
Jan  8 12:12:18 fw dhcpcd[1796]: red0: waiting for carrier
Jan  8 12:12:21 fw dhcpcd[1796]: red0: carrier acquired
Jan  8 12:12:21 fw dhcpcd[1796]: red0: IAID 14:a0:bc:eb
Jan  8 12:12:21 fw dhcpcd[1796]: red0: adding address fe80::227c:14ff:fea0:bceb
Jan  8 12:12:21 fw dhcpcd[1796]: ipv6_addaddr1: Permission denied
Jan  8 12:12:21 fw dhcpcd[1796]: red0: soliciting an IPv6 router
Jan  8 12:12:22 fw dhcpcd[1796]: red0: rebinding lease of $REDACTED_REAL_IP
Jan  8 12:12:27 fw dhcpcd[1796]: red0: DHCP lease expired
Jan  8 12:12:27 fw dhcpcd.exe[1842]: red0 has been brought down (EXPIRE)
Jan  8 12:12:28 fw dhcpcd[1796]: red0: soliciting a DHCP lease
Jan  8 12:12:49 fw dhcpcd[1796]: red0: carrier lost
Jan  8 12:12:49 fw dhcpcd.exe[2010]: red0 has been brought down (EXPIRE)
Jan  8 12:12:52 fw dhcpcd[1796]: red0: carrier acquired
Jan  8 12:12:52 fw dhcpcd[1796]: red0: IAID 14:a0:bc:eb
Jan  8 12:12:53 fw dhcpcd[1796]: red0: soliciting an IPv6 router
Jan  8 12:12:54 fw dhcpcd[1796]: red0: soliciting a DHCP lease
Jan  8 12:13:17 fw dhcpcd[1796]: red0: carrier lost
Jan  8 12:13:17 fw dhcpcd.exe[2186]: red0 has been brought down (EXPIRE)
Jan  8 12:13:18 fw dhcpcd[1796]: timed out

I manually reboot ipfire before cable service is back, trying to diagnose why there is no Internet.

Jan  8 12:53:43 fw dhcpcd[1729]: dhcpcd-9.4.1 starting
Jan  8 12:53:43 fw dhcpcd[1732]: DUID 00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
Jan  8 12:53:43 fw dhcpcd[1732]: red0: waiting for carrier
Jan  8 12:53:46 fw dhcpcd[1732]: red0: carrier acquired
Jan  8 12:53:46 fw dhcpcd[1732]: red0: IAID 14:a0:bc:eb
Jan  8 12:53:46 fw dhcpcd[1732]: red0: adding address fe80::227c:14ff:fea0:bceb
Jan  8 12:53:46 fw dhcpcd[1732]: ipv6_addaddr1: Permission denied
Jan  8 12:53:47 fw dhcpcd[1732]: red0: soliciting an IPv6 router
Jan  8 12:53:47 fw dhcpcd[1732]: red0: soliciting a DHCP lease
Jan  8 12:54:43 fw dhcpcd[1732]: timed out

It looks like dhcpcd just gives up after 60 seconds!

I rebooted the machine manually after I saw the cable modem had reacquired a link with the ISP.

Jan  8 15:08:12 fw dhcpcd[1733]: dhcpcd-9.4.1 starting
Jan  8 15:08:12 fw dhcpcd[1736]: DUID 00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
Jan  8 15:08:12 fw dhcpcd[1736]: red0: waiting for carrier
Jan  8 15:08:15 fw dhcpcd[1736]: red0: carrier acquired
Jan  8 15:08:15 fw dhcpcd[1736]: red0: IAID 14:a0:bc:eb
Jan  8 15:08:15 fw dhcpcd[1736]: red0: adding address fe80::227c:14ff:fea0:bceb
Jan  8 15:08:15 fw dhcpcd[1736]: ipv6_addaddr1: Permission denied
Jan  8 15:08:15 fw dhcpcd[1736]: red0: soliciting an IPv6 router
Jan  8 15:08:17 fw dhcpcd[1736]: red0: soliciting a DHCP lease
Jan  8 15:08:20 fw dhcpcd[1736]: red0: offered $REDACTED_REAL_IP from $REDACTED_REAL_DCHP_SERVER $REDACTED_DOMAIN
Jan  8 15:08:20 fw dhcpcd[1736]: red0: probing address $REDACTED_REAL_IP/20
Jan  8 15:08:25 fw dhcpcd[1736]: red0: leased $REDACTED_REAL_IP for 216000 seconds
Jan  8 15:08:25 fw dhcpcd[1736]: red0: adding route to $REDACTED_NETWORK/20
Jan  8 15:08:25 fw dhcpcd[1736]: red0: adding default route via $REDACTED_GW
Jan  8 15:08:25 fw dhcpcd.exe[1782]: red0 has been (re)configured with IP=$REDACTED_REAL_IP

The man page for dhcpcd (I can only find them for non-Linux systems) says:

     dhcpcd gets the host information (IP address, routes, etc) from a DHCP
     server and configures the network interface of the machine on which it is
     running.

...

     dhcpcd then daemonises
     and waits for the lease renewal time to lapse.  It will then attempt to
     renew its lease and reconfigure if the new lease changes when the lease
     begins to expire or the DHCP server sends a message to renew early.

...

     If any interface reports a working carrier then dhcpcd will try to obtain
     a lease before forking to the background, otherwise it will fork right
     away.  This behaviour can be modified with the -b, --background and -w,
     --waitip options.

According to this, invoking dhcpcd red0 asks dhcpcd to start, try to get a lease, and then only if it does, go into the background and try to renew it before it times out.

Based on the log contents and the observed behaviour, it seems like if it doesn’t get a lease within the first 60 seconds, it does not go into the background and keep trying!

I don’t quite understand why the daemon with the job of keeping the interface with an active DHCP lease would decide to not keep trying forever by default, but that certainly sounds like it’s the problem.

The options for fixing these seem to be:

  1. Add --timeout 0 so that it tries forever to get a lease. This certainly seems like what I (and most people) would want. However, it doesn’t seem like ipfire would expect this to take place in the foreground while its dhcpcd_start() function is running, so . . .

  2. Add both --timeout 0 and the --background flag to immediately background and keep trying forever. I think that ipfire is built to handle this judging by the check of $ip_address in dhcpcd_start().

So, I’ll give this a try and report back when I have a chance to test it properly.

1 Like
28

Hi @spencer

Welcome to the IPFire community.

dhcpcd is used on red to aquire dhcp info from the ISP.
It tries for 60 secs to get the dhcpnip address and then stops if it has been unsuccessful.
At that point you have to reboot ipfire to get it to try again.

Therefore before starting ipfire you need to ensure that your modem is connected to your ISP.

29

If you use timeout 0 then dhcpcd will stay there until your connection becomes available but that also means that the boot basically stops at that point so your system will effectively look like it has become unresponsive as there will be no messages while it waits for tge dhcp response from your ISP.

It will be interesting to see if going into tge background works or not. It wl depend on what else depends on dhcpd having made a connection.

1 Like
30

Hi. Thanks for the response!

Therefore before starting ipfire you need to ensure that your modem is connected to your ISP.

I agree that’s how things behave right now, but can you help me understand how that behaviour is useful?

Why should a person need to manually intervene to restore the network when the same result can be achieved through an entirely automated process? What harm is there in having red0 retry until it obtains its initial address?

Also, what happens if red0 loses its lease later? Does ipfire via dhcpcd keep trying to get it back? Or does it stop and require manual intervention then?

If you use timeout 0 then dhcpcd will stay there until your connection becomes available but that also means that the boot basically stops

This is why I think that adding both --timeout 0 and --background seems like it might produce the correct result. I don’t see why “I have a lease and will keep it alive” is any different than “I don’t have a lease yet and will keep trying” in terms of the lifecycle of red0 (and the boot process).

1 Like
31

Give it a try and see if it works. If it does and doesn’t break anything else then you can always submit a patch to the development mailing list.

I tried the timeout 0 setting in the past but not the background option.

1 Like
32

I will try it and if possible will submit something.

Do you happen to know if ipfire, as a whole, expects and monitors for changes in the red0 IP and handles them by updating all of its firewall rules with the new address?

33

No I don’t.

I think you will have to check the code to find that out unless someone else is able to say.

I think you should join the development mailing list and ask the question there.

https://wiki.ipfire.org/devel/mailing-lists

1 Like
34

One problem may be the behaviour of the modem.
If the modem cannot reach the CMTS it should go in ‘local mode’, handing out an IP of the ‘modem net’ ( 192.168.100.0/24 ) with an very short lease time <1min.
With a running modem there should be no timeout and through the short lease time the DHCP client ( IPFire ) should update his IP very quick after return of the DOCSIS connection.

So remains the timing problem at power up of both IPFire and modem. As it is configured now, the modem must be online 1 min after online state of IPFire.

35

If that can be done then that would be great. I am just not sure if the current structure of IPFire2.x allows that to be done without a large rewrite but I am not sufficiently knowledgeable to be able to figure that out.

If you are able to find a solution that can be implemented into IPFire 2.x then I think your efforts and results would be greatly appreciated.

Let us know how you get on with your investigations and if successful we will help, if needed, with pointers to the appropriate parts of the wiki for how to submit a patch to get your solution reviewed by the core devs and hopefully integrated into IPFire2.x :+1: :+1:

1 Like