Recent changes to bugs

Problems when capture length is different of actual packet length

Anonymous — Sun, 16 Nov 2014 20:36:58 -0000

http://sourceforge.net/p/packetnet/discussion/1045279/thread/af241173/

#20 Attempting to set a negative length of -4

Anonymous — Fri, 18 Jul 2014 14:15:50 -0000

Is there an update on this bug?

#21 Not able to set Time Stamps in TCp Hedaer Package.

Chris Morgan — Fri, 25 Apr 2014 11:52:56 -0000

Hello.

I'm the author of packet.net and sharppcap. Have you looked to see if any of the unit tests are covering testing that field? There could be an issue with that field or options parsing in general.

I do have some available time to work on this, email me at chmorgan@gmail.com if you'd be interested in contracting with me to resolve the issue asap.

Not able to set Time Stamps in TCp Hedaer Package.

Jatin Chandarana — Fri, 25 Apr 2014 10:05:11 -0000

Hello All,

I am using SharpPcap 4.2 library to parse TCP ip packages,now i have problem for Windows client request.

When ever i receive request from window client i am not able to get Time Stamp potion field from TCP header,so i have goggling and find if you are not able to receive packages from Client and Server set this Time Stamp fro ACK packet then all subsequent request you will receive the Time Stamp for that client packages,but i am not able to set this field from server.

Below is code which i am using.

Bytes [] by =new Bytes[10];

tcp.OptionsCollection.Add(new PacketDotNet.Tcp.Option(by,1,10));
As this Option class is abstract ,so i am not able to add a new option,please help me it is needed as fast as possible.

Attempting to set a negative length of -4

Anonymous — Thu, 20 Feb 2014 00:22:45 -0000

I have attached a runnable test case including the offending packet TCP/IPv4/Ethernet packet. I have been collecting all network traffic on one of my servers and a few packets from China are crashing the parser.

I have stripped the destination IP address and replaced it with 127.0.0.1. The source IP address is still accurate. It seems you can try to connect to that server on port 80 and it will send back a packet that crashes the parser, but it's pretty hit or miss.

#11 InvalidOperationException

Anonymous — Wed, 19 Feb 2014 06:19:54 -0000

I have encountered a similar error, but it involves a -4 length and TCP/IPv4/Ethernet. I have made my receiver dump packets when it crashes, so we'll see here in a few hours when I get another crash.

#17 Index error when parsing packet

Douglas McLaughlin — Mon, 05 Aug 2013 19:31:06 -0000

I, too, am getting this index error. The previous version of Packet.Net did not have this issue. I do need to see and parse TCPv6 packets so filtering them out is not an option.

IP fragmented data

Pluskal Jan — Sat, 15 Jun 2013 10:06:10 -0000

Parsing this PCAP file i`m getting exception (attempting to set a negative length of -4) at second frame. PCAP contains two frames L2 Ethernet, L3 IPv4 segmented and L4 UDP. Inspection this PCAP in Wireshark and Network Monitor frame seems to be OK.

#11 InvalidOperationException

Anonymous — Tue, 16 Apr 2013 14:44:15 -0000

Hello Chris,

I too found a similar problem when using PacketDotNet for parsing a pcap file. I got the "Attempting to set negative length" exception when using my pcap file in "ReadingCaptureFile" example code from SharpCap. Sorry, but I can't upload the pcap file sample.

From what I was able to debug using the PacketDotNet source code, it seems that this occurs when a UDP datagram is fragmented on the IP layer. In this case only the 1st packet has the UDP header. For subsequent packets the parser assumes that there is a UDP header and when it tries to create a ByteArraySegment, it may encounter a -ve length. In cases where it doesn't throw the exception, due to the size of the data in the 2nd packet being more, then the data in the assumed UDP header is wrong for the 2 packet.

Example-
UDP Data of 1485 bytes split in 2 frames
Frame1-
FrameTotalBytes-1514
EthBytes-1514 (14 header + 1500 data)
IPBytes-1500 (20 header + 1480 data)
UDPBytes-1480 (08 header + 1472 data)

Frame2-
FrameTotalBytes-60
EthBytes-60 (14 header + 25 data + 21 padding)
IPbytes-25 (20 header + 5 data)
UDPbytes-0

For Frame2, PacketDotNet parser assumes presence of UDP header when calculating the ByteArraySegments.

I hope this explanation is good enough to help you identify the problem.

Thanks,
SB

#18 Incorrect Return type for TcpPacket.CalculateTCPChecksum

Marcel Saturnyne — Tue, 12 Mar 2013 21:23:08 -0000

Update:
Lines 400 - 417 of TcpPacket.cs ver. 0.13 refer:

///
/// Computes the TCP checksum. Does not update the current checksum value
///
/// The calculated TCP checksum.
public int CalculateTCPChecksum()
{
var newChecksum = CalculateChecksum(TransportChecksumOption.AttachPseudoIPHeader);
return newChecksum;
}

///
/// Update the checksum value.
///
public void UpdateTCPChecksum()
{
log.Debug("");
this.Checksum = (ushort)CalculateTCPChecksum();
}

As seen in the UpdateTCPChecksum() function, the int value of the Checksum is unnatural, and only the CalculateTCPChecksum() makes use of the value as an integer. The CheckUDPChecksum() in UdpPacket.cs function also uses int, which is then typecast back to ushort elsewhere. The IPv4Packet.cs only uses the ushort form of the Checksum value.

I have not gone through all code, and I know this is easily fixed in-line during end-user implementations with a typecast, but this feels counter-intuitive to the level of abstraction being sought. I cannot find any comment as to why these two functions are the only Checksum related functions to return int values.