Broadcast datagrams
Anyone hackers here sent broadcast packets? I think this is how you
do it:
#!/usr/bin/perl -w
use strict;
use Socket;
my $dst = inet_aton("172.30.255.255");
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname("udp"))
or die "socket: $!";
setsockopt(SOCKET, SOL_SOCKET, SO_BROADCAST, pack("l", 1))
or die "setsockopt: $!";
send(SOCKET, "hello", 0, sockaddr_in(6868, INADDR_BROADCAST))
#send(SOCKET, "hello", 0, sockaddr_in(6868, $dst))
or die "send: $!";
For some reason I'm getting "send: Can't assign requested address"
for INADDR_BROADCAST. How can it *not* assign that? Flipping the
comments over works fine (for that subnet) -- in other words, in my
C code, I have to spelunk the interface list with ioctl()s and then
get the sodding broadcast address. Which is a lot of work :-(
FWIW (this is on the failing machine, yes different subnet),
en0: flags=8963UP,BROADCAST,b6,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
ether 00:30:65:7e:d1:96
media: autoselect (none) status: inactive
supported media: none autoselect 10baseT/UTP half-duplex 10baseT/UTP
full-duplex 100baseTX half-duplex 100baseTX full-duplex
Any ideas?
Paul
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 03:25:09AM -0700, Paul Makepeace wrote:
Anyone hackers here sent broadcast packets? I think this is how you
do it:
#!/usr/bin/perl -w
use strict;
use Socket;
my $dst = inet_aton("172.30.255.255");
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname("udp"))
or die "socket: $!";
setsockopt(SOCKET, SOL_SOCKET, SO_BROADCAST, pack("l", 1))
or die "setsockopt: $!";
send(SOCKET, "hello", 0, sockaddr_in(6868, INADDR_BROADCAST))
#send(SOCKET, "hello", 0, sockaddr_in(6868, $dst))
or die "send: $!";
For some reason I'm getting "send: Can't assign requested address"
for INADDR_BROADCAST. How can it *not* assign that? Flipping the
comments over works fine (for that subnet) -- in other words, in my
C code, I have to spelunk the interface list with ioctl()s and then
get the sodding broadcast address. Which is a lot of work :-(
FWIW (this is on the failing machine, yes different subnet),
en0: flags=8963UP,BROADCAST,b6,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
ether 00:30:65:7e:d1:96
media: autoselect (none) status: inactive
supported media: none autoselect 10baseT/UTP half-duplex 10baseT/UTP
full-duplex 100baseTX half-duplex 100baseTX full-duplex
If you have a complete /usr/src installed, look in there for examples
of how it's done in C (it looks like you have a BSD machine - so it's
quite likely /usr/src is populated).
Darn, your example works on both the Linux and FreeBSD machines I just
tried it on. What machine are you using? On both machines, EADDRNOTAVAIL
(what you're seeing) isn't even listed as an error in the man page.
Try running perl under strace or truss or ktrace, whatever your native
tracing tool is.
-Dom
Re: Broadcast datagrams
Paul Makepeace [EMAIL PROTECTED] writes: Anyone hackers here sent broadcast packets? I think this is how you do it: Any ideas? Well covered on page 590 of Stein's book... ;-) He uses IO::Socket BTW... -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 11:49:20AM +0100, Dominic Mitchell wrote: If you have a complete /usr/src installed, look in there for examples of how it's done in C (it looks like you have a BSD machine - so it's quite likely /usr/src is populated). The weird thing is this is even happening with Apple's own nextstep bootp client (don't ask :) in C, which is originally the language I was using. I cast the example to perl just to ask here and as a sanity check. Darn, your example works on both the Linux and FreeBSD machines I just tried it on. What machine are you using? On both machines, EADDRNOTAVAIL OS X/Darwin. Thanks for checking though -- I'll keep looking. Paul
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 04:02:29AM -0700, Paul Makepeace wrote: On Wed, Apr 18, 2001 at 11:49:20AM +0100, Dominic Mitchell wrote: If you have a complete /usr/src installed, look in there for examples of how it's done in C (it looks like you have a BSD machine - so it's quite likely /usr/src is populated). The weird thing is this is even happening with Apple's own nextstep bootp client (don't ask :) in C, which is originally the language I was using. I cast the example to perl just to ask here and as a sanity check. Darn, your example works on both the Linux and FreeBSD machines I just tried it on. What machine are you using? On both machines, EADDRNOTAVAIL OS X/Darwin. Thanks for checking though -- I'll keep looking. You're probably going to have to grep through the kernel source to see why it's being returned in that case. And I have a sneaky suspicion that the networking stuff is quite changed from the "normal" BSDs... -Dom
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 12:11:45PM +0100, Dominic Mitchell wrote: You're probably going to have to grep through the kernel source to see why it's being returned in that case. And I have a sneaky suspicion that the networking stuff is quite changed from the "normal" BSDs... I've been using Rich Stevens's bible and stuff compiles copy/pasted. OK, I can't even ping 255.255.255.255 (when PPP is down, but when it's up it's OK): # ping 255.255.255.255 PING broadcasthost (255.255.255.255): 56 data bytes ping: sendto: No route to host ping: wrote broadcasthost 64 chars, ret=-1 ^C [ppp up] # ping 255.255.255.255 PING broadcasthost (255.255.255.255): 56 data bytes 64 bytes from 209.232.142.2: icmp_seq=0 ttl=255 time=163.571 ms 64 bytes from 209.232.142.2: icmp_seq=1 ttl=255 time=2954.65 ms 64 bytes from 209.232.142.2: icmp_seq=2 ttl=255 time=1968.95 ms # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default209.232.142.2 UGSc30 ppp0 127.0.0.1 127.0.0.1 UH 9 2099 lo0 192.168link#2 UC 00 en0 192.168.0.10:30:65:7e:d1:96 UHLW0 14 lo0 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 08 en0 So for whatever reason it's not being recognized and turned into an Ethernet 48bit broadcast. Paul
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 04:26:56AM -0700, Paul Makepeace wrote: On Wed, Apr 18, 2001 at 12:11:45PM +0100, Dominic Mitchell wrote: You're probably going to have to grep through the kernel source to see why it's being returned in that case. And I have a sneaky suspicion that the networking stuff is quite changed from the "normal" BSDs... I've been using Rich Stevens's bible and stuff compiles copy/pasted. OK, I can't even ping 255.255.255.255 (when PPP is down, but when it's up it's OK): # ping 255.255.255.255 PING broadcasthost (255.255.255.255): 56 data bytes ping: sendto: No route to host ping: wrote broadcasthost 64 chars, ret=-1 ^C [ppp up] # ping 255.255.255.255 PING broadcasthost (255.255.255.255): 56 data bytes 64 bytes from 209.232.142.2: icmp_seq=0 ttl=255 time=163.571 ms 64 bytes from 209.232.142.2: icmp_seq=1 ttl=255 time=2954.65 ms 64 bytes from 209.232.142.2: icmp_seq=2 ttl=255 time=1968.95 ms # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default209.232.142.2 UGSc30 ppp0 127.0.0.1 127.0.0.1 UH 9 2099 lo0 192.168link#2 UC 00 en0 192.168.0.10:30:65:7e:d1:96 UHLW0 14 lo0 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 08 en0 So for whatever reason it's not being recognized and turned into an Ethernet 48bit broadcast. Don't forget that there are 4 different kinds of broadcast. :-) You're using a "limited broadcast address", which is not being interpreted specially by the kernel and is going down the default route. Which probably doesn't exist when you're not dialled up. Hint: "route -n get" is a useful tool for finding out what the kernel would do when presented with an IP address. You'd probably be better off using a subnet-directed broadcast, which does have a route set up for you: 192.168.0.255. According to the book in front of me (UNP2v1, P472): "Another question is: what does a multi-homed host do when the application sends a UDP datagram to 255.255.255.255? Some systems send a single broadcast on the primary interface (the first interface that was configured) with the destination IP address set to the subnet-directed broadcast address of that interface. Other systems send one copy of the datagram from each broadcast capable interface. Section 3.3.6 of RFC 1122 ``takes no stand'' on this issue. For portability, however, if an application needs to send a broadcast out from all broadcast capable interfaces, it should obtain the interface configuration and do one sendto for each broadcast capable interface with the destination set to that interface's broadcast address." In short, what happens is very system dependent. :-( -Dom
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 12:41:49PM +0100, Dominic Mitchell wrote:
According to the book in front of me (UNP2v1, P472):
"Another question is: what does a multi-homed host do when the
application sends a UDP datagram to 255.255.255.255? Some systems
send a single broadcast on the primary interface (the first
interface that was configured) with the destination IP address
set to the subnet-directed broadcast address of that interface.
Other systems send one copy of the datagram from each broadcast
capable interface. Section 3.3.6 of RFC 1122 ``takes no stand''
on this issue. For portability, however, if an application needs
to send a broadcast out from all broadcast capable interfaces,
it should obtain the interface configuration and do one sendto for
each broadcast capable interface with the destination set to that
interface's broadcast address."
In short, what happens is very system dependent. :-(
Thanks very much! That's a great help -- if ffFFffFF doesn't work and
it doesn't necessarily have to that's OK. My original code that is
using ioctl(sockfd, SIOCGIFCONF, (caddr_t)ifconf_list will be pressed
back into service :-)
(push @{$books{Paul}}, "UNP" ;)
Re: Broadcast datagrams
On Wed, Apr 18, 2001 at 03:25:09AM -0700, Paul Makepeace wrote:
Anyone hackers here sent broadcast packets? I think this is how you
do it:
#!/usr/bin/perl -w
use strict;
use Socket;
my $dst = inet_aton("172.30.255.255");
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname("udp"))
or die "socket: $!";
setsockopt(SOCKET, SOL_SOCKET, SO_BROADCAST, pack("l", 1))
or die "setsockopt: $!";
send(SOCKET, "hello", 0, sockaddr_in(6868, INADDR_BROADCAST))
#send(SOCKET, "hello", 0, sockaddr_in(6868, $dst))
or die "send: $!";
I'd agree, tho' I don't think you need to pack() the last arg to
setsockopt().
For some reason I'm getting "send: Can't assign requested address"
for INADDR_BROADCAST. How can it *not* assign that? Flipping the
I had a lot of fungames with this (before LDS's book came out!):
Trying both IO::Socket and Socket.pm, I could do either read or
write but not both ... and had that msg.
My definitely working version is:
socket(SOCK, PF_INET, SOCK_DGRAM, getprotobyname('udp'))
|| die "$prog: socket: $!\n";
...
my $rip = INADDR_BROADCAST;
$rip = inet_aton($opt{d}) if defined $opt{d};
my $raddr = sockaddr_in($opt{p}, $rip);
setsockopt(SOCK, SOL_SOCKET, SO_BROADCAST, 1)
|| die "$prog: setsockopt: $!\n";
send(SOCK, $msg . "\015\012", 0, $raddr)
|| die "$prog: send: $!\n";
Which looks the same but for the pack().
--
Chris Benson
