|Summary:||ASTERISK-15932: [patch] Command/Response queue stuck|
|Reporter:||Daniel A. Veiga (dveiga)||Labels:|
|Date Opened:||2010-04-08 19:25:55||Date Closed:||2011-07-26 15:22:07|
|Environment:||Attachments:||( 0) chan_mobile.diff|
( 1) chan_mobileV2.diff
|Description:||My phone, a Samsung GT-S5230, seems to send \r\n after the responses. The \r is interpreted as the terminator and the \n ends up as the first char of the next response. at_read_full() fails under theese circumstances returning AT_UNKNOWN. A copy of the debug info is appended in "additional information".|
The proposed patch trims the answer prior to processing, solving the problem.
****** ADDITIONAL INFORMATION ******
[Apr 8 19:20:58] DEBUG: chan_mobile.c:2954 handle_response_ok: [CEL5] volume level synchronization successful
]Apr 8 19:20:58] DEBUG: chan_mobile.c:1348 rfcomm_write_full: rfcomm_write() (33) [AT+CMGF=1
[Apr 8 19:20:58] DEBUG: chan_mobile.c:3439 do_monitor_phone: [CEL5]
[Apr 8 19:20:58] DEBUG: chan_mobile.c:3523 do_monitor_phone: [CEL5] ignoring unknown message:
NOTE: The OK's are in the next line because they have a \n in front. The response is ignored even though it is expected because it is not recognised as such.
|Comments:||By: Daniel A. Veiga (dveiga) 2010-05-11 23:37:48|
First of all I want to correct what I said before. It is not that the phone sends \r\n and the \n ends up as the first char of the next command. The problem is the phone seds \r\n\r\n, and the second \r\n ends up as an empty command that causes the error explained before.
Anyhow, now that I've understood the code a little bit better, I changed the patch. The previous one discards the empty command before processing it. I didn't like it because it appears in the debug info as an unknown command. This new patch discards the empty line from the beggining, and nothing appears in the debug info.
By: Leif Madsen (lmadsen) 2011-07-26 15:22:01.002-0500
Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines