summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaul Fox2006-03-29 23:01:33 +0000
committerPaul Fox2006-03-29 23:01:33 +0000
commitef81ce620ced149ce72b5a8df1d5410e8f120ee8 (patch)
treee7d289b4713c770edf00f875f98540d197fdde45
parentd409c3a2f787dd2276d242d70e03b25e33436cea (diff)
downloadbusybox-ef81ce620ced149ce72b5a8df1d5410e8f120ee8.zip
busybox-ef81ce620ced149ce72b5a8df1d5410e8f120ee8.tar.gz
fix from David Daney, on busybox mailing list:
> The problem is that if the zcip protocol times out at about the same > time another ARP packet is being received, the newly calculated timeout > may be set to wait forever. This prevents the protocol from progressing > through its various states. > > The Fix is to set the timeout to zero if it used to be a positive > number, but it has already expired. This causes the next protocol state > to be entered immediately instead of never. > > If OK please commit. > > Also note that if you may have to apply the patch on this page: > > http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements > > To the linux kernel to get proper zcip behavior. >
-rw-r--r--networking/zcip.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/networking/zcip.c b/networking/zcip.c
index 716c4a5..ed30bb3 100644
--- a/networking/zcip.c
+++ b/networking/zcip.c
@@ -437,7 +437,7 @@ fail:
gettimeofday(&tv2, NULL);
if (timercmp(&tv1, &tv2, <)) {
- timeout = -1;
+ timeout = 0;
} else {
timersub(&tv1, &tv2, &tv1);
timeout = 1000 * tv1.tv_sec