I have a small server/wifi-router (an old notebook) that gets a global IP assigned via DHCP from my ISP.
As a postup action (and also every 10 minutes via cron) a script is run which sends me an email if the assigned IP has changed.
This setup should theoretically make it a poor-man's server/router, but even though dhcpcd renews the lease a few times, after some time it fails and cannot rebind.
I cannot remember the scipt notifying me of IP change, so I suspect the DHCP server refuses to assign me a different IP because I haven't disconnected before the request (which would be the standard use case most likely).

in /etc/conf.d/net and the default /etc/dhcpcd.conf. I think the main problem is that the package form my ISP is for simple net access, it's not expecting a computer to be connected all the time. But maybe some dhcpcd option could make it communicate better.

As for the script approach, I was wondering if I could hook it into the postdown action. The thing is that I'm not sure if dhcpcd failing will count as a down action.

Most dhcp servers will rarely change a client's address, particularly if it is continuously connected (connected often enough that it's lease doesn't expire). Depending on expectations of client turnover, most are configured to issue leases lasting a day or so. Dhcp clients normally run in a mode that will automatically renew the lease without any user intervention.

To see whether your dhcp client is actually running, let's see the output of:

Code:

pgrep -l dh

Maybe you should also post the contents of this script you're running.

Additionally, explain more clearly why you think you have a problem. Also, what is your need to know that your address has changed?

Most DHCP servers do what you say, but this one doesn't, upon reboot I often get a new IP which is why I made that script that informs of the new address so I could ssh into my server from far away.

dhcpcd runs fine, renews the leases a couple of time times and then after some time (days or weeks usually) cannot renew or rebind. It's this moment that I'm trying to troubleshoot. Either I could find some dhcpcd option to enable/disable or at least make a script that would try to restart or retry dhcpcd on this occasion.

I've been using dhcpcd for years on several of my machines and have never observed what you describe.

You say this is on a home-made router? Are you running a firewall you configured yourself? If so, have you considered whether you may be blocking dhcp communication to the dhcp server? This is not as trivial a question as it may seem. For example, some ISPs use private IPV4 addressing for their hardware, and if you are blocking external communication to the private address space (in accordance with RFC 1918), then your DHCP client would be able to initially get an address, but not renew it. This might not become apparent for some time, because the lease would first have to expire, and the some DHCP clients fall back to just continuing to use the address and attempting to send dhcp-notify messages. Or, they may attempt to use ARP to test whether anybody is using the address, and then continue to use it if nobody is.

So I would look closely at the firewall, after reviewing what protocols and communication modes (i.e., broadcast vs unicast) DHCP uses at various stages of operation. You may also want to look at the dhcpcd documentation, to see how it handles being unable to get an acknowledgement from the server.

I had a problem with dhcp recently where I'd misconfigured the client. It would get
an IP, renew it a few times, and then fail to renew and renegotiate. The renegotiation
would produce a new IP (since the server thought the old one was still in use) and
the device would continue to shuffle between the two IPs.

No misconfiguration here, it's the default configuration.
Just to be sure, here's /etc/dhcpcd.conf:

Code:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Inform the DHCP server of our hostname for DDNS.
hostname
# To share the DHCP lease across OSX and Windows a ClientID is needed.
# Enabling this may get a different lease than the kernel DHCP client.
# Some upstream DHCP servers may also require a ClientID, such as FRITZ!Box.
#clientid

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

# dhcpcd ebuild requested no zeroconf
noipv4ll

The iptables firewall is indeed configured by me, but I have

Code:

iptables -P OUTPUT ACCEPT

Yeah, I'm lazy.

And dhcpcd renews the lease successfully many times, but after some time it just fails.

So either I find some configuration option, or I find a mechanism (something like postdown, but dhcpcd not being able to renew is not detected as interface down by OpenRC) that would enable me do some stuff once dhcpcd fails to rebind (e.g. restart net.ethernet0)

1. Your firewall could still be blocking traffic from the DHCP server.

2. Did you ever run that command I asked to run?

Code:

pgrep -l dh

This may seem silly, but the reason I asked you to run it is because you may not actually be running dhcpcd, even though it's installed. At some point in time, my home-made router started ignoring the presence of dhclient and instead running udhcp. I didn't think I needed a 'modules' entry in /etc/conf.d/net specifying which dhcp client I wanted to use, because I believed I had only one installed. At some point in time this became untrue, with the default busybox configuration including udhcp (either that or openrc's order of preference changed, and udhcp was moved above dhclient).

Now, dhcpcd is, I believe, Gentoo's preferred dhcp client, so maybe it's at the top of the preference hierarchy and this doesn't matter, but it still would not hurt to check and see which dhcp client is actually running.

3. Other troubleshooting:

a. Do you have dhcp going to its own log and have you reviewed it, or have you grepped your consolidated log to see what the logs say is going on? You may be able to increase dhcpcd's log level in its config file. I believe you may also be able to start dhcpcd in foreground mode from a terminal so you can observe its activity.

b. Another thing you could do is configure your firewall to log all dhcp packets, so you can get an idea of what's going on, (or better yet, if you're familiar with it, set up wireshark (tcpdump on the router, governed by wireshark on your desktop) to capture just dhcp traffic in such a way you can actually inspect it).

c. Try installing a different dhcp client and see if it has the same trouble (this would help you determine whether you dhcp client is the problem).

As I said, dhcpcd works as expected for several days, so the firewall isn't blocking it. I'm aware of the dhcp client modules, I'm certain it's dhcpcd (in htop) and I had the respective modules variable set up. I actually installed dhcpcd, because I thought udhcp wasn't enough.

I only checked /var/log/messages which seemed to show that dhcpcd couldn't renew (usually around midnight) and rebinding also failed. I'll add --debug.

On another note, is it possible that a running emerge could decrease the firewall routing abilities (iptables based)?

As I said, dhcpcd works as expected for several days, so the firewall isn't blocking it.

As I said, the fact that your computer has a valid IP address and nothing is complaining loudly does not mean your firewall isn't blocking it. Dhcp clients are designed to be robust, and do things like assert they are using an existing lease or even a previous one (ask forgiveness not permission). But let's assume you've checked the actual traffic and log entries and are sure that dhcp transactions are being fully completed well after the firewall is up and running (transactions such as lease renewal).

Is the ISP's dhcp server an IANA private address? As I recall, dhcpcd stores its leases in binary format, so you can't tell from that, but you should be able to tell from the dhcp and/or firewall logs.

smartass wrote:

I'm aware of the dhcp client modules, I'm certain it's dhcpcd (in htop) and I had the respective modules variable set up. I actually installed dhcpcd, because I thought udhcp wasn't enough.

Okay, that rules that out. You had only mentioned your config_ethernet0="dhcp" entry.

smartass wrote:

I only checked /var/log/messages which seemed to show that dhcpcd couldn't renew (usually around midnight) and rebinding also failed. I'll add --debug.

Yeah, that's probably a a good next step. You might want to configure a separate dhcp.log file or run some grep commands to get a bigger picture of what's going on. Also, you might check bugzilla to see if anyone else has reported similar issues.

smartass wrote:

On another note, is it possible that a running emerge could decrease the firewall routing abilities (iptables based)?

Effectively, no (unless you're doing something unlikely that's bringing it to its knees). In any case, I think the emerge should stall before the firewall is impacted, because emerge is niced. I've never seen any indications of this my own router (Pentium III uniprocessor with only 192 MiB of RAM). If you suspect this is a problem, you could adjust the PORTAGE_NICENESS value, although I don't think it's necessary.

What I meant is that I see dhcpcd renewing the leases in the log over the course of days.

I would say this pretty much rules out a firewall problem, and it suggests the problem is not on your end, or that there is indeed some kind of bug with dhcpcd.

smartass wrote:

The ISP's dhcp server is indeed within 10.0.0.0/8. So what could that mean?

Just that, in troubleshooting potential firewall problems you would want to verify that rules intended to protect you against certain kinds of attacks by blocking inbound traffic from private address spaces are not blocking dhcp traffic. I think given that we've now confirmed that your dhcp client is in fact successfully renewing its lease, we can probably rule that out. However, you might still want to look at the dhcp log entries at 'debug' level and make sure the transactions are fully completing (i.e., two-way mutual exchange of information, acknowledgments, etc., and that the client is not simply asserting that the lease is renewed).

smartass wrote:

By "doing wrong" you meant what ?

I mean like putting something silly in PORTAGE_NICENESS in an attempt to get it to "go faster", trying to emerge something you don't have enough RAM or /var/tmp/portage space to emerge, and that sort of thing. As I said, I don't think this is your problem.

At this point, I think I'd probably try the following:

1. check bugzilla to see if anyone else has reported similar issues

2. temporarily replace dhcpcd with something else to see if the problem persists (as a means of possibly ruling out dhcpcd as the problem)

smartass wrote:

Thx for all the help so far btw.

You're welcome. I don't think I know any more about this than you do, but sometimes it's helpful just to get another person's perspective.

Interesting, for the past ~3 weeks minus this one, suddenly every couple of nights my net dropped out (but all other machines had working net?!), I couldn't even get in to my router at 192.168.0.1 when this happened. Trying to restart dhcpcd wouldn't fix it, even after powering down the machine and back on still no connection. I ended up having to power off&on my router (netgear) to be able to get net back on this machine.

My solution so far has been that I have switched back to using net.lo/net.etho and even a static ip (didn't use static before using dhcpcd but I thought "why not" while I was at it), I removed dhcpcd completely and haven't had any issues in 5 days now.
I couldn't seem find anyone with even a similar sounding problem till seeing this, although now I'm not interested in trying to fix it. I also got a new IP each boot and was using default configuration like yourself, smartass.

Here is another interesting aspect of the use of private addressing by ISPs. The unicast communication used by dhcp doesn't work well in this situation.

Some dhcp servers (Windows Server, for example), will not respond to unicast dhcp request messages if the server's address is outside the subnets it is allocating. Apparently this is a common problem. The dhcp client in newer versions of windows is set up to only use broadcast requests.

Similarly, outbound traffic to private address space is typically blackholed. if the ISP has not set up unicast routing to handle traffic coming from customers intended for its privately-addressed servers, these packets will simply be dropped. So how does dhcp keep working in such a scenario?

In such a case, a normal dhcp client will operate until it's "renew" time (here is a diagram), then start trying to renew every so often (this may be a frequent operation, like every 30 seconds, spamming your log, and then probably at a gradually decreasing interval). Depending on how it's configured, it may continue these right up to "rebind" time, it may fail out, or it may simply continue to use the current address. If it doesn't fail trying to renew, it will next reach its "rebind" time, at which time it sends a broadcast message.

The broadcast message is handled by a dhcp relay on the same layer 2 network as the client, so this then succeeds.

You wouldn't know if this were happening unless you reviewed your dhcp logs. I don't know if linux dhcp clients can be configured to only send broadcast requests. I don't know how dhcpcd behaves in this regard (I use dhcpcd internally and dhclient externally). I do know that dhclient's behavior matches what I've described above.

The more thorough logging over night didn't show anything suspicious. dhcpcd attempts to renew lease, sends a request, server responds and acknowledges. Everything looks ok. I expect trouble in several days/weeks when the ISP's server decides I've had this IP for too long (that's how I interpret it).

BoneKracker wrote:

... In such a case, a normal dhcp client will operate until it's "renew" time (here is a diagram), then start trying to renew every so often (this may be a frequent operation, like every 30 seconds, spamming your log, and then probably at a gradually decreasing interval). Depending on how it's configured, it may continue these right up to "rebind" time, it may fail out, or it may simply continue to use the current address. If it doesn't fail trying to renew, it will next reach its "rebind" time, at which time it sends a broadcast message.

This sounds promising. I didn't see anything like that in the configuration of dhcpcd.