Re: HEADSUP: OpenBSD dhclient incoming

From: Marcin Jessa <lists_at_yazzy.org>
Date: Thu, 16 Jun 2005 09:34:29 +0200
On Wed, 15 Jun 2005 22:55:56 -0700
Sam Leffler <sam_at_errno.com> wrote:

> M. Warner Losh wrote:
> > In message: <20050615061009.GA11914_at_odin.ac.hmc.edu>
> >             Brooks Davis <brooks_at_one-eyed-alien.net> writes:
> > : On Wed, Jun 15, 2005 at 07:42:48AM +0400, Vladimir Grebenschikov wrote:
> > : > ? ??, 14/06/2005 ? 20:57 -0400, Matthew Emmerton ?????:
> > : > > On Tue, 14 Jun 2005, Brooks Davis wrote:
> > : > > 
> > : > > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote:
> > : > > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????:
> > : > > >>> I'm about to start importing the OpenBSD dhclient and required
> > : > > >>> support in /etc.  I will unhook dhclient from the build while I work so
> > : > > >>> there shouldn't be much breakage for most people
> > : > > >>
> > : > > >> I have strange behavior of new dhclient + devd:
> > : > > >>
> > : > > >> just after boot (with ethernet plugged) I have no devd events about
> > : > > >> state of media and have interface down, but after first ifconfig (even
> > : > > >> without parameters, even executed by any user) "link state chages to UP"
> > : > > >> event appears and devd starts dhclient on interface.
> > : > > >>
> > : > > >> I do not think that it is desired behavior.
> > : > > >>
> > : > > >> my rc.conf, related to this:
> > : > > >>
> > : > > >> ifconfig_fxp0="dhcp"
> > : > > >> network_interfaces="lo0"
> > : > > >> devd_enable="YES"
> > : > > >>
> > : > > >> Probably I need to comment network_interfaces line, but anyway, now it
> > : > > >> works strange.
> > : > > 
> > : > > Shouldn't you have network_interfaces="lo0 fxp0" in order for the rc 
> > : > > scripts to run the appropriate ifconfig or dhclient command for each 
> > : > > interface?
> > : > 
> > : > Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=0
> > : > triggers dhclient ?
> > : > 
> > : > I think behavior should be consistent, either rc.d/netif relay only on
> > : > devd events and does not depends on network_interfaces= or rc.d/netif
> > : > should relay on network_interfaces= and ignore not mentioned interfaces.
> > : > 
> > : > Also devd's IFUP event should not depend on user's /bin/ifconfig issued
> > : > (or not issued) by hands.
> > : 
> > : There are two issues here.  First, if we're going to keep
> > : network_interfaces around, /etc/rc.d/dhclient should honor it and
> > : not start dhclient on interfaces not in either network_interfaces or
> > : removable interfaces.  Second, running ifconfig should not be triggering
> > : link events.  That makes no sense.  I'll have to see if can replicate
> > : that, I'm a bit dubious.
> > 
> > ifconfig fxp0 1.2.3.4/24
> > 
> > will kill dhclient every time for me.
> 
> There are several drivers that have issues with reliably generating LINK 
> state up/down events.  The bge driver does not work right for me with a 
> 5704 (I think) part--the gige part in my Dell 600m.  I tried discussing 
> this this with wpaul but he's out of touch these days.
> 
> > 
> > I've also been seeing weirdness with the new dhclient when i move from
> > network to network on boot when I have the 'old' lease around but no
> > cable connected.  I'll see if I can replicate this enough to submit a
> > report.
> 
> I've noticed one issue.  If you mark an interface down then dhclient 
> exits but any assigned ip address is not removed.  This is a change from 
> the previous dhclient and something I thought I'd fixed (but clearly 
> not).  OTOH brooks pointed out that leaving the ip address around means 
> tcp sessions don't immediately die so if you reconnect and reacquire the 
> same lease your sessions can be revived if they were idle.
> 
> 	Sam
> 

One small thing. 
Pressing CTR+C during boot to stop dhclient not only stops it but prevents system from assigning any other IP's, loopback included.
 
Received on Thu Jun 16 2005 - 05:34:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC