ipfilter: OOW and NEG_OOW

[Oscar del Rio]

on a couple of systems running nv109 and nv110, with ipfilter enabled,
occasionally we get OOW and NEG_OOW errors.

ipf rule (a web server):
pass in quick proto tcp from any to any port = 80 keep state keep frags

ipmon error:
iprb0 @0:2 b [LOCAL_IP],80 -> [REMOTE_IP],1250 PR tcp len 20 40 -A OUT OOW


ipf rule (a desktop):
pass out quick from [LOCAL_IP] to any keep state keep frags

ipmon error:
e1000g0 @0:3 b [REMOTE_IP],80 -> [LOCAL_IP],43130 PR tcp len 20 1500 -AP
IN NEG_OOW


Is this a known problem? (I remember earlier OOW problems in Solaris 10
but I thought those were already fixed)

Thanks

Oscar

[Jens Elkner]

Post by Oscar del Rio
on a couple of systems running nv109 and nv110, with ipfilter enabled,
occasionally we get OOW and NEG_OOW errors.
pass in quick proto tcp from any to any port = 80 keep state keep frags

An SUN case engineer told me, that on should always add 'flags S' when using
'keep state' too get not into trouble. Why: unknown ...
But I guess, this is not the real problem.

Post by Oscar del Rio
Is this a known problem? (I remember earlier OOW problems in Solaris 10
but I thought those were already fixed)

We have encountered ipf problems on our mail servers, too - since
installation of 138888-07 (138888-08 doesn't solve the problem):

After 2..3 days ipfilter seems to trash its tables or bumps some packets
into a black hole and thus only occasional mail comes through. Strange
thing is, that mail connections from the local net come through without
any problem - so its not so easy to get notified, that's something
wrong. The problem doesn't occure on machines with the same patch level
and snv110 - I guess because they get much much less external connection
requests.

Had the same problem (at least wrt. symptoms) when feature upgrading to
S10u4 (120011-14) - also on the mail servers, only. That time,
IDR136697-08 did mitigate the problem but did not resolve it.
IDR137077-05 finally fixed it.

Don't know, whether a new IDR exists - so re-enabled ipfilter restart
per cron job ...

Regards,
jel.

[Darren Reed]

Post by Jens Elkner

Post by Oscar del Rio
on a couple of systems running nv109 and nv110, with ipfilter enabled,
occasionally we get OOW and NEG_OOW errors.
pass in quick proto tcp from any to any port = 80 keep state keep frags

An SUN case engineer told me, that on should always add 'flags S' when using
'keep state' too get not into trouble. Why: unknown ...

Because TCP window scaling options are only in the SYN/SYN-ACK
packets and they affect what each end system considers to be "in window".
If you create TCP state with IPFilter in mid-stream, it will be without
that knowledge and hence unable to correctly mimic the end nodes
idea of what the window really is.

Thus IPFilter will think things are "out of winodw" (OOW) when they
really aren't...

Darren

[Oscar del Rio]

Post by Darren Reed

Post by Jens Elkner

Post by Oscar del Rio
on a couple of systems running nv109 and nv110, with ipfilter enabled,
occasionally we get OOW and NEG_OOW errors.
pass in quick proto tcp from any to any port = 80 keep state keep frags

An SUN case engineer told me, that on should always add 'flags S' when using
'keep state' too get not into trouble. Why: unknown ...

Because TCP window scaling options are only in the SYN/SYN-ACK
packets and they affect what each end system considers to be "in window".
If you create TCP state with IPFilter in mid-stream, it will be without
that knowledge and hence unable to correctly mimic the end nodes
idea of what the window really is.
Thus IPFilter will think things are "out of winodw" (OOW) when they
really aren't...

Thanks, Darren and Jens!
I will fix the keep state rules and check if the OOW errors go away.

[Jens Elkner]

Post by Oscar del Rio
pass in quick proto tcp from any to any port = 80 keep state keep frags
An SUN case engineer told me, that on should always add 'flags S' when using
'keep state' too get not into trouble. Why: unknown ...
Because TCP window scaling options are only in the SYN/SYN-ACK
packets and they affect what each end system considers to be "in window".
If you create TCP state with IPFilter in mid-stream, it will be without
that knowledge and hence unable to correctly mimic the end nodes
idea of what the window really is.
Thus IPFilter will think things are "out of winodw" (OOW) when they
really aren't...

Aha ok - understood.

Thanx a lot!!!,
jel.

[Gordon Ross]

I need to get the list of IPv4 and IPv6 addresses for
some given hostname. I also need the CNAME.

I thought getaddrinfo with the AI_CANONNAME would get
that for me, but that seems to be not the case:

***@dell6300gwr$ getent hosts 129.148.169.51
129.148.169.51 dhcp-ubur01-169-51.East.Sun.COM
***@dell6300gwr$ ./getaddr dhcp-ubur01-169-51.East.Sun.COM
ai[0]: af=2, len=16 saf=2, IP=129.148.169.51
ai[0]: cname="dhcp-ubur01-169-51.East.Sun.COM"
***@dell6300gwr$ ./getaddr 129.148.169.51
ai[0]: af=2, len=16 saf=2, IP=129.148.169.51
ai[0]: cname="::ffff:129.148.169.51"

Is this a bug? Or am I being a "noob" here?
My "getaddr" test program is attached.

[Sebastien Roy]

Post by Gordon Ross
ai[0]: af=2, len=16 saf=2, IP=129.148.169.51
ai[0]: cname="::ffff:129.148.169.51"
Is this a bug? Or am I being a "noob" here?
My "getaddr" test program is attached.

This looks like a bug (which I see that you filed already). :-)

-Seb

[Gordon Ross]

Yes, I determined that it's a bug. Here's the CR:
6831339 getaddrinfo() sets ai_canonname incorrectly

It has a work-around, which is to call getnameinfo()
on the result. (I should add that to the CR.)

Thanks,
Gordon