Problems with 6.2-PRE and udp applications - dhcpd and named - ipfw stateful issue?

[Jonathan Feally]

OK - It did it again. named locked up - wait chan was select. But I was 
able to kill the process this time and restart it. However I was still 
not able to do any query's. I added a quick ipfw add 1 allow ip from any 
to any and that solved the query problem. I then proceeded to inspect my 
ipfw rules. All outbound dnsquery's are using the following rule:
allow udp from any to any dst-port 53 keep-state.
I then tried to utilize some of my other keep-state rules with no luck. 
It would seem as if the firewall stack simply doesn't want to do 
stateful after a while.
I also tried flushing all the rules and reloading them - that still did 
not work.
I can live for today with out stateful, so if anyone can help me with it 
today/tpnight troubleshooting that would be great. I don't want to 
reboot the machine until somebody can help me diagnose the problem - 
especially since I'm running what is going to be 6.2-RELEASE.

Looking back at the mailing list - I see that there was a change to 
ipfw.c that deals with dynamic rule timeout, perhaps this is to blame?

I am willing to give ssh access to debug this problem.

-Jon

Robert Watson wrote:

>
> On Fri, 13 Oct 2006, Jonathan Feally wrote:
>
>> I have a P4 2.8 box running on an intel MB with a em0 acting as a 
>> firewall. The em0 has multiple tagged vlans on it, no ip assigned to 
>> main interface. Almost clockwork now, 6-7 days after bootup named or 
>> dhcpd completly locks up. I can't even kill -9 the apps. I have 
>> recompiled both apps since upgrading. I have only made two changes to 
>> this system around the same time. 1.  Removed 2nd em nic that had 
>> only 1 network connected not vlan tagged. 2. Upgraded to 6.2-PRE
>>
>> Has anyone else had these problems? I am going to try running the 
>> system with the internet connection not tagged to see if that helps.
>
>
> I've not seen this on any boxes.  The usual debugging path here is to:
>
> (1) Look at the process wait channel in ps axl.
>
> (2) Compile KDB/DDB into the kernel, and do a kernel stack trace of the
>     process.
>
> Once you know what the kernel thread associated with the process is 
> doing, we can attempt to figure out why it's doing it.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>