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"
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
--===== ===GMXBoundary2 49391106917237 Transfer- Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Content-
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
-- www.gmx. net/de/ go/topmail ===GMXBoundary2 49391106917237 .patch" Transfer- Encoding: base64 Disposition: attachment; filename= "neighbour. patch"
10 GB Mailbox, 100 FreeSMS http://
+++ GMX - die erste Adresse f�l, Message, More +++
--=====
Content-Type: text/x-diff; name="neighbour
Content-
Content-
LS0tIGxpbnV4LTI uNC4yOC9uZXQvY2 9yZS9uZWlnaGJvd XIuYwlGcmkgSmFu IDI4IDE0OjI2OjU 5 pbnV4LTIuNC4yOG ZpeC9uZXQvY29yZ S9uZWlnaGJvdXIu YwlGcmkgSmFuIDI 4 wMDUKQEAgLTEzNT EsNyArMTM1MSw2I EBAIGludCBuZWln aF9kZWxldGUoc3R y gKnNrYiwgc3QKIA ogCQlpZiAodGJsL T5mYW1pbHkgIT0g bmRtLT5uZG1fZmF t udGludWU7Ci0JCX JlYWRfdW5sb2NrK CZuZWlnaF90Ymxf bG9jayk7CiAKIAk J BTDsKIAkJaWYgKG 5kYVtOREFfRFNUL TFdID09IE5VTEwg fHwKQEAgLTEzNjA s gQEAgaW50IG5laW doX2RlbGV0ZShzd HJ1Y3Qgc2tfYnVm ZiAqc2tiLCBzdAo g tPm5kbV9mbGFncy ZOVEZfUFJPWFkpI HsKIAkJCWVyciA9 IHBuZWlnaF9kZWx l fREFUQShuZGFbTk RBX0RTVC0xXSksI GRldik7Ci0JCQln b3RvIG91dDsKKwk J rCQkJCWNvbnRpbn VlOwkvKiBtYXliZ SBpbiBhbm90aGVy IHRhYmxlICovCis J lIHsKKwkJCQlnb3 RvIG91dDsKKwkJC X0KIAkJfQogCi0J CWlmIChkZXYgPT0 g ldHVybiAtRUlOVk FMOworCQlpZiAoZ GV2ID09IE5VTEwp IHsKKwkJCWdvdG8 g KIAkJbiA9IG5laW doX2xvb2t1cCh0Y mwsIFJUQV9EQVRB KG5kYVtOREFfRFN U KIAkJaWYgKG4pIH sKIAkJCWVyciA9I G5laWdoX3VwZGF0 ZShuLCBOVUxMLCB O xLCAwKTsKIAkJCW 5laWdoX3JlbGVhc 2Uobik7CiAJCX0K KwkJZWxzZSB7Cis J JLyogbWF5YmUgaW 4gYW5vdGhlciB0Y WJsZSAqLworCQl9 CiBvdXQ6CisJCXJ l uZWlnaF90YmxfbG 9jayk7CiAJCWlmI ChkZXYpCiAJCQlk ZXZfcHV0KGRldik 7 lcnI7CkBAIC0xMz kwLDYgKzEzOTksO CBAQCBpbnQgbmVp Z2hfYWRkKHN0cnV j za2IsIHN0cnVjCi AJc3RydWN0IHJ0Y XR0ciAqKm5kYSA9 IGFyZzsKIAlzdHJ 1 ibGUgKnRibDsKIA lzdHJ1Y3QgbmV0X 2RldmljZSAqZGV2 ID0gTlVMTDsKKwl p BRERSTk9UQVZBSU w7CisJaW50IG9sZ GVycjsKIAogCWlm IChuZG0tPm5kbV9 p JCWlmICgoZGV2ID 0gZGV2X2dldF9ie V9pbmRleChuZG0t Pm5kbV9pZmluZGV 4 KQEAgLTEzOTgsMz UgKzE0MDksNDcgQ EAgaW50IG5laWdo X2FkZChzdHJ1Y3Q g iLCBzdHJ1YwogCi AJcmVhZF9sb2NrK CZuZWlnaF90Ymxf bG9jayk7CiAJZm9 y fdGFibGVzOyB0Ym w7IHRibCA9IHRib C0+bmV4dCkgewot CQlpbnQgZXJyID0 g 2ZXJyaWRlID0gMT sKIAkJc3RydWN0I G5laWdoYm91ciAq bjsKIAogCQlpZiA o gIT0gbmRtLT5uZG 1fZmFtaWx5KQogC QkJY29udGludWU7 Ci0JCXJlYWRfdW5 s 0YmxfbG9jayk7Ci AKLQkJZXJyID0gL UVJTlZBTDsKIAkJ aWYgKG5kYVtOREF f VTEwgfHwKLQkJIC AgIG5kYVtOREFfR FNULTFdLT5ydGFf bGVuICE9IFJUQV9 M rZXlfbGVuKSkKKw kJICAgIG5kYVtOR EFfRFNULTFdLT5y dGFfbGVuICE9IFJ U sLT5rZXlfbGVuKS kgeworCQkJZXJyI D0gLUVJTlZBTDsK IAkJCWdvdG8gb3V 0 JaWYgKG5kbS0+ bmRtX2ZsYWdzJk5 URl9QUk9YWSkgew ogCQkJZXJyID0gL UVO pZiAocG5laWdoX2 xvb2t1cCh0YmwsI FJUQV9EQVRBKG5k YVtOREFfRFNULTF d KKwkJCWlmIChwbm VpZ2hfbG9va3VwK HRibCwgUlRBX0RB VEEobmRhW05EQV9 E sIDEpKSB7CiAJCQ kJZXJyID0gMDsKK wkJCQlnb3RvIG91 dDsKKwkJCX0KKwk J JCWNvbnRpbnVlOw kvKiBtYXliZSBpb iBhbm90aGVyIHRh YmxlICovCisJCQl 9 gKGRldiA9PSBOVU xMKSB7CisJCQllc nIgPSAtRUlOVkFM OwogCQkJZ290byB v JaWYgKGRldiA9PS BOVUxMKQotCQkJc mV0dXJuIC1FSU5W QUw7Ci0JCWVyciA 9 KIAkJaWYgKG5kYV tOREFfTExBRERSL TFdICE9IE5VTEwg JiYKLQkJICAgIG5 k SLTFdLT5ydGFfbG VuICE9IFJUQV9MR U5HVEgoZGV2LT5h ZGRyX2xlbikpCis J BX0xMQUREUi0xXS 0+cnRhX2xlbiAhP SBSVEFfTEVOR1RI KGRldi0+ YWRkcl9s lcnIgPSAtRUlOVk FMOwogCQkJZ290b yBvdXQ7CisJCX0K KworCQlvbGRlcnI 9 gPSAwOwogCQluID 0gbmVpZ2hfbG9va 3VwKHRibCwgUlRB X0RBVEEobmRhW05 E kZXYpOwogCQlpZi AobikgewotCQkJa WYgKG5saC0+ bmxtc2dfZmxhZ3M mTkxN JCWlmIChubGgtPm 5sbXNnX2ZsYWdzJ k5MTV9GX0VYQ0wp IHsKIAkJCQllcnI g rCQkJCWdvdG8gb3 V0bmVpZ2g7CisJC Ql9CiAJCQlvdmVy cmlkZSA9IG5saC0 + mTkxNX0ZfUkVQTE FDRTsKIAkJfSBlb HNlIGlmICghKG5s aC0+bmxtc2dfZmx h FQVRFKSkKIAkJCW VyciA9IC1FTk9FT lQ7CkBAIC0xNDQy LDkgKzE0NjUsMTY g oX2FkZChzdHJ1Y3 Qgc2tfYnVmZiAqc 2tiLCBzdHJ1Ywog CQkJCQkgICBuZG0 t KIAkJCQkJICAgb3 ZlcnJpZGUsIDApO wogCQl9CisJCWVs c2UgeworCQkJZXJ y JCWNvbnRpbnVlOw kvKiBtYXliZSBpb iBhbm90aGVyIHRh YmxlICovCisJCX0 K 6CiAJCWlmIChuKQ ogCQkJbmVpZ2hfc mVsZWFzZShuKTsK IG91dDoKKwkJcmV h laWdoX3RibF9sb2 NrKTsKIAkJaWYgK GRldikKIAkJCWRl dl9wdXQoZGV2KTs K ycjsKQEAgLTE0NT MsNyArMTQ4Myw3I EBAIG91dDoKIAog CWlmIChkZXYpCiA J 2KTsKLQlyZXR1cm 4gLUVBRERSTk9UQ VZBSUw7CisJcmV0 dXJuIGVycjsKIH0 K 3LDggKzE1NzcsNy BAQCBpbnQgbmVpZ 2hfZHVtcF9pbmZv KHN0cnVjdCBza19 i JCQljb250aW51ZT sKIAkJaWYgKHQgP iBzX3QpCiAJCQlt ZW1zZXQoJmNiLT5 h zaXplb2YoY2ItPm FyZ3MpLXNpemVvZ ihjYi0+ YXJnc1swXSkpOwo tCQlpZiAo 0YWJsZSh0YmwsIH NrYiwgY2IpIDwgM CkgCi0JCQlicmVh azsKKwkJbmVpZ2h f 0YmwsIHNrYiwgY2 IpOwogCX0KIAlyZ WFkX3VubG9jaygm bmVpZ2hfdGJsX2x v ===GMXBoundary2 49391106917237- -
IDIwMDUKKysrIGx
IDEzOjIyOjA2IDI
dWN0IHNrX2J1ZmY
aWx5KQogCQkJY29
ZXJyID0gLUVJTlZ
MTggKzEzNTksMjg
CiAJCWlmIChuZG0
dGUodGJsLCBSVEF
CWlmKGVycikgewo
CQl9CisJCQllbHN
TlVMTCkKLQkJCXJ
b3V0OworCQl9CiA
LTFdKSwgZGV2KTs
VURfRkFJTEVELCA
CQljb250aW51ZTs
YWRfdW5sb2NrKCZ
CiAJCXJldHVybiB
dCBza19idWZmICp
Y3QgbmVpZ2hfdGF
bnQgZXJyID0gLUV
ZmluZGV4KSB7CiA
KSkgPT0gTlVMTCk
c2tfYnVmZiAqc2t
ICh0Ymw9bmVpZ2h
MDsKIAkJaW50IG9
dGJsLT5mYW1pbHk
b2NrKCZuZWlnaF9
RFNULTFdID09IE5
RU5HVEgodGJsLT5
QV9MRU5HVEgodGJ
OworCQl9CisKIAk
T0JVRlM7Ci0JCQl
KSwgZGV2LCAxKSk
U1QtMV0pLCBkZXY
CWVsc2UgeworCQk
CisJCX0KKwkJaWY
dXQ7CiAJCX0KLQk
IC1FSU5WQUw7Cis
YVtOREFfTExBRER
CSAgICBuZGFbTkR
ZW4pKSB7CisJCQl
ZXJyOwogCQllcnI
QV9EU1QtMV0pLCB
X0ZfRVhDTCkKKwk
PSAtRUVYSVNUOwo
bmxtc2dfZmxhZ3M
Z3MmTkxNX0ZfQ1J
QEAgaW50IG5laWd
Pm5kbV9zdGF0ZSw
PW9sZGVycjsKKwk
Kworb3V0bmVpZ2g
ZF91bmxvY2soJm5
IAkJcmV0dXJuIGV
CWRldl9wdXQoZGV
IAogCkBAIC0xNTQ
dWZmICpza2IsCiA
cmdzWzFdLCAwLCB
bmVpZ2hfZHVtcF9
ZHVtcF90YWJsZSh
Y2spOwogCg==
--=====