Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Desired behavior

When an application sends a packet to the global broadcast IP address 255.255.255.255, I would like that the packet 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 seems to work. Windows XP and Windows 7 exhibit different behaviors about this, and neither behaviour is desirable for my situation.

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
  • On adapter 2: 192.168.0.1 => 255.255.255.255
  • On adapter 3: 192.168.0.1 => 255.255.255.255

    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 I'd like it to do.

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 as expected to one interface, which in practice is equivalent to the Windows 7 behavior.

The goal

I want to change this 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 supported configuration change (registry hack or similar), but I'm open to all suggestions.

Any ideas?

share|improve this question
    
What are you using to generate these broadcasts. I can't get my XP stack to do anything but directed broadcasts. i.e. 10.202.255.255 in your case. –  Scott Lundberg Oct 7 '09 at 12:42
    
Can you reference an RFC or other document that indicates the Correct Behavior you describe? While I agree it's desired behavior, to call it correct behavior should reference a spec that defines what is correct. Could it be that the specific routing implementation is left up to the provider (Microsoft in this case)? –  Jason R. Coombs Oct 7 '09 at 13:17
    
Scott Lundberg: many applications (especially games) will send global broadcast. You can generate some using netcat: "nc -v -u 255.255.255.255 5000" for example. –  e-t172 Oct 7 '09 at 13:26
    
Jason R. Coombs: indeed, maybe I had a poor choice of words. I should have used "desirable behavior". I don't think there is a RFC for this, but I may be wrong. –  e-t172 Oct 7 '09 at 13:29
    
Are you sending a TCP or UDP packet? According to this that matters social.msdn.microsoft.com/Forums/en/peertopeer/thread/…. –  Nissan Fan Oct 7 '09 at 16:38

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
2  
Thanks for putting it unter GPL –  PEra Nov 1 '09 at 0:02
    
As the windows stack is a fork of the BSD stack, I'm curious to know if BSD exhibits the same behaviour. –  x0n Apr 22 '11 at 14:20

Not that I am in the business of defending Microsoft, but after reading through the following RFCs which attempt to define how broadcasts work, I don't think that Microsoft is necessarily violating any RFCs. IMO the problem should be fixed at the application level (i.e. directed broadcasts, not global) which will hit the appropriate routes in the routing table and only be sent from the correct interface for that IP network.

They both state that there is no standard defined for broadcasts. It also mentions in 919 that a specific physical interface should be selected for the broadcast. In the case of a multi-homed, multi-NIC machine generating the broadcast, I don't think that it's clearly stated what should happen. Broadcasts are never supposed to be passed by routers from one interface to the other, so is the Windows machine a router or not in this case?
If it is acting as a router, then any host responding to the broadcast with the incorrect IP address for that network (Adapters 2 and 3 in your example) should send the packet back to the ethernet address of Adapters 2 and 3 in response to Adapter 1's IP address and the Windows host should route it to the proper interface.
That sounds confusing... but can't think of a better way to phrase this

And finally, RFC 919 specifically says From RFC 919

Since we assume that the problem has already been solved at the data link layer, an IP host wishing to
send either a local broadcast or a directed broadcast need only
specify the appropriate destination address and send the datagram as
usual. Any sophisticated algorithms need only reside in gateways.

Reading that would suggest that the source IP address is irrelevant for a broadcast.


Since each application seems to handle broadcasts differently, I think that's where the responsibility resides. For example. nbtstat sends out directed broadcasts on multi-NICed machines, whereas games might use global broadcasts.
In short, the application should be fixed, not the OS in this case...

EDIT: Here is a link for the same circumstances, but on Linux. The linux kernel handles it by only sending one packet out the default interface (NIC A in this example). They recommend that the application enumerate the NICs and send a directed broadcast out each NIC. Link

share|improve this answer
1  
In don't understand the relation between the paragraph you're quoting from RFC 919 and the source address. It seems obvious to me that it is always wrong to send an IP packet on an interface with the source address of another interface, regardless of the broadcast/unicast nature of the packet. I mean, you can't reasonably say "the source IP address is irrelevant for a broadcast", of course it is! How else are applications supposed to know who sent the broadcast? –  e-t172 Oct 7 '09 at 15:24
1  
"It also mentions in 919 that a specific physical interface should be selected for the broadcast." Where? "The address 255.255.255.255 denotes a broadcast on a local hardware network" (RFC919 7.)? In that case I respectfully disagree. We're discussing what to do with broadcasts at the host level, not at the network level. Besides, it is said just below that a host may "broadcast to all of its immediate neighbors by using 255.255.255.255". All its immediate neighbours. Not "all the neighbours on a specific network interface". –  e-t172 Oct 7 '09 at 15:32
1  
"Applications don't care which interface sent the broadcast. They just need to respond to it." Huh... they need to send broadcasts too, not only respond to them. Consider the case of a LAN gameserver browser. It sends broadcast packets to discover game servers on the network. If the broadcast packets are not sent to all interfaces, the gameserver browser will not show game servers reachable through these interfaces. In other words, epic fail. –  e-t172 Oct 7 '09 at 16:52
1  
"I am not sure, but I think that the OS is seeing 255.255.255.255 request and saying that it needs to send that out on all interfaces (to find all immediate neighbors), but it was requested from a specific application, bound to a specific IP (might be default based on metric)." I agree. That doesn't mean it's the Right Thing To Do. In my opinion it completely violates the principle of least surprise from the point of view of the application developer, who just expects to have the packet sent to everyone on all interfaces. –  e-t172 Oct 7 '09 at 16:55
4  
Not sure what you mean by duplicated. The RFCs specifically forbid forwarding of broadcast packets. There should only be one packet sent, which I think is the whole crux of our discussion. If the OS were to do as you say, it would actually have to generate 9 total packets (3 for each interface) because the IP layer would have to generate three packets with separate source IPs (one for each NIC at Layer 3) and then each NIC would have to send those out on the Ethernet (Layer 2). If there were routes between networks, then you get 3 responses back! Which one is right? –  Scott Lundberg Oct 7 '09 at 18:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.