Date: Mon, 3 Sep 2001 15:23:50 -0400 From: Paul Chvostek <paul@it.ca> To: freebsd-questions@freebsd.org Subject: missing arp, 90 second ping times Message-ID: <20010903152350.A86584@gahch.it.ca>
next in thread | raw e-mail | index | archive | help
Hiya. Major weirdness here, confusing me greatly. I've just set up a Dell Latitude XPi CD with a fresh install of 4.3-RELEASE (since the boot floppies for 4.4-RC[12] cause a kernel panic on this box, but that's another story). I've got a pair of 3COM 3C589D cards which both exhibit identical behaviour, both of which have work fine in other other laptops and other operating systems on the same laptop, on the same Ethernet cable. I see the same behaviour with the GENERIC kernel as well as the stripped-down kernel with only 'device ep' for Ethernet. The 3C589D cards are recognized properly by pccardd using the default config file. The interface is assigned, I see the card's MAC address, and can assign an IP address. The ifconfig for one shows: ep0: flags=8843<UP,BROADAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.4.1.9 netmask 0xffffff00 broadcast 10.4.1.255 ether 00:60:97:78:2a:e4 media: 10baseT/UTP supported media: 10base2/BNC 10baseT/UTP 10base5/AUI Oddly, the laptop's own IP and MAC address pair appears as "permanent" in its arp table (I haven't noticed that before), and it's picking up arp from the rest of the network. I tried removing that entry, but it didn't change the behaviour. I thought at first that the card just wasn't talking to the network, despite showing a link light on both ends. On a hunch, I left a ping to the laptop running for a while, and started seeing the real weirdness. # ping -r 10.4.1.9 PING 10.4.1.9 (10.4.1.9): 56 data bytes 64 bytes from 10.4.1.9: icmp_seq=75 ttl=255 time=78305.271 ms 64 bytes from 10.4.1.9: icmp_seq=153 ttl=255 time=99514.223 ms 64 bytes from 10.4.1.9: icmp_seq=154 ttl=255 time=98504.297 ms 64 bytes from 10.4.1.9: icmp_seq=155 ttl=255 time=97494.497 ms 64 bytes from 10.4.1.9: icmp_seq=156 ttl=255 time=96484.632 ms 64 bytes from 10.4.1.9: icmp_seq=157 ttl=255 time=95474.784 ms 64 bytes from 10.4.1.9: icmp_seq=158 ttl=255 time=94464.932 ms 64 bytes from 10.4.1.9: icmp_seq=159 ttl=255 time=93455.088 ms 64 bytes from 10.4.1.9: icmp_seq=160 ttl=255 time=92445.242 ms 64 bytes from 10.4.1.9: icmp_seq=161 ttl=255 time=91435.438 ms 64 bytes from 10.4.1.9: icmp_seq=162 ttl=255 time=90425.590 ms 64 bytes from 10.4.1.9: icmp_seq=163 ttl=255 time=89415.743 ms 64 bytes from 10.4.1.9: icmp_seq=164 ttl=255 time=88405.884 ms 64 bytes from 10.4.1.9: icmp_seq=165 ttl=255 time=87396.055 ms 64 bytes from 10.4.1.9: icmp_seq=166 ttl=255 time=86386.208 ms 64 bytes from 10.4.1.9: icmp_seq=167 ttl=255 time=85376.361 ms 64 bytes from 10.4.1.9: icmp_seq=168 ttl=255 time=84366.512 ms 64 bytes from 10.4.1.9: icmp_seq=169 ttl=255 time=83356.672 ms 64 bytes from 10.4.1.9: icmp_seq=170 ttl=255 time=82346.809 ms 64 bytes from 10.4.1.9: icmp_seq=171 ttl=255 time=81336.987 ms 64 bytes from 10.4.1.9: icmp_seq=172 ttl=255 time=80327.140 ms 64 bytes from 10.4.1.9: icmp_seq=173 ttl=255 time=79317.297 ms 64 bytes from 10.4.1.9: icmp_seq=174 ttl=255 time=78307.456 ms ^C --- 10.4.1.9 ping statistics --- 270 packets transmitted, 23 packets received, 91% packet loss round-trip min/avg/max/stddev = 78305.271/88449.701/99514.223/6628.680 ms Pings in the other direction (i.e. laptop to network) look the same, but are more difficult to cut and paste. :) The lines from 153 to 174 appeared ALL AT ONCE (note the decending times). If I leave it for a long time, the pattern repeats, with a slew of ping responses showing up at irregular intervals. I also ran tcpdumps elsewhere on the network, and found that ... - pings *to* the laptop merely generate gobs of "arp who-has" on the network, none of which is seen by tcpdump on the laptop, - pings from the laptop are being seen by other hosts but ARP isn't being answered in a timely fashion, so other machines on the network can't respond to the pings. A ping from the laptop (.9) as seen from another box (.4): # tcpdump -neixl0 icmp or arp tcpdump: listening on xl0 01:36:39.754243 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:39.754375 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:40.762199 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:40.762276 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:41.772074 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:41.772139 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:42.781983 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:42.782061 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:43.791886 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:43.791937 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:44.801844 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:45.811725 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:46.821628 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:47.831538 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:48.841466 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request ... 01:37:43.376789 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:44.386633 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:45.396575 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:46.406470 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:47.417971 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418017 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:47.418030 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418090 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418288 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418356 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418423 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418491 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418559 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418627 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418695 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418763 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418830 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418899 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418989 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.419034 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.419134 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:47.419192 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:48.426296 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:48.426379 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:49.436246 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:49.436331 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply Note the collection of arp replies at 01:37:47. So the icmp is moving, but the laptop is failing to spit out the arp replies that would let machines on the LAN send traffic to it. Note that despite the "echo reply" shown by tcpdump at the end of this session, the responses never actually showed up in ping's stdout. It seems to me that everything would work a little better if the laptop would respond to arp who-has packets, which it does not seem to do. The only time other machines get to see the laptop's MAC address is from outbound traffic from the laptop, except for bursts which happen every few minutes of traffic. I've got other tcpdump details that may or may not be relevant, but would certainly lengthen this email if included, so I won't include 'em. Anybody have any idea what's going on? I'm stumped. -- Paul Chvostek <paul@it.ca> Operations / Development / Abuse / Whatever vox: +1 416 598-0000 IT Canada http://www.it.ca/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010903152350.A86584>