Sending Broadcasts to 255.255.255.255
Horst Triebenbacher
I'm implementing an easy configuration protocol. For this I need to send a
network broadcast to 255.255.255.255 because the client doesn't know its ip
address. The server can either be an other vxWorks station or a pc using any
other os. If I set the broadcast address to 255.255.255.255 the function
fails - error code S_hostLib_UNKNOWN_HOST - a broadcast to 255.255.255.255
if the ip adress is not set to 255.x.x.x fails with S_errno_EHOSTUNREACH and
a broadcast having the ip adress in 255.x.x.x is not accept by a Windows
program.
Has anyone an idea to broadcast in an easy way. I dont't want to use
BOOTP/DHCP to configure my client, because it should be possible to use more
server in a network.
Thanks
Horst Triebenbacher
Dave Korn
<3bb1bdfb$0$18120$6e36...@newsreader02.highway.telekom.at>...
>Hello,
>
>I'm implementing an easy configuration protocol. For this I need to send a
>network broadcast to 255.255.255.255 because the client doesn't know its ip
>address. The server can either be an other vxWorks station or a pc using
any
>other os. If I set the broadcast address to 255.255.255.255 the function
>fails - error code S_hostLib_UNKNOWN_HOST - a broadcast to 255.255.255.255
>if the ip adress is not set to 255.x.x.x fails with S_errno_EHOSTUNREACH
and
>a broadcast having the ip adress in 255.x.x.x is not accept by a Windows
>program.
You need to use 255.255.255.255 as the broadcast address. You also need
to use the 'setsockopt' function to enable the sending of broadcasts - they
are disallowed by default. See the setsockopt entry in the reference
manual:
-----------
OPTION FOR DATAGRAM SOCKETS
The following section discusses an option for datagram (UDP) sockets.
SO_BROADCAST -- Sending to Multiple Destinations
Specify the SO_BROADCAST option when an application needs to send data to
more than one destination:
setsockopt (sock, SOL_SOCKET, SO_BROADCAST, &optval, sizeof (optval));
The value at optval is an integer (type int), either 1 (on) or 0 (off).
-----------
Finally, you need to be careful when handling the IP address
255.255.255.255 as a long, since that is equivalent to 0xFFFFFFFF which is
the same as -1. So if you call a function like inet_addr
("255.255.255.255"), you will get the return value -1, which is the correct
translation of the address, but unfortunately is also the return value used
to indicate ERROR! So you have to watch out so that your error-handling
code doesn't think the function failed and give up too soon!
DaveK
--
Burn your ID card! http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!
Horst Triebenbacher
but the function failed and no broadcast was sent.
Horst
"Dave Korn" <no....@my.mailbox.invalid> wrote in message
news:Nlmu7.19$1F6.1...@newsr2.u-net.net...
Dave Korn
>I tried to broadcast with the SO_BROADCAST option, and watched the network,
>but the function failed and no broadcast was sent.
>
>Horst
Hmm, that's strange then. Can you post the relevant part of your code for
us to look at? VxWorks *does* do broadcasts, the address *is*
255.255.255.255, so either there's a problem with your code or you've
uncovered a bug in the OS that hasn't shown itself before.
Horst Triebenbacher
udp-socket too -with same effects. I got the tip to add a default route to
my ethernet interface before sending the broadcast - this works.
Horst
void request()
{
struct s_lncp lncp;
SOCKET sock = INVALID_SOCKET;
SOCKADDR_IN saUdpServ, saUdpCli;
int err,nSize;
BOOL fHeader = TRUE;
char szBroadcast[32], Buffer[1024];
u_long fBroadcast;
sock = socket(AF_INET,SOCK_RAW,IPPROTO_LNCP);
if (sock == INVALID_SOCKET)
{
ERRPRINT("socket");
return LNCP_ERR_SOCKET;
}
err = setsockopt(sock,SOL_SOCKET,SO_BROADCAST,(char
*)&fHeader,sizeof(BOOL));
if (err == SOCKET_ERROR)
{
ERRPRINT("setsockopt");
return LNCP_ERR_SOCKOPTION;
}
saUdpCli.sin_family = AF_INET;
saUdpCli.sin_addr.s_addr = htonl ( INADDR_ANY );
saUdpCli.sin_port = htons ( 0 );
err = bind ( sock, (SOCKADDR *) &saUdpCli, sizeof (SOCKADDR_IN) );
if (err == SOCKET_ERROR)
{
ERRPRINT("bind");
return LNCP_ERR_BIND;
}
saUdpServ.sin_family = AF_INET;
saUdpServ.sin_addr.s_addr = htonl ( INADDR_BROADCAST );
saUdpServ.sin_port = htons ( 0 );
memset(&lncp,0,sizeof(struct s_lncp));
lncp.lncp_length=htons(sizeof(struct s_lncp));
lncp.lncp_station=StationId;
lncp.lncp_op = ADDRESSREQUEST;
err = sendto ( sock,
(char *)&lncp,
sizeof(struct s_lncp),
0,
(SOCKADDR *) &saUdpServ,
sizeof ( SOCKADDR_IN )
);
if (err == SOCKET_ERROR)
{
ERRPRINT("sendto");
return LNCP_ERR_SEND;
}
err = recvfrom ( sock,rcvBuffer,sizeof(rcvBuffer),0,(SOCKADDR
*)&saUdpServ,&nSize);
if (err == SOCKET_ERROR)
{
ERRPRINT("recvfrom");
return LNCP_ERR_RCV;
}
else
{
printf("Received %d bytes\n",nSize);
}
}
"Dave Korn" <no....@my.mailbox.invalid> wrote in message
news:O8Gw7.146$gW6.8...@newsr2.u-net.net...
Dave Korn
>This is the original code for my broadcast. I have tried to do this with
>udp-socket too -with same effects. I got the tip to add a default route to
>my ethernet interface before sending the broadcast - this works.
Hmm, it's good that you've got it working, but it shouldn't have been
necessary to add a default route, should it? I mean a broadcast should be
sent through *all* the known network interfaces that are flagged as
broadcast-capable, shouldn't it?
> sock = socket(AF_INET,SOCK_RAW,IPPROTO_LNCP);
Mind you, you didn't mention that you were using raw sockets before, and
that perhaps makes a lot of difference. Raw sockets are one of the
trickiest grey areas of network programming, since there's no clearly
defined standard for how they operate, there are many specifications that
have significantly different behaviour and semantics from each other, and
there are a lot of buggy, restricted and/or partial implementations out
there.
In particular, the SO_BROADCAST option is specified as applying to UDP
sockets only, and so is probably ignored by your raw socket. That being the
case, it may also be that the raw socket protocol layer doesn't have a
concept of a broadcast address, and is attempting to route the packet as if
it were an ordinary packet; hence it sends it out the default interface
(dropping it if there is none). You could test this theory by adding a
specific route to 255.0.0.0:ff000000 rather than adding a default route;
then see if the packets still make it.
However, it should have worked when you tried it with UDP. Is it perhaps
the case that in the course of development you first tried UDP, couldn't get
it working, then tried raw sockets, and only then added the SO_BROADCAST
option?
> BOOL fHeader = TRUE;
> err = setsockopt(sock,SOL_SOCKET,SO_BROADCAST,(char
>*)&fHeader,sizeof(BOOL));
Or is it possible that you are using a big-endian system on which BOOL is
not defined as a char, but is a short or int ? You absolutely *must* pass a
pointer to a real char to the setsockopt function here, not merely cast a
pointer to another type to char. The receiving socket control function deep
inside the network stack expects to receive a pointer to a single byte that
is 0 or 1, so if you pass it a pointer to a short that is 0 or 1 on a
big-endian system, it will look at the high byte of that short or int which
is always zero and you will never enable broadcasting!
If this is the case, you may also be able to consider using normal UDP
packets instead of a custom protocol over raw sockets. Apart from the fact
that UDP sockets are more reliable to code for (since more standard and well
tested) it doesn't make any difference if your kit is only ever going to be
used on private LANs but if you want these packets to traverse the public
internet it would be very wrong indeed to start sending IP packets without a
standard IANA-allocated protocol number in them, you might well find that
they didn't route reliably or that they get specifically filtered at
backbone routers.
Horst Triebenbacher
"Dave Korn" <no....@my.mailbox.invalid> schrieb im Newsbeitrag
news:Psez7.11$rQ4.1...@newsr2.u-net.net...
> Horst Triebenbacher wrote in message
> <3bcd277e$0$9460$6e36...@newsreader02.highway.telekom.at>...
> >This is the original code for my broadcast. I have tried to do this with
> >udp-socket too -with same effects. I got the tip to add a default route
to
> >my ethernet interface before sending the broadcast - this works.
>
> Hmm, it's good that you've got it working, but it shouldn't have been
> necessary to add a default route, should it? I mean a broadcast should be
> sent through *all* the known network interfaces that are flagged as
> broadcast-capable, shouldn't it?
I think so, but it has no effects.
>
> > sock = socket(AF_INET,SOCK_RAW,IPPROTO_LNCP);
>
> Mind you, you didn't mention that you were using raw sockets before, and
> that perhaps makes a lot of difference. Raw sockets are one of the
> trickiest grey areas of network programming, since there's no clearly
> defined standard for how they operate, there are many specifications that
> have significantly different behaviour and semantics from each other, and
> there are a lot of buggy, restricted and/or partial implementations out
> there.
>
> In particular, the SO_BROADCAST option is specified as applying to UDP
> sockets only, and so is probably ignored by your raw socket. That being
the
> case, it may also be that the raw socket protocol layer doesn't have a
> concept of a broadcast address, and is attempting to route the packet as
if
> it were an ordinary packet; hence it sends it out the default interface
> (dropping it if there is none). You could test this theory by adding a
> specific route to 255.0.0.0:ff000000 rather than adding a default route;
> then see if the packets still make it.
>
> However, it should have worked when you tried it with UDP. Is it
perhaps
> the case that in the course of development you first tried UDP, couldn't
get
> it working, then tried raw sockets, and only then added the SO_BROADCAST
> option?
My first approach was using UDP with SO_BROADCAST set. It doesn't work. Then
I mention that what I need is raw packets. So the last step was to implement
if fully as raw socket and make it work.
BTW Now I have to specify the whole protocol and another group have to
implent it. So if they have problems, I will support them. But now I know
how to do it.
thanks
Horst