[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-bugs
Subject:    [haiku-bugs] Re: [Haiku] #18384: TCP hangs
From:       "Haiku" <trac () haiku-os ! org>
Date:       2023-07-27 11:19:07
Message-ID: 056.81c68c8d487a7837ffebc279afcb3a2d () haiku-os ! org
[Download RAW message or body]

--===============4082454733440147236==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

#18384: TCP hangs
-------------------------------------+----------------------------
  Reporter:  axeld                   |      Owner:  axeld
      Type:  bug                     |     Status:  new
  Priority:  normal                  |  Milestone:  Unscheduled
 Component:  Network & Internet/TCP  |    Version:  R1/Development
Resolution:                          |   Keywords:
Blocked By:                          |   Blocking:
  Platform:  All                     |
-------------------------------------+----------------------------
Comment (by pulkomandy):

 A few things I noticed in Wireshark:

 - Looking at the "window scaling" graph, the time where the traffic stalls
 is clearly seen. Interestingly we can see some retransmission retries
 (marked as dots in the graph), but the "in flight bytes" quantity never
 seems to move
 - Looking at the packets around that time interval, we can see packet
 number 42752 where 192.168.0.14 decides to use a selective ACK for the
 first time, first with one range of received packets, then with two and
 later three ranges of received packets with holes in between
 - 192.168.0.48 replies to this by re-sending the last packet from normal
 ACKs as expected (relative sequence number 2922770) but this is never
 acknowledged by the other machine
 - It also sends packet 2931722 which does not seem to be matching with any
 of the selective ACK ranges from 192.168.0.14. This also has no effect on
 the ranges acknowledged by 192.168.0.14

 As the connexion stalls so shortly after SACK is used for the first time,
 that certainly raises a question about implementation of that function. It
 has a history of creating problems, see #13681.

 It looks like as soon as we start sending SACK options, the normal
 mechanism to acknowlege received frames stops working. After that, the
 transmission will stall since no new packets are ever acknowledged.

 But it is also surprising that the machine sends a SACK in the first
 place. Why does it think that there are such big holes in the received
 data? The corresponding packets are present in the capture, so, where did
 they disappear?
-- =

Ticket URL: <https://dev.haiku-os.org/ticket/18384#comment:3>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
--===============4082454733440147236==--

[prev in list] [next in list] [prev in thread] [next in thread]