Sending broadcast to 255.255.255.255

Hello,

I’m running into a bit of an issue porting some code from Linux to QNX.
I need to send a broadcast UDP packet to 255.255.255.255, but for some
reason QNX (6.3.2) change the IP of the packet recipient to
192.168.255.255 … which is the broadcast @ of the adapter … I have
googled around and it seems that several people have encountered that
issue, but I haven’t found any link to a solution … yet.

Thanks in advance for any tips/advice or solution(s).

Cheers,

Jean-Louis Villecroze wrote:

Hello,

I’m running into a bit of an issue porting some code from Linux to QNX.
I need to send a broadcast UDP packet to 255.255.255.255, but for some
reason QNX (6.3.2) change the IP of the packet recipient to
192.168.255.255 … which is the broadcast @ of the adapter … I have
googled around and it seems that several people have encountered that
issue, but I haven’t found any link to a solution … yet.

Thanks in advance for any tips/advice or solution(s).

Cheers,

That doesn’t work by default in Linux either. See

http://www.linux.org/docs/ldp/howto/DHCP/x369.html

I suspect that a similar reconfiguration may make it work on QNX.

John Nagle

That doesn’t work by default in Linux either. See

http://www.linux.org/docs/ldp/howto/DHCP/x369.html

I suspect that a similar reconfiguration may make it work on QNX.

Actualy, it must depend on the Linux distribution as it does work on
Ubuntu and Suse (at least).

“Jean-Louis Villecroze” <jlv@prosilica.com> wrote in message
news:ebfguj$6tf$1@inn.qnx.com

That doesn’t work by default in Linux either. See

http://www.linux.org/docs/ldp/howto/DHCP/x369.html

I suspect that a similar reconfiguration may make it work on QNX.

Actualy, it must depend on the Linux distribution as it does work on
Ubuntu and Suse (at least).

Here is some information on QNX broadcasting. It covers a bit of history,
but the information on Momentics on the bottom still applies. dhcp.client
and dhcpd use a combination of SO_BINDTODEVICE and MSG_DONTROUTE for
predictable behaviour.

Dave
TCPIP 5.0 or earlier unless noted. RTP 6.1.0 or earlier unless noted.

When attempting to broadcast a UDP packet using the limited broadcast
address (255.255.255.255), the following happens:

The TCP/IP stack will attempt to resolve the limited broadcast address to
the broadcast address of the primary interface. eg 255.255.255.255 →
10.255.255
…255 if the primary interface is on network 10.0.0.0 netmask 255.0.0.0

The primary interface is the first interface configured. In TCPRT 4.25 and
later
versions, the primary interface is localhost since it is configured
automatically.

The stack will then check to see if the primary interface supports
broadcasting (interface flags “ifconfig -a”). If it does not, it will
attempt to
transmit the broadcast with the original limited broadcast address.

This will result in a “no route to host” error since there is no route to
that
network unless the default route exists, which would not be the
correct ethernet broadcast result.

There are two ways to get around this and specifically determine what
interface the packet is transmitted on.

You can reconfigure localhost, which will move localhost to the end of
the interface list making the next interface the primary interface (assuming
the next interface supports broadcasting). This will result in the packet
being transmitted with the destination address of the subnet broadcast
address.

or define the route

route add -interface 255.255.255.0 x.x.x.x

where x.x.x.x is the ip address of the interface you wish to transmit out
of. (This assumes the primary interface does not support broadcasting). This
will result in the packet being transmitted with the limited broadcast
address
as the destination address.

With Momentics 6.2.0, the broadcast behavior changed so that
the interface list is searched until the first interface which supports
broadcasting is found, and the subnet broadcast address will be used.

When TCPIP 5.0 (QNX4) and Momentics 6 with the full BSD stack were
introduced,
it included support for SO_BINDTODEVICE. Using this socket option combined
with bypassing the routing table with either the socket option SO_DONTROUTE,
or
more preferably using the flags option in send() or sendto() (MSG_DONTROUTE)
you can direct the broadcast packets to a specific interface in your
program.
This will result in the packets being transmitted with the destination
ipadress set to the limited broadcast address (255.255.255.255) which
the application specified as the destination address.