Skip Menu |

This queue is for tickets about the Net-Pcap CPAN distribution.

Report information
The Basics
Id: 132204
Status: new
Priority: 0/
Queue: Net-Pcap

People
Owner: Nobody in particular
Requestors: cfdbaker [...] comcast.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: it appears that Net::Pcap returns two extra bytes to parameter '$packet' in callback
Date: Mon, 23 Mar 2020 10:00:42 -0600
To: bug-Net-Pcap [...] rt.cpan.org
From: "cfdbaker [...] comcast.net" <cfdbaker [...] comcast.net>
Hi, Sorry, but I have reached the end of my ability to diagnose so in reading the CPAN page for Net::Pcap I decided to ask for some review. I setup and use a capture session using the example I see in Net::Pcap, at least to the best of my ability to understand; $pcap = Net::Pcap::open_live($dev, 65536, 1, 1000, \$err); $retval = Net::Pcap::loop($pcap, -1, \&write_packet, "$dev"); and process the resulting captured packets; my($user_data, $header, $packet) = @_; What I am seeing is that thins seem to be 'ok' from a capture perspective, i.e. $$header{"len"} == $$header{"caplen"} == ( length $packet ) I have processing the $packet working, well so it seems, because I can verify that the source/destination MAC's are valid, I get a good etherType (such as 0800), I can process IP formatted structures for both IPv4 and IPv6 (ok I also have ARP working) and see all the fields as I expect them to be. Basically I have done what I can to verify that I am processing the $packet correctly, yes granted there are other CPAN modules to do this but my interest is in doing it myself. What I am finding is that most, not quite all but virtually every, $packet I get back contains two extra bytes at the end that are not part of the datagram processing. What I mean by this is that if I follow any datagram ($packet) and use the IETF defined values the length's for the datagram ($packet) when parsing and preparing my variables I find it ends up being two bytes less than what I am getting from Pcap. To facilitate debugging and validation of my observation I have done things like generate a telnet session (so I can see the 'ext' in the clear) in the captured path and then examine what I am parsing to character-by-character verify that what I type in the session is what I see in the Pcap capture. So, $$header{"len"} == $$header{"caplen"} == ( length $packet ) is two bytes longer than the actual datagram. For a while I thought it might be the FCS (frame check) but that is supposed to be 4 bytes so I abandoned that effort. I finally decided that it must be my Perl code so I have spent quite a while trying to figure out what I might be doing that results in the two-byte mystery. Alas no joy in my debugging my code. I thus turn to you. Might you consider testing to see if you also see a two-byte addition to $packet? Kind regards, Doug Baker P.S. :) I'd love to see an option to Net::Pcap::loop return a reference to $packet as is done for $header so that I can access $packet by reference and reduce (by at least once) the number of times $packet gets moved and thus ever-so-slightly increase the potential processing rate, i.e. how long it takes me to complete the &callback (sub write_packet) and maybe miss a few less packets when capture rates are higher.