Summary:	ASTERISK-26749: chan_dahdi.c: my_dahdi_write() returns zero even if it fails.
Reporter:	Segii Cherkavskyi (perec-jar)	Labels:
Date Opened:	2017-01-25 04:44:10.000-0600	Date Closed:	2017-02-08 12:57:35.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence	Constant
Related Issues:
Environment:	Gentoo Linux, asterisk 1.8.31.1	Attachments:	( 0) asterisk-15-12-2017-10-02-55.log ( 1) jira_asterisk_26749_v13.patch
Description:	Although my asterisk version is not the newest, I checked chan_dahdi.c in the more recent asterisk version (13) and the code in question is remained untouched, so here is the problem: {code:title=chan_dahdi.c|borderStyle=solid} static int my_dahdi_write(struct dahdi_pvt *p, unsigned char *buf, int len, int idx, int linear) { int sent=0; int size; int res; int fd; fd = p->subs[idx].dfd; while (len) { size = len; if (size > (linear ? READ_SIZE * 2 : READ_SIZE)) size = (linear ? READ_SIZE * 2 : READ_SIZE); res = write(fd, buf, size); if (res != size) { ast_debug(1, "Write returned %d (%s) on channel %d\n", res, strerror(errno), p->channel); return sent; } len -= size; buf += size; } return sent; } {code} *apps/chan_dahdi.c* has a method *my_dahdi_write()*, which returns *0*, even if writing to a file descriptor fails. In case of failure *my_dahdi_write()* produces the following log output: {noformat} chan_dahdi.c: Write returned -1 (Resource temporarily unavailable) on channel 4 {noformat} The return value of the method *my_dahdi_write()* is checked by the calling function *dahdi_write()* and returns with *-1*, in case if *my_dahdi_write()* fails, {color:red}which never happens{color}. While searching through the asterisk issue tracker, I found similar logs to the one I have, with discussions about echo cancellation etc. not directly discussing the return value of *my_dahdi_write()*. *dahdi_write()* is one of the tech interface methods and not returning -1 in case of write error informs other side (asterisk, sending application) that channel has successfully digested the frame. Thus, in my case SendFax() application believes the fax was successfully transmitted, which is not the case, since *my_dahdi_write()* silently drops data in case of failure.
Comments:	By: Asterisk Team (asteriskteam) 2017-01-25 04:44:12.034-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-01-25 11:39:52.572-0600 Thanks for the report! In order to maximize efficiently, there are project guidelines for how to report issues. Please read through the Asterisk Issue Guidelines [1]. After reading the guidelines, please clean up this issue so that bug marshals can more easily help you. In particular: 1. Don't post extensive debug or logs inside the Description or Comment fields. 2. Use the Description field for a description of the issue, referencing *attached* debug with links or notes. 3. Use the Comment fields for discussion regarding the issue. 4. If you need to put a few lines of debug or logs into any field, surround the text with "noformat" tags to help us read it easily. 5. Attach files with a '.txt' extension where possible so that they can be analyzed futher by bug marshals. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Rusty Newton (rnewton) 2017-01-25 11:44:14.735-0600 In addition to the comment about formatting, be aware that Asterisk 1.8 is no longer supported. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions Regarding the chan_dahdi issue, after you clean up the ticket please provide additional explanation as to the negative effects of your stated problem. I'm not sure it is completely clear. [~rmudgett] Has looked at the issue briefly and will reply in regards to the return value. By: Richard Mudgett (rmudgett) 2017-01-25 11:49:48.252-0600 Changing the my_dahdi_write() function to return -1 on failure will result in the channel hanging up.  Is the channel not being hung up on write failure the issue you are having? By: Segii Cherkavskyi (perec-jar) 2017-01-25 12:54:15.624-0600 Hello Richard Thank you and the whole team for helping with the issue. I apologise for badly created ticket, I will improve. In my use case multiple faxes are being queued by means of callfiles for a delivery to a fax machine. While there are 4 dahdi channels, only one is able to answer, since only one of four ports is occupied by a fax machine. From the log you can see that when channel 4 is answered, dahdi is unable to write data to a file descriptor in any of the calls to dahdi_write(). So the frames queued by SendFax() are silently droped. At the very end of the log however, once SendFax() application is done with queuing frames to dahdi, I see that transmission was successful (app_fax.c lines) and hangs up the channel resulting in dahdi channel also being hung up. If I correctly interpret the log, then behavior of dahdi is wrong and the correct would be to hang up the channel. I look forward to receiving your comment and thanks once again for help! By: Segii Cherkavskyi (perec-jar) 2017-01-25 14:51:52.709-0600 This is a debug log from the asterisk By: Richard Mudgett (rmudgett) 2017-01-25 15:20:03.118-0600 [^jira_asterisk_26749_v13.patch] - Patch to make my_dahdi_write() return -1 when the write fails.  This will result in the channel hanging up. The patch will apply correctly to v1.8 with some fuzz adjustments due to line numbers being different. By: Segii Cherkavskyi (perec-jar) 2017-01-25 15:31:44.469-0600 Thank you for the patch, Richard! Is this an issue and is going to be fixed in the recent versions of asterisk (because this code is exactly the same in asterisk 14.2.1)? Or this patch is just to try out how things will going to work in my 1.8 version of asterisk? By: Richard Mudgett (rmudgett) 2017-01-25 15:50:07.082-0600 That patch is ready for review on gerrit.  It does exactly what you are saying.  I put it here for you to test to see if it is really what you need.  Though, if anything further is needed you'll really need to move to a supported Asterisk version. By: Segii Cherkavskyi (perec-jar) 2017-01-25 15:58:44.436-0600 When I think about calls, this is not really a solution to hang up the channel, isn't it? Because I don't want to hang up the channel if some audio frame could not be written to the fd, right? By: Richard Mudgett (rmudgett) 2017-01-25 16:04:48.886-0600 It may be that your real problem is the fax data frames are being sent too fast and not allowing earlier frames to go out.  That could be the real reason for the "Resource temporarily unavailable" error. By: Richard Mudgett (rmudgett) 2017-02-08 12:57:35.362-0600 Closing because the suggested change seems like the wrong thing to do because it results in the channel hanging up.  Also this is reported against an unsupported Asterisk version.