[Asterisk-Dev] Re: EAGAIN - recvfrom - bad udp checksum

[Tom Ivar Helbekkmo]

"Olle E. Johansson" <oej at edvina.net> writes:

> Yes, but do you also have insights on FreeBSD and other BSD's - is EAGAIN
> really a signal of a bad UDP checksum there as well or is it another issue?

The IP stack in my NetBSD system running Asterisk claims that *no* UDP
checksum errors occur, even while Asterisk is dumping a torrent of
such messages to the console.  I hear that others see them while
playing back voice mail, but I have only seen them while using the
Conference application from the IAXclient package.  I've run it on two
dual-CPU systems, where one has 350Mhz processors, the other 700MHz.
They run the same version of the OS, and of Asterisk.  On the slow
one, I see a continuous stream of these messages whenever two or more
people are in a conference.  On the fast one, I only get about a dozen
of them in a quick burst whenever a conference participant hangs up.

At this point, Conference is doing:

	left = ast_waitfor( chan, AST_CONF_WAITFOR_LATENCY ) ;

...and then, if left > 0,

	f = ast_read( chan ) ;

I assume this should mean that if ast_waitfor() returns a positive
number, this means the channel now has data available *before* the
timeout expired, right?  So the ast_read() should succeed?  It does
not, in this case, and here's a traceback from a forced break at the
printing of the error message, when this happens:

#0  ast_rtp_read (rtp=0x8249000) at rtp.c:425
#1  0x4837e07a in sip_rtp_read (ast=0x810a000, p=0x8245000) at chan_sip.c:2188
#2  0x4837c46b in sip_read (ast=0x810a000) at chan_sip.c:2224
#3  0x08059de3 in ast_read (chan=0x810a000) at channel.c:1309
#4  0x487727d6 in member_exec (chan=0x810a000, data=0x67ffdd38) at member.c:209
#5  0x487705d4 in app_conference_main (chan=0x810a000, data=0x67ffdd38)
    at app_conference.c:124
#6  0x0806c751 in pbx_exec (c=0x810a000, app=0x8231a80, data=0x67ffdd38, 
    newstack=1) at pbx.c:478
#7  0x08073e45 in pbx_extension_helper (c=0x810a000, con=0x0, 
    context=<incomplete type>, exten=<incomplete type>, priority=1, 
    label=<incomplete type>, callerid=<incomplete type>, action=1)
    at pbx.c:1317
#8  0x0806dfa9 in ast_pbx_run (c=0x810a000) at pbx.c:1815
#9  0x0807436a in pbx_thread (data=0x810a000) at pbx.c:2060
#10 0x4814c719 in pthread_create () from /usr/lib/libpthread.so.0

The fun bit is at chan_sip.c:2188:

	switch(ast->fdno) {
	case 0:
		f = ast_rtp_read(p->rtp);	/* RTP Audio */
		break;
	case 1:
		f = ast_rtcp_read(p->rtp);	/* RTCP Control Channel */
		break;
	case 2:
===>		f = ast_rtp_read(p->vrtp);	/* RTP Video */
		break;
	case 3:
		f = ast_rtcp_read(p->vrtp);	/* RTCP Control Channel for video */
		break;
	default:
		f = &null_frame;
	}

Yes, it's trying to read RTP Video from my Grandstream BT100.  :-)

I'm guessing there's some assumption in ast_waitfor_nandfds() that's
Linux dependent, and fails under BSD.  That's just a gut feeling, of
course.

-tih
-- 
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway Hosting
www.eunet.no  T +47-22092958 M +47-93013940 F +47-22092901 FWD 484145