locked
How to fix the global broadcast address (255.255.255.255) behavior on Windows? RRS feed

  • General discussion

  • Correct behavior

    Normally, when an application sends a packet to the global broadcast IP address `255.255.255.255`, the packet should be sent to the Ethernet global broadcast address (`ff:ff:ff:ff:ff:ff`), on all interfaces.

    On Linux and probably other OSes as well this works perfectly. Unfortunately, Windows XP and Windows 7 exhibit different behaviors about this, and neither is correct.

    Windows XP behavior

    The packet will be sent correctly to the first network interface (interface order is specified in "Network Connections/Advanced/Advanced Settings"). It will also be sent to the other interfaces.

    Everything is right so far. Problem is, when sending to the other interfaces, the source address of the broadcast packet is the IP address of the first interface. For example, imagine this network configuration (order is important):

    - Adapter 1: IP address `192.168.0.1`
    - Adapter 2: IP address `10.0.0.1`
    - Adapter 3: IP address `172.17.0.1`

    Now if I send a broadcast packet, the following packets will be sent (with source and destination IP addresses):

    - On adapter 1: `192.168.0.1` => `255.255.255.255`: OK
    - On adapter 2: `192.168.0.1` => `255.255.255.255`: WTF?
    - On adapter 3: `192.168.0.1` => `255.255.255.255`: WTF?

    This is of course completely wrong. In practice, applications using broadcast packets won't work on any interfaces other than adapter 1. In my opinion, this is a blatant bug in the TCP/IP stack of Windows XP.

    Windows 7 behavior

    Modifying the network interface order doesn't seem to have any effect on Windows 7. Instead, broadcast seems to be controlled by the IP route table.

        IPv4 Route Table
        ===========================================================================
        Active Routes:
        Network Destination        Netmask          Gateway       Interface  Metric
                  0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
                  0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
               10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
               10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
           10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
                127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
                127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
          127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
              192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
              192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
            192.168.0.255  255.255.255.255         On-link       192.168.0.3    266
                224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
                224.0.0.0        240.0.0.0         On-link       192.168.0.3    266
                224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
          255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
          255.255.255.255  255.255.255.255         On-link       192.168.0.3    266
          255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
        ===========================================================================

    See the `255.255.255.255` routes? Yep, they control broadcast packets. In this situation, broadcast packets will be send via the `192.168.0.3` because it has the lower metric... but not to the other interfaces.

    You can change the interface through which global broadcast packets will be sent very easily (just add a persistent `255.255.255.255` route with a low metric). But no matter how hard you try, broadcast packets will only be sent on only *one* interface, not all of them like it's supposed to.

    Conclusion

    - Windows 7 only sends broadcast packets to one interface. You can choose which one, but that's not the point here.
    - Windows XP sends broadcast packets to all interfaces, but it only sends them *correctly* to one interface, which in practice is equivalent to the Windows 7 behavior.

    The goal

    I want to fix this broken global IP broadcast support in Windows (preferably Windows 7) once and for all. Of course the better way would be to have some kind of proper fix (registry hack or similar), but I'm open to all suggestions.

    Any ideas?
    • Changed type Arthur Xie Tuesday, October 13, 2009 3:51 AM
    Wednesday, October 7, 2009 3:44 PM

All replies

  • 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:

    route –delete

    route -add


    Arthur Xie - MSFT
    Friday, October 9, 2009 9:35 AM
  • Good try, too bad it doesn't seem to change anything.
    Saturday, October 10, 2009 10:51 PM
  • 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.

    Sunday, November 1, 2009 11:40 AM
  • I see 2 default gateways (0.0.0.0). I think, this is your problem.

    Sunday, November 1, 2009 1:36 PM
  • No it's not. If I remove one of them I still have the same problem. Besides I don't see the relation between the default gateways and the broadcast behavior.
    Sunday, November 1, 2009 7:27 PM
  • 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.

    Don't use more than one default gateway.
    Sunday, November 1, 2009 9:15 PM
  • 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.
    Sunday, November 1, 2009 10:34 PM
  • Hi. Good idea with the WinIPBroadcast program.

    But it doesn't work in one case. For some reason the raw sockets don't catch the global broadcast if the source port and destination port are the same. That's on Vista. Does this case work on Win7?

    Also, as far as I can tell, the the raw sockets don't seem to catch any global broadcasts at all on WinXP.
    Monday, December 21, 2009 1:07 PM
  • e-t172,

    I've definitely seen the behaviour where changing the order for Network Adapters priority seems to be worthless. 
    In my situation I set a NIC up on my internet router with highest priority.  Then set my other NIC to connect to my domain.  No matter what it kept freaking out about the two gatways, even though you would think Adapter Priority rules would handle this.  So if I tried to browse the internet it would ignore the highest priority NIC and go to my domain NIC.

    I hope MS takes your app into consideration as it's kind of annoying that they do not have this figured out.  Almost like they never had more then one NIC on their test machines.  =-)

    Amaranthe
    Monday, December 21, 2009 4:37 PM
  • Aurtur Xie,

    Where does Windows 7 come up with the metric values when you have multiple NICs installed?  The adapter priority definitely doesn't seem to make a difference.

    Amaranthe
    Monday, December 21, 2009 4:49 PM
  • 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

    Monday, December 21, 2009 5:39 PM
  • 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

    Monday, April 12, 2010 6:49 PM
  • 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?

    Thursday, October 14, 2010 12:04 AM