Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the NetPacket CPAN distribution.

Report information
The Basics
Id: 62554
Status: resolved
Priority: 0/
Queue: NetPacket

People
Owner: Nobody in particular
Requestors: gavin.brown [...] centralnic.com
Cc:
AdminCc:

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



Subject: NetPacket::TCP->decode() error?
Date: Fri, 29 Oct 2010 15:06:11 +0100
To: bug-NetPacket [...] rt.cpan.org
From: Gavin Brown <gavin.brown [...] centralnic.com>
Hi there, I'm using NetPacket 0.43.0 on Fedora 12 and have encountered a problem with NetPacket::TCP. I'm attaching a test case. The script uses Net::Pcap to capture packets on the network (specifically DNS packets on TCP port 53). Net::Pcap passes the raw Ethernet frame to the callback, and I use NetPacket::Ethernet, NetPacket::IP and NetPacket::TCP to strip off the ethernet, IP and TCP headers to get to the raw DNS packet, which I then parse with Net::DNS::Packet. The problem is that the payload of the TCP packet has an extra two bytes at the front: lines 38-41 in my test code show what happens if you try to give $tcp->{data} directly to Net::DNS::Packet->new() (you get a croak as the header is too short). Lines 44-47 show what happens if you strip the two leading bytes from $tcp->{data}: the DNS packet is parsed and printed successfully. To run this test script you'll need to be root or have sudo on an IPv4 host with the 'dig' command, to issue a DNS request over TCP use 'dig +tcp example.com'. Cheers, -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

Message body is not shown because sender requested not to inline it.

I've captured and looked at the packets, and the first two bytes are the length of the DNS packet. Wireshark confirms that it's part of the data payload, which puts the problem with Net::DNS rather than NetPacket