Mike Karels wrote:
I think that the possible courses of action are:
1/ Ignore further incoming data, but ACK it.
(this is basically what the userland code does in this case)
This could lead to indefinite data transfer, while misleading the sender
into thinking the data are being delive
> I think that the possible courses of action are:
> 1/ Ignore further incoming data, but ACK it.
> (this is basically what the userland code does in this case)
This could lead to indefinite data transfer, while misleading the sender
into thinking the data are being delivered.
> 2/ Stop AC
Eygene Ryabinkin wrote:
Julian, good day.
Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote:
replying to myself.. the comment in the code in question said:
/*-*/
/** if the elaborateTCPFin option is set, keeps
On Thu, 19 Jul 2007, Eygene Ryabinkin wrote:
Another way to deal with the problem is not to send the FIN's after the one
provoked by the closed descriptor. As I understand, the SS_NOFDREF check is
a optimization to avoid processing unneeded data in the TCP stack. So we
may just silently bla
Julian, good day.
Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote:
> replying to myself.. the comment in the code in question said:
>
> /*-*/
> >/** if the elaborateTCPFin option is set, keeps the socket open
> > * and
Julian Elischer wrote:
Eygene Ryabinkin wrote:
Julian, good day.
Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote:
Seems like it is the effect of the SS_NOFDREF check in the
netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5.
See the post
http://lists.freebsd.or
Eygene Ryabinkin wrote:
Julian, good day.
Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote:
Seems like it is the effect of the SS_NOFDREF check in the
netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5.
See the post
http://lists.freebsd.org/pipermail/freebsd-curre
Julian, good day.
Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote:
> >Seems like it is the effect of the SS_NOFDREF check in the
> >netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5.
> >
> >See the post
> >http://lists.freebsd.org/pipermail/freebsd-current/2007-Jul
Eygene Ryabinkin wrote:
Chuck, Julian, good day.
Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote:
% tcpdump -nS -r IE7.pcap
reading from file IE7.pcap, link-type EN10MB (Ethernet)
18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win
32120
18:24:41.313995
Andre, good day.
Wed, Jul 18, 2007 at 08:57:47AM +0200, Andre Oppermann wrote:
> >Seems like it is the effect of the SS_NOFDREF check in the
> >netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5.
> >See the post
> >http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074
Eygene Ryabinkin wrote:
Chuck, Julian, good day.
Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote:
% tcpdump -nS -r IE7.pcap
reading from file IE7.pcap, link-type EN10MB (Ethernet)
18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win
32120
18:24:41.313995 IP
Chuck, Julian, good day.
Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote:
> % tcpdump -nS -r IE7.pcap
> reading from file IE7.pcap, link-type EN10MB (Ethernet)
> 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290
> win
> 32120
> 18:24:41.313995 IP 10.251.22.29.1
[ I'm not sure which email address I should use when you reply to
yourself using a different addy. :-) ]
On Jul 17, 2007, at 4:24 PM, Julian Elischer wrote:
Julian Elischer wrote:
I have been looking at the following snippet of packets (under
FreeBSD 6.1).
This makes IE7 fail (but not IE6)
Julian Elischer wrote:
I have been looking at the following snippet of packets (under FreeBSD
6.1).
This makes IE7 fail (but not IE6) with a generic error.
We see lots of strange things here.. (like, why does the RST
go to a different sequence number?)
figured that one out... it's using the
14 matches
Mail list logo
