https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #42 from Sepherosa Ziehau ---
(In reply to Mike Karels from comment #41)
Would transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME-WAIT for this
code segment be more "appropriate" than transition to CLOSED?
--
You are rec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
Mike Karels changed:
What|Removed |Added
CC||kar...@freebsd.org
--- Comment #41 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #40 from Sepherosa Ziehau ---
(In reply to Michael Tuexen from comment #33)
I think the code that transit the FIN-WAIT-1 to CLOSED is this:
/*
* If new data are received on a connection after the
* use
The context has gotten messy here, so I’m going to break down and
top-post.
I started review https://reviews.freebsd.org/D10059 with a fix for the
reference-count leak.
It changes the semantics so only routes within an in_pcb automatically
do L2 caching.
I’ll put the tcp_output change for V6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #39 from Michael Tuexen ---
(In reply to slw from comment #38)
The text you are referring to deals with the case that the application has
called shutdown(..., SHUT_WR), not close(). So the text doesn't apply here...
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #38 from s...@zxy.spb.ru ---
(In reply to Michael Tuexen from comment #37)
RST+ACK, in sequence of data.
And don't do transition from FIN-WAIT-1 until got ACK to FIN.
"All segments preceding and including FIN will be retransmit
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #37 from Michael Tuexen ---
(In reply to slw from comment #36)
Please note that RFC 793 defines the CLOSE operation as "I have no more data to
send."
So this does NOT map to the close() system call in the socket API, but to the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #36 from s...@zxy.spb.ru ---
(In reply to Michael Tuexen from comment #35)
> This doesn't happen because NEW data arrives and the application has called
close().
So this new data cannot be delivered to the application. The TCP s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #35 from Michael Tuexen ---
(In reply to slw from comment #34)
> I am don't understund this. CLOSING must be only after got FIN.
> FIN don't received, data in buffer don't ack, what reasson to CLOSING
> transition
> and lost da
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #34 from s...@zxy.spb.ru ---
(In reply to Michael Tuexen from comment #33)
Right, FIN_WAIT_1.
> Then the state is FIN-WAIT-1. Then it receives the second part of the
> request. Since the socket is closed, it responds with a RS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #33 from Michael Tuexen ---
(In reply to slw from comment #32)
The server does
socket()
listen()
accept()
read()
write()
close()
which means it reads the first part of the request, sends the response (en
error message) and close
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #32 from s...@zxy.spb.ru ---
server CLOSE_WAIT, not client.
after application close socket server must wait for acknowledgment sended data
and resend it if need.
So client retransmit must be routed to existing inpcb in CLOSE_WAIT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #31 from Michael Tuexen ---
(In reply to slw from comment #30)
The client retransmits the whole data and only acks the SYN. So he hasn't
processed the FIN sent by the server. All that has been dropped. So I think the
client is n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #30 from s...@zxy.spb.ru ---
(In reply to Michael Tuexen from comment #29)
I am ask again about CLOSE_WAIT state and retransmit lost replay.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #29 from Michael Tuexen ---
(In reply to Julian Elischer from comment #28)
No, I think even FreeBSD would behave the same as a client if the client does
socket()
connect()
send(part1)
send(part2)
and the third segment from the t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
Julian Elischer changed:
What|Removed |Added
CC||jul...@freebsd.org
--- Comment #
18 matches
Mail list logo
