Re: RELENG_6_3 ping and DUP packets
From: Chuck Swiger [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address good point, but it's the same A.B.C.X# tcpdump -e icmp tcpdump: listening on rl0, link-type EN10MB 08:41:51.136023 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:51.136171 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:51.136343 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138366 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:52.138447 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138692 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply ^C 169 packets received by filter 0 packets dropped by kernel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
On Fri, Apr 11, 2008 at 08:48:10AM +0200, Damian Weber wrote: From: Chuck Swiger [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address good point, but it's the same A.B.C.X# tcpdump -e icmp tcpdump: listening on rl0, link-type EN10MB 08:41:51.136023 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:51.136171 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:51.136343 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138366 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:52.138447 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138692 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply ^C 169 packets received by filter 0 packets dropped by kernel Possibly an interrupt is being called twice on the same packet? Shot in the dark, but try disabling MSI/MSI-X and see if the problem recurs. Put this in /boot/loader.conf: hw.pci.enable_msi=0 hw.pci.enable_msix=0 Reboot, and see if the problem continues. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
On Thu, 10 Apr 2008, Jeremy Chadwick wrote: Date: Thu, 10 Apr 2008 23:52:56 -0700 From: Jeremy Chadwick [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Fri, Apr 11, 2008 at 08:48:10AM +0200, Damian Weber wrote: From: Chuck Swiger [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address good point, but it's the same A.B.C.X# tcpdump -e icmp tcpdump: listening on rl0, link-type EN10MB 08:41:51.136023 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:51.136171 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:51.136343 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138366 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:52.138447 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138692 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply ^C 169 packets received by filter 0 packets dropped by kernel Possibly an interrupt is being called twice on the same packet? Shot in the dark, but try disabling MSI/MSI-X and see if the problem recurs. Put this in /boot/loader.conf: hw.pci.enable_msi=0 hw.pci.enable_msix=0 Reboot, and see if the problem continues. Bingo! No duplicates anymore. Is this considered as a permanent solution or just a hack? In any case, I've summarized it on http://www-crypto.htw-saarland.de/weber/misc/unix/freebsd-dup-packets/ including the output of the mptable command (MSI disabled/enabled). Thanks a lot, Damian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
On Fri, Apr 11, 2008 at 11:51:15AM +0200, Damian Weber wrote: On Thu, 10 Apr 2008, Jeremy Chadwick wrote: Date: Thu, 10 Apr 2008 23:52:56 -0700 From: Jeremy Chadwick [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Fri, Apr 11, 2008 at 08:48:10AM +0200, Damian Weber wrote: From: Chuck Swiger [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address good point, but it's the same A.B.C.X# tcpdump -e icmp tcpdump: listening on rl0, link-type EN10MB 08:41:51.136023 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:51.136171 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:51.136343 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138366 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:52.138447 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138692 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply ^C 169 packets received by filter 0 packets dropped by kernel Possibly an interrupt is being called twice on the same packet? Shot in the dark, but try disabling MSI/MSI-X and see if the problem recurs. Put this in /boot/loader.conf: hw.pci.enable_msi=0 hw.pci.enable_msix=0 Reboot, and see if the problem continues. Bingo! No duplicates anymore. Is this considered as a permanent solution or just a hack? In any case, I've summarized it on http://www-crypto.htw-saarland.de/weber/misc/unix/freebsd-dup-packets/ including the output of the mptable command (MSI disabled/enabled). Thanks a lot, We use MSI/MSI-X on our servers here, with em(4), and there's no problem. This leads me to believe that some motherboards vendors implement things oddly or incorrectly, or possibly it's a BIOS bug. I'm not really sure. Anyway, CC'ing Jack Vogel (em(4) maintainer), who can very likely answer this and/or help further. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
On Thu, 10 Apr 2008, Jeremy Chadwick wrote: On Fri, Apr 11, 2008 at 08:48:10AM +0200, Damian Weber wrote: From: Chuck Swiger [EMAIL PROTECTED] To: Damian Weber [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address good point, but it's the same A.B.C.X# tcpdump -e icmp tcpdump: listening on rl0, link-type EN10MB 08:41:51.136023 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:51.136171 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:51.136343 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138366 0:20:ed:5f:3:3b 0:19:99:33:7c:9 ip 98: A.B.C.X A.B.C.D: icmp: echo request 08:41:52.138447 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply 08:41:52.138692 0:19:99:33:7c:9 0:20:ed:5f:3:3b ip 98: A.B.C.D: icmp: echo reply ^C 169 packets received by filter 0 packets dropped by kernel Possibly an interrupt is being called twice on the same packet? Shot in the dark, but try disabling MSI/MSI-X and see if the problem recurs. Put this in /boot/loader.conf: hw.pci.enable_msi=0 hw.pci.enable_msix=0 Reboot, and see if the problem continues. FYI, this did NOT solve it for me, even though it did solve it for the original poster. But I did find the solution for my system... While rebooting to try disabling MSI, I noticed that the machine was still pingable during the reboot (and returning just one response each), while the thing was still doing its POST routines -- which of course made me do a few double-takes, given that the FreeBSD kernel wasn't even running :) Weirder is that the responses all had the bogus 255 TTL that the dupes had when the system was up. Once the system did finish booting, the dupes returned. Turns out this Intel S3000AHV motherboard has a built-in management thingie that's kind of IPMI-ish but apparently not quite actually IPMI (at least ipmitool and freeipmi want nothing to do with it). Somehow it had gotten itself enabled and was pulling an IP from the DHCP server, and bridging itself through the onboard LAN. So ping replies were coming from both the management CPU and the main CPU when the system was up, and just the management CPU when the system was down. The reason the other Intel S3000AH* system I have didn't do this is because that other system just happens to be the DHCP server for its subnet -- and the reason the other systems w/ the same chipset didn't do it is because they're all Supermicro boxes with different management CPU's. So, yeah, short version, goofy pilot error, nothing wrong with FreeBSD, at least in RELENG_7. Maybe there's an MSI issue in RELENG_6_3 though that the original poster was hitting, but at least in my case that wasn't it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
On Fri, Apr 11, 2008 at 03:40:48PM -0400, Mike Andrews wrote: While rebooting to try disabling MSI, I noticed that the machine was still pingable during the reboot (and returning just one response each), while the thing was still doing its POST routines -- which of course made me do a few double-takes, given that the FreeBSD kernel wasn't even running :) Weirder is that the responses all had the bogus 255 TTL that the dupes had when the system was up. Once the system did finish booting, the dupes returned. Braindump time! FreeBSD, back in the 3.x or 4.x days, used to have a problem where during a reboot, after bringing down the network interfaces, the box would still respond to certain packets (ICMP being one of them). That got fixed. This is different than your problem, but I thought I'd point it out as a reminder for those who are newer to FreeBSD, or have forgotten it. A box pinging during or very shortly after POST would indicate a piggy-backed management interface on one of the NICs. I **hate** these things. Supermicro has this capability as well (via some IPMI add-on modules, while others (the more expensive ones) have a dedicated NIC, which is how it should be). Said management interfaces have a full layer 2 through layer 7 stacks on them. In bge(4) land, the feature is called ASF, and you can toggle FreeBSD's knowledge/respect of said feature via hw.bge.allow_asf in loader.conf. The problem with ASF is that if it's enabled in the BIOS/on the system somehow, and FreeBSD isn't aware of it, what happens is that systems on the network see two MAC addresses (sometimes for the same IP address) that are associated with one physical PHY/NIC. People end up seeing broken IP traffic, or duplicate packets in this case. Turns out this Intel S3000AHV motherboard has a built-in management thingie that's kind of IPMI-ish but apparently not quite actually IPMI (at least ipmitool and freeipmi want nothing to do with it). Somehow it had gotten itself enabled and was pulling an IP from the DHCP server, and bridging itself through the onboard LAN. So ping replies were coming from both the management CPU and the main CPU when the system was up, and just the management CPU when the system was down. The reason the other Intel S3000AH* system I have didn't do this is because that other system just happens to be the DHCP server for its subnet -- and the reason the other systems w/ the same chipset didn't do it is because they're all Supermicro boxes with different management CPU's. Bingo. :-) None of our Supermicro boxes have piggybacked management capabilities, and they all use Intel PHY/NICs. It's likely a feature Intel has on their boards -- a cool feature, but piggybacking it on an existing NIC is such a bad idea, case in point. Glad to know you figured out the cause of your pain! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_6_3 ping and DUP packets
Hello list, after upgrading from RELENG_6_2 to RELENG_6_3, I'm seeing duplicate packets when pinging the upgraded machine. I'm somewhat stuck, didn't find anything useful on the Web, so I'm asking the list, what I should try next. BTW, everything else works fine (ssh, NFS mount, NIS,). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is the uname output on the machine A.B.C.D$ $ uname -a FreeBSD 6.3-RELEASE-p1 FreeBSD 6.3-RELEASE-p1 #0: Thu Apr 10 10:21:06 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ISL-POOL-6_3 i386 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pinging locally gives A.B.C.D$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.033 ms 64 bytes from A.B.C.D: icmp_seq=1 ttl=64 time=0.015 ms 64 bytes from A.B.C.D: icmp_seq=2 ttl=64 time=0.014 ms ^C --- A.B.C.D ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.014/0.021/0.033/0.009 ms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The ifconfig says A.B.C.D$ ifconfig em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet A.B.C.D netmask 0xff00 broadcast A.B.C.255 ether 00:19:99:33:7c:09 media: Ethernet autoselect (100baseTX full-duplex) status: active plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The netstat says A.B.C.D$ netstat -I em0 NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 Link#1 00:19:99:33:7c:0917962 0 9695 0 0 em01500 A.B.C/24 . 9461 - 9666 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) 64 bytes from A.B.C.D: icmp_seq=1 ttl=64 time=0.144 ms 64 bytes from A.B.C.D: icmp_seq=1 ttl=255 time=0.449 ms (DUP!) 64 bytes from A.B.C.D: icmp_seq=2 ttl=64 time=0.248 ms 64 bytes from A.B.C.D: icmp_seq=2 ttl=255 time=0.367 ms (DUP!) --- A.B.C.D ping statistics --- 3 packets transmitted, 3 packets received, 3 duplicates, 0.0% packet loss round-trip min/avg/max/std-dev = 0.144/0.311/0.449/0.104 ms Curiously, no duplicates are seen if the packet size is increased to 1481 (1473 data bytes): A.B.C.X$ ping -s 1473 A.B.C.D PING A.B.C.D (A.B.C.D): 1473 data bytes 1481 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.781 ms 1481 bytes from A.B.C.D: icmp_seq=1 ttl=64 time=0.630 ms 1481 bytes from A.B.C.D: icmp_seq=2 ttl=64 time=0.646 ms 1481 bytes from A.B.C.D: icmp_seq=3 ttl=64 time=0.642 ms 1481 bytes from A.B.C.D: icmp_seq=4 ttl=64 time=0.666 ms 1481 bytes from A.B.C.D: icmp_seq=5 ttl=64 time=0.666 ms 1481 bytes from A.B.C.D: icmp_seq=6 ttl=64 time=0.675 ms --- A.B.C.D ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.630/0.672/0.781/0.050 ms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - There are no other machines with IP A.B.C.D on the network. Especially strange are the two different TTL-values. I started tcpdump on A.B.C.D but tcpdump doesn't see the duplicated packets. The tcpdump on the remote machine certainly prints the correct and the duplicated packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Finally, the dmesg output of A.B.C.D follows. Here, the kernel configuration ISL-POOL-6_3 is the GENERIC one with firewire devices firewire,sbp,fwe commented out. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p1 #0: Thu Apr 10 10:21:06 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ISL-POOL-6_3 ACPI APIC Table: PTLTD APIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 2103115776 (2005 MB) avail memory = 2052919296 (1957 MB) ioapic0 Version 2.0 irqs 0-23 on
Re: RELENG_6_3 ping and DUP packets
On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6_3 ping and DUP packets
Chuck Swiger wrote: On Apr 10, 2008, at 1:58 PM, Damian Weber wrote: But here is the problem, pinging the machine from remote gives A.B.C.X$ ping A.B.C.D PING A.B.C.D (A.B.C.D): 56 data bytes 64 bytes from A.B.C.D: icmp_seq=0 ttl=64 time=0.272 ms 64 bytes from A.B.C.D: icmp_seq=0 ttl=255 time=0.391 ms (DUP!) Please run tcpdump -e icmp on this box and repeat your testing. It will be most interesting to know whether you're seeing the same MAC address I'm seeing the same thing on *one* of my RELENG_7 boxes, including the problem going away at 1481 bytes. In my case, if I run tcpdump -e icmp on both the offending RELENG_7 box and on the machine pinging it (tried with both a Mac Mini running Leopard on the same LAN, and a RELENG_7_0 box on the other side of a DSL line), the RELENG_7 box only shows a single reply packet going out, but the pinger shows two -- and both packets have the same (correct) mac address. It does not happen with all of my RELENG_7 machines though... just one of them... even though all of them have the same motherboard chipset (Intel 3000) and NIC (em0). I haven't figured out exactly when it started or what's different about that one machine. It doesn't seem to hurt anything other than it's somewhat annoying and Nagios complains bitterly about it. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
