We opened a service call on a system where we had this problem with sun,
not realizing ipf was involved at all. In fact, it only occurs on reconfig
boots, because ipf attaches, and then detaches some time later. It happens
during detach. (ipf is installed but not actually being used to filter on
the pool of systems we had this problem on)
I looked at the current alpha and it looks like it can still happen.
Here's what they said.
--
The problem here is because of the third party IP Filter module that is
freeing up messages to IP during detach operation. A TPI request sent
down as part of setsockopt() message has been freed. setsockopt() will
not return unless an ACK/NACK is returned for its request causing this
hang.
Going through IP filter code, there is a window when it can free up
messages putnext() from TCP to IP during IP Filter detach operation.
Essentially ipf_detach() function is called during detach which sets
fr_running to -1 before calling soldetach().
soldetach() routine is the one that puts back ip_wput() and ip_rput()
functions back in the IP's qinit structures.
Anyway when fr_running is -1, ipf_ip_qin() will free packets.
...
static int ipf_ip_qin(q, mb)
queue_t *q;
mblk_t *mb;
{
struct iocblk *ioc;
int ret;
if (fr_running <= 0) {
mb->b_prev = NULL;
freemsg(mb);
return 0;
}
...
IP Filter needs to be fixed to not drop control packets.
