I have written a tcp checksum calculation function. I need to check if it works as specified in http://www.ietf.org/rfc/rfc793.txt (which uses ipv4 addresses to calculate the pseudoheader).
To do this I need to have a known checksum value for a given packet. Does anybody have such a known checksum/packet pair for me or tell me where I can find it? Preferably one where an odd number of data bytes is sent. For example the checksum of:
Sourceport: 9999
Destinationport: 11111
seqnumbr: 5555
acknumber: 6666
Dataoffset: 5
Flags: ACK and PUSH
Window: 8000
Urgentpointer: 0
Options: no options
data: {0x01, 0x02, 0x03, 0x04, 0x05}
Source IP (for the psuedo header): 192.168.0.10
Destination IP (for the psuedo header): 192.168.0.20
How can I find out what the checksum for that tcp packet is?
Thanks!
Related
For example, one 2000 bytes UDP package(contains UDP header) and network MTU is 1500. So this UDP package should be split to two IP fragments. Only the first IP package contains the UDP header.
What value should be filled into UDP length in the UDP header of first IP package? 1480 or 2000?
Is there any document to confirm this?
UDP Length is the length of the UDP header AND the UDP data, in bytes. The fragmentation will/should NOT change this.
[UDP] "Length is the length in octets of this user datagram including this header and the data" --RFC768, an Internet Standard. It is also in the Stevens link referenced: "Referring to Figure 10-2, the UDP Length field is the length of the UDP header and the UDP data in bytes."
I think you may be overthinking this. Just set the UDP length to however big your data is.
IP fragmenting can occur at any router hop, without your knowledge (assuming you are the sender). It's the IP layer's responsibility to fragment and re-assemble the packet before the UDP datagram is delivered to the application. Unless you're plugged in to the NIC driver, you won't be able to reliably tell if the packet was fragmented on the way.
If there's an IP fragment lost on the way, you won't get any UDP datagram at all, it will simply be lost from the application's point of view, even though the IP layer may have gotten 9 out of 10 fragments.
Everything about this is brilliantly described in Richard Stevens et al's seminal work: TCP/IP Illustrated, Volume 1: The protocols
, section 10.7 IP Fragementation.
When send a UDP datagram larger than the MTU size, only the last fragment of the UDP datagram is putted out to the destination. The rest of fragments are silently discarded. Sendto() return the sendlength (no error).
Envirenment:
OS: vxWorks6.8
CPU: ARM9
MTU: 1500
The vxWorks board is direct connected via ethernet cable to the Win7 PC (with wireshark).
The DF flag isn't set.
Example 1:
sendto with 1400 Bytes
wireshark shows: udp with 1400 Databytes4
Example 2:
sendto with 1800 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (312 bytes)
Example 3:
sendto with 4000 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (1016 bytes)
Example 4:
sendto with 7800 Bytes
wireshark shows: Fragmented IP protocol (proto=udp 0x11, off=1496, id0a00) -> Data (328 bytes)
I use the same test on a second vxworks board with CPU PPC and this work fine and the ip-fragmentation work properly.
Why the first fregments of the udp packet are always discarded?
Many Thanks
I have a lot of pcap files
in each pcap file there are some tcp packets
I want to the following steps:
1 filter the pcap file to get expected tcp packets(if with tshark, the filter is like tcp.srcport==80 and tcp.dstport==20000). The tcp data in each tcp packet are of tens of bytes,
1) the first 2 bytes are sequence number
2) the second 2 bytes indicate a length: **n**
3) the following **n** bytes are random (if **n** is 2, then there are 2 random bytes)
4) immediately after the **n** bytes is an IP address
2 from each tcp packet, I want to get the source IP and the IP address string as mentioned in 4)
Above all, I just want to get an IP pair from each tcp packet, the source IP is easy to be obtained from tshark, but the IP address in the tcp data needs some effort
are there any good source code snippets or good ways that can be used for my target?
thanks!
I've encountered the following statement somewhere in the net: "Although
theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
assume complete L4 info is available...". I don't understand how possible
that only 8 bytes of a transport are guaranteed in a fragment, as the IP
fragment can't be less than 46 bytes (minimum payload size for Ethernet
frame), and this includes 20 bytes of IP header and 20bytes of TCP header
(not considering variable-lngth options), UDP will be less.
Thus for the first IP fragment we always can expect IP header at tcp header,
while other fragments will carry only IP header + payload.
I believe I'm missing something, but I still can't understand why only 8
bytes can be guaranteed in a fragment? I would appreaciate if someone helps
to clarify this issue. Thanks !
Mark
Imagine a router receives a TCP packet containing one more byte of data than will fit in the MTU of the destination network. It must split on an 8-byte boundary because that's an IP fragmentation rule.
It won't split into more than two fragments because that would be silly. So it must include at least one byte of data in the first fragment..
Thus the minimum number of data bytes you can place in the first fragment of an IP datagram is 8.
How will you identify the next layer protocol after Ethernet ? IS there any provision for same in Ethernet frame ?
The ethernet frame contains an Ethertype, a 2 byte field designating the upper layer protocol. For example IP has 0x800. When a network engine receives a frame from the network interface it checks this field and forwards it to the appropriate handler.
The ethertype (2 bytes, the 13th and 14th bytes) is generally right behind destination mac and source mac.
The case is true for Ethernet II.
For 802.3, there is a case where the ethertype is encapsulated as part of the LLC SNAP.
So in general, you can check if the 13th and 14th bytes are indeed ethertype, then use it.
If not ethertype (ethertype must be greater than 0x05DC), then you know it's payload length.
Then parse the LLC SNAP to obtain the ethertype within.
This is Ethernet header
DstMacAddr // 6 bytes
SrcMacAddr // 6 bytes
EthType // 2 bytes -> ARP(0x0806), IPv4(0x0800), IPv6(0x86dd), VLAN(0x8100), etc
Payload // ARP, IPv4, IPv6, etc
FSC // CRC32