No inbound traffic on DHCP RED


With the recent change to default firewall rules affecting PPPoE connections, and the fact that it takes forever to connect with PPPoE I have started trying to use DHCP instead.

I have fiber to the house.
My IPFire is running on physical hardware, not a virtual machine.
I’m running 2.27 core 176

When I set RED to use DHCP, I get a valid IP address, but NO inbound traffic.

Here is the log from the RED interface where I switched from PPPoE to DHCP and then back to PPPoE again.

12:20:16 dhcpcd[25631] : sending signal ALRM to pid 3597
12:20:16 dhcpcd[25631] : waiting for pid 3597 to exit
12:20:16 dhcpcd[3598] : received SIGALRM, releasing
12:20:16 dhcpcd[3598] : red0: removing interface
12:20:16 dhcpcd[3598] : red0: releasing lease of 75.***.246.200
12:20:16 dhcpcd[3598] : red0: deleting route to 75.***.240.0/21
12:20:16 dhcpcd[3598] : red0: deleting default route via 75.***.240.1
12:20:17 dhcpcd[3598] : main: control_stop: No such file or directory
12:20:17 dhcpcd[3598] : dhcpcd exited
12:20:19 dhcpcd[25971] : dhcpcd-10.0.1 starting
12:20:19 dhcpcd[25974] : DUID 00:01:00:01:2c:58:0d:54:00:::::**
12:20:19 dhcpcd[25974] : red0: waiting for carrier
12:20:22 dhcpcd[25974] : red0: carrier acquired
12:20:22 dhcpcd[25974] : red0: IAID b6:15:9b:f9
12:20:24 dhcpcd[25974] : red0: soliciting a DHCP lease
12:20:24 dhcpcd[25974] : red0: probing address 75.***.47.96/21
12:20:29 dhcpcd[25974] : red0: leased 75.***.47.96 for 3600 seconds
12:20:29 dhcpcd[25974] : red0: adding route to 75.***.40.0/21
12:20:29 dhcpcd[25974] : red0: adding default route via 75.***.40.1
12:30:36 dhcpcd[25974] : red0: carrier lost
12:30:36 dhcpcd[25974] : ps_bpf_recvbpf: unexpected event 0x0100
12:30:36 dhcpcd[25974] : red0: deleting route to 75.***.40.0/21
12:30:36 dhcpcd[25974] : red0: deleting default route via 75.***.40.1
12:30:37 pppd[28272]: Plugin loaded.
12:30:37 pppd[28272]: PPPoE plugin from pppd 2.4.9
12:30:37 pppd[28272]: pppd 2.4.9 started by root, uid 0
12:30:40 dhcpcd[25974] : red0: carrier acquired
12:30:40 dhcpcd[25974] : red0: IAID :::
12:30:41 dhcpcd[25974] : red0: rebinding lease of 75.***.47.96
12:30:46 dhcpcd[25974] : red0: probing address 75.***.47.96/21
12:30:51 dhcpcd[25974] : red0: leased 75.***.47.96 for 3600 seconds
12:30:51 dhcpcd[25974] : red0: adding route to 75.***.40.0/21
12:30:51 dhcpcd[25974] : red0: adding default route via 75.***.40.1
12:31:52 pppd[28272]: Timeout waiting for PADO packets
12:31:52 pppd[28272]: Unable to complete PPPoE Discovery
12:31:52 pppd[28272]: Exit.

All the asterisks were added for my protection. Can’t be too careful these days

If I disconnect the IPFire box from the ONT and plug my Ubuntu box in instead, and set my Ubuntu box to DHCP it connects immediatly, and works perfectly.

Where do I start looking for answers as to why DHCP on the RED interface on my IPFire box doesn’t work?


can you post the kernel logs from the Ubuntu machine?

Yes the dhcp connection logs from Ubuntu would be of interest.

Normally when ISP’s provide a PPPoE connection that same connection won’t work with DHCP because the PPPoE also has an Authentication process using PAP or CHAPS and that won’t be recognised or responded too by the dhcpc client on IPFire, nor would I expect it to be responded to by the Ubuntu system.
Normally with PPPoE, no authentication means no connection.

1 Like

There are exceptions from this. On newer access concentrators from the german telekom both modes (PPPoE via VLAN7 and DHCP) works but often you have to restart the modem to switch between the modes. The first try set the mode and also the mac address of the client are not changeable until repower the modem.


Thanks, I’ve learnt something new. Wasn’t aware of that. :+1:

My Swiss provider (INIT7) has also a time limit before the mac address can be changed. Should be 30 min if I remember correctly.

Not really much to see in the logs:

This is from my Ubuntu machine

redlance@redlance:/var/log$ cat syslog | grep -Ei ‘dhcp’
2023-08-14T12:37:40.593823-05:00 redlance NetworkManager[1198]: [1692034660.5937] dhcp: init: Using DHCP client ‘internal’
2023-08-14T12:37:40.761323-05:00 redlance dnsmasq[1468]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
2023-08-14T12:37:40.761347-05:00 redlance dnsmasq-dhcp[1468]: DHCP, IP range –, lease time 1h
2023-08-14T12:37:40.761371-05:00 redlance dnsmasq-dhcp[1468]: DHCP, sockets bound exclusively to interface virbr0
2023-08-14T12:37:40.761461-05:00 redlance dnsmasq-dhcp[1468]: read /var/lib/libvirt/dnsmasq/default.hostsfile
2023-08-14T09:41:01.462778-05:00 redlance NetworkManager[1198]: [1692024061.4627] dhcp4 (enp4s0): activation: beginning transaction (timeout in 45 seconds)
2023-08-14T09:41:03.678314-05:00 redlance NetworkManager[1198]: [1692024063.6780] dhcp4 (enp4s0): state changed new lease, address=75..243.183
2023-08-14T10:11:04.021247-05:00 redlance NetworkManager[1198]: [1692025864.0210] dhcp4 (enp4s0): state changed new lease, address=75.
2023-08-14T10:41:03.986343-05:00 redlance NetworkManager[1198]: [1692027663.9861] dhcp4 (enp4s0): state changed new lease, address=75.***.243.183
2023-08-14T11:04:24.138158-05:00 redlance NetworkManager[1198]: [1692029064.1381] dhcp4 (enp4s0): canceled DHCP transaction
2023-08-14T11:04:24.138201-05:00 redlance NetworkManager[1198]: [1692029064.1381] dhcp4 (enp4s0): activation: beginning transaction (timeout in 45 seconds)
2023-08-14T11:04:24.138240-05:00 redlance NetworkManager[1198]: [1692029064.1381] dhcp4 (enp4s0): state changed no lease

Should I be looking in a different log file? I tried the same command on kernlog and got nothing.
And again, I modified the IP address.

With Ubuntu were you able to actually access web sites on the internet via your browser.

The reason I ask is that you have the following section

which starts with “new lease, address …”

then there is a line with “canceled DHCP transaction”

and ends a fraction of a second later with “state changed no lease”

I would interpret this as having obtained a new lease then something cause the client to cancel the DHCP transaction and then the state changed to not having a lease.

On you ubuntu system can you check what IP it has assigned to enp4so and confirm if the above IP Address is actually assigned to it.
In IPFire that would be ip address show and doing a quick search on Ubuntu packages then at least from 20.04 to 23.04 all the ubuntu versions have iproute2 available so the same command should work as long as the package is installed by default.

@redlance might your CPE be a Mikrotik?

Yes, everything on my Ubuntu box worked perfect. Webpages, games, pings and the CLI version of speedtest.

I had to move the cable from the ONT back to the IPFire box so the rest of the household could use it. I’ll have to try verifying the IP address after I get home from work.

And my CPE is from Adtran

Okay, I did a little more testing this evening…

When I have the IPFire box set to DHCP on RED, I get a valid routable IP address.

From my green network, I can ping that IP address but NOT the gateway address associated with it.

If I ping from my cell phone, (I made sure it’s wifi was turned off) I could ping the gateway, but not the IP address given to my IPFire box’s RED interface.

But again, if I set it back to PPPOE it connects and traffic flows, but lots of stuff is very slow apparently due to the change to the firewall rules.

Oh, and I also noticed that IPFire is now up to core 179, but mine is still at 176 and apparently thinks there is no update…

At this point I am wondering if maybe I just need to download the latest and do a fresh install.

I finally seem to have this fixed.

I commented out the rapid-commit line in the dchpc.conf and now it works.

Still takes a long time to get an IP address, but now it is set to DHCP instead of PPPoE and it’s working fine.

I am using Windstream 1Gb fiber to the home.


Good that you have found a solution.

It shouldn’t be needed but a few ISP’s do configure their dhcp servers in ways that are not in line with the various dhcp RFC’s. There have been a couple of other posts in the past where the ISP just refused to send any dhcp offer communication unless that rapid-commit option was disabled.

For the rapid-commit option, if the ISP’s dhcp server had that option disabled then it would just ignore the client rapid-commit request and follow the standard 4-message request approach. This is defined in RFC4039 which was released back in 2005.

You could try and follow this up with your ISP, it depends on how they respond to bugs flagged by customers.