Incorrect DHCPClient behavior in some instances

[anevilyak]

If DHCPClient detects a media change on an interface (i.e. unplugging/replugging the ethernet cable), it issues a release/discover. Depending on the server, this can result in losing the IP you last had, which probably isn't a desired outcome. It should just issue a dhcprequest in that instance instead.

[anevilyak]

(In #7380) Indeed the same problem, closing as a duplicate.

[umccullough]

Is this essentially a duplicate of enhancement request #6970 ?

[axeld]

It's been some weeks again since I read the specs, but IIRC the current behaviour is a bug rather than a missing feature. It's about the same thing, though, so I'm going to close it.

[axeld]

(In #6970) This is actually a bug that is now tracked in #7346.

[bbjimmy]

This looks like what I reported in ticket #6455 that was hever fixed, just closed and marked fixed.

[phoudoin]

The patch is not ready for commit yet (not yet code style policied either), but shared here to allow people to test it on far more DHCP network configurations than mine.

[bbjimmy]

I do not know how to apply the patch to test. I can use jam and svn build the tree, but how does one apply a patch?

[phoudoin]

Improved patch, which move the logic in DHCPClient, not in AutoconfigLooper.

[phoudoin]

The patch was made against hrev41279.

To apply it, bbjimmy, download it directly in src/servers/net and then:

patch < net_server.patch

[phoudoin]

I just reproduce your issue bbjimmy, and this patch don't fix it. It's another problem, that I'll track down ASAP.

[anevilyak]

Replying to phoudoin:

The patch is not ready for commit yet (not yet code style policied either), but shared here to allow people to test it on far more DHCP network configurations than mine.

Appears to work nicely with my Linksys router running DD-WRT. Thanks!

[anevilyak]

Replying to anevilyak:

Appears to work nicely with my Linksys router running DD-WRT. Thanks!

Actually, now that I've had it running a little longer, one anomaly, DHCPREQUEST appears to get sent far more often than it should/needs to be, unless I misunderstood something in the spec. The parameters we get from the dhcp lease are:

lease time: 86400 seconds
renewal time: 43200 seconds
rebinding time: 75600 seconds

However, according to syslog, literally hundreds of requests have been sent in the past day or so. Shouldn't those only get sent as often as either the renewal or rebinding time, or am I misunderstanding something?

[phoudoin]

Ideally, you should have indeed one DHCPREQUEST every renewal time, aka 2 per day in your case.

Either I broke the timer or something else make many DHCPREQUEST failed to get a reply before it send another one. Or I break it somewhere else in recent changes made to src/servers/net/*

Previously, does this misbehavior was observed too?

Could you post (or send me if concerned whith privacy) your syslog? I guess you test the latest patch, right?

[anevilyak]

Replying to phoudoin:

Previously, does this misbehavior was observed too?

Were we ever sending DHCPREQUEST before? I'd have to revert and check in any case.

Could you post (or send me if concerned whith privacy) your syslog?

I can, but it doesn't really show anything interesting from what I've seen, it just says daemon (dhcp) sending DHCPREQUEST and then last message repeated 47 times or whatnot followed by other data (i.e. occasional usb port errors triggered by my keyboard). There isn't really any pattern to it that I can see beyond that though.

I guess you test the latest patch, right?

Yes.

[phoudoin]

I guess you test the latest patch, right?

Yes.

Sure. But I got hit by Trac's attachement duplicate patch names bug. Sorry. I'll upload the new one ASAP.

[phoudoin]

I don't have the latest patch on my office computer, so it wont be before I'm back home. Best ETOA : in 8 hours.

[phoudoin]

turns out I'm simply wrong, the patch available is the second one. So, back to square one: without futher info I can't explain why you see such quick renewal period.

[phoudoin]

Fixed in hrev41285.

After 6 days with extensive forced DHCP reconfiguration, link unplug/replug and different lease time (forever, 1 hour, 3 minutes), I didn't detect any regression. One could always re-open if he find some.

[deejam]

I can confirm that this did fix my issues reported in #7380. Great work!