mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* Question about RATP protocol limitation during handshake in barebox
@ 2023-01-24 18:22 Jules Maselbas
  2023-01-24 21:59 ` John Watts
  0 siblings, 1 reply; 6+ messages in thread
From: Jules Maselbas @ 2023-01-24 18:22 UTC (permalink / raw)
  To: barebox; +Cc: Yann Sionneau

Hi,

I am facing some issues with the RATP protocol that has been ironically
unreliable lately. I've looked at the implementation in barebox and in
ratp-barebox-cli host tool. I think I am starting to understand the last
issue I am facing: sometimes the host tool fails to initialize the RATP
link.

    host                                             barebox
 1. CLOSED                                           LISTEN
 2. SYN_SENT    --> <CTL=SYN>                    --> SYN_RECEIVED
 3.             ...             <CTL=SYN,ACK,AN> <--
 4. ESTABLISHED <-- <CTL=SYN,ACK,AN>             ...     
 5.             --> <CTL=ACK,AN,SN>              ...
 6.             ...             <CTL=SYN,ACK,AN> <-- (retransmit)
 7.             ..               <CTL=ACK,AN,SN> --> ESTABLISHED
 8. CLOSED (C2) <-- <CTL=SYN,ACK,AN>             ...
 9.             --> <CTL=AN,SN,RST>              --> (connection reset)

The Figure above illustrate the issue: during the handshake barebox has
a chance to resend the SYN-ACK packet however, upon reception, the host
will move into the ESTABLISHED state after the first packet and respond
with an ACK packet. When the host receive the duplicated SYN-ACK packet
it will execute behavior C2: "we assume that the other end crashed and
has attempted to open a new connection"; and close the connection.

I think it is important to note that I have locally applied the patch:
`[RFC PATCH] ratp: Fix retransmission for header-only packets`
https://lore.barebox.org/barebox/20230123102752.15444-1-jmaselbas@kalray.eu/T/#u
This issue might be revealed by the patch above, because now every
packets can be resent, but I think this issue is in the very nature of
RATP protocol and I cannot think of a good/simple way of fixing this.

I am tempted to simply tune the RTO (retransmit time out) of barebox to
be less aggressive during the handshake.

I would like to know your insight on this :)

Thanks
-- Jules


--- debug log from ratp-barebox-cli on host:
425089.225208 [ratp 000000000000000] debug: initialization requested
425089.225265 [ratp 000000000000000] debug: /dev/ttyACM0: opening tty
425089.225801 [ratp 000000000000000] debug: /dev/ttyACM0: tty open
425089.226008 [ratp 000000000000000] debug: initialization done
425089.226035 [ratp 000000000000000] debug: link active open requested...
425089.226045 [ratp 000000000000000] debug: sending SYN...
425089.226065 [ratp 000000000000000] debug: raw_send 01:80:ff:80
425089.226106 [ratp 000000000000000] debug: message sent    : [-- --- -- -- --- --- --- syn] len: 255: 01:80:ff:80
425089.226130 [ratp 000000000000000] info : state update: closed -> syn-sent (ok)
425089.226251 [ratp 140419952396032] debug: private thread started
425089.376918 [ratp 140419952396032] debug: message received: [-- --- an -- --- --- ack syn] len: 255: 01:c4:ff:3c
425089.376950 [ratp 140419952396032] debug: [behavior B]
425089.376961 [ratp 140419952396032] debug: stop_retransmission_logic
425089.376975 [ratp 140419952396032] debug: last packet acknowledged in 150ms (SRTT: 190ms, RTO: 285ms)
425089.376995 [ratp 140419952396032] info : state update: syn-sent -> established (ok)
425089.377034 [ratp 140419952396032] debug: raw_send 01:4c:00:b3
425089.377073 [ratp 140419952396032] debug: message sent ack: [-- --- an sn --- --- ack ---] len: 0  : 01:4c:00:b3
425089.377115 [ratp 140419952396032] debug: message received: [-- --- an -- --- --- ack syn] len: 255: 01:c4:ff:3c
Sending PING...
425089.377129 [ratp 140419952396032] debug: [behavior C2]
425089.377269 [ratp 140419952396032] debug: raw_send 01:1c:00:e3
425089.377307 [ratp 140419952396032] debug: message sent    : [-- --- an sn rst --- --- ---] len: 0  : 01:1c:00:e3
425089.377323 [ratp 140419952396032] debug: stop_retransmission_logic
425089.377344 [ratp 140419952396032] info : state update: established -> closed (connection reset)
error: couldn't send PING: invalid transition
425089.377462 [ratp 000000000000000] debug: shutdown requested
425089.377567 [ratp 140419952396032] debug: private thread finished
425089.378662 [ratp 000000000000000] debug: [/dev/ttyACM0] closed tty
425089.378708 [ratp 000000000000000] debug: shutdown requested

--- debug log from barebox:
ratp: Establish...
ratp:                       recv>-- --- -- -- --- --- --- syn< len: 255
ratp:  state LISTEN
ratp: ratp_behaviour_a
ratp: send>-- --- an -- --- --- ack syn< len: 255
ratp: state LISTEN     -> SYN_RECEIVED
ratp: ratp_poll: retransmit
ratp: resend>-- --- an -- --- --- ack syn< len: 255
ratp:                       recv>-- --- an sn --- --- ack ---< len: 0
ratp:  state SYN_RECEIVED
ratp: ratp_behaviour_c1
ratp: ratp_behaviour_d1
ratp: ratp_behaviour_e
ratp: ratp_behaviour_f1
ratp: ratp_behaviour_h1
ratp: state SYN_RECEIVED -> ESTABLISHED
ratp:                       recv>-- --- an sn rst --- --- ---< len: 0
ratp:  state ESTABLISHED
ratp: ratp_behaviour_c2
ratp: ratp_behaviour_d2
ratp: connection reset
ratp: ratp_behaviour_e
ratp: ratp_behaviour_f2
ratp: send>-- eor an sn --- --- ack ---< len: 5








^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-01-25 17:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-24 18:22 Question about RATP protocol limitation during handshake in barebox Jules Maselbas
2023-01-24 21:59 ` John Watts
2023-01-25  8:41   ` Jules Maselbas
2023-01-25 15:19     ` Draft of an errata for RFC916 Jules Maselbas
2023-01-25 16:27       ` John Watts
2023-01-25 17:11         ` Jules Maselbas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox