From owner-freebsd-hackers Thu May 18 13:29:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA17501 for hackers-outgoing; Thu, 18 May 1995 13:29:27 -0700 Received: from haywire.DIALix.COM (peter@haywire.DIALix.COM [192.203.228.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA17493 for ; Thu, 18 May 1995 13:29:19 -0700 Received: (from peter@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id EAA16712; Fri, 19 May 1995 04:28:53 +0800 Date: Fri, 19 May 1995 04:28:50 +0800 (WST) From: Peter Wemm To: David Greenman cc: hackers@FreeBSD.org Subject: Re: Hmm. Strange... In-Reply-To: <199505181018.DAA01255@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hackers-owner@FreeBSD.org Precedence: bulk On Thu, 18 May 1995, David Greenman wrote: [..] > [corbin:davidg] ifconfig -a [..] > [corbin:davidg] arp -na > ? (198.145.90.17) at 0:0:c0:39:48:2c > ? (198.145.90.49) at 0:0:c0:eb:c3:9c > ? (198.145.90.50) at 0:0:c0:ef:c3:9c permanent > > [corbin:davidg] netstat -rn [..] > [corbin:davidg] ping 198.145.90.31 # Carefull, pinging the broadcast > # isn't very smart > PING 198.145.90.31 (198.145.90.31): 56 data bytes > 64 bytes from 198.145.90.18: icmp_seq=0 ttl=255 time=0.502 ms > 64 bytes from 198.145.90.19: icmp_seq=0 ttl=255 time=1.442 ms (DUP!) > 64 bytes from 198.145.90.18: icmp_seq=1 ttl=255 time=0.346 ms > 64 bytes from 198.145.90.19: icmp_seq=1 ttl=255 time=0.767 ms (DUP!) > 64 bytes from 198.145.90.18: icmp_seq=2 ttl=255 time=0.351 ms > 64 bytes from 198.145.90.19: icmp_seq=2 ttl=255 time=0.765 ms (DUP!) > > --- 198.145.90.31 ping statistics --- > 3 packets transmitted, 3 packets received, +3 duplicates, 0% packet loss > round-trip min/avg/max = 0.346/0.695/1.442 ms > > ...Hmmm, I see that the machine at 198.145.90.17 isn't responding to the > broadcast ping. I don't think machines are supposed to (according to > some RFC I forgot). I think we fixed that in 1.1.5 (which is what .17 > is running), and forgot to bring the fix into 2.x. > > -DG I have some more info. What I was trying to do was to get freebsd to run in place of an existing host (running SVR4, but we needn't go into that.. :-) The C class is subnetted into 16 chunks of 16, and subnet 0 is in use (apparently, using subnet 0 is illegal, but it's too late now.. there are hundreds of DNS NS records pointing there... We have to vacate the other 15 nets some time..) Anyway, try as I might, I couldn't get gated to broadcast a rip advertisment onto the local ethernet. I run gated 3.5alpha9 on the SVR4 machine, which works beautifully (with the exception of variable size subnet support.. good old hash routing tables.. :-( ). Anyway, I fired up pppd, (so there were two "networks" so that gated would advertise (it runs "quiet" if there is one network only)), and the !&@^#%!#$!&#^ thing (/usr/ports/net/gated (3.5alpha10)) just wouldn't broadcast the RIP announcements. At that point, I started looking with netstat, arp etc looking for mixed up broadcast addresses when I saw the arp for the broadcast address. It turns out.. it was a false alarm. It was rwhod that was making the arp entry. Not just rwhod, but *everything* that accessed the broadcast address was causing it to appear. I suspect there are cloning bugs still.. To test my theory, in the commands that you ran above, do an arp -na *after* the pings.. (and try a telnet to the broadcast address too for good measure) See if the system creats a route to the broadcast address that arp is picking up as a failed arp. As for gated, The really good bit, is that even after getting it so that it *said* it was broadcasting (ie: RIP SENT 192.203.228.69 -> 192.203.228.79) appears in the logs every 30 seconds.. tcpdump (on ed0) says there are definately no packets being sent, and none of the other hosts got them either. I've just transferred the working gated-alpha 9 code from the machine next to the freebsd box to see if that makes a difference. I'll be trying that soon, as soon as some rdists have finished and I can bring the link down. Anyway, here's the creation of the bogus "arp" entry for the broadcast address: -------------------- jhome # arp -a haywire.DIALix.COM (192.203.228.65) at 0:80:48:88:5d:9 jhome.DIALix.COM (192.203.228.69) at 0:80:48:98:75:56 permanent jhome # rwhod jhome # arp -a haywire.DIALix.COM (192.203.228.65) at 0:80:48:88:5d:9 jhome.DIALix.COM (192.203.228.69) at 0:80:48:98:75:56 permanent haywire_bcast.DIALix.COM (192.203.228.79) at (incomplete) ----------------------- And here's another (actually older than the above, but that doesn't matter) run, showing that it's not related to there being an illegal 16 address subnet 0 being present: jhome # arp -na ? (192.203.228.65) at (incomplete) ? (192.203.228.69) at 0:80:48:98:75:56 permanent ? (192.203.228.79) at (incomplete) jhome # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127 127.0.0.1 URc 0 0 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.203.228.64 link#1 UC 0 0 192.203.228.65 link#1 UHLW 2 1122 192.203.228.69 0:80:48:98:75:56 UHLW 3 316 lo0 192.203.228.79 link#1 UHLW 1 4 224 link#1 UCS 0 0 224.0.0.9 127.0.0.1 UH 0 1 lo0 jhome # netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 00.80.48.98.75.56 2464 0 1527 0 0 ed0 1500 192.203.228 192.203.228.69 2464 0 1527 0 0 lo0 16384 316 0 316 0 0 lo0 16384 127 127.0.0.1 316 0 316 0 0 ppp0* 1500 0 0 0 0 0 ppp1* 1500 0 0 0 0 0 sl0* 552 0 0 0 0 0 sl1* 552 0 0 0 0 0 tun0* 1500 0 0 0 0 0 tun1* 1500 0 0 0 0 0 Cheers, -Peter