From: Aleksander Morgado <aleksander@aleksander.es>
To: s.hauer@pengutronix.de, barebox@lists.infradead.org
Cc: Aleksander Morgado <aleksander@aleksander.es>
Subject: [PATCH 09/16] ratp: remove FIXME comment: FIN always requires ACK
Date: Thu, 15 Jun 2017 13:14:13 +0200 [thread overview]
Message-ID: <20170615111420.5318-10-aleksander@aleksander.es> (raw)
In-Reply-To: <20170615111420.5318-1-aleksander@aleksander.es>
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@aleksander.es>
---
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2017-06-15 11:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-15 11:14 [PATCH 00/16] RATP logic fixes and improvements Aleksander Morgado
2017-06-15 11:14 ` [PATCH 01/16] ratp: add missing transition to SYN-RECEIVED in behavior B Aleksander Morgado
2017-06-15 11:14 ` [PATCH 02/16] ratp: avoid unnecessary variable initializations Aleksander Morgado
2017-06-15 11:14 ` [PATCH 03/16] ratp: send missing RST in behavior C2 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 04/16] ratp: add missing RST flag in behavior G Aleksander Morgado
2017-06-15 11:14 ` [PATCH 05/16] ratp: completely ignore RST flagged packets " Aleksander Morgado
2017-06-15 11:14 ` [PATCH 06/16] ratp: fix data presence check Aleksander Morgado
2017-06-15 11:14 ` [PATCH 07/16] ratp: fix single byte sending flagged with SO Aleksander Morgado
2017-06-15 11:14 ` [PATCH 08/16] ratp: remove bogus data checks in behavior C2 Aleksander Morgado
2017-06-15 11:14 ` Aleksander Morgado [this message]
2017-06-15 11:14 ` [PATCH 10/16] ratp: fix sending ACKs without data Aleksander Morgado
2017-06-15 11:14 ` [PATCH 11/16] ratp: consolidate ratp_sn_expected() and ratp_an_expected() Aleksander Morgado
2017-06-15 11:14 ` [PATCH 12/16] ratp: prefer using ratp_send_ack() in behaviour I1 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 13/16] ratp: send initial data in behaviour B if any pending Aleksander Morgado
2017-06-15 11:14 ` [PATCH 14/16] ratp: don't ignore data that may arrive in behaviour H1 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 15/16] ratp: consolidate setting the next AN or SN flags Aleksander Morgado
2017-06-15 11:14 ` [PATCH 16/16] ratp: user close may happen in SYN-RECEIVED state Aleksander Morgado
2017-06-19 6:46 ` [PATCH 00/16] RATP logic fixes and improvements Sascha Hauer
2017-06-19 9:07 ` Aleksander Morgado
2017-06-19 9:37 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170615111420.5318-10-aleksander@aleksander.es \
--to=aleksander@aleksander.es \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox