https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254725
Richard Scheffenegger <***@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|13.0-RC4 crash tcp_lro |[tcp] 13.0-RC4 crash
| |tcp_lro
--- Comment #14 from Richard Scheffenegger <***@freebsd.org> ---
Extracted a more complete set of packet headers belonging to the problematic
session from the privately provided core.
The session is ECN-enabled
At the time of the panic, SENTFIN was set
Based on the Timestamp option of the incoming ACKs, serious reordering and
spurious retransmissions were going on.
The final packet with FIN originally has a payload of 1 byte. (TSopt val
..5625), but that is apparently lost and not received by the client.
Susequently (based on TSopt val), just the FIN is retransmitted twice, with
TSopt val ..5861 and ..5979 (e.g. when a transmission opportunity would be
there, but no new data is available).
The RTT appears to be nearly 100ms from the very last round, sRTT is averaged
at 275ms
At the panic, TSval would have been ..5988
This is for retransmitting the final payload byte, as the client only SACKed
the 1st FIN retransmission.
However, for some reason that byte is no longer available in the send socket
buffer, causing the crash.
Srv -> clnt F. 9999:10000(1) //dropped
Clnt -> Srv E. 1:1(0) ack -26seg <sack -25seg:9999>
(unobserved retransmission Srv->Clnt)
Clnt -> Srv E. 1:1(0) ack 9999
Srv -> cnt F. 10000:10000(0)
Clnt -> Srv E. 1:1(0) ack 9999 <sack 10000:10001>
attempt to retransmit 10000:10001(1) -> crash.
However, current attempts to recreate this misbehavior were unsuccessful in
recreating the panic.
--
You are receiving this mail because:
You are the assignee for the bug.