| Summary: | ASTERISK-14101: [patch] chan_mobile.c:1038 mbl_read: read error 107 | ||
| Reporter: | hmld (hmld) | Labels: | |
| Date Opened: | 2009-05-10 18:58:37 | Date Closed: | 2009-05-27 12:19:37 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Addons/chan_mobile |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) chan_mobile_v2.diff ( 1) chan_mobile_v2a.diff ( 2) chan_mobile.diff | |
| Description: | In bug report http://bugs.digium.com/view.php?id=15037 I mentioned that a "read error 104" happened repeatedly. Now, with chan_mobile version 905 and the quickly evolving git version of the bluetooth kernel subsystem, when asterisk is making a call via the cell phone I'm getting read error 107. This error number translates to "transport endpoint is not connected" (formely: 104 "connection reset by peer"). But voice is back and clear. Error 107 stops to be printed two seconds and 80856 identical copies later the very moment the mobile reports that it is ringing the other side : - Executing [0xxxxxxxxx@phones:1] Dial("SIP/1000-b9660308", "Mobile/Nokia/0xxxxxxxx,45") in new stack -- Called Nokia/0xxxxxxxxx [May 11 18:32:45] ERROR[7791]: chan_mobile.c:1038 mbl_read: read error 104 [...] [May 11 18:32:47] ERROR[7791]: chan_mobile.c:1038 mbl_read: read error 107 -- Mobile/Nokia-1728 is ringing -- Mobile/Nokia-1728 is ringing == Spawn extension (phones, 0xxxxxxxxx, 1) exited non-zero on 'SIP/1000-b9660308' -- Bluetooth Device Nokia has disconnected. -- Bluetooth Device Nokia has connected, initilizing... -- Bluetooth Device Nokia initialized and ready. The high poll frequency (about 40 kHz) points to a problem with file descriptor handling around the select system call. Possibly FD_CLR is left out on in case of a read error? ****** ADDITIONAL INFORMATION ****** 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Nokia 6280 Firmware Version 6.43 Bluez-4.38 Kernel: http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-testing.git;a=commit;h=d0c79a9f9fe1fe42dd8e2b9ad316b6a8bb82436a dmesg says something like: hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 btusb_isoc_complete: hci0 corrupted SCO packet btusb_isoc_complete: hci0 corrupted SCO packet hci_scodata_packet: hci0 SCO packet for unknown connection handle 46 hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 | ||
| Comments: | By: hmld (hmld) 2009-05-10 19:02:56 Reviewing what I have just written I recognize, that error 104 is the first error after starting a call, only then the long list of error 107 begins. By: hmld (hmld) 2009-05-21 06:51:03 Others seem to have the same problem: http://www.spinics.net/lists/linux-bluetooth/msg02253.html By: zvision (zvision) 2009-05-22 08:29:12 I wrote a simple patch that solves the issue. For some reason Nokia resets established SCO connection during call establishment sometimes (it also resets an RFCOMM connection after call hangup, causing phone rediscovery). My patch simply closes SCO socket correctly inside mbl_read when error 104 is encountered. After this, Nokia will establish another connection and everything is fine. I know this is not a solution but a workaround, but it's better than nothing. I also added missing pvt locks (other channels do so, so we should follow, I think). By: zvision (zvision) 2009-05-22 08:47:12 I corrected my patch to check for the errno value first and the do ast_log, as it may change the errno variable. Maybe a more general solution would be to check for EAGAIN and some other special cases that do not signal fatal connection errors and close the socket on other error types, not only the 104. By: hmld (hmld) 2009-05-22 09:11:02 In a message sent to the Bluetooth mailing list (http://www.spinics.net/lists/linux-bluetooth/msg02269.html), R. Seste reports to have found a working configuration:kernel 2.6.9-78 and bluez 2.10-3. In a previous message he also said that he had encountered this problem with a Nokia 5310, but also using a LG KF-240. Hence I wonder if this is really a Nokia problem. Nevertheless, I will try your patch later this day. By: zvision (zvision) 2009-05-22 09:30:44 I forgot to mention that my kernel version is 2.6.26 and bluez is 4.40 By: hmld (hmld) 2009-05-22 12:50:44 zvision, your patch cures most of the symptoms, thank you very much for your effort. However, because the patch introduced a pointer-to-int cast, gcc was a bit unhappy at the first place. I' attach another patch which should be applied after chan_mobile_v2.diff. Tested on x86 with a CSR Adapter (0a12:0001), a Nokia 6280 V6.43, linux-2.6.30-rc6-00159-ga15ae93 and bluez-4.40. By: zvision (zvision) 2009-05-22 17:03:41 Good point! I tested it with a few CSR based dongles connected and Nokia 6021 phones (various firmware revisions) and it seems to work fine. By: Rafael Seste (rseste) 2009-05-27 09:43:42 zvision, I tested your patch, and got a good improvement in audio quality, I can hear the outgoing voice perfectly, but the incoming audio is still not intelligible. From the hcidump output, I saw that incoming SCO packets have stranges handle sizes and data. for example: 0000 03 ff ee ff ee ff ee ff ee ff ee ff 5c 00 30 ee ........ ....\.0. 0010 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 0020 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 0030 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff 5c ........ .......\ 0040 00 30 ee ff ee ff ee ff ee ff ee ff ee ff ee ff .0...... ........ 0050 ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ........ ........ 0060 ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ........ ........ 0070 ee ff 5c 00 30 ee ff ee ff ee ff ee ff ee ff ee ..\.0... ........ 0080 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 0090 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 00a0 ff ee ff ee ff 5c 00 30 ee ff ee ff ee ff ee ff .....\.0 ........ 00b0 ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ........ ........ 00c0 ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ........ ........ 00d0 ee ff ee ff ee ff ee ff 5c 00 30 ee ff ee ff ee ........ \.0..... 00e0 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 00f0 ff ee ff ee ff ee ff ee ff ee ff ee ff ee ff ee ........ ........ 0100 ff ee ff ... the 2º\3º\4º bytes should be 5c 00 30 Could this be a compilation problem, because it is an ARM? like structure paddings or littleendian/bigendian Tested on ARM with Integrated System Solution Corp. KY-BT100 dongle, Nokia 5310 and LG KF240, linux 2.6.30-rc6 and bluez 4.40 By: hmld (hmld) 2009-05-27 10:26:53 @rseste, just avoid anything made by ISC. I tested two dongles made by ISC, and got distorted voice, delayed voice or no voice at all. Do you have exactly the same setup working on x86? By: Rafael Seste (rseste) 2009-05-27 10:56:50 I tested with a Cambridge Silicon Radio dongle too, and the same problem occurs. I don't have the same setup on x86. I have one with 2.6.28-11 and bluez 4.32 without this patch and it works perfectly. By: Matthew Nicholson (mnicholson) 2009-05-27 11:34:44 I wonder if this is something asterisk should handle, or if this is a bluez bug. Either way, that issue is unrelated to this bug. By: Matthew Nicholson (mnicholson) 2009-05-27 11:57:42 Good work with the patch guys. I am cleaning it up and I will commit it shortly. By: Digium Subversion (svnbot) 2009-05-27 12:07:01 Repository: asterisk-addons Revision: 926 U trunk/channels/chan_mobile.c ------------------------------------------------------------------------ r926 | mnicholson | 2009-05-27 12:07:01 -0500 (Wed, 27 May 2009) | 9 lines Lock the pvt structure in the mbl_read() and mbl_write() functions. (issue ASTERISK-14101) Reported by: hmld Patches: chan_mobile_v2.diff uploaded by zvision (license 798) chan_mobile_v2a.diff uploaded by hmld (license 777) Tested by: hmld, zvision, rseste ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk-addons?view=rev&revision=926 By: Digium Subversion (svnbot) 2009-05-27 12:13:45 Repository: asterisk-addons Revision: 927 U trunk/channels/chan_mobile.c ------------------------------------------------------------------------ r927 | mnicholson | 2009-05-27 12:13:45 -0500 (Wed, 27 May 2009) | 9 lines Handle read errors from the sco_socket by closing the socket conenction and waiting for another one before reading again. This is non standard behavior to accomidate certain Nokia handsets. (closes issue ASTERISK-14101) Reported by: hmld Patches: chan_mobile_v2.diff uploaded by zvision (license 798) chan_mobile_v2a.diff uploaded by hmld (license 777) Tested by: hmld, zvision, rseste ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk-addons?view=rev&revision=927 By: Digium Subversion (svnbot) 2009-05-27 12:19:36 Repository: asterisk-addons Revision: 928 _U branches/1.6.2/ U branches/1.6.2/channels/chan_mobile.c ------------------------------------------------------------------------ r928 | mnicholson | 2009-05-27 12:19:36 -0500 (Wed, 27 May 2009) | 27 lines Merged revisions 926-927 via svnmerge from https://origsvn.digium.com/svn/asterisk-addons/trunk ........ r926 | mnicholson | 2009-05-27 12:07:00 -0500 (Wed, 27 May 2009) | 9 lines Lock the pvt structure in the mbl_read() and mbl_write() functions. (issue ASTERISK-14101) Reported by: hmld Patches: chan_mobile_v2.diff uploaded by zvision (license 798) chan_mobile_v2a.diff uploaded by hmld (license 777) Tested by: hmld, zvision, rseste ........ r927 | mnicholson | 2009-05-27 12:13:44 -0500 (Wed, 27 May 2009) | 9 lines Handle read errors from the sco_socket by closing the socket conenction and waiting for another one before reading again. This is non standard behavior to accomidate certain Nokia handsets. (closes issue ASTERISK-14101) Reported by: hmld Patches: chan_mobile_v2.diff uploaded by zvision (license 798) chan_mobile_v2a.diff uploaded by hmld (license 777) Tested by: hmld, zvision, rseste ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk-addons?view=rev&revision=928 | ||