1. Thanks for the answer ;)

2. I already snooped an umts user incoming on the system, and I just saw the incoming line and an outgoing line, then nothing. I thought it was apache2 too, but it seems not to be the case: I tried shutting down apache, and run TomCat behind the same 80 port, and it does not work.
If I run TomCat on 18080 and open 18080, it works fine.
If I run Apache on a different port (82) it works fine.
There must be something before the service, and I can't think at other things but ipfilter.
----------------------------------------------------------------------------------

Da: Darren Reed <[EMAIL PROTECTED]>
A: Gabriele Bulfon <[EMAIL PROTECTED]>
Cc: [email protected]
Data: 19 aprile 2006 15.41.59 CEST
Oggetto: Re: IPFilter 4.1.9 problems on Solaris 10

> Hello, I am resending my hard problems cause I was asked not to send
> html emails.
>
> I stumbled upon two strange problems with IPFilter 4.1.9 on Solaris 10
> (any platform).
> It is a self-built ipfilter with gcc, substituting the original Sun's
> version.
>
> 1. when I do "svcadm disable ipfilter", the filter is not actually
> disabled. Nats still run, blocked ports are still blocked. Changing the
> rule file and doing "svcadm disable ipfilter -> svcadm enable ipfilter"
> reloads the changes.

Yes, this is a problem with the file /lib/svc/method/ipfilter(?) that
only kills the ipmon process and does not unload the ipf module. It
is missing this line after "stop)":
[ -n "$ipfid" ] && modunload -i $ipfid

I haven't gone looking to see if there is a bug open about this.

> 2. I have a configuration file that opens just few ports on the public
> machine (itself). Port 80 is one of them.
> All seems to run fine. Then I found 2 customers that cannot reach ONLY
> PORT 80 on any of these public machines running this build of ipfilter.
> These 2 customers remotely use the same Internet connection method: a
> pcmcia UMTS connect card.
> I tried to move apache to port 82 and open up port 82 on ipfilter (the
> same way it was open on port 80): it magically works fine.
> I moved again apache back to port 80 and asked the UMTS/connect-card
> user to do a "telnet www.mymachine.com 80" and try a "GET / HTTP/1.0".
> Once the user types the "G" the connection is broken.
> This does not happen on any other port, and this does not happen at all
> on any other user connection through other methods (works fine on UMTS
> through a nokia-phone used as an usb modem).
> And this did not happen with Sun's version.

Can you use tcpdump/snoop on the network interface in use here and
look at what's happening at the network level ? My bet is that the
webserver is closing the connection...

Darren

Reply via email to