Searching \ for '[EE] Receiving broadcast UDP packets' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/atod.htm?key=adc
Search entire site for: 'Receiving broadcast UDP packets'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Receiving broadcast UDP packets'
2006\01\10@110308 by Herbert Graf

picon face
Hello everyone, was wondering if someone out there might be able to help
me with something.

I have a device on my network that sends out broadcast packets (ip
255.255.255.255).

I would like to write a linux program that receives these packets on
another machine.

I pulled out a linux socket programming example from University that
works fine for unicast packets and have been trying to modify it for
broadcast packets. I have it set to the correct port, but it never sees
any of the broadcast packets.

I've set SO_BROADCAST with set_sockopt but it didn't improve things.

Is there a trick to enabling the reception of broadcast packets?

Does anyone have a compilable example of a problem that receives
broadcast UDP packets?

Thanks for any help. TTYL
--

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\10@112157 by Peter Onion

flavicon
face

> I've set SO_BROADCAST with set_sockopt but it didn't improve things.

I think that only applies to sending to the broadcast address.

> Is there a trick to enabling the reception of broadcast packets?

Set the bind address to INADDR_BROADCAST

       Name.sin_family = AF_INET;
       Name.sin_addr.s_addr = INADDR_BROADCAST;
       Name.sin_port = htons(potrNumber);

       Bind(rxSocket,(struct sockaddr *) &Name,sizeof(name));

Peter

2006\01\10@115958 by Alex Harford

face picon face
On 1/10/06, Herbert Graf <spam_OUThgrafTakeThisOuTspamemail.com> wrote:
>
> Is there a trick to enabling the reception of broadcast packets?
>
> Does anyone have a compilable example of a problem that receives
> broadcast UDP packets?

I wonder if your networking equipment is sending out the packets with
a broadcast of 255.255.255.255 (ie every node on the internet).

Use ethereal to do a capture to see if your computer is actually
seeing those packets.  You may need to use a more specific mask
(192.168.0.255) or change your switch/router's settings.

Alex

2006\01\10@121353 by olin piclist

face picon face
Herbert Graf wrote:
> I pulled out a linux socket programming example from University that
> works fine for unicast packets and have been trying to modify it for
> broadcast packets. I have it set to the correct port, but it never sees
> any of the broadcast packets.

Are you sure the source isn't on the other side of a router?

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\10@121547 by M Graff

flavicon
face
Alex Harford wrote:

> I wonder if your networking equipment is sending out the packets with
> a broadcast of 255.255.255.255 (ie every node on the internet).

255.255.255.255 is still only local.  Switches will propagate it (since
it has an ethernet destination of broadcast as well) but routers won't
(typically) route it.

Most modern Unix-like implementations (including the one I use, NetBSD)
will send on a more specific subnet of (say) 10.42.255.255 for a
10.42.0.0/16 ethernet, but will still accept 255.255.255.255.  This
allows "supernetting" -- running more than one logical network on top of
the same physical ethernet without vlans.  It gets confusing, but in
certain limited environments it works well enough.  Modern
implementations of IP are encouraged to send on interface-specific
broadcast addresses only.

> Use ethereal to do a capture to see if your computer is actually
> seeing those packets.  You may need to use a more specific mask
> (192.168.0.255) or change your switch/router's settings.

It won't require any switch or router settings unless the switch is a IP
switch.  If it is just a plug-it-in-and-it-goes switch (linksys, etc) it
switches ethernet frames, not IP.

--Michael

2006\01\10@121646 by Herbert Graf

flavicon
face
On Tue, 2006-01-10 at 16:21 +0000, Peter Onion wrote:
>  > I've set SO_BROADCAST with set_sockopt but it didn't improve things.
>
> I think that only applies to sending to the broadcast address.

Hmm, see, there was some conflicting information on that. Some man pages
send it was for reception and transmission, others just for
transmission. Thanks for the clearing that one up!

> > Is there a trick to enabling the reception of broadcast packets?
>
> Set the bind address to INADDR_BROADCAST
>
>        Name.sin_family = AF_INET;
>        Name.sin_addr.s_addr = INADDR_BROADCAST;
>        Name.sin_port = htons(potrNumber);
>
>        Bind(rxSocket,(struct sockaddr *) &Name,sizeof(name));

Hmm, odd, that's the last thing I tried, to no avail. Is it possible
that INADDR_BROADCAST only responds to certain broadcast addresses, i.e.
192.168.1.255 but NOT 255.255.255.255?

Have you seen a small example that you were able to get working?

Thanks for the help. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\10@121827 by Herbert Graf

flavicon
face
On Tue, 2006-01-10 at 08:59 -0800, Alex Harford wrote:
> On 1/10/06, Herbert Graf <.....hgrafKILLspamspam@spam@email.com> wrote:
> >
> > Is there a trick to enabling the reception of broadcast packets?
> >
> > Does anyone have a compilable example of a problem that receives
> > broadcast UDP packets?
>
> I wonder if your networking equipment is sending out the packets with
> a broadcast of 255.255.255.255 (ie every node on the internet).
>
> Use ethereal to do a capture to see if your computer is actually
> seeing those packets.  You may need to use a more specific mask
> (192.168.0.255) or change your switch/router's settings.

Etherreal does indeed show the packets as destination ff:ff:ff:ff at the
MAC layer, and 255.255.255.255 on the IP layer. Is this wrong?

Another thing, do you think running Etherreal in promiscuous mode would
mess up reception of broadcast packets?

Thanks, TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\10@123120 by Peter Onion

flavicon
face


{Quote hidden}

Yes I think that's right (and what I would expect).

If your device is really sending to 255.255.255.255 I think it is
misconfigured !  It SHOULD be sending to the broadcast address for the
subnet to which it belongs (i.e. 192.168.1.255) !

I'm not sure that 255.255.255.255 is even a valid broadcast address ?

>
> Have you seen a small example that you were able to get working?

I don't have a "small example", but that code was taken from a working
application that uses broadcast udp packets to find other versions of it
self running on the local network.

Peter




> Thanks for the help. TTYL
>
> -----------------------------
> Herbert's PIC Stuff:
> http://repatch.dyndns.org:8383/pic_stuff/
>
> -

2006\01\10@123720 by William Couture

face picon face
On 1/10/06, Herbert Graf <EraseMEhgrafspam_OUTspamTakeThisOuTemail.com> wrote:
> Hello everyone, was wondering if someone out there might be able to help
> me with something.
>
> I have a device on my network that sends out broadcast packets (ip
> 255.255.255.255).
>
> I would like to write a linux program that receives these packets on
> another machine.

Your broadcast addres should complement your subnet mask and
IP address.

For example, if you have a local subnet of 192.168.1.x, and a netmask
of 255.255.255.0, your broadcast address should be 192.168.1.255

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\01\10@125843 by Alex Harford

face picon face
On 1/10/06, Herbert Graf <mailinglist2spamspam_OUTfarcite.net> wrote:
>
> Etherreal does indeed show the packets as destination ff:ff:ff:ff at the
> MAC layer, and 255.255.255.255 on the IP layer. Is this wrong?
>
> Another thing, do you think running Etherreal in promiscuous mode would
> mess up reception of broadcast packets?

Not in my experience.

Alex

2006\01\10@130930 by Herbert Graf

flavicon
face
On Tue, 2006-01-10 at 12:14 -0500, Olin Lathrop wrote:
> Herbert Graf wrote:
> > I pulled out a linux socket programming example from University that
> > works fine for unicast packets and have been trying to modify it for
> > broadcast packets. I have it set to the correct port, but it never sees
> > any of the broadcast packets.
>
> Are you sure the source isn't on the other side of a router?

Yup. Etherreal (a packet sniffer) sees the broadcast packets on the same
machine as I'm running the program on, so the packets are physically
getting to the machine, it just appears that Linux isn't passing them
on.

Thanks, TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\10@134225 by Danny Sauer

flavicon
face
Herbert wrote regarding '[EE] Receiving broadcast UDP packets' on Tue, Jan 10 at 10:06:
> I have a device on my network that sends out broadcast packets (ip
> 255.255.255.255).

Presumably you know the destination port as well? :)

> I pulled out a linux socket programming example from University that
> works fine for unicast packets and have been trying to modify it for
> broadcast packets. I have it set to the correct port, but it never sees
> any of the broadcast packets.

Are you sure you've set it to the *correct* port?  As far as I know,
that's all you need to do.  In order to test that, I just wrote a
client and server in perl, and the same client works fine with
directed UDP data as with broadcasts.  That's one of the appeals of
UDP...

The client's pretty darned complicated.  Feel free to use it instead
of bashing your head against the C wall. :)  If you're on Linux,
surely you have perl installed.

   #!/usr/bin/perl -w
   use IO::Socket;
   my $udp = new IO::Socket::INET (LocalPort => 12344,
                                   Proto     => 'udp',
                                  ) or die "$! \n";
   my $buffer;
   while($udp->recv($buffer, 4096)){
           print "$buffer\n";
   }

The server's pretty simple, too, just for the sake of completeness
(and because it could be useful while you're testing):

   #!/usr/bin/perl -w
   use IO::Socket;
   my $peer = shift or
              die "usage: $0 destination_addr\n";
   my $udp = new IO::Socket::INET (PeerPort  => 12344,
                                   Proto     => 'udp',
                                   PeerAddr  => $peer,
                                   Broadcast => 1,
                                  ) or die "$! \n";
   while(<>){
           chomp;
           last unless $_;
           $udp->write($_);
   }

Setting the broadcast flag to 1 doesn't really affect unicast packets,
in case you're wondering about that...  Anyway, the client responds to
messages sent to 255.255.255.255, the interface's broadcast address,
and the target machine's IP.

--Danny

2006\01\10@142508 by Gerhard Fiedler

picon face
Peter Onion wrote:

> I'm not sure that 255.255.255.255 is even a valid broadcast address ?

It is valid. One RFC for this is 919 <http://www.ietf.org/rfc/rfc919.txt>

It says about 255.255.255.255: "The address 255.255.255.255 denotes a
broadcast on a local hardware network, which must not be forwarded.  This
address may be used, for example, by hosts that do not know their network
number and are asking some server for it."

Sounds like any router or gateway is (or should be) a barrier for this
address, but otherwise it's fine to use.

Gerhard

2006\01\10@153111 by Peter Onion

flavicon
face
On Tue, 2006-01-10 at 17:24 -0200, Gerhard Fiedler wrote:
> Peter Onion wrote:
>
> > I'm not sure that 255.255.255.255 is even a valid broadcast address ?
>
> It is valid. One RFC for this is 919 <http://www.ietf.org/rfc/rfc919.txt>
>
> It says about 255.255.255.255: "The address 255.255.255.255 denotes a
> broadcast on a local hardware network, which must not be forwarded.  This
> address may be used, for example, by hosts that do not know their network
> number and are asking some server for it."

Now that I am at home I have used ethereal to look at the packets my
application sends, and they are indeed addressed to 255.255.255.255, so
the example code I  gave should work for you as well...

Peter

2006\01\10@184809 by Peter

picon face


On Tue, 10 Jan 2006, Alex Harford wrote:

{Quote hidden}

Doesn't broadcasting work in groups ? And a node must be enabled to
receive broadcast by giving it an address in the group (in addition to
the normal address) ? That's the way I remember it. Only after that does
the broadcast enter the tcp/ip stack of a client. Also the routers must
be configured to pass this traffic, else hosts won't see it. Afaik
switches (as opposed to hubs) must also be enabled for this.

See here:

http://www.linuxjournal.com/node/3041/print
http://www.tldp.org/HOWTO/Multicast-HOWTO.html

Peter

2006\01\10@200402 by Peter

picon face


On Tue, 10 Jan 2006, Herbert Graf wrote:

> Does anyone have a compilable example of a problem that receives
> broadcast UDP packets?

Look at the dhclient/dhcpd package source in addition to the links which
I have sent. Afaik you can't broadcast unless you have superuser
privileges as broadcasting and receiving requires access to the network
interface in raw (promiscuous) mode. So your program should be suid root
at least probably.

Peter

2006\01\10@213118 by kravnus wolf

picon face

> >
> > Hmm, odd, that's the last thing I tried, to no
> avail. Is it possible
> > that INADDR_BROADCAST only responds to certain
> broadcast addresses, i.e.
> > 192.168.1.255 but NOT 255.255.255.255?
>
> Yes I think that's right (and what I would expect).
>
> If your device is really sending to 255.255.255.255
> I think it is
> misconfigured !  It SHOULD be sending to the
> broadcast address for the
> subnet to which it belongs (i.e. 192.168.1.255) !
>
> I'm not sure that 255.255.255.255 is even a valid
> broadcast address ?
>


255.255.255.255 is a limited broadcast. routers do not
forward the packet. it is usually used when the subnet
and ip address of the interface is NOT known. bootp
uses this feature.

John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2006\01\10@213557 by kravnus wolf

picon face

> Doesn't broadcasting work in groups ? And a node
> must be enabled to
> receive broadcast by giving it an address in the
> group (in addition to
> the normal address) ? That's the way I remember it.

 I believe you are refering to multicast. Not quite
the same
as broadcast. Multicast use class D IP range.

John

{Quote hidden}

> --

2006\01\11@015724 by William Chops Westfield

face picon face

On Jan 10, 2006, at 3:48 PM, Peter wrote:

> Doesn't broadcasting work in groups ? And a node must be enabled to
> receive broadcast by giving it an address in the group (in addition to
> the normal address) ?

No, that's "multicasting."

Everything receives broadcasts.  There was a bunch of trouble
in the early internet days because unix was brain-dead and thought
the broadcast IP address was 0.0.0.0.  It would receive a broadcast
to 255.255.255.255, and decide that it wanted to be a router and
forward that packet, since it was obviously not for IT (did I mention
that unix was brain dead at the time?)  So it would
then ARP for 255.255.255.255 in an attempt to find out what ethernet
address to forward it to.  Of course, this was on an ethernet, and a
network segment with one unix workstation probably had a bunch
of them, and they'd ALL be trying to ARP for 255.255.255.255 AT THE
SAME TIME.  The ARP packets of course were broadcasts received by
everyone, so this ate up a lot of collective CPU cycles.  The most
amusing melt-down I heard of happened when some helpful device
decided to ANSWER the arp request for the broadcast IP address with
the ethernet broadcast (seems reasonable, eh?  But consider what
happens next when the broken workstations actually FORWARD the
packets to that ethernet address!)

And that's why cisco made a lot of money selling routers when some
people were trying to build large networks with nothing but bridges
and repeaters (routers stop hardware broadcasts!)

BillW

2006\01\11@172500 by Peter

picon face

On Tue, 10 Jan 2006, William Chops Westfield wrote:

> On Jan 10, 2006, at 3:48 PM, Peter wrote:
>
>> Doesn't broadcasting work in groups ? And a node must be enabled to
>> receive broadcast by giving it an address in the group (in addition to
>> the normal address) ?
>
> No, that's "multicasting."

Ok, my confusion. Point taken wrt. Unix being broken ;-) When was that
and which *nix was broken ?

Peter

2006\01\12@003407 by William Chops Westfield

face picon face

On Jan 11, 2006, at 2:24 PM, Peter wrote:
>> [multicast vs broadcast, and "broadcast storms."]
> Ok, my confusion. Point taken wrt. Unix being broken ;-) When was
> that and which *nix was broken ?

Mid to late 1980s.  It was 4.2BSD that had "odd" ideas about
internet addresses and such; that was about the only network-aware
unix that existed at the time, and everyone who could was copying
their network code.   I was working at Stanford at the
time, and the big offenders as far as machines went were the early
SUN workstations, which were found there in abundance.  (SUN being
a Stanford spinoff...)

It was about that time that the unix-haters mailing list was
active, mainly holding mainframe and lisp machine people who
were decrying the unix philosophy of ... ignoring other philosophies.
It was/is very disorienting that unix is now "the good guy."

BillW

2006\01\12@010544 by kravnus wolf

picon face
What was wrong with Unix in the past? Why a "bad" guy?

John



--- William Chops Westfield <KILLspamwestfwKILLspamspammac.com> wrote:

{Quote hidden}

> --

2006\01\12@014840 by William Chops Westfield

face picon face
On Jan 11, 2006, at 10:05 PM, kravnus wolf wrote:

> What was wrong with Unix in the past?  Why a "bad" guy?

I really don't want to get into that here.  The nay-sayers are
all gone, and unix has survived.  For the purpose of this
conversation, you can start with the fact that unix systems
decided that they were routers by default, but the code authors
hadn't read the RFCs carefully enough to get the broadcast address
right (or didn't care.)  It also foisted atrocities like a
"privileged" TCP port range, intensely insecure protocols like
rlogin, and a full set of chatty broadcast protocols of dubious
merit (rwhod, etc) (which tickled the broadcast forwarding bugs
very nicely, of course...)  And then there's "grep."

BillW

2006\01\12@044943 by kravnus wolf

picon face
But BSD was written by students :) True that Unix
has some hiccups but it has come a long way. As the
saying goes,
don't like it, change it ;)

John


--- William Chops Westfield <RemoveMEwestfwTakeThisOuTspammac.com> wrote:

{Quote hidden}

> --

2006\01\12@194132 by Tad Anhalt

picon face
kravnus wolf wrote:
> What was wrong with Unix in the past? Why a "bad" guy?

http://research.microsoft.com/~daniel/unix-haters.html

;)  <-- Note smiley

HTH,
Tad Anhalt

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...