so I was wondering, what value goes into the checksum header on the receiving end?
For example, if I am sniffing http data, and I receive a packet, how is the value in the checksum header calculated? I am pretty sure I got how to calculate checksum but I don't understand why the value is as it is.
basically you get the sum of the binary string while splitting the string into groups of 1 byte and lines of 2 bytes, and then operate a 1 complement thingy on that sum, and that's your checksum. and to verify, the receiving end calculates the sum by himself, and adds the checksum to the sum, if everything is 1 then the packet was sent with no errors and 0 is the opposite. but if that's the case shouldn't I see an "ff ff" checksum value? why does it look like "34 ef" instead?
I apologize if this is a stupid question but I just couldn't find the answer as much as I tried looking. Thanks!
Related
If TCP runs out of its sequence number, what will happen?
If it again turns to 0 as the sequence number of the next byte, won't that be considered "duplicate" by the receiver?
If yes, then it has to ignore that byte.
If not, why?
I think, i found the answer.
The answer of this query, lies on one of the TCP option field known as "timestamp". It's in every TCP segment (including data and ACK segments).
Therefore to identify a unique tcp segment, we look for a combination of "timestamp" and "sequence number".
The basic idea is that a segment can be discarded as an old duplicate if it is
received with a timestamp less than some timestamp recently received on this connection.
Example :
Two segments 400:12001 and 700:12001 definitely belongs to two different incarnations.
And this mechanism is known as "PAWS" or protection against wrapped sequence numbers.
Reference: https://www.rfc-editor.org/rfc/rfc1323#page-17
While going through IP header checksum i.e. 1's complement of 1's complement sum of 16 bits data, I can't help but think that how come this method can detect error/alteration in data. For example, computer A sends a packet with data (12 and 7) and computer B receives the packet but with data altered (13 and 6). Hence in the receiver, checksum still match however data is altered. Could you please help me to understand if I am missing something in this topic?
Thank you.
Is IP header checksum a full proof method of error detection?
No.
The IP header checksum's purpose is to enable detection of a damaged IP header. It does not protect against manipulation or damage to the data field (which often has its own checksum).
For protection against manipulation a cryptographic method is required.
I have a question. I want to change the time value of a packet in a pcap. when we open a pcap in wireshark, we see a timestamp value in 2nd column after the packet serial numbers.
I want to change the time value of the packets. Though I am able to do the same but face a problem like below.
Let's say current time value showed for the packet in wireshark is 0.960727
I want to add 100000 to this time stamp.
Now the new stamp for the packet becomes 0.1060727 which ideally should be 1.060727.
If you open any pcap file in wireshark, you will never find a time value of more than 6 digits after decimal point.
But when I add this value I get 7 numbers after decimal point.
Could anhyone please let me know how can I make the time value to 1.060727 instead of 0.1060727 ?
Thank you for your suggestions here.
Regards,
Som
It's not completely clear to me what you're trying to do, but I'm going to take a guess that you are attempting to manually modify the timestamp of a single packet by editing the binary capture file. Assuming the file format is a .pcap file, then I suppose you're attempting to add 100000 microseconds to the timestamp of one particular packet?
Assuming this is the case, then you need to locate the packet header's ts_sec and ts_usec values and add 0x000186a0 microseconds to the current value of the ts_usec value, but if this value exceeds 0x000f423f (i.e., it's greater than or equal to 1 second), then you should add 0x00000001 to the ts_sec value and subtract 0x000f4240 from the newly computed ts_usec value.
One important thing to keep in mind is whether the .pcap file is written in big-endian or litte-endian format. This is determined by the so-called magic number (0xa1b2c3d4 implying big-endian and 0xd4c3d2a1 implying little-endian). Make sure you perform the addition/subtraction using the correct byte order of the ts_usec value and ts_sec value if appropriate, and make sure you write the bytes back to the ts_usec and ts_sec fields in the expected byte order of the file; otherwise your resulting timestamp will not be correct.
If this is not what you're attempting to do, then please clarify exactly what it is that you are attempting to do.
In TCP/UDP, the sender xors 16-bit words and the final result is complemented again to get the checksum. Now, this is done so that the receiver would recompute the checksum with the data and the checksum and if the result were all ones, it can be certain (well, almost!) that there's no error. My question is why would we have to do a final complement of the result at the sender. We might as well send it as such so that when the receiver recomputes the checksum, it'll have to check for all zeros, instead of all ones like in the other case.
Because 0 has a special meaning. It is used to indicate that checksum computation is to be ignored.
So that the receiver can just do a 1's complement sum of the all the data (including the checksum field) and see if it is -0 (0xffff).
I'm reading the book Data Communications and Networking 4th Edition Behrouz-Forouzan. I have a question in an exercise that asked me the following: The receiver of a message uses the checksum technique (Checksum) for 8-bit characters and get the following information
100101000011010100101000
. How I can know if the Data sent is correct or not? and why?
I Learned how to calculate the checksum in hexadecimal values, but do not understand as determined by a binary output, if the information is correct.
The sender calculates checksum to the data are sends it with the data in same message.
The receiver calculates the checksum again to the received data and checks if result matches with the received checksum.
There is still a chance that both the data and checksum got modified during transmission so they still match but the likelihood of that happening because of random noise is extremely low.