Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Getting packets over 1500 Bytes pcap.

by Anonymous Monk
on May 24, 2014 at 21:28 UTC ( [id://1087333]=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Im currently using the fallowing script to capture packets..
#!/usr/usc/perl/5.6.1/bin/perl use strict; use warnings; $|++; my $dev = shift @ARGV; $dev ||= 'eth1'; my $filter_string = 'dst port 111'; #my $filter_string = 'udp'; my $snaplen = 65500; my $promisc = 0; my $timeout = 0; my $count = -1; use Net::Pcap; my $err = ''; my $cap_dev; my $filter = ''; my $net = -256; $cap_dev = Net::Pcap::open_live($dev, $snaplen, $promisc, $timeout, \$ +err); die "$err\n" if $err; Net::Pcap::compile($cap_dev, \$filter, $filter_string, 0, -256) and die "compile: $err\n"; Net::Pcap::setfilter($cap_dev, $filter); Net::Pcap::loop($cap_dev, $count, \&callback, 'woot'); Net::Pcap::close($cap_dev); exit 0; sub callback { my ($user_data, $hdr, $pkt) = @_; warn "packet!\n"; my %header = %$hdr; process_packet(\%header, $pkt); my $len = length $pkt; warn "$header{len} $header{caplen} $len\n"; } sub process_packet { my ($hdr, $pkt) = @_; my $len = length $pkt; warn "$hdr->{len} $hdr->{caplen} $len\n"; }
Now when i send a 5550 byte packet, I get this:
root@a05s24:~/scanner# perl dn3.pl packet! 1514 1514 1514 1514 1514 1514
I have the snaplen high in the script, and TCPdump pics up the packet fine:
23:27:26.508174 IP 37.X.X.X.57114 > a05s24.sunrpc: UDP, length 5550
At this point im pretty stumped :( Anyone with Pcap experience please help me on this little error.

Replies are listed 'Best First'.
Re: Getting packets over 1500 Bytes pcap.
by NetWallah (Canon) on May 25, 2014 at 15:09 UTC
    Most Ethernet LANs have a Maximum Transmission Unit (MTU) size of just over 1500 bytes.

    Since you seem to be capturing UDP which does not support "packet segmentation and re-assembly", or packet retry - the network sill silently drop packets larger than the MTU.

    Are you capturing TCPDUMP at the source, or destination of the packet ? You will probably not see any problem at the source.

            What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?
                  -Larry Wall, 1992

      UDP which does not support "packet segmentation and re-assembly"

      UDP layers on top of IP, which does fragment packets that are larger than the MTU. Reassembly happens at the final destination, so while you may not see all IP fragments of a large UDP packet while they are in transit, you should be able to see the full UDP packet at both source and destination.

      the network sill silently drop packets larger than the MTU

      That makes it sound like any UDP packets larger than the MTU will silently be dropped, which isn't the case. UDP packets may be dropped silently, however there isn't a general rule tying this to the MTU. If the IP "don't fragment" bit is set and the packet is larger than the MTU, it may be discarded, but it should generate an ICMP "Fragmentation Required" message.

        I guess we are both right - depending on which IP option is implemented:

        From http://en.wikipedia.org/wiki/IP_fragmentation

        In a case where a router receives a protocol data unit (PDU) larger than the next hop's MTU, it has two options if the transport is IPv4: drop the PDU and send an Internet Control Message Protocol (ICMP) message which indicates the condition Packet too Big, or fragment the IP packet and send it over the link with a smaller MTU.

                What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?
                      -Larry Wall, 1992

        That makes it sound like any UDP packets larger than the MTU will silently be dropped, which isn't the case.

        A lot of firewalls don't pass fragments nowdays, so it mostly is the case.

        >ping -c3 -s1400 perlmonks.org PING perlmonks.org (209.197.123.153): 1400 data bytes 1408 bytes from 209.197.123.153: icmp_seq=0 ttl=49 time=85.135 ms 1408 bytes from 209.197.123.153: icmp_seq=1 ttl=49 time=82.106 ms 1408 bytes from 209.197.123.153: icmp_seq=2 ttl=49 time=83.449 ms --- perlmonks.org ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 82.106/83.563/85.135/1.239 ms >ping -c3 -s1500 perlmonks.org PING perlmonks.org (209.197.123.153): 1500 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 --- perlmonks.org ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
Re: Getting packets over 1500 Bytes pcap.
by Anonymous Monk on May 26, 2014 at 00:06 UTC

    The latest release of Net::Pcap (and the last GitHub activity) is about 1.5 years old and there are 13 open bugs. I have tried to interface libpcap on two occasions, and my experience has been that this is one of those cases where it seems to be easier to let the specialized tools handle the packet capturing instead of attempting to roll your own. As much as I love Perl, I have to ask: why are you trying to write this in Perl instead of using tcpdump or tshark?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1087333]
Approved by atcroft
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (2)
As of 2024-04-26 01:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found