yes. The hypothesis being back at the provider, which could be blacklisting or making other DHCP leases incomplete. Maybe even the hostname of IPFire should be the same of your laptop as well?
CFUSCO - tried the mod of the MAC address to no avail. Just noticed the following, however:
When my hostname updated from IPFIRE.aude.home to the correct upstream hostname, here is what was logged - Unique BTW to this event:
|11:05:02|dhcpcd[3789]|: red0: failed to renew DHCP, rebinding|
|11:05:02|dhcpcd[3789]|: red0: leased 208.102.183.36 for 3600 seconds|
Curious what this means - failed to renew, then rebinding. Is the rebinding something I can force?
This message I know from my provider. Seems sometimes the DHCP server isn’t able/eager to handle RENEW. Don’t knpw why. It is gone momths ago. 
2 Likes
Greetings,
I am having the same issue with my IPFire and my recent fiber connection. Windstream is my provider. I’m now running Core Update 174. The technician was just here yesterday to look into slow speeds. He left a different modem. I went into the setup for that modem and it was set to use IPoE and had VLAN turned off.
IPoE is also known as simply DHCP. I had been using PPPoE as I was previously told I need to use my credentials to log in. The technician said I don’t need to use PPPoE. I set my IPFire box to DHCP and got a valid IP address, but no traffic would pass. I didn’t really see any errors in the logs. If I set it back to PPPoE, it works, but still not until the hostname updates.
I really wish we could figure this out.
I tried changing the settings in the dhcpcd.conf but that didn’t work either…
You cannot ping the provider gateway? In any case, my first hypothesis in these situations is always to assume a MAC address binding from the provider side. If you change router from your provider to your IPFire machine, the MAC address of the network interface of your provider’s modem could be bound to the IP address you are supposed to receive and therefore failing to renegotiate. For example, my provider has a certain embargo time before allowing a new DHCP negotiation with a different MAC address.
Keep in mind that with IPoE there is no exchange of credentials, therefore the only way for your provider to know that it is you knocking at their door is a table storing the MAC address. I would clarify with them if/when you can change MAC address or in alternative, you could try to spoof in IPFire the MAC address of the provider’s modem.
In my provider case, if I intend to change MAC address, I need to switch off the router for a time longer than their embargo. After, I can switch on my new router and I can correctly negotiate a new DHCP session.
2 Likes
Hmmm, I haven’t tried to ping the upstream gateway. I just know that no traffic will flow until the hostname resolves into the dynamicly assigned reverse DNS name for whatever IP address they gave me. Once that updates, traffic flows fine. But sometimes it takes hours to update, sometimes it only takes a few minutes. But I always get a valid IP address right away, it’s just the hostname that is wrong.
Thanks for the help!
When I have the chance, I will test the --noarp argument.
Brian -
We share the same experience. No traffic will flow for me either, and as I noted in my RED log (posted above), it appears that there is a pattern when the host name finally sets.
I wish I could peek into the chatter between IPFire RED0 and my ISP to see what is going on. When I call the ISP they tell me everything ‘looks good’ on their end - which I have to believe it does - but are not able to help me dig deeper.
Does anyone know how to run a trace or look at this handshake in a log? Happy to instigate this issue on my network and share the findings here.
This issue persists for me with Altafiber. A bit more detail -
This pattern - seen below - can be observed when the HOSTNAME on my IPFIre device RED0 does not update. Note the failure to renew DHCP, rebind request as the start. The very next log item is a negative ack - NAK.
| 18:00:03 | dhcpcd[3785] | : red0: failed to renew DHCP, rebinding |
|---|---|---|
| 18:00:03 | dhcpcd[3785] | : red0: NAK: from 10.2.2.128 |
| 18:00:03 | dhcpcd[3785] | : red0: deleting route to 208.102.243.0/24 |
| 18:00:03 | dhcpcd[3785] | : red0: deleting default route via 208.102.243.1 |
| 18:00:14 | dhcpcd[3785] | : red0: soliciting a DHCP lease |
| 18:00:14 | dhcpcd[3785] | : red0: probing address 74.215.41.11/20 |
| 18:00:18 | dhcpcd[3785] | : red0: leased 74.215.41.11 for 3600 seconds |
| 18:00:18 | dhcpcd[3785] | : red0: adding route to 74.215.32.0/20 |
| 18:00:18 | dhcpcd[3785] | : red0: adding default route via 74.215.32.1 |
This pattern - shown here - is what occurs when the HOSTNAME successfully updates:
| 00:10:03 | dhcpcd[3789] | : red0: failed to renew DHCP, rebinding |
|---|---|---|
| 00:10:03 | dhcpcd[3789] | : red0: leased 208.102.182.44 for 3600 seconds |
I’m not sure what these two log entries indicate, since these two log entries are listed above as well. That said, it appears there may be an issue with the NAK response - perhaps this is the issue?
Any thoughts are welcomed. Would very much like to get this resolved!
There are some peculiar entries in that log.
This means that IPFire’s dhcpcd received a Not AcKnowledged signal from 10.2.2.128
NAK usually means that the info was received with errors or otherwise unreadable.
The interesting thing is that you are getting that message on your red connection from a private address range that is clearly not your ISP. Do you have another machine connected on the red side that has the private address of 10.2.2.128 and is running a dhcp server?
Then you have
This is IPFire doliciting a dhcp lease and being given one - 74.215.41.11
You say that in this mode it is not working.
The working connection has
This connection works but with a totally different public IP of 208.102.182.44
Is your ISP supplying you a connection with two public routable IP’s?
1 Like
Thank you for the reply - and great questions! My setup is rather simple -
Altafiber ↔ ONT ↔ RED0 IPFire.
Nothing in-between ONT and IPFire.
In terms of the two routable IPs - great question. Each time I call they ask if I have a modem, and I describe my setup. They can see my RealTek LAN card and they also indicate that ‘everything is working’ on the ONT.
That is very simple. I also have the same setup (but with a different ISP).
The two routable IP’s are part of the same ISP IP range so it might depend on what gets offered by the ISP’s dhcp server.
In your earlier screen shot you had the non-working period with an IP of 72.49.246.182 and a gateway of 72.49.246.1
When you have the working connection with an IP of 208.102.182.44 what gateway do you have.
When you have a connection that is not working properly (no internet browsing) do you get an response if you ping the gateway IP?
Incidentally the failed to renew, rebinding message is that when the lease time gets to 50% of its defined length (3600 seconds) then dhcpcd will request a renewal. Normally the lease will be extended. If no response comes back then dhcpcd asks the same renewal question again until a certain time period has passed without getting any response. At that point it will rebind with the previous IP it had and try to continue with that.
My searching on getting that message suggests that this indicates a dhcp server (at your ISP) that is not configured properly or an overloaded dhcp server.
I will try and have a look through the dhcpcd config file and see if there is any option that might be worth testing with some different value.
2 Likes
Thanks Adolf.
The gateway that seems to work is shown below - 208.102.176.1
When things are not working properly, my IPFIre hostname is IPFIRE.aude.home. When it is working properly, I have a hostname provided by the ISP.
What I’m perplexed by is that if I wait (in the case of last night, over 4 hours), this all resolves on its own.
Having two gateways from the same ISP seems a bit peculiar but I am not knowledgeable enough to know if that might cause you the problems you are seeing or not.
The option settings in the dhcpcd.conf file are all ones that should not cause any problems if the ISP is using an RFC standards compliant dhcp server.
Other people on this forum have had problems where they have had to change some of the options because their ISP responded incorrectly to those options.
I would propose that you change all the options I will list to see if that solves the problem. If it does then you can change the options back one by one till you find the one causing the problem. It would be best to only modify the option(s) required to make the connection work consistently.
If the problem still persists with all the changes I will suggest then I am not sure of where to go from here. Hopefully other people have some additional ideas in that case.
The file to change is /var/ipfire/dhcpc/dhcpcd.conf
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
Comment out duid and uncomment clientid.
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
Comment out option rapid_commit. This caused a problem for someone else, even though it should be safe to use according to the comment.
# A ServerID is required by RFC2131.
require dhcp_server_identifier
Comment out require dhcp_server_identifier
When all the changes are made then you will need to run
Before running the above it would be good to have tail -f /var/log/dhcpcd.log run in another terminal window. Then when you run the above commands you can see in the other window what is getting into the dhcpcd logs as it occurs and see if everything works okay or if there is some error message indicating one of those options I suggested can’t be modified.
3 Likes