Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#7346 closed bug (fixed)

Incorrect DHCPClient behavior in some instances

Reported by: anevilyak Owned by: phoudoin
Priority: normal Milestone: R1
Component: Servers/net_server Version: R1/Development
Keywords: Cc: umccullough, black.belt.jimmy@…, modeenf
Blocked By: Blocking: #6970, #7380
Platform: All

Description

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.

Attachments (1)

net_server.patch​ (8.4 KB ) - added by phoudoin 14 years ago.
Improved patch, which move the logic in DHCPClient, not in AutoconfigLooper.

Download all attachments as: .zip

Change History (22)

comment:1 by anevilyak, 14 years ago

Blocking: 7380 added

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

comment:2 by umccullough, 14 years ago

Cc: umccullough added

Is this essentially a duplicate of enhancement request #6970 ?

We can close that one if this one is more accurate :)

Last edited 14 years ago by umccullough (previous) (diff)

comment:3 by axeld, 14 years ago

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.

comment:4 by axeld, 14 years ago

Blocking: 6970 added

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

comment:5 by bbjimmy, 14 years ago

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

comment:6 by bbjimmy, 14 years ago

Cc: black.belt.jimmy@… added

comment:7 by phoudoin, 14 years ago

patch: 0 → 1

comment:8 by phoudoin, 14 years ago

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.

comment:9 by bbjimmy, 14 years ago

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?

by phoudoin, 14 years ago

Attachment: net_server.patch​ added

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

comment:10 by phoudoin, 14 years ago

The patch was made against hrev41279.

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

patch < net_server.patch

comment:11 by phoudoin, 14 years ago

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

in reply to:  8 ; comment:12 by anevilyak, 14 years ago

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!

in reply to:  12 comment:13 by anevilyak, 14 years ago

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?

comment:14 by phoudoin, 14 years ago

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?

in reply to:  14 ; comment:15 by anevilyak, 14 years ago

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.

in reply to:  15 comment:16 by phoudoin, 14 years ago

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.

comment:17 by phoudoin, 14 years ago

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.

comment:18 by modeenf, 14 years ago

Cc: modeenf added

comment:19 by phoudoin, 14 years ago

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.

comment:20 by phoudoin, 14 years ago

Resolution: → fixed
Status: new → closed

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.

comment:21 by deejam, 13 years ago

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

Note: See TracTickets for help on using tickets.