Re: possible arp table corruption [2.4.18]

Re: possible arp table corruption [2.4.18]

[Carsten Otto]

I switched to read("/proc/net/arp") in my script and basically have no
difference.
Today I found following "nice" bug:

134.130.48.70    0x1         0x2         00:E0:98:AD:01:97     *        eth0
134.130.48.157   0x1         0x2         00:10:4B:4D:01:97     *        eth0
134.130.48.157   0x1         0x2         00:10:4B:45:86:6C     *        eth0

These three entries appeared near the end of the output and had no
lines between them. Notice how the second MAC is composed from the
other two. The first and last entry is correct. If my database and
script etc. work correct, this (wrong) second combination occured at
least five times, but only one of them showed up today.

Where is the bug? What should I do to avoid this?

Thanks,
-- 
Carsten Otto
carsten.otto@gmail.com
http://c-otto.de

Re: possible arp table corruption [2.4.18]

[Bernd Eckenfels]

In article <13e9886104070615087452e595@mail.gmail.com> you wrote:
> Where is the bug? What should I do to avoid this?

Probably in the line generation code of the /proc file in (your old) kernel,
and you can (still) avoid it with netlink. Or you need to read multiple
times through the table.

Another option would be to use a user space arp daemon to catch changes of
the table.

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

possible arp table corruption [2.4.18]

[Carsten Otto]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

Hello!

I noticed a few strange errors in the arp table of a local firewall serving
about 300 connected computers.
This PC is running 2.4.18 (Debian Woody) and I get the list via the program
"arp" (version 1.60-4, called from inside a python script). This script is called
about every 20 seconds.

I don't know if the kernel or "arp" or something else is broken, but I don't
think "arp" does change much before printing the output. That is why I think
posting the problem to this list is not very wrong.

Here are some examples of the errors:

134.130.48.66            ether   00:00:5A:13:3A:36   C   eth0
134.130.49.152           ether   00:50:04:46:8A:B2   C   eth0 <- wrong!
134.130.49.45            ether   00:50:FC:FF:62:4E   C   eth0

---

134.130.48.240           ether   00:02:3F:AF:3C:B4   C   eth0
134.130.48.157           ether   00:10:4B:45:86:6C   C   eth0 <- OK
134.130.48.157           ether   00:10:4B:45:86:6C   C   eth0 <- double!
134.130.48.213           ether   00:0E:A6:3B:41:81   C   eth0

---

134.130.48.186           ether   00:04:61:52:CC:9F   C   eth0 
134.130.49.41            ether   00:02:3F:68:67:E9   C   eth0 <- OK
134.130.48.40            ether   00:02:3F:68:67:E9   C   eth0 <- MAC repeated
134.130.48.40            ether   00:07:95:04:C8:3C   C   eth0 <- OK
134.130.49.159           ether   00:E0:18:2D:95:F0   C   eth0

I also got a "134.130.4x.6xx" IP a few times, but that case is not in my logs.

Please tell me
   - if there is a known bug in (at least) 2.4.18
   - if "arp" is broken
   - if I am doing something wrong

Please also reply directly to me, because the LKML is quite complex.

Thank you very much,
-- 
Carsten Otto
c-otto@gmx.de
www.c-otto.de

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: possible arp table corruption [2.4.18]

[Bernd Eckenfels]

In article <20040629200558.GH25252@carsten-otto.halifax.rwth-aachen.de> you wrote:
> I don't know if the kernel or "arp" or something else is broken

the /proc interface is most likely broken in some way :)

>   - if I am doing something wrong

you can try "arpd -p", "cat /proc/net/arp"  and 2ip neigh show"  
in addition to your arp script.

Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: possible arp table corruption [2.4.18]

[Bernd Eckenfels]

In article <E1BfPwb-0006gl-00@calista.eckenfels.6bone.ka-ip.net> you wrote:
> you can try "arpd -p"

oops arpwatch -p

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/