Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!wuarchive!uunet!racerx!ken
From: ken@racerx.UUCP (Ken Hardy)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: IP broadcasts using FTP's software
Keywords: broadcast subnets
Message-ID: <701@racerx.UUCP>
Date: 30 May 91 17:51:34 GMT
Organization: Bridge Information Systems, St. Louis
Lines: 38


Greetings, Earthlings!


Our application makes liberal use of broadcast UDP packets.  We have a
DOS based server talking to Sun Workstations.  The Suns give me a
broadcast IP address along the lines of "128.66.0.0" if I use ioctl()'s
to query the drivers' configuration.  If I use the inet_makeaddr ()
library subroutine, it gives me "128.66.255.255".  Either of these seem
to work in the absence of subnets.  I use the ioctl()'s because the
inet_makeaddr() does no know or care about subnetting.

However, on the DOS side, when our software is written (using FTP's
development package and TCP/IP kernel) to use an address of the type
"128.66.0.0", we see it go out on the wire with an IP address of
"255.255.255.255".  This works OK on our lan.  But will it work with
subnets?  What about in an organization with its own large
internetwork?  Will this attempt to broadcast across the whole thing
when we want to remain on one or two smaller legs of it?

I'm mostly concerned with how it works with routers when there are
subnets in place.  The plain "128.66.255.255" did not work at a site
with subnets were the broadcast had to cross a router.  That's when I
used the ioctl()s to give me a broadcast address including the subnet
part (not represented in the sample addresses here).  Fortunately, that
customer is only using an application where only the Suns broadcast,
not the DOS systems.  What happens when we do need to pass broadcasts
addressed as "255.255.255.255" accross a router with subnets?

And why is FTP doinking with the IP address we give in the send call?
If I say I want it to go to "128.66.0.0", by golly, that's where they
should send it!


-- 

Ken Hardy                         uunet!racerx!ken
Bridge Information Systems        racerx!ken@relay1.uu.net