[prev in list] [next in list] [prev in thread] [next in thread]
List: ipfilter
Subject: simple rdr timing out
From: Brian Busch <bdbuschg () gmail ! com>
Date: 2009-01-29 4:44:16
Message-ID: 16380_1233204861_4981367C_16380_134_1_a204a5d50901282044jec65a4boca04fe55a6a963e3 () mail ! gmail ! com
[Download RAW message or body]
Brand new to IPF! Just found it last week and my simple rdr seemed to work -
until today.
Scoured the FAQ, Archive, google and this great writeup:
http://www.obfuscation.org/ipf/ipf-howto.txt
I have a very simple one-liner ipnat.conf, on Solaris 10 using the ipf
provided by the OS.
I just want to redirect port 80 to 8443 to get around running jboss to start
on a priv port.
root@dev # cat /etc/ipf/ipnat.conf
#!/sbin/ipnat -f -
rdr e1000g0 0.0.0.0/0 port 443 -> 0.0.0.0 port 8443
root@dev # ipf -V
ipf: IP Filter: v4.1.9 (592)
Kernel: IP Filter: v4.1.9
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
Feature mask: 0x107
root@dev # uname -a
SunOS dev 5.10 Generic_127112-02 i86pc i386 i86pc
It works, but under a very slight load, my Ext/javascript/Ajax client times
out on transactions - in fact, I can simulate the timeout by sending our XML
commands to a little servlet I wrote. Its not really load - its just how
long it takes for the server to respond - I think ipf is closing the socket.
If the transaction (Ajax POST to a servlet) on the jboss server (really,
tomcat) takes more than ~4 seconds, the browser/client just hangs - the
server reports all is well, has sent all the data to the client, no
exceptions, no "broken pipes" or anything network related. Any command sent
that takes less than this time works fine!
Plus, the SAME XML sent to 8443 works fine, using nat, they timeout or abort
or simply disappear. Again, all commands "work" to 8443 - if I substitute
443 in my url from the browser, which goes thru the nat/rdr in ipf, "long"
transactions disappear or timeout.
While I'm running my commands I run this simple loop in another putty
while true; do date; ipnat -l ; sleep 1; done
(the ipfstat command doesn't have stats on redirections, it appears)
and the sessions almost immediately disappear after they're serviced - I get
a few during a transaction from my client going to port 443 and in the next
loop (after a 1 second sleep), they're gone. Very quick. Too quick?
I'm steeped in tcp/udp and all the ndd(1M) timers - expected to see similar
to CLOSE_WAIT states, etc. but can't seem to find anything in ipf -T that
smells too low.
The only tunable I see that resembles something like a timeout on tcp is
fr_tcptimeout and it is set to 240, which appears to be 4 * MSL (downloaded
source) which is set to 60 - and I get mixed messages via google whether
this is ticks (2/sec) or seconds - if seconds, my 4 SECOND connection is
certainly under the 4 minute timer if 240 = seconds.
I looked in the source for fr_tcptimeout and note from a header file that it
appears to read-write - i.e., ipf doesn't have to down for it to change:
# define CTLFLAG_OFF 0x00800000 /* IPFilter must be disabled */
# define CTLFLAG_RWO (CTLFLAG_RW|CTLFLAG_OFF)
SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcptimeout, CTLFLAG_RWO,
&fr_tcptimeout, 0, "");
Can someone help?
I've also tried to simply change the setting fr_tcptimeout (assuming I
didn't know the units and it was something horrible like ms):
I tried
Using ipf(1M)
root@dev # ipf -D
root@dev # ipf -T fr_tcptimeout=3600
root@dev # ipf -T fr_tcptimeout
fr_tcptimeout min 0x1 max 0x7fffffff current 3600
root@dev # ipf -E
root@dev # ipf -T fr_tcptimeout
fr_tcptimeout min 0x1 max 0x7fffffff current 240 # reverts back!
Using SMF:
root@dev # ipf -T fr_tcptimeout
fr_tcptimeout min 0x1 max 0x7fffffff current 240
root@dev # svcadm disable ipfilter
root@dev # ipf -T fr_tcptimeout=3600
root@dev # svcadm enable ipfilter
root@dev # ipf -T fr_tcptimeout
fr_tcptimeout min 0x1 max 0x7fffffff current 240
Using ipf or SMF I can tell the ipf service is down, as my aforementioned
loop starts spewing ioctl problems.
Using ADB:
root@dev # echo "fr_tcptimeout/W 3600" | adb -w -k /dev/ksyms /dev/mem
physmem 1ff78c
adb: failed to dereference symbol: unknown symbol name
This makes we worried I don't have the version embedded in the kernel.
Next is to try system(4) - but I don't even believe I'm getting a timeout
from ipf! Folks were on the box so couldn't reboot then.
Thanks for any help!
Brian
[Attachment #3 (text/html)]
<div class="gmail_quote">Brand new to IPF! Just found it last week and my simple rdr \
seemed to work - until today.<div><br></div><div>Scoured the FAQ, Archive, google and \
this great writeup: <a href="http://www.obfuscation.org/ipf/ipf-howto.txt" \
target="_blank">http://www.obfuscation.org/ipf/ipf-howto.txt</a></div>
<div><br></div><div>I have a very simple one-liner ipnat.conf, on Solaris 10 using \
the ipf provided by the OS.</div><div><br></div><div><div><div><div>I just want to \
redirect port 80 to 8443 to get around running jboss to start on a priv port.<br> \
</div></div></div><div><br></div></div><div><div><div>root@dev # cat \
/etc/ipf/ipnat.conf</div><div>#!/sbin/ipnat -f -</div> <div>rdr e1000g0 <a \
href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> port 443 -> 0.0.0.0 port \
8443</div><div><br></div><div><div>root@dev # ipf -V</div><div>ipf: IP Filter: v4.1.9 \
(592)</div><div>Kernel: IP Filter: v4.1.9</div>
<div>
Running: yes</div><div>Log Flags: 0 = none set</div><div>Default: pass all, Logging: \
available</div><div>Active list: 1</div><div>Feature mask: \
0x107</div><div><br></div><div><div>root@dev # uname -a</div><div>SunOS dev 5.10 \
Generic_127112-02 i86pc i386 i86pc</div>
<div><br></div></div><div>It works, but under a very slight load, my \
Ext/javascript/Ajax client times out on transactions - in fact, I can simulate the \
timeout by sending our XML commands to a little servlet I wrote. Its not really load \
- its just how long it takes for the server to respond - I think ipf is closing the \
socket.<br> </div></div></div>
<div><br></div><div>If the transaction (Ajax POST to a servlet) on the jboss server \
(really, tomcat) takes more than ~4 seconds, the browser/client just hangs - the \
server reports all is well, has sent all the data to the client, no exceptions, no \
"broken pipes" or anything network related. Any command sent that takes \
less than this time works fine!</div>
<div><br></div><div>Plus, the SAME XML sent to 8443 works fine, using nat, they \
timeout or abort or simply disappear. Again, all commands "work" to 8443 - \
if I substitute 443 in my url from the browser, which goes thru the nat/rdr in ipf, \
"long" transactions disappear or timeout.</div> <div><br></div><div>While \
I'm running my commands I run this simple loop in another putty</div>
<div><div><br></div><div>while true; do date; ipnat -l ; sleep 1; \
done<br></div><div><br></div><div>(the ipfstat command doesn't have stats on \
redirections, it appears)</div><div><br></div><div>and the sessions almost \
immediately disappear after they're serviced - I get a few during a transaction \
from my client going to port 443 and in the next loop (after a 1 second sleep), \
they're gone. Very quick. Too quick?</div>
<div><br></div><div>I'm steeped in tcp/udp and all the ndd(1M) timers - expected \
to see similar to CLOSE_WAIT states, etc. but can't seem to find anything in ipf \
-T that smells too low. </div><div><br></div><div>
The only tunable I see that resembles something like a timeout on tcp is \
fr_tcptimeout and it is set to 240, which appears to be 4 * MSL (downloaded source) \
which is set to 60 - and I get mixed messages via google whether this is ticks \
(2/sec) or seconds - if seconds, my 4 SECOND connection is certainly under the 4 \
minute timer if 240 = seconds.</div>
<div><br></div><div>I looked in the source for fr_tcptimeout and note from a header \
file that it appears to read-write - i.e., ipf doesn't have to down for it to \
change:</div><div><br></div><div><div># define CTLFLAG_OFF 0x00800000 \
/* IPFilter must be disabled */</div> <div># define CTLFLAG_RWO \
(CTLFLAG_RW|CTLFLAG_OFF)</div><div>SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcptimeout, \
CTLFLAG_RWO,</div><div> &fr_tcptimeout, 0, \
"");</div><div><br></div></div><div>Can someone help? </div> \
<div><br></div><div>I've also tried to simply change the setting fr_tcptimeout \
(assuming I didn't know the units and it was something horrible like \
ms):</div><div><br></div><div>I tried</div><div><br>
</div><div>Using ipf(1M)</div><div>root@dev # ipf \
-D <br></div><div><div>root@dev # ipf -T fr_tcptimeout=3600</div><div>root@dev # \
ipf -T fr_tcptimeout</div><div>fr_tcptimeout min 0x1 max 0x7fffffff \
current 3600</div>
<div>
root@dev # ipf -E</div><div>root@dev # ipf -T fr_tcptimeout</div><div>fr_tcptimeout \
min 0x1 max 0x7fffffff current 240 # reverts \
back!</div><div><br></div></div><div>Using SMF: </div><div><div>root@dev # ipf \
-T fr_tcptimeout</div>
<div>fr_tcptimeout min 0x1 max 0x7fffffff current 240</div><div>root@dev \
# svcadm disable ipfilter<br></div><div>root@dev # ipf -T \
fr_tcptimeout=3600</div><div>root@dev # svcadm enable ipfilter</div><div>root@dev # \
ipf -T fr_tcptimeout</div>
<div>fr_tcptimeout min 0x1 max 0x7fffffff current \
240</div><div><br></div><div>Using ipf or SMF I can tell the ipf service is down, as \
my aforementioned loop starts spewing ioctl problems.</div><div><br></div><div>Using \
ADB:</div>
<div>root@dev # echo "fr_tcptimeout/W 3600" | adb -w -k /dev/ksyms \
/dev/mem<br></div><div>physmem 1ff78c</div><div>adb: failed to dereference symbol: \
unknown symbol name</div><div><br></div><div>This makes we worried I don't have \
the version embedded in the kernel.</div>
<div><br></div><div>Next is to try system(4) - but I don't even believe I'm \
getting a timeout from ipf! Folks were on the box so couldn't reboot \
then.</div><div><br></div></div><div>Thanks for any help!</div> <div><br></div><font \
color="#888888"><div>Brian</div>
</font></div></div>
</div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic