Summary:	ASTERISK-02084: [*BSD only?] Invalid poll() processing, channel.c; Packets with bad UDP checksum.
Reporter:	Konstantin Prokazoff (oryx)	Labels:
Date Opened:	2004-07-22 09:35:31	Date Closed:	2004-09-25 02:07:27
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	My previous modifications to file.c in ast_waitstream_full() was an indirect patch of problem (bugid: 2067). There are some misprocessing in channel.c with poll(), which provides incorrect RTP transmission/timing -> voice garbaged. ****** ADDITIONAL INFORMATION ****** Now we are testing patch, I haven't any messages like "UDP checksum bad, etc"
Comments:	By: Konstantin Prokazoff (oryx) 2004-07-22 12:00:13 First differ are at channel.c (CVS 16/07), in ast_waitfor_nandfs(...), after res = poll(pfds, max, rms). This are trully trancates if(res < 0) or if(res > 0), but what asterisk does if(!res)? This provides incorrect sheduling in the future, if no one of descriptors have to been proceed. For example: ast_waitstream(), ast_waitstreamfull() in file.c. Still working. Now I have NOTICE messages about incorrect sheduling/UDP packets only when context changed (so, new Playback() for example). By: Konstantin Prokazoff (oryx) 2004-07-23 04:27:22 Have chaned file.c, in ast_readaudio_callback() & ast_readvideo_callback(). In ast_sched_add in both functions, if whennext=1, so whennext/8=0! That's why scheduler says about "scheduled event in 0ms?" Still making diffs and testing them. edited on: 07-23-04 04:13 By: Mark Spencer (markster) 2004-07-24 13:04:17 So what's the story with this bug, anyway? By: Konstantin Prokazoff (oryx) 2004-07-24 13:25:15 Welcome Mark! We are (maybe) too seriously taking care about code and asterisk safe execution, but we thinking this maybe great softswitch in the future. For example, if it w'be interested for your, we have application, which provides Interbase-compatible database access. About this bug, so, we had next questions: 1. By rtp.c, notice: RTP: Received packet with bad UDP checksum, which a cause of unproper sheduling (we are trying to recvfrom(), when nobody sends us a packet), key in channel.c, when ast_waitfor_nandfds() or ast_waitfor_n_fd() called, it uses res=poll(), which can return res>0, res<0 and res=0. So, in case res=0 asterisk incorrectly shedules next event. 2. By sched.c, notice: Scheduled event in 0 ms?, which a cause of inproper value of int when in ast_sched_add function call from file.c: ast_readaudio_callback() and ast_readvideo_callback(). New events are added to scheduler at 1ms, but in functions described below your pass when/8, and if when=1, so when/8=0! 3. Now we are working with bug, which becomes from RTP processing of playstream(), I think. If you have newly created RTP stream and you're streaming file, your have at beginning txcore=0. But if you try to stream next file, txcore w'll have difference calculated between txcore of last UDP packet received and time(&now). That's why we have notice messages like "Difference is ..., ms is ...". How I understanding, RTP streamed only if data present? 4. In safe_system(), wait4() may return ECHILD, which means (how I think) that child have finished execution or not executed at all. I haven't tested all this points on linux, but have 100% reproducibility on two different P4-2.8, fbsd521 ht enabled. Chris said me, that he haven't such NOTICEs. I can't understand why, but we think that code must provide maximum error checking & validation. Thnx. By: Brian West (bkw918) 2004-08-11 23:09:10 Any thing else on this? By: Mark Spencer (markster) 2004-08-12 19:35:37 Do you have a diff?  It might be easier for me to see what you're talking about with a diff, preferably one for each issue. By: Brian West (bkw918) 2004-08-22 23:11:31 Please update this bug so we can move along here guys... we are pushing for 1.0 and need a faster turn around time. bkw By: darwin35 (darwin35) 2004-09-04 16:51:38 Oryx do you have a diff so I can test with you ? to see if this fixes  the error I am getting about  bad udp ? By: Mark Spencer (markster) 2004-09-07 12:55:31 I'm merging the BSD compatibility bugs into a single holder, so please place any comments about any remaining BSD issues in that new bug.  Thanks.