Date: Thu, 18 May 1995 03:17:18 -0700 From: David Greenman <davidg@Root.COM> To: Peter Wemm <peter@haywire.dialix.com> Cc: hackers@FreeBSD.org Subject: Re: Hmm. Strange... Message-ID: <199505181018.DAA01255@corbin.Root.COM> In-Reply-To: Your message of "Thu, 18 May 95 17:55:23 %2B0800." <Pine.SV4.3.91.950518175100.28579D-100000@haywire.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>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<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,LINK2,MULTICAST> mtu 1500 inet 198.145.90.18 netmask 0xfffffff0 broadcast 198.145.90.31 ether 00:80:48:e8:04:08 de1: flags=c863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,LINK2,MULTICAST> mtu 1500 inet 198.145.90.50 netmask 0xfffffff0 broadcast 198.145.90.63 ether 00:00:c0:ef:c3:9c lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 sl0: flags=9011<UP,POINTOPOINT,LINK0,MULTICAST> mtu 552 inet 198.145.90.33 --> 198.145.90.34 netmask 0xfffffff0 sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505181018.DAA01255>