tcp header
-
Hi, i wonder if anybody with knowledge of the TCP header can help me with this one: I am casting some data from a buffer provided by the winpcap packet capture library into a struct I have defined to represent the TCP header, the header is at the start of the buffer and I am casting it like this:
tcpHeader = (tcp_header *) (UCHAR*) tempDatagram.pkt_data;where the tcpHeader is of type:typedef struct tcp_header{ USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement number // assume little endian for now UINT x2:4; // Unused UINT off:4; // Header length (offset) UCHAR flags; // TCP flags USHORT win; // window USHORT crc; // checksum USHORT urp; // urgent pointer } tcp_header;the cast is working upto the offset i think and then values are being filled in a little randomly from there so I dont think i have the tcp_header defined right for the TCP header, can anybody suggest how to fix it? -
Hi, i wonder if anybody with knowledge of the TCP header can help me with this one: I am casting some data from a buffer provided by the winpcap packet capture library into a struct I have defined to represent the TCP header, the header is at the start of the buffer and I am casting it like this:
tcpHeader = (tcp_header *) (UCHAR*) tempDatagram.pkt_data;where the tcpHeader is of type:typedef struct tcp_header{ USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement number // assume little endian for now UINT x2:4; // Unused UINT off:4; // Header length (offset) UCHAR flags; // TCP flags USHORT win; // window USHORT crc; // checksum USHORT urp; // urgent pointer } tcp_header;the cast is working upto the offset i think and then values are being filled in a little randomly from there so I dont think i have the tcp_header defined right for the TCP header, can anybody suggest how to fix it?The TCP header is not quite right. See http://www.freesoft.org/CIE/Course/Section4/8.htm[^] for reference. The sizes for you off and flags are incorrect. off should be 6 bits and so is flags. :) Also ensure you pack with 1 byte alignment! Ant.
-
Hi, i wonder if anybody with knowledge of the TCP header can help me with this one: I am casting some data from a buffer provided by the winpcap packet capture library into a struct I have defined to represent the TCP header, the header is at the start of the buffer and I am casting it like this:
tcpHeader = (tcp_header *) (UCHAR*) tempDatagram.pkt_data;where the tcpHeader is of type:typedef struct tcp_header{ USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement number // assume little endian for now UINT x2:4; // Unused UINT off:4; // Header length (offset) UCHAR flags; // TCP flags USHORT win; // window USHORT crc; // checksum USHORT urp; // urgent pointer } tcp_header;the cast is working upto the offset i think and then values are being filled in a little randomly from there so I dont think i have the tcp_header defined right for the TCP header, can anybody suggest how to fix it?USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement numberSo far, so good. The next bit, according to "Internet Protocols Handbook," should be: Data Offset - 4 bits Reserved - 6 bits Flags - 6 bits I think I'd take the whole lot and make one 16-bit value of it, using ORs to set the flags and offset bitfields. Also, this reference indicates that a variable length Options field, padded by 0s in the low-order bits to 32-bits, is expected to precede the data block. The book doesn't mention whether the Options field is required; the RFC (793) may be more specific. I've felt much better since I gave up hope. -
USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement numberSo far, so good. The next bit, according to "Internet Protocols Handbook," should be: Data Offset - 4 bits Reserved - 6 bits Flags - 6 bits I think I'd take the whole lot and make one 16-bit value of it, using ORs to set the flags and offset bitfields. Also, this reference indicates that a variable length Options field, padded by 0s in the low-order bits to 32-bits, is expected to precede the data block. The book doesn't mention whether the Options field is required; the RFC (793) may be more specific. I've felt much better since I gave up hope.Cheers for the reply roger, Can you give me a hint at which data types would be best suited for these fields and how to declare them at that length in c++, considering that I would rather they were kept seperate from one another so no further processing is required to split the header data into component parts. As you can tell I am a bit of a novice at c++ and the MFC's and i think i have bitten off a bit more than I can chew :((
-
Cheers for the reply roger, Can you give me a hint at which data types would be best suited for these fields and how to declare them at that length in c++, considering that I would rather they were kept seperate from one another so no further processing is required to split the header data into component parts. As you can tell I am a bit of a novice at c++ and the MFC's and i think i have bitten off a bit more than I can chew :((
packetlos wrote: i think i have bitten off a bit more than I can chew I think you're right, but I don't know any better way to learn and grow than to take on and accomplish a task that is beyond one's current capabilities.:-D As for data types, there really isn't anything in C++ that I know of that handles 6-bit fields efficiently, but I rather like 32-bit words, manipulated with logical bitwise operators for what are essentially flag fields. This approach lets you define in advance several constants that you can simply OR into the word, and allows you to isolate parts of interest with an AND. I'd make the whole Offset:Reserved:Flags:Window section a single word, That should also eliminate any need for worrying about memory alignment in your struct. Some people think of it as a six-pack; I consider it more of a support group.
-
packetlos wrote: i think i have bitten off a bit more than I can chew I think you're right, but I don't know any better way to learn and grow than to take on and accomplish a task that is beyond one's current capabilities.:-D As for data types, there really isn't anything in C++ that I know of that handles 6-bit fields efficiently, but I rather like 32-bit words, manipulated with logical bitwise operators for what are essentially flag fields. This approach lets you define in advance several constants that you can simply OR into the word, and allows you to isolate parts of interest with an AND. I'd make the whole Offset:Reserved:Flags:Window section a single word, That should also eliminate any need for worrying about memory alignment in your struct. Some people think of it as a six-pack; I consider it more of a support group.
Could I not do something like this:
typedef struct len_flags { USHORT unused : 6, len: 4, flags : 6; } len_flags; typedef struct tcp_header { USHORT sport; // Source port USHORT dport; // Destination port UINT32 seq; // Sequence number UINT32 ack; // Acknowledgement number #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 len_flags lenflags; // TCP length & flags USHORT win; // window USHORT crc; // checksum USHORT urp; // urgent pointer } tcp_header;Then test the flags like this:
// test flags if (tcpHeader->lenflags.flags & TH_URG) tempTCP.flags = "URG "; if (tcpHeader->lenflags.flags & TH_ACK) tempTCP.flags += "ACK "; if (tcpHeader->lenflags.flags & TH_PUSH) tempTCP.flags += "PSH "; if (tcpHeader->lenflags.flags & TH_RST) tempTCP.flags += "RST "; if (tcpHeader->lenflags.flags & TH_SYN) tempTCP.flags += "SYN "; if (tcpHeader->lenflags.flags & TH_FIN) tempTCP.flags += "FIN ";But it dosent seem to work :((, something to do with #pragma pack? Regards Packetlos