[ale] bogus ESTABLISHED tcp connection on Windows 2003 (i386)

[Dow Hurst]

Jerry,
I've seen undocumented port connections on license servers.  The server
would have a documented port you would have to open to supposedly get a
connection.  However, two other ports would get used due to other parts
of the license server process talking back to the client.  So, I would
have three ports to deal with.  Once documented and two others
discovered via ethereal.  I figured it out by sniffing the network.  You
may not have the incentive to sniff like I had to since your application
is working.  However, a undocumented connection from a local client to
the local server as part of the application could be the reason for the
bogus port entry.
Dow

Jerry Yu wrote:
> This is not a linux question per se.
>
> A server application listens to tcp/8888 on a Windows 2003 server Ent
> (i386) with a few RHEL 4 (ppc64) and SEL9 (x86_64) clients in the same
> class C subnet. 
> When it exits properly, sometimes netstat shows a 'bogus' tcp
> connection in ESBALISHED state forever. A tuple like server:8888 <-->
> client 3456.
>
>     * on the clients: nobody uses tcp/3456 as reported by lsof and by
>       netstat
>     * on the server: nobody listens to tcp/8888.  windows own 
>       'commServer' now owns the server:8888 socket instead of the
>       server application.
>
> The  connection is obviously  bogus, so it doesn't stop me from
> starting up the server application to bind & listen to tcp/8888.
> However, the end-users are very concerned with this phantom connection.
> I am very curious too, on why commServer or any process would bother
> to take ownership of that socket/connection, and how can I rid of it?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale