Problem receiving UDP broadcast packets.

Problem receiving UDP broadcast packets.

Post by Grant Edward » Thu, 21 Apr 2011 08:19:31



I'm trying to receive UDP broadcast packets.  It's not working, and
I'm stumped.

Here's my test program:

------------------------------------------------------------------------
#include <stdlib.h>
#include <string.h>
#include <netdb.h>
#include <stdio.h>

void error(const char *msg)
{
  perror(msg);
  exit(0);

Quote:}

int main(int argc, char *argv[])
{
  int sock, n;
  struct sockaddr_in server;
  char buf[1024];
  int one = 1;

  if (argc < 2)
    {
      fprintf(stderr, "ERROR, no port provided\n");
      exit(0);
    }

  sock=socket(AF_INET, SOCK_DGRAM, 0);

  if (sock < 0)
    error("Opening socket");

  if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one))
    error("setsockopt SO_REUSEADDR");

  if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &one, sizeof one))
    error("setsockopt SO_BROADCAST");

  bzero(&server, sizeof server);
  server.sin_family=AF_INET;
  server.sin_addr.s_addr=INADDR_ANY;
  server.sin_port=htons(atoi(argv[1]));

  if (bind(sock,(struct sockaddr *)&server, sizeof server)<0)
    error("binding");

  while (1)
    {
      n = recv(sock,buf,(sizeof buf)-1,0);
      if (n < 0)
        error("recv");
      buf[n] = '\0';
      printf("rx: '%s'\n",buf);
    }

Quote:}

------------------------------------------------------------------------

Here's the tcpdump output showing that broadcast packets are being
received on the eth1 interface on the receiving machine:

   04:01:37.329967 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
        0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
        0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
        0x0020:  ffff 1392 1392 0015 7165 3133 3033 3235
        0x0030:  3435 3639 2e30 3100 0000
   04:01:38.149948 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
        0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
        0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
        0x0020:  ffff 1392 1392 0015 6f5d 3133 3033 3235
        0x0030:  3435 3639 2e38 3300 0000

But, the test program doesn't never sees the broadcast packets unless
the source IP address in the broadcast packets is on the same subnet
as the receiving machine's interface.

In the test case above the sending machine is 10.0.0.1/8 and the
receiving machine is 172.16.12.34/16.  But, since the packets are
destined for IP address 255.255.255.255, they should be received since
255.255.255.255 matches 172.16.12.34/16. Right?

I know the're being received by the interface, since tcpdump sees
them.  They should be passed up the stack, since iptables says
everything is being accepted:

   # /sbin/iptables -L
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination        

   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination        

   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination        

So I'm stumped as to why my program isn't receiving the broadcast
packet.

Any ideas?

--
Grant Edwards               grant.b.edwards        Yow! Eisenhower!!  Your
                                  at               mimeograph machine upsets
                              gmail.com            my stomach!!

 
 
 

Problem receiving UDP broadcast packets.

Post by Bill Marcu » Fri, 22 Apr 2011 01:11:58



Quote:> Here's the tcpdump output showing that broadcast packets are being
> received on the eth1 interface on the receiving machine:

>    04:01:37.329967 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>         0x0020:  ffff 1392 1392 0015 7165 3133 3033 3235
>         0x0030:  3435 3639 2e30 3100 0000
>    04:01:38.149948 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>         0x0020:  ffff 1392 1392 0015 6f5d 3133 3033 3235
>         0x0030:  3435 3639 2e38 3300 0000

> But, the test program doesn't never sees the broadcast packets unless
> the source IP address in the broadcast packets is on the same subnet
> as the receiving machine's interface.

I think you need to set the interface to promiscuous mode.

--
A wise man cannot be insulted. If the insult has no meaning, he ignores
it. If the insult does have meaning, he deserves it.

 
 
 

Problem receiving UDP broadcast packets.

Post by Tauno Voipi » Fri, 22 Apr 2011 03:47:42



> I'm trying to receive UDP broadcast packets.  It's not working, and
> I'm stumped.

> Here's the tcpdump output showing that broadcast packets are being
> received on the eth1 interface on the receiving machine:

>    04:01:37.329967 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>         0x0020:  ffff 1392 1392 0015 7165 3133 3033 3235
>         0x0030:  3435 3639 2e30 3100 0000
>    04:01:38.149948 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>         0x0020:  ffff 1392 1392 0015 6f5d 3133 3033 3235
>         0x0030:  3435 3639 2e38 3300 0000

> But, the test program doesn't never sees the broadcast packets unless
> the source IP address in the broadcast packets is on the same subnet
> as the receiving machine's interface.

> In the test case above the sending machine is 10.0.0.1/8 and the
> receiving machine is 172.16.12.34/16.  But, since the packets are
> destined for IP address 255.255.255.255, they should be received since
> 255.255.255.255 matches 172.16.12.34/16. Right?

The IP address 255.255.255.255 is the local subnet broadcast
address, this time equivalent to 10.255.255.255. It must not
traverse routers, and the receiving IP stack in a different
subnet is free to ignore them as martians.

You should not have two local subnets running in the
same physical local net segment, and suppose that they
will be routed as a single local net.

--

Tauno Voipio

 
 
 

Problem receiving UDP broadcast packets.

Post by Grant Edward » Fri, 22 Apr 2011 06:20:00




>> Here's the tcpdump output showing that broadcast packets are being
>> received on the eth1 interface on the receiving machine:

>>    04:01:37.329967 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>>         0x0020:  ffff 1392 1392 0015 7165 3133 3033 3235
>>         0x0030:  3435 3639 2e30 3100 0000
>>    04:01:38.149948 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>>         0x0020:  ffff 1392 1392 0015 6f5d 3133 3033 3235
>>         0x0030:  3435 3639 2e38 3300 0000

>> But, the test program doesn't never sees the broadcast packets unless
>> the source IP address in the broadcast packets is on the same subnet
>> as the receiving machine's interface.

> I think you need to set the interface to promiscuous mode.

Nope.  The interface is already receiving the packets or tcpdump
wouldn't see them.

What I had to do was disable reverse-path filtering:

  # echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
  # echo 0 > /proc/sys/net/ipv4/conf/ethN/rp_filter

--
Grant Edwards               grant.b.edwards        Yow! Are we wet yet?
                                  at              
                              gmail.com            

 
 
 

Problem receiving UDP broadcast packets.

Post by Grant Edward » Fri, 22 Apr 2011 06:32:09




>> I'm trying to receive UDP broadcast packets.  It's not working, and
>> I'm stumped.

>> Here's the tcpdump output showing that broadcast packets are being
>> received on the eth1 interface on the receiving machine:

>>    04:01:37.329967 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>>         0x0020:  ffff 1392 1392 0015 7165 3133 3033 3235
>>         0x0030:  3435 3639 2e30 3100 0000
>>    04:01:38.149948 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
>>         0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
>>         0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
>>         0x0020:  ffff 1392 1392 0015 6f5d 3133 3033 3235
>>         0x0030:  3435 3639 2e38 3300 0000

>> But, the test program doesn't never sees the broadcast packets unless
>> the source IP address in the broadcast packets is on the same subnet
>> as the receiving machine's interface.

>> In the test case above the sending machine is 10.0.0.1/8 and the
>> receiving machine is 172.16.12.34/16.  But, since the packets are
>> destined for IP address 255.255.255.255, they should be received since
>> 255.255.255.255 matches 172.16.12.34/16. Right?

> The IP address 255.255.255.255 is the local subnet broadcast address,
> this time equivalent to 10.255.255.255.

Hmm. I don't understand what you mean by that.  255.255.255.255 is
definitely different than 10.255.255.255 -- sending to the two
produces different packets and different results in the receiving
device.

Quote:> It must not traverse routers, and the receiving IP stack in a
> different subnet is free to ignore them as martians.

Indeed. Disabling reverse-path filtering [which was the $64 answer]
allows me to receive on the 172.16.12.34 device the "martians" sent to
255.255.255.255 from 10.0.0.1.

Quote:> You should not have two local subnets running in the same physical
> local net segment, and suppose that they will be routed as a single
> local net.

Standard Excuse #17B: I didn't invent the protocol, I'm just
implementing it.

FWIW, I don't suppose they are routed at all -- all I'm worried about
are devices on a single Ethernet segment.  The whole point of the
exercise is to implement a UDP-based device discovery and
configuration protocol that's used to find unconfigured or
misconfigured devices [which are running Linux] on an Ethernet segment
and configure them so they _are_ all on the right subnet.

In some ways (at least under Linux) it would be simpler and easier to
use a custom non-IP protocol at the Ethernet datagram level.  However,
doing stuff like that under Windows seems to cause sufficient pain and
suffering that jumping through hoops to get UDP to work in the desired
manner is a net win.

--
Grant Edwards               grant.b.edwards        Yow! HUMAN REPLICAS are
                                  at               inserted into VATS of
                              gmail.com            NUTRITIONAL YEAST ...

 
 
 

Problem receiving UDP broadcast packets.

Post by David Schwart » Fri, 22 Apr 2011 07:48:43



Quote:> So I'm stumped as to why my program isn't receiving the broadcast
> packet.

> Any ideas?

RFC919 specifies that the behavior of broadcasting to 255.255.255.255
be identical to the effect of broadcasting to the subnet-local
broadcast address. RFC922 clarified this rule -- in the absence of
VLSM, there is no difference between a subnet broadcast address and
the all one's address.

"Thus, a host on net 36, for example, may:
      - broadcast to all of its immediate neighbors by using
        255.255.255.255
      - broadcast to all of net 36 by using 36.255.255.255
   without knowing if the net is subnetted; if it is not, then both
   addresses have the same effect."
- RFC 922 "Broadcasting Internet Datagrams in the Presence of Subnets"

In effect, 255.255.255.255 means *this* subnet, not *any* subnet.

DS

 
 
 

Problem receiving UDP broadcast packets.

Post by David Schwart » Fri, 22 Apr 2011 07:50:10



Quote:> FWIW, I don't suppose they are routed at all -- all I'm worried about
> are devices on a single Ethernet segment. ?The whole point of the
> exercise is to implement a UDP-based device discovery and
> configuration protocol that's used to find unconfigured or
> misconfigured devices [which are running Linux] on an Ethernet segment
> and configure them so they _are_ all on the right subnet.

Wrong tool for the job. How can you expect subnet-local broadcasts to
find devices that are configured in the wrong subnet?

DS

 
 
 

Problem receiving UDP broadcast packets.

Post by Rick Jone » Sun, 24 Apr 2011 02:26:44




> > I think you need to set the interface to promiscuous mode.
> Nope.  The interface is already receiving the packets or tcpdump
> wouldn't see them.

Tcpdump tends to put the interface into promiscuous mode.

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

 
 
 

Problem receiving UDP broadcast packets.

Post by Grant Edward » Mon, 25 Apr 2011 00:01:47





>> > I think you need to set the interface to promiscuous mode.

>> Nope.  The interface is already receiving the packets or tcpdump
>> wouldn't see them.

> Tcpdump tends to put the interface into promiscuous mode.

Not if you use the -p option.

--
Grant

 
 
 

1. How to receive UDP and ICMP packet using one UDP socket, (Path MTUD)

Dear All,

Can we configure one socket to receive two different protocols packet.
Like how can we made a UDP socket to receive udp as well as icmp
messages.

Actually I am implementing Path MTUD, so for that I sent some udp
probs to destination host, now I want that the same socket at client
side must be able to receive both udp response and icmp error
messages(like host unreachable, port unreachable etc).

Another approach is that, we will use two sockets for both source and
destination, form source we will send udp probs(through udp socket)
while at destination host, after receiving that prob(through udp
socket), application will make an icmp packet and sent it back to the
source host (using ICMP socket). And here at source host, that message
and other icmp error messages will be received by icmp socket.

But this approch dosen't look efficient to me, what u people say? If
Any one has another approch plz let me know.

Eagerly waiting for some +ve pings.

2. User-friendliness

3. problems sending UDP packet to broadcast addr

4. Cascaded group administration not correct.

5. How to receive udp broadcasts?

6. I'm confused on why this doesn't work

7. Receive broadcast UDP and directed TCP on same port?

8. A few questions

9. question on sending/receiving broadcast packets

10. receiving broadcast packet on a socket

11. udp broadcast packet size limit?

12. reply to broadcast packets to UDP port 177 (XDM)

13. Unknown UDP Broadcast packets