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 rp-pppoe.so 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?
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.
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.
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.
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.
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.
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.
