From owner-freebsd-hackers Thu May 18 04:30:53 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA04621 for hackers-outgoing; Thu, 18 May 1995 03:18:43 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA04615 for ; Thu, 18 May 1995 03:18:37 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id DAA11702; Thu, 18 May 1995 03:21:16 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id DAA01255; Thu, 18 May 1995 03:18:15 -0700 Message-Id: <199505181018.DAA01255@corbin.Root.COM> To: Peter Wemm cc: hackers@FreeBSD.org Subject: Re: Hmm. Strange... In-reply-to: Your message of "Thu, 18 May 95 17:55:23 +0800." From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 18 May 1995 03:17:18 -0700 Sender: hackers-owner@FreeBSD.org Precedence: bulk >Err.. I'm having a spot of bother.. Nothing seems to be able to broadcast >on a subnetted c-class network.. The networking code does not seem to be >recognising the broadcast address, and is trying to arp it instead.. > >Is this supported? We have a stack of other machines running in this >config... It's definately supported. I'm doing it here right now...I'm even using the same subnet mask. I noticed that you have a route for the class C itself. This doesn't look right. [corbin:davidg] ifconfig -a de0: flags=c863 mtu 1500 inet 198.145.90.18 netmask 0xfffffff0 broadcast 198.145.90.31 ether 00:80:48:e8:04:08 de1: flags=c863 mtu 1500 inet 198.145.90.50 netmask 0xfffffff0 broadcast 198.145.90.63 ether 00:00:c0:ef:c3:9c lo0: flags=8009 mtu 16384 inet 127.0.0.1 netmask 0xff000000 sl0: flags=9011 mtu 552 inet 198.145.90.33 --> 198.145.90.34 netmask 0xfffffff0 sl1: flags=c010 mtu 552 [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 Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 198.145.90.17 UGSc 1 0 de0 127.0.0.1 127.0.0.1 UH 1 157 lo0 198.145.90.16 link#1 UC 0 0 198.145.90.17 0:0:c0:39:48:2c UHLW 3 7131 de0 1193 198.145.90.18 127.0.0.1 UGHS 1 24 lo0 198.145.90.34 198.145.90.33 UH 1 131 sl0 198.145.90.48 link#2 UC 0 0 198.145.90.49 0:0:c0:eb:c3:9c UHLW 6 25231 de1 713 198.145.90.50 0:0:c0:ef:c3:9c UHLW 0 3 lo0 [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