Re: s...port's - problem

From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Tue, 28 Jun 2005 20:55:43 +0200
Message-ID: <d9s64u$hj4$1@news2.zwoll1.ov.home.nl>

Fabrizio wrote:
> This log show the client side connection. The 6037 and 6041 are on the
> client side.
>
> The server side 8as showed in your netstat) is always the 1522.
>
> You can see it better by using lsof or opening the connection from a
> client not on the server machine.
>
> What you have to demostrate, if you want to prove that I'm wrong, is
> that the server process is communicating on a port different from 1522.
>

OK - I see the flaw in my reasoning...

Now what can I come up with? Will a windows client do?

[oracle10_at_csdb01 oracle10]$ lsof -i

COMMAND  PID     USER   FD   TYPE  DEVICE SIZE NODE NAME
oracle  3671 oracle10   14u  IPv4    4300       UDP
localhost.localdomain:1026
tnslsnr 5195 oracle10   11u  IPv4 7030116       TCP *:1522 (LISTEN)
tnslsnr 5195 oracle10   12u  IPv4 7030122       TCP *:2484 (LISTEN)

After a windows client connected:

[oracle10_at_csdb01 oracle10]$ lsof -i

COMMAND  PID     USER   FD   TYPE  DEVICE SIZE NODE NAME
oracle  3671 oracle10   14u  IPv4    4300       UDP
localhost.localdomain:1026
tnslsnr 5195 oracle10   11u  IPv4 7030116       TCP *:1522 (LISTEN)
tnslsnr 5195 oracle10   12u  IPv4 7030122       TCP *:2484 (LISTEN)
oracle  5327 oracle10   14u  IPv4 7062795       TCP

csdb01.cs.nl:1522->cs-frank02.cs.nl:1208 (ESTABLISHED)

So all there is, is a new process (5327) , but it still seems to go via 1522... Case closed, I stand corrected; I did not understand the port redirection bit.

Now - how about the client process getting a new port#?!? That is still not just windows - I think that was demonstrated correctly. And *that* is the cause firewalls will fail (that is, static rule based ones - you could of course allow all traffic *initiated* from within - but this is cdo.server)

-- 
Regards,
Frank van Bortel

Received on Tue Jun 28 2005 - 13:55:43 CDT