This is more of a theoretical question than an actual problem I have.
If I understand correctly, the sequence number in the TCP header of a packet is the index of the first byte in the packet in the whole stream, correct? If that is the case, since the sequence number is an unsigned 32-bit integer, then what happens after more than FFFFFFFF = 4294967295 bytes are transferred? Will the sequence number wrap around, or will the sender send a SYN packet to restart at 0?
The sequence number loops back to 0. Source:
TCP sequence numbers and receive
windows behave very much like a clock.
The receive window shifts each time
the receiver receives and acknowledges
a new segment of data. Once it runs
out of sequence numbers, the sequence
number loops back to 0.
Also see chapter 4 of RFC 1323.
It wraps. RFC 793:
It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. The symbol "=<" means "less than or equal" (modulo 2**32).
Read more: http://www.faqs.org/rfcs/rfc793.html#ixzz0lcD37K7J
The sequence number is not actually the "index of the first byte in the packet in the whole stream" since sequence numbers deliberately start at a random value (this is to stop a form of attack known as the TCP Sequence Prediction Attack).
No SYN is required, the sequence number simply loops back to zero again once it gets to the limit.
Related
I am trying to wrap my head around 1's complement checksum error detection as is used in UDP.
My understanding with simplified example for an UDP-like 1's complement checksum error checking algorithm operating on 8 bit words (I know UDP uses 16 bit words):
Sum all 8 bit words of data, carry the MSB rollover to the LSB.
Take 1's complement of this sum, set checksum, send datagram
Receiver adds with carry rollover all received 8 bit words of data in the incoming datagram, adds checksum.
If sum = 0xFF, no errors. Else, error occurred, throw away packet.
It is obvious that this algorithm can detect 1 bit errors and by extension any odd-numbered bit errors. If just one bit in an 8-bit data word is corrupted, the sum + checksum will never equal 0xFF. A plain and simple example would be A = 00000000, B = 00000001, then ~(A + B) = 11111110. If A(receiver) = 00000001, B(reciever) = 00000001, the sum + checksum would be 0x00 != 0xFF
My question is:
It's not too clear to me if this can detect 2 bit errors. My intuition says no, and a simple example is taking A = 00000001, B = 00000000, then sum + checksum would be 0xFF, but there are two total errors in A and B from sender to receiver. If the 2 bit error occurred in the same word, theres a chance it could be detected, but it doesn't seem guaranteed.
How robust is UDP error checking? Does it work for even numbers of bit errors?
Some even-bit changes can be detected, some can't.
Any error that changes the sum will be detected. So a 2-bit error that changes the sum will be detected, but a 2-bit error that does not change the sum will not be detected.
A 2-bit error in a single word (single byte in your simplified example) will change the value of that word, which will change the sum, and therefore will always be detected. Most 2-bit errors across different words will be detected, but a 2-bit error that changes the same bit in different directions (one 0->1, the other 1->0) in different words will not change the sum -- the change in value created by one of the changed bits will be cancelled out by the equal-but-opposite change in value created by the other changed bit -- and therefore that error will not be detected.
Because this checksum is simply an addition, it will also fail to detect the insertion or removal of words whose arithmetic value is zero (and since this is a one's complement computation, that means words whose content is all 0s or all 1s).
It will also fail to detect transpositions of words, (because a+b gives the same sum as b+a), or more generally it will fail to detect errors that add the same amount to one word as they subtract from the other (because a+b gives the same sum as (a+n)+(b-n), e.g. 3+3=4+2=5+1). You could consider the transposition and cancelling-error cases to be made up of multiple pairs of same-bit changes.
I am very sorry to not be able to provide code for this question but it is more of a logical situation. My termination sequence for the AX.25 protocol is "111111" which is six 1s. So if this sequence of 1s is found inside my data packet, it will denote the end of the packet file and send it without correctly sending the rest of the packet. I will do my best to explain my conclusions and test results such that you can understand my dilemma.
***Programming in Arduino******
byte 1 contains 8 bits. Look below and attempt to picture a byte in a rectangular box. right next to it is byte 2 which also contains 8 bits.
Situation 1:
||_1_0_1_1_1_0_1_0_ ||_1_1_1_1_1_1_0_0_||
Attempted Solution 1: you could simply change 1 into 0 and keep track of it.
Situation 2:
||_1_0_1_1_1_0_1_1_ ||_1_1_1_1_0_0_1_0_||
Attempted Solution 2: attempted solution 1 breaks apart. and I am stuck here.
Individually the bytes are safe from activating AX.25 termination sequence but combined bytes results in a problem.
Here is a list of possible cases:
1) six 1s = termination sequence activated for end of packet
2) six 1s inside actual data of packet = premature termination
3) if 1s are changed to 0s than a sequence of six 0s can be a problem in reverting changes back
4) can only read 1 byte at a time (EEPROM) due to memory limitations
5) if six 1s occur between two bytes will also prematurely activate termination sequence.
Thank you in advance for any kind of help.
The solution mandated by the ax.25 protocol is bit stuffing.
Conceptually, any time the receiver sees five sequential one bits and a zero bit, it assumes that the zero bit has been stuffed by the sender (to break up erroneous frame sequences in the data), and removes it before emitting the received data. The only sequence of six 1-bits that can have been sent un-stuffed is the framing sequence; all data will have been sent stuffed. The receiver must always de-stuff.
To stuff or unstuff will generally require a couple of bytes of working ram (or a couple of bytes of registers), although there might be creative ways around that.
To quote the official TAPR protocol standard:
"In order to ensure that the flag bit sequence mentioned above does not appear accidentally anywhere else in a frame, the sending station monitors the bit sequence for a group of five or more contiguous “1” bits. Any time five contiguous “1” bits are sent, the sending station inserts a “0” bit after the fifth “1” bit. During frame reception, any time five contiguous “1” bits are received, a “0” bit immediately following five “1” bits is discarded."
A google search for AX.25 bit stuffing should return as much detail as you might need.
Assume a TCP is sending at 100Mbps. The sequence number starts with 329,114,852. how long will it take in seconds before the sequence number reaches 100,000,000
I don't have the answer for this so i am not sure if my working is correct. (329,144,852-100,000,000)/100,000,000 =2.29 seconds
I'm trying to get into assembler and I often come across numbers in the following form:
org 7c00h
; initialize the stack:
mov ax, 07c0h
mov ss, ax
mov sp, 03feh ; top of the stack.
7c00h, 07c0h, 03feh - What is the name of this number notation? What do they mean? Why are they used over "normal" decimal numbers?
It's hexadecimal, the numeral system with 16 digits 0-9 and A-F. Memory addresses are given in hex, because it's shorter, easier to read, and the numbers that represent memory locations don't mean anything special to humans, so no sense to have long numbers. I would guess that somewhere in the past someone had to type in some addresses by hand as well, might as well have started there.
Worth noting also, 0:7C00 is the boot sector load address.
Further worth noting: 07C0:03FE is the same address as 0:7FFE due to the way segmented addressing works.
This guy's left himself a 510 byte stack (he made the very typical off-by-two error in setting up the boot sector's stack).
These are numbers in hexadecimal notation, i.e. in base 16, where A to F have the digit values 10 to 15.
One advantage is that there is a more direct conversion to binary numbers. With a little bit of practice it is easy to see which bits in the number are 1 and which are 0.
Another is is that many numbers used internally, such as memory addresses, are round numbers in hexadecimal, i.e. contain a lot of zeros.
In selective repeat protocol, the window size must be less than or equal to half the size of the sequence number space for the SR protocol. Why is this so, and how?
This is to avoid packets being recognized incorrectly.
If the windows size is greater than half the sequence number space, then if an ACK is lost, the sender may send new packets that the receiver believes are retransmissions.
For example, if our sequence number range is 0-3 and the window size is 3, this situation can occur.
[initially] (B's window = [0,1,2])
A -> 0 -> B (B's window = [1,2,3])
A -> 1 -> B (B's window = [2,3,0])
A -> 2 -> B (B's window = [3,0,1])
[lost] ACK0
[lost] ACK1
A <- ACK2 <- B
A -> 3 -> B
A -> 0 -> B [retransmission]
A -> 1 -> B [retransmission]
After the lost packet, B now expects the next packets to have sequence numbers 3, 0, and 1.
But, the 0 and 1 that A is sending are actually retransmissions, so B receives them out of order.
By limiting the window size to 2 in this example, we avoid this problem because B will be expecting 2 and 3, and only 0 and 1 can be retransmissions.
The sequence space wraps to zero after max number is reached. Consider the corner case where all ACKs are lost - sender does not move its window, but receiver does (since it's unaware the sender is not getting the ACKs). If we don't limit the window size to half the sequence space, we end up with overlapping sender "sent but not acknowledged" and receiver "valid new" sequence spaces. This would result in retransmissions being interpreted as new packets.
Because the receiver will fail to distinguish between an old packet or a new packet. The receiver identifies packets based on sequence numbers, and there is a finite number of unique numbers for each connection. You can't have an infinite buffer.
Lets look at a obvious fail scenario:
The window size is greater than the sequence number space. Lets say we have sequence numbers 0, 1, 2. And our window size is 4. This means that the window has two occurrences of 0.
0,1,2,0 <- modulo wrap. When we get a package with a seq of 0. Is it the first packet or the fourth? No clue. Now, this problem will occur insofar as the window size is greater than half of the sequence number space. Why? Because there's always the possibility that the receiver is looking at a sequence number that MAY be contained in a packet coming from the sender that is NEW or OLD. Does it always happen? No. But when it does, here's what happens:
Case 1:
Receiver window after properly receiving packets 0,1,2.
0,1,2,[3,0,1],2
But what if the ACKs sent are lost? Well, the sender will resend 0,1,2. But are 0,1 OLD or NEW? The receiver can't tell.
Case 2:
Same window on receiving end. The three packets are received.
0,1,2,[3,0,1],2
Now, the receiver receives ALL the acks but ONE correctly. Lets pick the 2nd one (1). Now, it's going to resend 1. But the receiver is looking at 1! So is this the new one as it expects (nope), or the old one?
Therefore, to ensure that the window is never expecting sequence numbers that could possibly be used by potential outstanding packets (either coming from a normal transmission or re-transmission of a missing ack) we have to either decrease the window size or increase sequence numbers.
Look what happens when we increase the sequence number space to, say 6.
0,1,2,3,4,5.
No matter how we position the window, it's never at risk of receiving a packet with a old sequence number.
0,1,2,[3,4,5]0,1...
By the time the window wraps around, we are positive that we've received the previous ones in order.
This link has an animation that walks through each of the steps of the protocol to explain why the window size matters:
http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=73
Basically, if the window size is too high, then corruption in transmission can cause incorrect assumptions and lead to data corruption in the final result.