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,
I don’t think it’s “legal” to broadcast outside of your segment.
AFAIK it is ‘legal’ … routers won’t propagate it. DHCP discovery (for example) use it.
Have you tried changing the netmask to see if the destination address changes?
yes, but setting the netmask to 0x000000000 doesn’t work, ifconfig change it automaticaly to 0xffffff00 
Stevens: Unix Network Programming Volume 1, 2nd ed. (1998)
"… the subnet-directed broadcast address is the most common today. But some older systems still send datagrams destined to 255.255.255.255 "
‘subnet-directed’ being what you’re seeing (netmask applied to the broadcast address)
BSD seems to have an IOCTL which will allow you to force the 255.255.255.255 address but it’s not
supported in QNX.
You may be stuck with this behavior or have to go to raw sockets - and there’s no guaruntee it’ll
work there either.
Wikipedia:
“… A special type of IP address is the limited broadcast address 255.255.255.255. A broadcast involves delivering a message from one sender to many recipients. This broadcast is ‘limited’ in that it does not reach every node on the Internet, only nodes on the LAN.”
We use this broadcast address (RFC1122) to discover devices (cameras) on the local network, this is what the standard (GigE Vision) request. QNX is the only OS to not allow it AFAIK. Assigning a broadcast address of 255.255.255.255 with ifconfig to the adapter “solve” the issue … but I’m not sure this is an acceptable solution
While I agree that you should be able to send to the general boradcast address, this does bring up an obvious question. If your subnet covers the local lan, why would a local broadcast address not be sufficient for your needs? I’m just trying to be practical here.
Well, broadcasting to 255.255.255.255 garantee that we can “reach” any devices on the local network, inlcuding the ones that are not configured properly (unreachable otherwise as they won’t answer a subnet broadcast as they don’t know, or have an incorrect, netmask.
Please post “ifconfig -a” and “netstat -rn”.
One suggestion:
assuming you have an IP 192.168.2.5 on en0, try the below command
route add -host 255.255.255.255 -interface 192.168.2.5
“route add -host 255.255.255.255 -interface 192.168.2.5” didn’t help, the broadcast are still sent with 192.168.255.255 as recipient
Here’s the output of the commands:
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0<>
inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:0c:f1:6c:aa:7e
inet 192.168.0.69 netmask 0xffff0000 broadcast 192.168.255.255
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.0.1 UG 2 2493 - en0
127.0.0.1 127.0.0.1 UH 0 0 33212 lo0
192.168/16 link#2 UC 2 0 - en0
192.168.0.1 00:05:5d:75:0b:03 UHLc 1 0 - en0
192.168.255.255 link#2 UHLc 0 2 - en0
A few things you could try:
route add -host 255.255.255.255 -interface 192.168.0.69
route add -net 255.255.255 -interface 192.168.0.69
no luck, noc And actualy, the second one (corrected to 255.255.255.255 instead of 255.255.255) mess the routing table.
Using ping and a packet sniffer (Ethereal on XP) you can see that when
pinging 255.255.255.255 the address is NOT getting mangled.
If you look at the source for ping (I don’t have that handy) you’ll see
that it uses a raw socket. So apparently you can bypass this addressing
issue by going to a lower level in the stack.
That explains it. I was testing using ping and all worked. Was wondering why it failed for jlv.