Re: TCP socket close problem

per@xxxxxxxxxxxx (Per Hedeland) writes:

In article <87wtbhqkoi.fsf@xxxxxxxxxxxxxxxxxxxxx> Staffan Ulfberg
<staffan@xxxxxxxxxx> writes:

Your issue probably has nothing to do with FreeBSD specifically, but
people seem to post here about all kinds of things they run into while
they just happen to be running FreeBSD...

You're probably right, and therefore I'm somewhat reluctant to post
here, but I've used up far too much time on network issues lately and
do not know any better forum:(

It should transition to CLOSE_WAIT on receipt of FIN, and be deleted
altogether on receipt of RST AFAIK.
[...]
Well, theoretically, unless you use non-blocking I/O, your code be
blocked on send() and so never get to notice the arriving FIN via
select()/recv() (I prefer to use write()/read() on TCP sockets btw, but
I don't think that makes any difference). But I assume you would have
noticed that in your trace output, and the packet trace has other
info...
[...]
It seems clear that the server is seeing neither FIN nor RST - if it had
seen the FIN it should be ACK'ingwith 119, not 118, and if it had seen
the RST it certainly shouldn't send more data. It also seems that the
client isn't seeing the retransmits from the server, since it should
respond with RST to those (of course it may have been disconnected...).

Right. So indeed it looks like the server doesn't really see the
incoming FIN/RST at all.

Last time I believe you had a broken NAT device that corrupted the TCP
checksum, I suppose you have ruled out any similar (or even same)
problem now?:-) And I assume the trace is done on the server? Any local
firewall on it, that could possibly block the FIN/RST from being
delivered to the TCP/IP stack even though tcpdump sees them?

And yes, the trace is on the server, behind the broken firewall
(which, BTW, now runs an older firmware that does not seem to have the
bug discovered last time -- at least not the exact same bug...). No
local firewall.

I've now compared dumps from both inside and outside the firewall, and
I can detect no difference. I will of course try removing the
firewall completely, just in case there's something I'm missing in the
traces.

If this eventually turns out to be related to that firewall box again,
I promise it will be disconnected, dismantled, and permanently
prevented from ever seeing an IP fragment again! :)

Staffan
.

Relevant Pages

  • Re: TCP socket close problem
    ... And yes, the trace is on the server, behind the broken firewall ... power or yank the network cable in the middle of a session, ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Problem with Connection String & Data Direct!
    ... What tool would I want to be using to trace a connection?? ... >> Everything is running on a server internal to the company, ... >>>Is this an unsecured database with no firewall just waiting to be ...
    (comp.databases.oracle.tools)
  • Re: CEICW fails at firewall config
    ... Do you or do you not have ISA 2000 or ISA 2004 installed on the SBS server? ... Do you have 2 NICs in the SBS? ... CEICW fails on firewall configuration every time. ... >>> Call to Creating the protected networks access rule returned ok. ...
    (microsoft.public.windows.server.sbs)
  • Re: Recycler security issues on IIS server
    ... > latest upates to the server. ... > like to see the server put behind our firewall, ... other software, install all patches, IISlockdown, URLscan, use the correct ... the procedures you follow may vary depending on your security needs. ...
    (microsoft.public.inetserver.iis.security)
  • Re: ISA SERVER NOT STARTING
    ... I delete the nat/basic firewall and stop and started the RRAS an tried to ... There were no critical events in the DNS Server Log in the last 24 hours. ... An error occurred during logon ... Caller User Name: - ...
    (microsoft.public.windows.server.sbs)