Re^3: udp recv question

You really don't want to code this yourself. Here is a trivial example for interest sake only. It shows you how to build a packet (and its checksum) and that you do get data back which as you can see it is encoded in a binary packet format.

use IO::Socket;

use constant ICMP_ECHO      => 8;
use constant SUBCODE        => 0; # No ICMP subcode for ECHO and ECHOR
+EPLY
use constant ICMP_STRUCT    => "C2 n3 A64";

my $icmp = IO::Socket::INET->new(   PeerAddr => 'perlmonks.org',
                                    Proto=>'icmp'
);
print "Got socket\n";

my $data = '1'x64;
my $seq = 1;
my $checksum = 0; 
my $msg = pack(ICMP_STRUCT, ICMP_ECHO, SUBCODE, $checksum, $$, $seq, $
+data);
$checksum = checksum($msg);
my $msg = pack(ICMP_STRUCT, ICMP_ECHO, SUBCODE, $checksum, $$, $seq, $
+data);

print "Sending: $msg\n";
$icmp->send($msg);
$icmp->recv(my $buf, 1500);
print "Got: $buf";
print "Done\n";

sub checksum {
  my ($msg ) = @_;
  my $len_msg = length($msg);
  my $num_short = int($len_msg / 2);
  my $chk = 0;
  for my $short (unpack("n$num_short", $msg)) {
    $chk += $short;
  } 
  $chk += (unpack("C", substr($msg, $len_msg - 1, 1)) << 8) if $len_ms
+g % 2;
  $chk = ($chk >> 16) + ($chk & 0xffff);
  return(~(($chk >> 16) + $chk) & 0xffff);
}
[download]

cheers

tachyon

Comment on Re^3: udp recv question Download Code

Replies are listed 'Best First'.
Re^4: udp recv question by smackdab (Pilgrim) on Jun 28, 2004 at 03:30 UTC
I VERY MUCH APPRECIATE YOUR COMMENTS. I can also be quite dense on some of these matters...but: I am NOT trying to SEND an ICMP packet. I AM trying to see if a remote UDP port is "open" My assumption has been to send a UDP packet out and if the port is CLOSED, then I get a ICMP error msg back Otherwise I know the remote port is OPEN... The code above sends an UDP packet out and an ICMP error msg is sent back. But I DON'T know how to grab it. I tried reading on the UDP and ICMP sockets but neither seem to have it. Are you saying that I need to send an ICMP packet out??? Again, sorry if I am missing something completely obvious ;-)	[reply]
Re^5: udp recv question by tachyon (Chancellor) on Jun 28, 2004 at 04:22 UTC
You need to read up on port scanning. UDP is connectionless ie you can't see if a port is open by seeing if you can connect a socket to it, you have to send some data and check for a response. Port scanning usually means scanning for TCP ports, which are connection-oriented and therefore give good feedback to the attacker. UDP, or connection-less traffic, responds in a different manner. In order to find UDP ports, the attacker generally sends empty UDP datagrams at the port. If the port is listening, the service will send back an error message or ignore the incoming datagram. If the port is closed, then the operating system sends back an "ICMP Port Unreachable" message. Note that UDP packets may be dropped by all manner of devices along the way (so you get no response). The response, if it is coming, will arrive on the socket you sent the probe out on as shown. You have to send some sort of valid(ish) UDP packet to incite a response from the server. NetworkInfo::Discovery::Scan does what you want and you can pull code from there. cheers tachyon	[reply]
Re^6: udp recv question by smackdab (Pilgrim) on Jun 28, 2004 at 04:42 UTC
I did that reading, and I thought I provided a complete sample program that does exactly the technique you describe. From a sniffer, I know a UDP packet goes out and an ICMP one comes back. I can't figure out to read the ICMP into memory (not decode, just read into a buffer...) No worries, no more comments needed, I'll review my code in the morning...maybe a good night sleep will clear out the cobbwebs...	[reply]
Re^7: udp recv question by Anonymous Monk on Jun 28, 2004 at 06:12 UTC
Re^5: udp recv question by JamesNC (Chaplain) on Jun 28, 2004 at 04:13 UTC
Yes, he is telling you that. Taken from the RFC 768 The UDP protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP).	[reply]