Re: s...port's - problem

Frank van Bortel wrote:

 > 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.

I really wish I didn't sound rude, Frank. I didn't mean to! most is due to my poor english :(

> 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)

The difference in port number on the client side is due to the TCP implementation.

When you create a connection it is unambiguously recongnized by 4 numbers: client ip address, client port, server ip address, server ip port.

usually a deamon (as the oracle listener) do not "redirect" the server side port (as showed by your tests as well). So two different connections on the same client are distinguished only by the port numbers. This is why the client port is pseudo-random chosen.

In general the firewall doesn't check the starting port for the communication but only the target one.

The OP issue is probably due to using oracle on windows which after creating a new thread on the server side redirects the server port (ex: if the listener is on 1521 the server connection will go on port 12345 which is a behaviour not shared by unix).

Now the firewall has only the (for example) 1521 open while windows instructed the client to communicate on 12345 (server side). but that port is blocked by the firewall and the connection is broken.

The windows behaviour can be changed by using use_shared_socket which, as Sybrand pointed, has some contraindications.

-- 
Fabrizio Magni

fabrizio.magni_at_mycontinent.com

replace mycontinent with europe