'ip addr flush dev eth0' enters an endless loop

[Rui Matos]

The title says it all. I ran this command by accident without sudo and had to
kill it after a while with ^C. Running with sudo goes normally. I'm using Hoary
vanilla.

[Andreas Barth (aba)]

tag 282492 + unreproducible help
thanks

Hi,

this problem is not reproducible for me, at least not with the current
version -1.

The bad thing is also that I don't have any idea how to fix it, so this
means that I need help.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Wilfried Weissmann (wilfried-weissmann)]

Hi,

I also have this problem. It only occurs with (debian i686) kernel
version 2.6.9 and above. This causes my fwbuilder startup script to hang...

The command is:
/sbin/ip -4 neigh flush dev lan

The problem is not new. I just kept on using kernel 2.6.8 which works fine.

iproute version is 20041019-2. strace is the same so I do not send it.

Greetings,
Wilfried

[Wilfried Weissmann (wilfried-weissmann)]

hi,

kernel-image-2.6.10-1-686 2.6.10-4 works for me. the fw-builder script
and the ip flush command do not hang anymore.

greetings,
wilfried

[Ernesto Baschny [cron] (ernesto-cron-it)]

We had a setup with kernel-image-2.6.9-2-k7 2.6.9-5 and iproute
20010824-8woody1 and the same problem as described. Then we upgraded to
the latest unstable versions:

kernel-image-2.6.10-1-k7 2.6.10-4
iproute 20041019-2

but still encounter the same problem: "ip -4 neigh flush dev eth0" hangs
up.

We noticed that it only happens if there are entries in the ARP-Table.
If the ARP cache is empty, it exits normally saying "Nothing to flush".
Our ARP-Cache is also being populated very quickly, maybe there is a
race-condition here?

If we leave the hung ip neigh flush dev eth0 running and in another
console issue something like:

# for a in `arp -n | awk '/^[0-9]/ { print $1; }'`; do arp -d $a; done

some times in a row (it cleans up all entries in the arp-cache), the
hung ip command awakes and finishes.

[Wilfried Weissmann (wilfried-weissmann)]

allright, i got the same as ernesto. if an arp entry exists then the
command still hangs. the startup scripts must have been changed so the
bug is not triggered anymore during the boot process. <:/

greetings,
wilfried

[Wilfried Weissmann (wilfried-weissmann)]

I have the same result on a non-debian system with kernel 2.4.28 while
2.4.27 is still fine. 2.4.9 and 2.4.28 have the same changes in the
neighbour.c code so this is most likely a kernel issue.

hope this helps,
wilfried

[Wilfried Weissmann (wweissmann)]

Hi,

The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
the neighbour cache code. neigh_delete() and neigh_add() only work properly
if one cache table per address family exist. After ATM-CLIP installed a
second cache table for AF_INET, neigh_delete() and neigh_add() only examine
the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
call fails.

This bug causes "ip neigh flush dev <some ethernet device>" to run into an
infinite loop when the arp cache is already populated (debian bug #282492).
"ip neigh delete ..." commands for non ATM-CLIP entries fail with an EINVAL.
This is because of the IPv4 neighbour table that is installed in arp.c is
never examined when sending delete commands.

I have attached a minimally tested patch for 2.4.28 that fixes this problem.

Greetings,
Wilfried

--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f�r Mail, Message, More +++

[Herbert Xu (herbert-gondor)]

Wilfried Weissmann <email address hidden> wrote:
>
> The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
> the neighbour cache code. neigh_delete() and neigh_add() only work properly
> if one cache table per address family exist. After ATM-CLIP installed a
> second cache table for AF_INET, neigh_delete() and neigh_add() only examine
> the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
> the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
> call fails.

Indeed, this has been the case for a very long time.

IMHO you need to give the user a way to specify which table they want
to operate on. If they don't specify one, then the current behaviour
of choosing the first table found is reasonble.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <email address hidden>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= (yoshfuji)]

In article <email address hidden> (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert Xu <email address hidden> says:

> IMHO you need to give the user a way to specify which table they want
> to operate on. If they don't specify one, then the current behaviour
> of choosing the first table found is reasonble.

We have dev. Isn't is sufficient?

--yoshfuji

[Herbert Xu (herbert-gondor)]

On Sat, Jan 29, 2005 at 07:46:05AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <email address hidden> (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert Xu <email address hidden> says:
>
> > IMHO you need to give the user a way to specify which table they want
> > to operate on. If they don't specify one, then the current behaviour
> > of choosing the first table found is reasonble.
>
> We have dev. Isn't is sufficient?

It could be used for neigh_add/neigh_delete. We'll need to add a way
to query whether a given table is the right one for a device.

For dump it isn't the same. However, perhaps it's not too important
to query a specific table.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <email address hidden>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[Rui Matos (tiagomatos)]

The title says it all. I ran this command by accident without sudo and had to
kill it after a while with ^C. Running with sudo goes normally. I'm using Hoary
vanilla.

[lkcl (lkcl)]

Package: iproute
Version: 20041019-3
Severity: normal
Followup-For: Bug #282492

one million and increasing attempts to flush eth0.

this is what i am using (in combination with fwbuilder) to attempt
to get round of the problem. it is not successful always but can be
eventually successful after killing /sbin/ip and re-running the script,
repeat until success.

#!/bin/sh

iptables -F
iptables -X
ifdown eth0
ifdown eth1

rmmod ip6table_filter
rmmod ip6_tables
rmmod ipt_LOG
rmmod ipt_state
rmmod ip_nat_tftp
rmmod ip_nat_snmp_basic
rmmod ip_nat_irc
rmmod ip_nat_ftp
rmmod ip_nat_amanda
rmmod iptable_nat
rmmod ip_conntrack_tftp
rmmod ip_conntrack_proto_sctp
rmmod ip_conntrack_irc
rmmod ip_conntrack_ftp
rmmod ip_conntrack_amanda
rmmod ip_conntrack
rmmod iptable_filter
rmmod ipt_REDIRECT

sleep 1
rmmod tulip
rmmod 3c59x
modprobe tulip
modprobe 3c59x
sleep 1
ifup eth0
ifup eth1
ip -4 neigh flush dev eth0
ip -4 neigh flush dev eth1
sleep 1
ifdown eth0
ifdown eth1
sleep 1
ifup eth0
ifup eth1

sh /etc/fwbuilder.script.fw

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux highfield 2.6.11-1-686 #1 Fri May 20 07:34:54 UTC 2005 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages iproute depends on:
ii libatm1 2.4.1-16 shared library for ATM (Asynchrono
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an

-- no debconf information

[Ante Karamatić (ivoks)]

Confirmed. Loop takes CPU to 100% usage. Moving to normal severity. This isn't a
case in Breezy, only Hoary.

[Rui Matos (tiagomatos)]

(In reply to comment #1)
> Confirmed. Loop takes CPU to 100% usage. Moving to normal severity. This isn't a
> case in Breezy, only Hoary.

If it isn't the case in Breezy then maybe it is a kernel bug. I've never done
this with 2.6.12 and am still running with 2.6.10 (because of other bugs) even
if my userspace is all the latest breezy. To sum it up: in hoary's 2.6.10-34
with all userspace being breezy I still get this behaviour.

[Ante Karamatić (ivoks)]

No, this isn't a kernel issue. Tested on Hoary on 2.6.11.7.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282492

[Piotr Roszatycki (dexter)]

I've found that the latest snapshot does work:

./ip -4 neigh flush dev eth0
*** Flush not complete bailing out after 10 rounds

It doesn't hang up completly. I hope this solution can be backported to the
Debian's version. The bug is very annoying and important for me.

--
 .''`. Piotr Roszatycki, Netia SA
: :' : mailto:<email address hidden>
`. `' mailto:<email address hidden>
  `-

[Herbert Straub (herbert)]

I had the same situation with Ubuntu Hoary (iproute_20041019). I think
this is the same version as in Debian and also the 2.6.10 kernel.
Yesterday i inform Stehpen Hemminger at osdl.org about this problem and
he answer:

Thanks, this usually shows up when someone tries to run flush
as non-root. Some vendors added a check for getuid() != 0, but that
fails in secure environments with capabilities and no root user.

I'll probably just change it to try 10 times and give up.

I isolate his changes and create this patch

--- ip/ipneigh.c.ORIG 2005-08-17 22:11:06.000000000 +0200
+++ ip/ipneigh.c 2005-08-17 22:13:02.000000000 +0200
@@ -31,6 +31,7 @@
 #include "ip_common.h"

 #define NUD_VALID
(NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY)
+#define MAX_ROUNDS 10

 static struct
 {
@@ -411,7 +412,7 @@
         filter.rth = &rth;
         filter.state &= ~NUD_FAILED;

- for (;;) {
+ while (round < MAX_ROUNDS) {
             if (rtnl_wilddump_request(&rth, filter.family,
RTM_GETNEIGH) < 0) {
                 perror("Cannot send dump request");
                 exit(1);
@@ -437,6 +438,9 @@
                 fflush(stdout);
             }
         }
+ printf("*** Flush not complete bailing out after %d rounds\n",
+ MAX_ROUNDS);
+ return 1;
     }

     if (rtnl_wilddump_request(&rth, filter.family, RTM_GETNEIGH) < 0) {

The modified iproute package for Ubuntu Hoary (and i think you can easy
rebuild it for Debian) are available under:
http://apt-get.linuxhacker.at/ubuntu/dists/hoary/main/pool/

More details in the Ubuntu Bug #9106
(https://bugzilla.ubuntu.com/show_bug.cgi?id=9106)

Best regards
Herbert Straub

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 22 Nov 2004 15:23:58 +0100
From: Piotr Roszatycki <email address hidden>
To: <email address hidden>
Subject: iproute: "ip -4 neigh flush dev eth0" hangs up

Package: iproute
Version: 20041019-0.1
Severity: normal

# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0d:9d:9d:b5:76 brd ff:ff:ff:ff:ff:ff
    inet 195.114.160.200/26 brd 195.114.160.255 scope global eth0
    inet6 fe80::20d:9dff:fe9d:b576/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 10
    link/[65534]
    inet 10.114.160.200 peer 10.0.0.1/32 scope global tun0

# strace ip -4 neigh flush dev eth0

execve("/sbin/ip", ["ip", "-4", "neigh", "flush", "dev", "eth0"], [/* 11 vars
*/]) = 0
uname({sys="Linux", node="ginger", ...}) = 0
brk(0) = 0x8069000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fe9000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=100000, ...}) = 0
old_mmap(NULL, 100000, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd0000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/i686/cmov/libresolv.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\'\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=64892, ...}) = 0
old_mmap(NULL, 73608, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7fbe000
old_mmap(0xb7fcd000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xf000) = 0xb7fcd000
old_mmap(0xb7fce000, 8072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7fce000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300X\1"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1278692, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fbd000
old_mmap(NULL, 1289004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7e82000
old_mmap(0xb7fb2000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x12f000) = 0xb7fb2000
old_mmap(0xb7fba000, 11052, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7fba000
close(3) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fbd860, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0xb7...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 5 Jan 2005 22:37:16 +0100
From: Andreas Barth <email address hidden>
To: <email address hidden>
Subject: iproute: ip -4 neigh flush ... - not reproducible for me

tag 282492 + unreproducible help
thanks

Hi,

this problem is not reproducible for me, at least not with the current
version -1.

The bad thing is also that I don't have any idea how to fix it, so this
means that I need help.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 11 Jan 2005 21:13:01 +0100
From: Wilfried Weissmann <email address hidden>
To: <email address hidden>
Subject: iproute: "ip -4 neigh flush dev eth0" hangs up

Hi,

I also have this problem. It only occurs with (debian i686) kernel
version 2.6.9 and above. This causes my fwbuilder startup script to hang...

The command is:
/sbin/ip -4 neigh flush dev lan

The problem is not new. I just kept on using kernel 2.6.8 which works fine.

iproute version is 20041019-2. strace is the same so I do not send it.

Greetings,
Wilfried

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 19 Jan 2005 19:37:32 +0100
From: Wilfried Weissmann <email address hidden>
CC: <email address hidden>
Subject: Re: iproute: "ip -4 neigh flush dev eth0" hangs up

hi,

kernel-image-2.6.10-1-686 2.6.10-4 works for me. the fw-builder script
and the ip flush command do not hang anymore.

greetings,
wilfried

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 20 Jan 2005 13:00:00 +0100
From: "Ernesto Baschny [cron]" <email address hidden>
To: <email address hidden>
Subject: Re: iproute: "ip -4 neigh flush dev eth0" hangs up

We had a setup with kernel-image-2.6.9-2-k7 2.6.9-5 and iproute
20010824-8woody1 and the same problem as described. Then we upgraded to
the latest unstable versions:

kernel-image-2.6.10-1-k7 2.6.10-4
iproute 20041019-2

but still encounter the same problem: "ip -4 neigh flush dev eth0" hangs
up.

We noticed that it only happens if there are entries in the ARP-Table.
If the ARP cache is empty, it exits normally saying "Nothing to flush".
Our ARP-Cache is also being populated very quickly, maybe there is a
race-condition here?

If we leave the hung ip neigh flush dev eth0 running and in another
console issue something like:

# for a in `arp -n | awk '/^[0-9]/ { print $1; }'`; do arp -d $a; done

some times in a row (it cleans up all entries in the arp-cache), the
hung ip command awakes and finishes.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 20 Jan 2005 19:18:00 +0100
From: Wilfried Weissmann <email address hidden>
CC: <email address hidden>
Subject: Re: iproute: "ip -4 neigh flush dev eth0" hangs up

allright, i got the same as ernesto. if an arp entry exists then the
command still hangs. the startup scripts must have been changed so the
bug is not triggered anymore during the boot process. <:/

greetings,
wilfried

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 25 Jan 2005 18:55:59 +0100
From: Wilfried Weissmann <email address hidden>
CC: <email address hidden>
Subject: Re: iproute: "ip -4 neigh flush dev eth0" hangs up

I have the same result on a non-debian system with kernel 2.4.28 while
2.4.27 is still fine. 2.4.9 and 2.4.28 have the same changes in the
neighbour.c code so this is most likely a kernel issue.

hope this helps,
wilfried

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 28 Jan 2005 14:00:37 +0100 (MET)
From: "Wilfried Weissmann" <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: multiple neighbour cache tables for AF_INET

--========GMXBoundary249391106917237
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
the neighbour cache code. neigh_delete() and neigh_add() only work properly
if one cache table per address family exist. After ATM-CLIP installed a
second cache table for AF_INET, neigh_delete() and neigh_add() only examine
the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
call fails.

This bug causes "ip neigh flush dev <some ethernet device>" to run into an
infinite loop when the arp cache is already populated (debian bug #282492).
"ip neigh delete ..." commands for non ATM-CLIP entries fail with an EINVAL.
This is because of the IPv4 neighbour table that is installed in arp.c is
never examined when sending delete commands.

I have attached a minimally tested patch for 2.4.28 that fixes this problem.

Greetings,
Wilfried

--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f�l, Message, More +++
--========GMXBoundary249391106917237
Content-Type: text/x-diff; name="neighbour.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="neighbour.patch"

LS0tIGxpbnV4LTIuNC4yOC9uZXQvY29yZS9uZWlnaGJvdXIuYwlGcmkgSmFuIDI4IDE0OjI2OjU5
IDIwMDUKKysrIGxpbnV4LTIuNC4yOGZpeC9uZXQvY29yZS9uZWlnaGJvdXIuYwlGcmkgSmFuIDI4
IDEzOjIyOjA2IDIwMDUKQEAgLTEzNTEsNyArMTM1MSw2IEBAIGludCBuZWlnaF9kZWxldGUoc3Ry
dWN0IHNrX2J1ZmYgKnNrYiwgc3QKIAogCQlpZiAodGJsLT5mYW1pbHkgIT0gbmRtLT5uZG1fZmFt
aWx5KQogCQkJY29udGludWU7Ci0JCXJlYWRfdW5sb2NrKCZuZWlnaF90YmxfbG9jayk7CiAKIAkJ
ZXJyID0gLUVJTlZBTDsKIAkJaWYgKG5kYVtOREFfRFNULTFdID09IE5VTEwgfHwKQEAgLTEzNjAs
MTggKzEzNTksMjggQEAgaW50IG5laWdoX2RlbGV0ZShzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdAog
CiAJCWlmIChuZG0tPm5kbV9mbGFncyZOVEZfUFJPWFkpIHsKIAkJCWVyciA9IHBuZWlnaF9kZWxl
dGUodGJsLCBSVEFfREFUQShuZGFbTkRBX0RTVC0xXSksIGRldik7Ci0JCQlnb3RvIG91dDsKKwkJ
CWlmKGVycikgeworCQkJCWNvbnRpbnVlOwkvKiBtYXliZSBpbiBhbm90aGVyIHRhYmxlICovCisJ
CQl9CisJCQllbHNlIHsKKwkJCQlnb3RvIG91dDsKKwkJCX0KIAkJfQogCi0JCWlmIChkZXYgPT0g
TlVMTCkKLQkJCXJldHVybiAtRUlOVkFMOworCQlpZiAoZGV2ID09IE5VTEwpIHsKKwkJCWdvdG8g
b3V0OworCQl9CiAKIAkJbiA9IG5laWdoX2xvb2t1cCh0YmwsIFJUQV9EQVRBKG5kYVtOREFfRFNU
LTFdKSwgZGV2KTsKIAkJaWYgKG4pIHsKIAkJCWVyciA9IG5laWdoX3VwZGF0ZShuLCBOVUxMLCBO
VURfRkFJTEVELCAxLCAwKTsKIAkJCW5laWdoX3JlbGVhc2Uobik7CiAJCX0KKwkJZWxzZSB7CisJ
CQljb250aW51ZTsJLyogbWF5YmUgaW4gYW5vdGhlciB0YWJsZSAqLworCQl9CiBvdXQ6CisJCXJl
YWRfdW5sb2NrKCZuZWlnaF90YmxfbG9jayk7CiAJCWlmIChkZXYpCiAJCQlkZXZfcHV0KGRldik7
CiAJCXJldHVybiBlcnI7CkBAIC0xMzkwLDYgKzEzOTksOCBAQCBpbnQgbmVpZ2hfYWRkKHN0cnVj
dCBza19idWZmICpza2IsIHN0cnVjCiAJc3RydWN0IHJ0YXR0ciAqKm5kYSA9IGFyZzsKIAlzdHJ1
Y3QgbmVpZ2hfdGFibGUgKnRibDsKIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gTlVMTDsKKwlp
bnQgZXJyID0gLUVBRERSTk9UQVZBSUw7CisJaW5...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 29 Jan 2005 09:19:49 +1100
From: Herbert Xu <email address hidden>
To: <email address hidden> (Wilfried Weissmann)
Cc: <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: multiple neighbour cache tables for AF_INET

Wilfried Weissmann <email address hidden> wrote:
>
> The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
> the neighbour cache code. neigh_delete() and neigh_add() only work properly
> if one cache table per address family exist. After ATM-CLIP installed a
> second cache table for AF_INET, neigh_delete() and neigh_add() only examine
> the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
> the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
> call fails.

Indeed, this has been the case for a very long time.

IMHO you need to give the user a way to specify which table they want
to operate on. If they don't specify one, then the current behaviour
of choosing the first table found is reasonble.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <email address hidden>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 29 Jan 2005 07:46:05 +0900 (JST)
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: multiple neighbour cache tables for AF_INET

In article <email address hidden> (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert Xu <email address hidden> says:

> IMHO you need to give the user a way to specify which table they want
> to operate on. If they don't specify one, then the current behaviour
> of choosing the first table found is reasonble.

We have dev. Isn't is sufficient?

--yoshfuji

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 29 Jan 2005 21:06:56 +1100
From: Herbert Xu <email address hidden>
To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <email address hidden>
Cc: <email address hidden>, <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: multiple neighbour cache tables for AF_INET

On Sat, Jan 29, 2005 at 07:46:05AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <email address hidden> (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert Xu <email address hidden> says:
>
> > IMHO you need to give the user a way to specify which table they want
> > to operate on. If they don't specify one, then the current behaviour
> > of choosing the first table found is reasonble.
>
> We have dev. Isn't is sufficient?

It could be used for neigh_add/neigh_delete. We'll need to add a way
to query whether a given table is the right one for a device.

For dump it isn't the same. However, perhaps it's not too important
to query a specific table.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <email address hidden>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 01 Jul 2005 01:26:47 +0100
From: Luke Kenneth Casson Leighton <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: iproute: removing modules, ifup down up down kill ip _eventually_ succeeds

Package: iproute
Version: 20041019-3
Severity: normal
Followup-For: Bug #282492

one million and increasing attempts to flush eth0.

this is what i am using (in combination with fwbuilder) to attempt
to get round of the problem. it is not successful always but can be
eventually successful after killing /sbin/ip and re-running the script,
repeat until success.

#!/bin/sh

iptables -F
iptables -X
ifdown eth0
ifdown eth1

rmmod ip6table_filter
rmmod ip6_tables
rmmod ipt_LOG
rmmod ipt_state
rmmod ip_nat_tftp
rmmod ip_nat_snmp_basic
rmmod ip_nat_irc
rmmod ip_nat_ftp
rmmod ip_nat_amanda
rmmod iptable_nat
rmmod ip_conntrack_tftp
rmmod ip_conntrack_proto_sctp
rmmod ip_conntrack_irc
rmmod ip_conntrack_ftp
rmmod ip_conntrack_amanda
rmmod ip_conntrack
rmmod iptable_filter
rmmod ipt_REDIRECT

sleep 1
rmmod tulip
rmmod 3c59x
modprobe tulip
modprobe 3c59x
sleep 1
ifup eth0
ifup eth1
ip -4 neigh flush dev eth0
ip -4 neigh flush dev eth1
sleep 1
ifdown eth0
ifdown eth1
sleep 1
ifup eth0
ifup eth1

sh /etc/fwbuilder.script.fw

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux highfield 2.6.11-1-686 #1 Fri May 20 07:34:54 UTC 2005 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages iproute depends on:
ii libatm1 2.4.1-16 shared library for ATM (Asynchrono
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 17 Aug 2005 19:19:32 +0200
From: Piotr Roszatycki <email address hidden>
To: <email address hidden>
Subject: Re: iproute: "ip -4 neigh flush dev eth0" hangs up

I've found that the latest snapshot does work:

./ip -4 neigh flush dev eth0
*** Flush not complete bailing out after 10 rounds

It doesn't hang up completly. I hope this solution can be backported to the
Debian's version. The bug is very annoying and important for me.

--
 .''`. Piotr Roszatycki, Netia SA
: :' : mailto:<email address hidden>
`. `' mailto:<email address hidden>
  `-

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 17 Aug 2005 23:18:08 +0200
From: Herbert Straub <email address hidden>
To: <email address hidden>
Subject: iproute: "ip -4 neigh flush dev eth0" hangs up

I had the same situation with Ubuntu Hoary (iproute_20041019). I think
this is the same version as in Debian and also the 2.6.10 kernel.
Yesterday i inform Stehpen Hemminger at osdl.org about this problem and
he answer:

Thanks, this usually shows up when someone tries to run flush
as non-root. Some vendors added a check for getuid() != 0, but that
fails in secure environments with capabilities and no root user.

I'll probably just change it to try 10 times and give up.

I isolate his changes and create this patch

--- ip/ipneigh.c.ORIG 2005-08-17 22:11:06.000000000 +0200
+++ ip/ipneigh.c 2005-08-17 22:13:02.000000000 +0200
@@ -31,6 +31,7 @@
 #include "ip_common.h"

 #define NUD_VALID
(NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY)
+#define MAX_ROUNDS 10

 static struct
 {
@@ -411,7 +412,7 @@
         filter.rth = &rth;
         filter.state &= ~NUD_FAILED;

- for (;;) {
+ while (round < MAX_ROUNDS) {
             if (rtnl_wilddump_request(&rth, filter.family,
RTM_GETNEIGH) < 0) {
                 perror("Cannot send dump request");
                 exit(1);
@@ -437,6 +438,9 @@
                 fflush(stdout);
             }
         }
+ printf("*** Flush not complete bailing out after %d rounds\n",
+ MAX_ROUNDS);
+ return 1;
     }

     if (rtnl_wilddump_request(&rth, filter.family, RTM_GETNEIGH) < 0) {

The modified iproute package for Ubuntu Hoary (and i think you can easy
rebuild it for Debian) are available under:
http://apt-get.linuxhacker.at/ubuntu/dists/hoary/main/pool/

More details in the Ubuntu Bug #15413
(https://bugzilla.ubuntu.com/show_bug.cgi?id=9106)

Best regards
Herbert Straub

[Daniel Silverstone (dsilvers)]

Accepted:
 OK: iproute_20041019-4ubuntu2.dsc
     -> Component: main Section: net
 OK: iproute_20041019-4ubuntu2.diff.gz

Format: 1.7
Date: Thu, 13 Apr 2006 11:41:34 +0100
Source: iproute
Binary: iproute-dev iproute
Architecture: source
Version: 20041019-4ubuntu2
Distribution: dapper
Urgency: low
Maintainer: Anibal Monsalve Salazar <email address hidden>
Changed-By: Daniel Silverstone <email address hidden>
Description:
 iproute - Professional tools to control the networking in Linux kernels
 iproute-dev - Development package for iproute
Changes:
 iproute (20041019-4ubuntu2) dapper; urgency=low
 .
   * Ensure that flushing the neighbour cache does not infinite-loop if an
     unprivileged process attempts the flush.
     Also ensure the same is true of the address cache.
     Closes: launchpad #16137
Files:
 636af651750d2c19d275cfb7281e9a2e 758 net optional iproute_20041019-4ubuntu2.dsc
 ec0575c797b7ea91b781e64aee25d857 19225 net optional iproute_20041019-4ubuntu2.diff.gz

[maximilian attems (maks-debian)]

# Automatically generated email from bts, devscripts version 2.9.20
tags 282492 - help unreproducible

[maximilian attems (maks-debian)]

severity 282492 important

[Alexander Wirt (formorer)]

Hi,

I applied the patch from Herbert Straub some time ago, but missed to close
this bug.

Alex