ken@racerx.UUCP (Ken Hardy) (05/31/91)
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
jbvb@FTP.COM ("James B. Van Bokkelen") (05/31/91)
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.
Don't depend on IP broadcasts crossing routers. Some routers can be
configured to forward "all subnets" (net.255.255) broadcasts through
all their interfaces, but not all of them. Furthermore, the default
configuration won't forward them, because there is no mechanism to
avoid routing loops which echo the packet around and around a multiply-
connected net until the TTL runs out (and your hosts have been severely
stressed).
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!
Because of RFC 1122, pg 66 & 67. "Hosts SHOULD use the Limited Broadcast
address to broadcast to a connected network." Networks exist where adherence
to this would cause serious problems (read up on "broadcast storms" with old
0-style 4.2 systems configured with 'ipforwarding' enabled), so we had to
support a configurable IP broadcast address (see the '-b' switch on the
kernel's command line). Thus, the configured value overrides whatever the
application asked for (which is likely to be compiled in and hard for the
user to change).
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901