Bug#537271: closed by Matthew Palmer mpal...@debian.org
clone 537271 -1 reassign -1 busybox block 537271 by -1 thanks Quoting Matthew Palmer (mpal...@debian.org): As you have identified: On Sun, Feb 06, 2011 at 10:15:48PM -0500, Robert Edmonds wrote: (this should probably actually be a loop that repeatedly invokes arping with a short timeout in order to update the progress bar.) This really needs to be implemented. Leaving users hanging with no clue as to what's happening for 45 seconds isn't right. I've left the patch tag on the bug for now, on the assumption that this can be fixed RSN. Also, busybox patches should be put into a separate bug report which blocks this one, to keep things clear. *this* is something I can do for helping..:-) To Robert: thanks for the patches and the finally fruitful discussion with Matthew (it started a little bit hot but you guys managed to handle it. That deserves applauses). signature.asc Description: Digital signature
Bug#537271: closed by Matthew Palmer mpal...@debian.org
On Monday, February 07, 2011 06:00:40 am Matthew Palmer wrote: Also, busybox patches should be put into a separate bug report which blocks this one, to keep things clear. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606654 - Busybox should include arping applet Regarding IPv6: I see there is already a bug for building a ndisc6-udeb: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611330 but it seems the idea is to put only rdisc6 in there: == I've now discovered that I need the rdisc6 tool as well as rdnssd, so the attached patch now builds an ndisc6-udeb containing just the rdisc6 binary. == Would it be possible to include the ndisc6 binary as well, and use that in the same way as arping? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org (This is done, regardless of the reason)
reopen 537271 thanks Debian Bug Tracking System wrote: Given that there is no possible way to detect that the network link is up but unuseable, did you even read #537271? the simple, 100% effective fix for the situation where your port has link up but the bridge port has not entered the forwarding state is to send ARP requests for the default gateway's IP address until they are answered. an IPv4 router must answer ARP requests or it cannot route packets. the improved DHCP configuration, whereby DHCP DISCOVER packets are sent every second, is the best possible fix for this (coupled with the ability to preseed whatever length of DHCP timeout you want). irrelevant for statically configured networks. i.e., servers. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org (This is done, regardless of the reason)
tag 537271 +help +wontfix # Need a 'cantfix' tag thanks On Sun, Feb 06, 2011 at 05:51:06PM -0500, Robert Edmonds wrote: Debian Bug Tracking System wrote: Given that there is no possible way to detect that the network link is up but unuseable, did you even read #537271? No, I find it far more productive just to close random bugs than to spend several hours investigating, testing, and talking to the maintainers of the relevant parts of the kernel. The initial bug merge was incorrect, I will admit that; given the number of closes and merges I did to cleanup the bug list, I wouldn't be surprised if it was the only mistake I made. Beyond that, though, what is your problem? the simple, 100% effective fix for the situation where your port has link up but the bridge port has not entered the forwarding state is to send ARP requests for the default gateway's IP address until they are answered. an IPv4 router must answer ARP requests or it cannot route packets. Emphasis on IPv4 and router, neither of which are required items. the improved DHCP configuration, whereby DHCP DISCOVER packets are sent every second, is the best possible fix for this (coupled with the ability to preseed whatever length of DHCP timeout you want). irrelevant for statically configured networks. i.e., servers. You are correct. I'm not exactly in a mood to fix this for you, though, so patches welcome. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org
tag 537271 +patch
thanks
Matthew Palmer wrote:
the simple, 100% effective fix for the
situation where your port has link up but the bridge port has not
entered the forwarding state is to send ARP requests for the default
gateway's IP address until they are answered. an IPv4 router must
answer ARP requests or it cannot route packets.
Emphasis on IPv4 and router, neither of which are required items.
then the fix would be made conditional on an IPv4 router being configured.
the improved DHCP configuration, whereby DHCP DISCOVER packets are
sent every second, is the best possible fix for this (coupled with the
ability to preseed whatever length of DHCP timeout you want).
irrelevant for statically configured networks. i.e., servers.
You are correct. I'm not exactly in a mood to fix this for you, though, so
patches welcome.
537271_busybox_arping.patch
enables arping in the busybox udeb.
537271_netcfg_arping.patch
modifies netcfg_detect_link() to wait invoke busybox's arping with
the '-f' flag (quit on first ARP reply). waits up to 45 seconds for
an ARP reply from the default gateway. (this should probably
actually be a loop that repeatedly invokes arping with a short
timeout in order to update the progress bar.)
severity 537271 wishlist
thanks
I'd say that for any bugs that are very difficult to fix due to major
design considerations where the major design consideration is STP
doesn't signal link availability applies nicely here.
yes, it would be very difficult to fix this if the proposed solution
were to modify STP, a protocol baked into millions of switches...
fortunately polling for layer 2/3 connectivity to the gateway is
far easier.
on cisco switches there is a per-port mode called spanning-tree
portfast, and on every cisco switch i've ever used this mode defaults
to off. when you turn it on, a warning message like this is printed:
Warning: portfast should only be enabled on ports connected to a
single host. Connecting hubs, concentrators, switches, bridges, etc.
to this interface when portfast is enabled, can cause temporary
bridging loops. Use with CAUTION
consequently it's frequently left off in many environments, so the usual
sequence of events ends up going something like:
* start up a preseeded installation on a new server.
* installer fails when trying to download something.
* realize the failure is due to portfast not being enabled.
* call up the networking guy and get him to enable portfast on this
server's switch port.
* power cycle the server and start the preseeded installation again.
--
Robert Edmonds
edmo...@debian.org
diff -Npru busybox-1.17.1.orig/debian/config/pkg/udeb busybox-1.17.1/debian/config/pkg/udeb
--- busybox-1.17.1.orig/debian/config/pkg/udeb 2010-11-09 05:37:10.0 -0500
+++ busybox-1.17.1/debian/config/pkg/udeb 2011-02-06 21:13:04.455899401 -0500
@@ -697,7 +697,7 @@ CONFIG_NC_EXTRA=y
# CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set
# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
# CONFIG_ARP is not set
-# CONFIG_ARPING is not set
+CONFIG_ARPING=y
# CONFIG_BRCTL is not set
# CONFIG_FEATURE_BRCTL_FANCY is not set
# CONFIG_FEATURE_BRCTL_SHOW is not set
diff -Npru netcfg-1.60.orig/netcfg-common.c netcfg-1.60/netcfg-common.c
--- netcfg-1.60.orig/netcfg-common.c 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg-common.c 2011-02-06 21:44:10.611927865 -0500
@@ -1048,6 +1048,14 @@ int netcfg_detect_link(struct debconfcli
break;
}
if (ethtool_lite (if_name) == 1) /* ethtool-lite's CONNECTED */ {
+if (gateway.s_addr) {
+char arping[256];
+char s_gateway[INET_ADDRSTRLEN];
+
+inet_ntop (AF_INET, gateway, s_gateway, sizeof(s_gateway));
+sprintf(arping, arping -w 45 -f -I %s %s, if_name, s_gateway);
+di_exec_shell_log(arping);
+}
debconf_progress_set(client, NETCFG_LINK_WAIT_TIME * 4);
rv = 1;
break;
Bug#537271: closed by Matthew Palmer mpal...@debian.org
As you have identified: On Sun, Feb 06, 2011 at 10:15:48PM -0500, Robert Edmonds wrote: (this should probably actually be a loop that repeatedly invokes arping with a short timeout in order to update the progress bar.) This really needs to be implemented. Leaving users hanging with no clue as to what's happening for 45 seconds isn't right. I've left the patch tag on the bug for now, on the assumption that this can be fixed RSN. Also, busybox patches should be put into a separate bug report which blocks this one, to keep things clear. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org
Matthew Palmer wrote:
On Sun, Feb 06, 2011 at 10:15:48PM -0500, Robert Edmonds wrote:
(this should probably
actually be a loop that repeatedly invokes arping with a short
timeout in order to update the progress bar.)
This really needs to be implemented. Leaving users hanging with no clue as
to what's happening for 45 seconds isn't right.
I've left the patch tag on the bug for now, on the assumption that this can
be fixed RSN.
ok, i've rewritten the patch such that the first 50% of the progress bar
is waiting for the link to come up and the second 50% of the progress
bar is the gateway reachability test. the reachability test now
repeatedly invokes arping with a one second timeout (up to 50 times)
until arping exits with a status of 0. (arping exits with a status of 1
if the time expired.)
in cases where the gateway is reachable as soon as the link is up or no
gateway is configured there will be an instantaneous jump from 50% to
100%.
in cases where the gateway takes 30 seconds to become reachable the
progress bar will increment by 1%/second until instantaneously jumping
from ~80% to 100%.
Also, busybox patches should be put into a separate bug report which blocks
this one, to keep things clear.
#612249
--
Robert Edmonds
edmo...@debian.org
diff -Npru netcfg-1.60.orig/netcfg-common.c netcfg-1.60/netcfg-common.c
--- netcfg-1.60.orig/netcfg-common.c 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg-common.c 2011-02-07 01:36:38.683940125 -0500
@@ -1035,23 +1035,40 @@ void netcfg_update_entropy (void)
*/
int netcfg_detect_link(struct debconfclient *client, const char *if_name)
{
-int wait_count, rv = 0;
+char arping[256];
+char s_gateway[INET_ADDRSTRLEN];
+int count, rv = 0;
+int link_waits = NETCFG_LINK_WAIT_TIME * 4;
+int gw_tries = NETCFG_GATEWAY_REACHABILITY_TRIES;
+
+if (gateway.s_addr) {
+inet_ntop(AF_INET, gateway, s_gateway, sizeof(s_gateway));
+sprintf(arping, arping -c 1 -w 1 -f -I %s %s, if_name, s_gateway);
+}
debconf_capb(client, progresscancel);
debconf_subst(client, netcfg/link_detect_progress, interface, if_name);
-debconf_progress_start(client, 0, NETCFG_LINK_WAIT_TIME * 4, netcfg/link_detect_progress);
-for (wait_count = 0; wait_count NETCFG_LINK_WAIT_TIME * 4; wait_count++) {
+debconf_progress_start(client, 0, 100, netcfg/link_detect_progress);
+for (count = 0; count link_waits; count++) {
usleep(25);
-if (debconf_progress_step(client, 1) == 30) {
+if (debconf_progress_set(client, 50 * count / link_waits) == 30) {
/* User cancelled on us... bugger */
rv = 0;
break;
}
-if (ethtool_lite (if_name) == 1) /* ethtool-lite's CONNECTED */ {
-debconf_progress_set(client, NETCFG_LINK_WAIT_TIME * 4);
+if (ethtool_lite(if_name) == 1) /* ethtool-lite's CONNECTED */ {
+if (gateway.s_addr) {
+for (count = 0; count gw_tries; count++) {
+if (di_exec_shell_log(arping) == 0)
+break;
+if (debconf_progress_set(client, 50 + 50 * count / gw_tries) == 30)
+break;
+}
+}
rv = 1;
break;
}
+debconf_progress_set(client, 100);
}
debconf_progress_stop(client);
diff -Npru netcfg-1.60.orig/netcfg.h netcfg-1.60/netcfg.h
--- netcfg-1.60.orig/netcfg.h 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg.h 2011-02-07 01:32:02.895935476 -0500
@@ -47,6 +47,11 @@
*/
#define NETCFG_LINK_WAIT_TIME 3
+/* The number of times to attempt to verify gateway reachability.
+ * Each try invokes arping with a one second timeout.
+ */
+#define NETCFG_GATEWAY_REACHABILITY_TRIES 50
+
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 63
#endif
