asterisk users - Apr 2005 - chan_iax2 stops listening to packets

I have two machines, running different versions of CVS HEAD. One with
CVS-HEAD-02/15/05-19:41:22, the other with CVS-HEAD-03/22/05-22:15:16.
Both are exhibiting the same problem. Basically, they stop listening to
packets, so they queue up in the kernel.

Proto Recv-Q Send-Q Local Address           Foreign Address    State      
<snip>
udp   107824      0 0.0.0.0:4569            0.0.0.0:*                          

The number just keeps going up. I've tried lots of different
configuration options. Just reloading doesn't unstuck it. Unloading the
module causes strange hangs. Stopping and starting Asterisk works until
the first IAX call attempt is made. Then it stops working.

One is using a TDM card (wct4xxp driver), the other is using ztdummy.
They are dual xeons, if it matters. How can I debug this? How do I
identify the thread running the IAX stuff? I confirmed the socket is
still open in lsof.

SIP calls keep working, ZAP calls keep working, just IAX is stuffed.
Perhaps I should just stick to SIP for the time being... I can't find
any bug that might have something to do with this. Any known patches
recently which might be related to this?

Actually, it doesn't even need to be triggered by a call. The log looks
like:

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
   Timestamp: 00001ms  SCall: 00006  DCall: 00000 [203.194.19.82:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: PONG   
   Timestamp: 00001ms  SCall: 00003  DCall: 00006 [203.194.19.82:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK    
   Timestamp: 00001ms  SCall: 00006  DCall: 00003 [203.194.19.82:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
   Timestamp: 00003ms  SCall: 00004  DCall: 00000 [203.194.19.82:4569]
glenmorangie*CLI> iax2 debug 
IAX2 Debugging Enabled

At this point the other machine starts recording this one as
UNREACHABLE. I've disabled all trunking, but that didn't help.

Thanks in advance,
-- 
Martijn van Oosterhout
Ecomtel Pty Ltd