How to fix the global broadcast address (255.255.255.255) behavior on Windows?
You can try to manually change the route table. Delete the following route.
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
Then add a new route
255.255.255.255 255.255.255.255 On-link 127.0.0.1
With a lower metric.
The commands that should be used are:
Finally, I solved it programatically. I wrote a very small software called WinIPBroadcast which takes care of relaying the broadcast frames to all interfaces.
It works using an interesting fact: it is possible to receive locally generated global broadcast packets when listening on the loopback address (127.0.0.1). WinIPBroadcast listens on the local address for all broadcast using RAW sockets, then for each broadcast packet, it relays it to all interfaces except the prefered one.
Windows always try to load blanace over all interfaces. If you use 2 or more default gateways, windows may answer incoming packets from other subnets over the wrong interface because of the 2 default gateways.No it doesn't. It only load balances if the two default routes have the same metric, which is not the case here. And again, this is irrelevant for broadcast, which have their own routes.
Zahni,
Windows 7 is a little fickle. If you ask me, it should be able to handle it better.
http://windows.microsoft.com/en-US/windows7/Configuring-multiple-gateways-on-a-network
Amaranthe
Thank you for explaining in a comprehensible manner your findings.
We've had this issue for a while and have come up with a few solutions. They all end up sending multiple broadcast packets at some point:
1. Enumerate all configured IP addresses and each netmask, compute the subnetwork broadcast address, and send individual broadcast packets for every local IP addresses. This allows to reach every network device, once. Because you specify a broadcast address based on the IP address and netmask, you don't have to bind unto any interface; the routes make sure the good source address is used.
e.g.: 192.168.2.2/16 ; subnetwork broadcast == 192.168.255.255
Of course, this solution doesn't work if your devices have different netmasks than your configured netmask.
2. If you don't care about your devices receiving multiple broadcast of the same packet, you can create a socket for each IP address, explicitly bind to the IP address, and send an all-broadcast packet on each connection.
There's no magical way to do this. Windows should have a more respectable network stack implementation, IMHO.
Charles
As a machine manufacturer / integrator, we rely heavily on the old (even broke) XP behavior. Our machines ALWAYS have 2 NIC cards.
One NIC for the machine sub-systems...
Machine I/O subsystem http://www.automationdirect.com/adc/Shopping/Catalog/Field_I-z-O/Terminator_I-z-O_Network_Interface_Modules
sound analyzer http://www.bksv.com/
Motor Drives
Environmental controls
IP devices of our own design and manufacture.
One NIC for corporate / lab networking.
All this worked just fine on XP.
I can change the code we've written, to send broadcast out all cards but this doesn't fix the drivers from 3rd parties. Seem everyone who's ever made an IP device relies on the now broken broadcast system to discover hardware connected to NIC card(s).
My only questions are...
1) Why did the behavior change from XP (even broken, it did work in all my cases).
2) Why can't Windows 7 just send broadcasts out all NICs (after all, it IS a broadcast not a narrowcast).
As a side note (XP behavior, unverified in Win7) ,
My IP modules send 1000 packets a second to the PC and the PC sends 500 packets a second to the module. Every 20 minutes or so, the PC sends my device an ARP request. If this request gets lost along the way, any my device doesn't send a reply, the PC sends NOTHING for 2 seconds (seems to throw the data away) then retries the ARP and all is good. It seems to me that if the PC is receiving 1000 packets a second from the device (with the device's MAC and IP address in the header), why does a ARP need to be sent at all?
|
.png){kind=spacer}