locked
Broadcast packet routing on multiple networks RRS feed

  • Question

  • I have written a Windows application that sends a UDP broadcast message packet over the network to attempt to locate devices that reside on the same network.  The devices listen for this message and respond with their IP addresses and a list of devices is displayed for the user to select from so they can connect.  If there is only 1 network active on my PC, this works fine.  But if the application is running on a PC that resides on both wired and wireless networks at the same time, the broadcast packet is going to wireless network, but not the wired network, which is where the devices reside. 

    Here are the broadcast-ish looking entries in my routing table using ROUTE PRINT:

      255.255.255.255  255.255.255.255       10.12.4.64      10.12.4.64       1
      255.255.255.255  255.255.255.255    172.16.254.63   172.16.254.63       1

    The 10.* network is the wireless and the 172* network is the wired network where the devices reside.  They both appear to have the same metric (1).

    I have tried, but Windows will NOT let me use ROUTE DELETE, ROUTE ADD, or ROUTE CHANGE with an entry of 255.255.255.255 to alter the route.   For example:

    D:\home>route delete 255.255.255.255
    route: bad destination address 255.255.255.255

    I have verified that the broadcast packet is going down the 10* network, but not the 172* network using Wireshark.  When I disable the 10* network, the 10 network's route disappears from the route table and everything works fine.  But having to disable one of my networks like that is a pain.

    So my question is:  is there some way to route my broadcast packet down the 172* network rather than the 10* network using the ROUTE command or by some other means either on the command line or within the application itself in code?

    Thanks..
    -+JD Farndon


    Visual C++ Developer
    Monday, May 18, 2009 10:38 PM

All replies

  • Call winsock bind call with interface ip address before sending the broadcast message. When you bind the socket to a particular interface, tcp/ip finding the best route part & using it is skipped.
    Wednesday, May 20, 2009 1:22 PM
  • The socket is a SOCK_DGRAM type socket (UDP) and is bound using IN_ADDR_ANY for an address (because its a broadcast).  Not sure what you mean by "bind the socket to a particular interface".   I don't specify my interface... I use IN_ADDR_ANY.   I don't really know my address ahead of time as I am a DHCP client (as are the devices I'm trying to talk to).  Again, it works fine if I am only on a single network.  It fails when I am on multiple networks (as described previously) because the broadcast packet goes down the wrong network.  


    Visual C++ Developer
    Wednesday, May 20, 2009 9:17 PM
  • When   u try to send a UDP data over socket to destination this occurs:
    1) Socket asks the TCP/IP to send a packet to the destination
    2) TCP/IP checks whether the socket is bound to a address if its bound its uses the bound  ipaddress as source address & flows via the same network interface. 
    3) IF the socket is unbound then applies the route rules on the destination & finds the best match. That interface ip address is given as source address to the outgoing packet. In your case the broadcast address best route matches with 10  network so it flows via the 10* network interface.
    If you bound with IN_ADDR_ANY , you can receive UDP broadcast from all network adapters. But when to send a UDP packet, the route rules are applied to find source address & network interface.
    otherway to do , but not recommended method is:
    U can try changing the metric value of the broadcast route.
    Monday, May 25, 2009 6:08 AM
  • I can't bind to a particular socket on the 172 network since that's what I'm trying to figure out (what the address of the device even is).  So that is why I use the IN_ADDR_ANY - I am broadcasting to unknown addresses on the network.

    I agree with what you said... it uses the route table to select which network to send the packet down.  The trouble is, the network table is in the wrong order for it to work the way I want.   If I could change the routing table, that would work.  But as I stated in my original post, windows will not let me change the routing table for the entries.

    From above, here are the last two entries in my routing table:

    255.255.255.255  255.255.255.255       10.12.4.64      10.12.4.64       1
    255.255.255.255  255.255.255.255    172.16.254.63   172.16.254.63       1

    I want my broadcast packets to go down the 172 network, but they go down the 10 network (because of the routing order, I assume).

    The problem is, as I said before, I cannot use the ROUTE command to alter, delete, or reorder the 255.255.255.255 entries.
    I get this error:

    route: bad destination address 255.255.255.255

    So this is why I was looking for another solution.  (and that brings us back to doe).





    Visual C++ Developer
    Thursday, May 28, 2009 3:13 PM


  • So this is why I was looking for another solution.  (and that brings us back to doe).


    Hello,

    I have a similar problem and I just read your thread. It's been a few months since you posted it that's why I'd like to ask if you found a solution after all?

    thanks

    Anestis
    Tuesday, October 27, 2009 7:05 PM

  • According to the rules of IPv4, the broadcast address 255.255.255.255 is not routable. Such a broadcast is restricted to the local network segment. Broadcasts might be bridged if the underlying spanning tree network allows for broadcast storms and can prune circular network topology.

    To have a routable broadcast IPv4, you need to specify a network prefix with the host part of the address being all ones.

    A routable subnet broadcast address of 10.255.255.255 requires a netmask of 255.0.0.0.

    A routable subnet broadcast address of 172.16.255.255 requires a netmask of 255.255.0.0.

    Microsoft operating systems have their own issues with multi-homed network access.

    Hope this helps,
    Steve

    Good systems are supportable
    Saturday, November 7, 2009 10:54 PM
  • The original post said he was trying to communicate with other clients who also may not have had their IPs set yet

    "I don't really know my address ahead of time as I am a DHCP client (as are the devices I'm trying to talk to)"

    He may not be able to communicate outside his local network segment with 255.255.255.255 since routers typically won't route that, but switches only care about MAC addresses.

    His solution was to send out a broadcast on his desired network device based on the IP. Chicken and the egg. Like someone said, he would have to bind to the NIC instead of binding to the IP. Another way around would be to use raw sockets and communicate over the local switches using your own protocol. I don't know what is trying to be done since it's strange to not have an IP.

    I haven't done socket programming, but I have had to setup my share of servers/routers/switches and manually create packets to broadcast/etc.
    Friday, November 13, 2009 10:30 PM