PHWinfo - Afficher un message

22/03/2006, 20h48

fell.anthony@gmail.com wrote:
> A dump from the inetstatShow command lists multiple connections in
> the FIN_WAIT_1 state, some of which have data in their Send-Q.
> These connections were previously ESTABLISHED connections between a
> CORBA middle-ware client and server. They remian in the FIN_WAIT_1
> state for hours.

Interesting. One would indeed expect those connections to "retransmit
timeout" - are you sure it is the same data in the Send-Q you see each
time, and is indeed the same connection in FIN_WAIT_1? You might try
to get a packet trace of traffic to/from those connections to see if
there are indeed ACKs coming back that may be keeping the connection
alive. Otherwise, it may be a bug in the TCP stack.

> The dump also shows some ESTABLISHED connections with data in the
> Recv-Q. The amount of data in the Recv-Q does not change over a
> period of hours, again, connections related to CORBA middle-ware.

That one sounds like a middleware/app issue - either not checking for
data available, or ignoring data available indications.

> Finally, there is a large amount of data in the Recv-Q of a UDP echo
> server. The amount of data fluctuates over time, but the Queue is
> never emptied.

That one sounds a triffle sinister. Unless you know you have
applications that really need to reach-out and touch the echo service
you should probably disable it, or at least restrict it to your
organization's IPs. Particularly a UDP echo service since that one
would be more vulnerable to IP source address spoofing, allowing an
attacker to get you to send data to some other poor slob out on the
network.

> All these partially terminated connections and non-empty data queues
> exhaust the avialable mbuf pool.

Just how many of these things do you have and how small is your mbuf
pool?

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...

feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

22/03/2006, 20h48	#2
Rick Jones Messages: n/a Hébergeur:	Re: Network stack question fell.anthony@gmail.com wrote: > A dump from the inetstatShow command lists multiple connections in > the FIN_WAIT_1 state, some of which have data in their Send-Q. > These connections were previously ESTABLISHED connections between a > CORBA middle-ware client and server. They remian in the FIN_WAIT_1 > state for hours. Interesting. One would indeed expect those connections to "retransmit timeout" - are you sure it is the same data in the Send-Q you see each time, and is indeed the same connection in FIN_WAIT_1? You might try to get a packet trace of traffic to/from those connections to see if there are indeed ACKs coming back that may be keeping the connection alive. Otherwise, it may be a bug in the TCP stack. > The dump also shows some ESTABLISHED connections with data in the > Recv-Q. The amount of data in the Recv-Q does not change over a > period of hours, again, connections related to CORBA middle-ware. That one sounds like a middleware/app issue - either not checking for data available, or ignoring data available indications. > Finally, there is a large amount of data in the Recv-Q of a UDP echo > server. The amount of data fluctuates over time, but the Queue is > never emptied. That one sounds a triffle sinister. Unless you know you have applications that really need to reach-out and touch the echo service you should probably disable it, or at least restrict it to your organization's IPs. Particularly a UDP echo service since that one would be more vulnerable to IP source address spoofing, allowing an attacker to get you to send data to some other poor slob out on the network. > All these partially terminated connections and non-empty data queues > exhaust the avialable mbuf pool. Just how many of these things do you have and how small is your mbuf pool? rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...