On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote: > On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij <satan_at_ukr.net> wrote: > >Look's like dhclient do down/up sequence - > > Not intentionally. > > >Aug 21 19:21:00 home kernel: fxp0: link state changed to UP > >Aug 21 19:21:01 home kernel: fxp0: link state changed to DOWN > >Aug 21 19:21:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx > >Aug 21 19:21:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 > >Aug 21 19:21:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.xx > >Aug 21 19:21:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx > >Aug 21 19:21:03 home kernel: fxp0: link state changed to UP > > I can reproduce this behaviour - but only on fxp (i82559 in my case) > NICs. My bge (BCM5750) and rl (RTL8139) NICs do not report the > spurious DOWN/UP. (I don't normally run DHCP on any fxp interfaces, > so I didn't see it during my testing). > > The problem appears to be the > $IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up > executed by /sbin/dhclient-script during PREINIT. This is making the > fxp NIC reset the link (actually, assigning _any_ IP address to an fxp > NIC causes it to reset the link). The post r239356 dhclient detects This comes from the hardware limitation. Assigning addresses will result in programming multicast filter and fxp(4) controllers require full controller reset to reprogram the multicast filter. > the link going down and exits. > > >Before r239356 iface just doing down/up without dhclient exit and > >everything work fine. > > For you, anyway. Failing to detect link down causes problems for me > because my dhclient was not seeing my cable-modem resets and therefore > failing to reacquire a DHCP lease. > > -- > Peter JeremyReceived on Tue Aug 21 2012 - 23:13:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC