https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285158
Bug ID: 285158
Summary: TCP segment with 0 length upon receiving partial ack
Product: Base System
Version: Unspecified
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: yjaey...@gmail.com
I am observing somewhat strange pcap behavior.
Scenario:
A --> B
A is the only sender of the data and B is the only receiver. Note that
we use PRR. When B is sending partial ACKs to A, there are cases when A sends
out
just an empty segment with the same sequence number to B. Which seems
to be pure overhead.
After digging through the code, I think this could be triggered by the
following sequence:
1.
https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_input.c#L2892
during prr-partial ack processing, it calls tcp_output with ACKNOW flag.
2.https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#L415
in tcp_output, it determines "len" how much to send and when ACKed
bytes in partial ack is small enough, this "len" becomes zero.
3.
https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#L702
As the flag is set to "ACKNOW", with zero length, it anyway sends out
a segment with 0 length.
I believe there should be some checks before sending out like checking
if the length is zero at the tcp_output?
--
You are receiving this mail because:
You are the assignee for the bug.
