Re: dhclient cause up/down cycle after 239356 ?
On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote: BTW to jhb: Can you check your mailer's list configuration. You appear to be adding freebsd-current@freebsd.org and leaving curr...@freebsd.org in the Cc list. It's a feature of kmail that the kmail developers refuse to provide an option to disable. (It's due to the List-ID for our lists being freebsd-foo@, but the common usage of the lists being foo@. I usually remove the foo@ when replying, but sometimes miss it.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Wednesday, August 22, 2012 9:35:34 pm Peter Jeremy wrote: On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? Does anyone know why this issue doesn't bite OpenBSD? Does it have a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? To be clear, I don't like this hack. If there is a way to fix this in the driver (e.g. not report the link state changes during a reset) that would be far preferable. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
ok next round :) dhclient updated to Revision 239564 with fxp : Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1 Aug 22 20:06:50 home kernel: fxp0: link state changed to UP Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:06:55 home kernel: fxp0: link state changed to UP Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:03 home kernel: fxp0: link state changed to UP Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:09 home kernel: fxp0: link state changed to UP Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:15 home kernel: fxp0: link state changed to UP ifconfig show that iface doesn't loose ip adress but, link realy loosed (for example 10 from icmp pachets cannot reach destination) Yes, my problem easy fixed by changed ethernet card to em, but there are meny motherboard with integrated ether's... YongHyeon PYUN wrote: YP On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote: YP On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@ukr.net wrote: YP Look's like dhclient do down/up sequence - YP YP Not intentionally. YP YP Aug 21 19:21:00 home kernel: fxp0: link state changed to UP YP Aug 21 19:21:01 home kernel: fxp0: link state changed to DOWN YP Aug 21 19:21:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx YP Aug 21 19:21:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 YP Aug 21 19:21:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.xx YP Aug 21 19:21:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx YP Aug 21 19:21:03 home kernel: fxp0: link state changed to UP YP YP I can reproduce this behaviour - but only on fxp (i82559 in my case) YP NICs. My bge (BCM5750) and rl (RTL8139) NICs do not report the YP spurious DOWN/UP. (I don't normally run DHCP on any fxp interfaces, YP so I didn't see it during my testing). YP YP The problem appears to be the YP$IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up YP executed by /sbin/dhclient-script during PREINIT. This is making the YP fxp NIC reset the link (actually, assigning _any_ IP address to an fxp YP NIC causes it to reset the link). The post r239356 dhclient detects YP YP This comes from the hardware limitation. Assigning addresses will YP result in programming multicast filter and fxp(4) controllers YP require full controller reset to reprogram the multicast filter. YP YP the link going down and exits. YP YP Before r239356 iface just doing down/up without dhclient exit and YP everything work fine. YP YP For you, anyway. Failing to detect link down causes problems for me YP because my dhclient was not seeing my cable-modem resets and therefore YP failing to reacquire a DHCP lease. YP YP -- YP Peter Jeremy YP YP YP ___ YP freebsd-current@freebsd.org mailing list YP http://lists.freebsd.org/mailman/listinfo/freebsd-current YP To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Wednesday, August 22, 2012 1:28:22 pm Vitalij Satanivskij wrote:
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:15 home kernel: fxp0: link state changed to UP
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up events if they occur with 5 seconds of the link down event. The 5 is
hardcoded which is kind of yuck.
Index: dhcpd.h
===
--- dhcpd.h (revision 239564)
+++ dhcpd.h (working copy)
@@ -209,6 +209,7 @@
int dead;
u_int16_tindex;
int linkstat;
+ time_t linktime;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c (revision 239564)
+++ dhclient.c (working copy)
@@ -285,8 +285,14 @@
ifi-linkstat ? up : down,
linkstat ? up : down);
ifi-linkstat = linkstat;
- if (linkstat)
+
+ /*
+* XXX: Hardcoded 5 second grace window on
+* link flaps.
+*/
+ if (linkstat (cur_time - ifi-linktime) = 5)
state_reboot(ifi);
+ ifi-linktime = cur_time;
}
break;
case RTM_IFANNOUNCE:
@@ -441,6 +447,7 @@
fprintf(stderr, got link\n);
}
ifi-linkstat = 1;
+ ifi-linktime = cur_time;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
Ew. Be careful. Your admin may decide to change the VLAN you're on
(for example.) You definitely want to renegotiate your link state
then.
Adrian
On 22 August 2012 12:35, John Baldwin j...@freebsd.org wrote:
On Wednesday, August 22, 2012 1:28:22 pm Vitalij Satanivskij wrote:
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:15 home kernel: fxp0: link state changed to UP
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up events if they occur with 5 seconds of the link down event. The 5 is
hardcoded which is kind of yuck.
Index: dhcpd.h
===
--- dhcpd.h (revision 239564)
+++ dhcpd.h (working copy)
@@ -209,6 +209,7 @@
int dead;
u_int16_tindex;
int linkstat;
+ time_t linktime;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c (revision 239564)
+++ dhclient.c (working copy)
@@ -285,8 +285,14 @@
ifi-linkstat ? up : down,
linkstat ? up : down);
ifi-linkstat = linkstat;
- if (linkstat)
+
+ /*
+* XXX: Hardcoded 5 second grace window on
+* link flaps.
+*/
+ if (linkstat (cur_time - ifi-linktime) = 5)
state_reboot(ifi);
+ ifi-linktime = cur_time;
}
break;
case RTM_IFANNOUNCE:
@@ -441,6 +447,7 @@
fprintf(stderr, got link\n);
}
ifi-linkstat = 1;
+ ifi-linktime = cur_time;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? Does anyone know why this issue doesn't bite OpenBSD? Does it have a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? BTW to jhb: Can you check your mailer's list configuration. You appear to be adding freebsd-current@freebsd.org and leaving curr...@freebsd.org in the Cc list. -- Peter Jeremy pgp9SoqeQglFI.pgp Description: PGP signature
Re: dhclient cause up/down cycle after 239356 ?
On Aug 22, 2012, at 7:35 PM, Peter Jeremy wrote: On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? Does anyone know why this issue doesn't bite OpenBSD? Does it have a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? Speaking of fxp(4), can't it defer reporting link status changes during the reset sequence it must perform? Wouldn't it be better to fix the broken driver(s) to behave better than to add a twisty maze of hacks to dhclient? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Thu, Aug 23, 2012 at 11:35:34AM +1000, Peter Jeremy wrote: On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? FreeBSD used to blindly call driver's if_init() in ether_ioctl() whenever an IP address is assigned to interface. This results in calling foo_init in a driver such that controller/link reset happens after IP address assignment. I tried to fix many ethernet drivers in tree to ignore redundant foo_init() call by checking whether this foo_init() call is the very first time initialization of interface. Both NetBSD/OpenBSD seems to not call if_init() if the driver is already running. Because some controllers(e.g. fxp(4)) may require full controller reset to make multicast work, I couldn't follow their approach. I still don't know what other drivers except fxp(4) require full controller reset. There are too many old ethernet drivers I don't have access. Another reason why fxp(4) requires redundant controller reset is flow control support of the driver. Due to hardware limitation, MAC configuration for negotiated link's flow control parameters also requires controller reset. Does anyone know why this issue doesn't bite OpenBSD? Does it have I guess OpenBSD's fxp(4) has to reset controller to update multicast filter but it does not support flow control for fxp(4) yet so OpenBSD may see less number of link flips than that of FreeBSD. a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? BTW to jhb: Can you check your mailer's list configuration. You appear to be adding freebsd-current@freebsd.org and leaving curr...@freebsd.org in the Cc list. -- Peter Jeremy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij sa...@ukr.net wrote: Hi all, After last update my home machine begin doin some strange things - ... Try reverting r239356 -- if that works, then please let jhb@ know. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
Garrett Cooper wrote: GC On Tue, Aug 21, 2012 at 2:55 AM, Vitalij Satanivskij sa...@ukr.net wrote: GC Hi all, GC GC After last update my home machine begin doin some strange things - GC GC ... GC GC Try reverting r239356 -- if that works, then please let jhb@ know. GC -Garrett Yes i'm revert it and everything is ok. Look's like dhclient do down/up sequence - 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 and in r239356 when iface down dhclient exiting then iface become up, dhclient staring, get adress, bring iface down (why?) and exit. Before r239356 iface just doing down/up without dhclient exit and everything work fine. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dhclient cause up/down cycle after 239356 ?
On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@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 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 Jeremy pgptb9EOcZ9Yg.pgp Description: PGP signature
Re: dhclient cause up/down cycle after 239356 ?
On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote: On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@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 Jeremy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
