|
From: | Elena Gurevich |
Subject: | [lwip-devel] TCP implementation voilates RFC 793 |
Date: | Mon, 3 Feb 2014 10:06:25 +0200 |
Hi dear all, I’m following the implementation of tcp_receive() function and it looks like function logic does not follow RFC793 specification of segment_arrives event: RFC specifies that: --------------------- snipped from RFC 793 -------------------------- first check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. There are four cases for the acceptability test for an incoming segment: Segment Receive Test Length Window ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 not acceptable >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs and RSTs. If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set, if so drop the segment and return): <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, drop the unacceptable segment and return. In the following it is assumed that the segment is the idealized segment that begins at RCV.NXT and does not exceed the window. One could tailor actual segments to fit this assumption by trimming off any portions that lie outside the window (including SYN and FIN), and only processing further if the segment then begins at RCV.NXT. Segments with higher begining sequence numbers may be held for later processing. --------------------- snipped from RFC 793 -------------------------- As I understand that all control information ( SYN, FIN, ACK, ack_no, window ) filed should be ignored and not processed in case of unacceptable segment arrival. According tcp_receive() function from first of all it takes care of ack_no and window field for segment with ACK ? uses actual ack_no and windows values to update tcb and takes into account segment seq_no only at data processing step. This looks like strong violation of RFC defined behavior. I am a new member of lwIP and intended to use the TCP implementation as a "golden" reference, but very confused now. Please explain me if I felt into some misunderstanding !!! with best regards, Lena |
[Prev in Thread] | Current Thread | [Next in Thread] |