UDP Broadcasts
Fred Roeber
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Charlie Grames wrote:
> Has anyone ever attempted a UDP broadcast with VxWorks? I managed to do everything I needed
> in Berkeley sockets to get the broadcast to work, but I was kind of surprised that sending to IP
> address 255.255.255.255 did not cause the message to go out all IP (Ethernet and backplane)
> interfaces (it just went out the first in the interface list). On multihomed UNIX systems I have
> tested (Solaris), the message was sent out all interfaces. Is there something special I have to do
> (enable, etc.) under VxWorks to get the same behavior, or do I just need to send the broadcast out
> each interface separately?
It's sort of a coincidence that I was checking into a related problem
with networking last night. In going through what I consider to be
the best definitive guides on the subject (the Stevens TCP/IP
Illustrated Volume 1/2 books) I read and was surprised by how this
exact issue is handled. Unfortunately, I can't provide an exact
page reference but I think it was in Volume 1, not Volume 2. As with
most networking stuff, the way it works is inconsistent across
implementations. MOST implementations will only send "general"
broadcasts out the first configured network in a multihomed system.
Some (such as Solaris) will send general broadcasts out all
connected interfaces. To be safe/portable you really should send
"network" broadcasts for each connected network rather than general
broadcasts.
Don't you just love the consistency of UNIX? My big question is how
much all these little details in network handling will change with
the new VxWorks networking protocol stack implementation? How much
code will have to change? Anyone have any good answers on exactly
what the new code is and when we see it? I heard performance
is greatly improved. Fred
--
| Fred J Roeber, BBN Systems & Technologies |
| 4 John Clarke Road Middletown, RI 02842-5202 |
| fro...@bbn.com 401-848-3548 |
--MimeMultipartBoundary--
Wes Peters
Charlie Grames asked:
% Has anyone ever attempted a UDP broadcast with VxWorks? I managed to do
everything I needed
% in Berkeley sockets to get the broadcast to work, but I was kind of
surprised that sending to IP
(Ethernet and backplane)
% interfaces (it just went out the first in the interface list). On
multihomed UNIX systems I have
% tested (Solaris), the message was sent out all interfaces. Is there
something special I have to do
% (enable, etc.) under VxWorks to get the same behavior, or do I just need
to send the broadcast out
% each interface separately?
Fred Roeber wrote in message <3475AA...@bbn.com>...
> It's sort of a coincidence that I was checking into a related problem
> with networking last night. In going through what I consider to be
> the best definitive guides on the subject (the Stevens TCP/IP
> Illustrated Volume 1/2 books) I read and was surprised by how this
> exact issue is handled. Unfortunately, I can't provide an exact
> page reference but I think it was in Volume 1, not Volume 2. As with
> most networking stuff, the way it works is inconsistent across
> implementations. MOST implementations will only send "general"
> broadcasts out the first configured network in a multihomed system.
> Some (such as Solaris) will send general broadcasts out all
> connected interfaces. To be safe/portable you really should send
> "network" broadcasts for each connected network rather than general
> broadcasts.
And none of the above has anything to do with the VxWorks TCP/IP stack,
which considers the address 255.255.255.255 to be "ERROR". Think
about the bits in those two for a minute, and you'll see why. Duh.
If you want to do UDP broadcasts on VxWorks, you'll have to use the "local
broadcast" address, which is the network address plus a host address
of all ones.
This, by the way, makes running a DHCP server on VxWorks tough.
Microsoft DHCP clients refuse to accept DHCP replies addressed to
the local broadcast address, they will only accept leases from
255.255.255.255.
> Don't you just love the consistency of UNIX? My big question is how
But, if you don't like the behavior, you can "fix" it. At least you can
if you use a version of UNIX that comes with source. See
http://freebsd.org for details. ;^)
> much all these little details in network handling will change with
> the new VxWorks networking protocol stack implementation? How much
> code will have to change? Anyone have any good answers on exactly
> what the new code is and when we see it? I heard performance
> is greatly improved.
If you're talking about the "SENS" network stack, it is available now.
Contact your WRS sales office for pricing information. It is based
on the 4.4BSD code you were maligning above, so you may or may
not achieve the effect you are looking for.
--
Wes Peters It was a diamond as big as the Ritz
Software Engineer What you gonna do with this, tell me
Intel Corp. Who's gonna save you
When you're a slave to
A diamond as big as the Ritz
Any opinions expressed are owned exclusively by the author.
Intel pays me for my time, not my opinions. ;^)
Hwa-Jin Bae
Solaris is pretty unique in that it handles multicasts/broadcasts
to be sent over all applicable interfaces per request.
Other systems (based on BSD) do not do this. The code base
of Solaris is from Mentat STREAMS code, which does this
a little different than the BSD based code. The way Solaris
routing code is interface to their IP layer is a lot more
generalized for multicast/broadcast stuff, and they have
seperate code path to handle these special cases. One could
argue for either approach, but RFCs are not clear on this
implementation details. The host requirement RFC, for example,
only mentions something vague about all 1's broadcast which
should be received by all hosts on a directly physically
connected network (but not all of those specifically, although
one could infer that from the original intent).
If you want your code to be portable, it's a good idea to first
find all interfaces on your machine, and each of the interface's
broadcast address to which you should send packets to achieve
what you are asking.
Hwa-Jin Bae
Actually 255.255.255.255 is NOT considered an error by VxWorks' TCP/IP
stack. The stack will take 255.255.255.255 and turn it into proper
broadcast address for the "primary" interface and send it out as
broadcast packet.
However, there IS a bug in inet_addr() (in the original BSD UNIX as
well as VxWorks implementation) in that it will return -1 for the
string "255.255.255.255", which is correct numeric representation
of the value passed. Since the error return of inet_addr() is also
defined as -1, this is a bad design/bug in the inet_addr. This
confuses many people, especially on systems that provide direct
interface to inet_addr() without further error checking for this
design mistake. For example, if you ping() from vxWorks' shell,
you will get an error, because inet_addr() returns -1, which
is considered an error, which it really is not in this case.
I'm not trying to be picky... just want to have correct information
published out on the USENET land.