Section 3.4 in the RFC916 shows a packet flow for the connection close
where the initial packet sent by the endpoint starting the close has
just the FIN flag set, without an ACK:
--> <SN=0><AN=1><CTL=FIN>
<SN=1><AN=1><CTL=FIN,ACK> <--
--> <SN=1><AN=0><CTL=ACK>
This may lead to think that it is actually allowed to send the initial
packet with just FIN set, without ACK-ing any other packet from the
peer.
But, this is actually not possible, the packet MUST be ACK-ing a
previous packet from the peer, even if this is just a duplicated ACK,
because otherwise the packet with the FIN wouldn't get processed in
the H2 behavior (FIN processing) of the peer, as the F2 behavior (ACK
processing) would filter it out.
This is actually the same reasoning why data packets always have ACK
set, even if the same ACK has already been sent previously (e.g. with
a simple ACK packet without data); if they didn't have it, they would
be filtered out in the F2 behavior, never arriving the I1 behavior,
which is where the received data is processed.
Signed-off-by: Aleksander Morgado <aleksander@xxxxxxxxxxxxx>
---
scripts/remote/ratp.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/remote/ratp.py b/scripts/remote/ratp.py
index 0dfc8420c..e6b3e19b6 100644
--- a/scripts/remote/ratp.py
+++ b/scripts/remote/ratp.py
@@ -724,7 +724,7 @@ class RatpConnection(object):
deadline = monotonic() + timeout
logging.info("CLOSE")
if self._state == RatpState.established:
- fin = RatpPacket(flags='FA') # FIXME: only F?
+ fin = RatpPacket(flags='FA')
fin.c_sn = (self._s_sn + 1) % 2
fin.c_an = (self._r_sn + 1) % 2
self._write(fin)
--
2.13.1
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
