- This topic has 4 replies, 4 voices, and was last updated 15 years, 2 months ago by
.
-
Posts
-
SerpentFly, I’ve noticed a discrepancy in packet structuring that I need your opinion on.
I’ve found a difference between what’s reported in the IP header field for datagram length(at IP header offset position 2, 3) and the total length of the physical IP datagram(and total length of the packet, in bytes), as returned in the _INTERMEDIATE_BUFFER.m_Length field.
I have confirmed that for some IP packets, _INTERMEDIATE_BUFFER.m_Length returns a value greater than a packet length computed using the IP header datagram length field, i.e. TotalPacketLength = EthHeaderLength + IPDatagramLength.
For example, and I’m talking Base10 integers, after I read a suspect IP packet, INTERMEDIATE_BUFFER.m_Length = 60 bytes, which would mean an IP datagram length of 60 – 14 = 46 bytes, since the ethernet header length is always 14 bytes. However, the IP header datagram length field, read directly from the _INTERMEDIATE_BUFFER.m_IBuffer field, at offset position 17, says 40 bytes. This means that the length of the packet reported by _INTERMEDIATE_BUFFER.m_Length is 6 larger than what the actual packet bytes say it is. A call to ReadPacket() is padding the returned bytes with 6 additional null bytes, in this scenario.
I’ve confirmed that if I use the _INTERMEDIATE_BUFFER.m_Length as the actual packet length(60 bytes), and adjust the IP datagram length field up to 46 bytes, recompute IP and TCP checksums, and pass this adjusted packet on, that the packet is invalid to the requesting application.
If I use the smaller packet length as reported in the physical bytes, then it’s valid to the the requesting application. The application is expecting 54 bytes in the packet, not 60 bytes as indicated by _INTERMEDIATE_BUFFER.m_Length.I have WinpkFilter 3.0.4.1 installed on a VMware instance of WinXPSP3.
My question to you is, for IP packets, should I always use the IP header datagram length field to determine the total length of the packet, i.e. TotalPacketLength = EthHeaderLength + IPDatagramLength? Or, should the _INTERMEDIATE_BUFFER.m_Length field be the “word of God” on total packet length? The answer here is important to for the DPI Proxy I’m developing, as I need to have accurate info about actual payload length and content.
I hope I’ve been clear. Thanks in advance for your advice.
~Cozmik
SerpentFly,
I’ve done further testing on this issue. It seems that the captured packet length reported by INTERMEDIATE_BUFFER.m_Length for some IP packets is incorrect. I’ve proven it by trimming off the unnecessary ending null bytes and resending the packet without it being dropped. If EthHeaderLength + IPDatagramLength < INTERMEDIATE_BUFFER.m_Length, then I can trim off the last difference null bytes and resend the packet safely. When doing all of this, I noticed an interesting behavior for TCP/IP packets. As you know, part of the TCP checksum uses the total TCP datagram length. Well, it seems that the captured packet TCP checksum includes these ending null bytes! If I modify the checksum to match the new shorter TCP datagram length, the resent packet is dropped. How a packet can be sent with a TCP checksum that doesn’t match the TCP datagram length is beyond my understanding. I hope you can help with this. Fragmented packets were not tested. Nor were other packet IP protocol types. I figured I’d keep it simple until you reply with advice. Thanks. ~Cozmik
Interesting behavior, I have never heard about anything like this before and I suspect this is somehow specific to particular TCP/IP stack implementation.
INTERMEDIATE_BUFFER.m_Length indicates the total size of the buffers containing packet data which were indicated from the NIC to MSTCP OR sent by MSTCP to NIC. So this is a system specific value, it is not taken/calculated from packet headers.
- You must be logged in to reply to this topic.