[Home]

Summary:ASTERISK-14509: [patch] Initialization error in chan_mobile
Reporter:Medardo Toledo (medtoledo)Labels:
Date Opened:2009-07-21 14:29:16Date Closed:2009-10-19 10:28:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Addons/chan_mobile
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_mobile_debug
( 1) debug-1.6.2-1.diff
( 2) mobile-bsir-ignore1.diff
( 3) mobile-bsir-ignore2.diff
( 4) mobile-ignore-unknown-fix1.diff
Description:we get error: "error inicializing bluetooth devise"



****** ADDITIONAL INFORMATION ******

Testing with Motorola phone i776

inicialization works fine in asterisk trunk but not asterisk 1.6.2
Comments:By: Matthew Nicholson (mnicholson) 2009-07-21 15:43:21

Please post your debug logs (/var/log/asterisk/debug) from the initialization process with debug level set to at least 1 (core set debug 1).

By: BrettS (ughnz) 2009-07-31 20:41:35

Have same issue with asterisk-1.6.2.0-beta4 and addons-1.6.2.0-rc1

Here is the info from log:
[Aug  1 13:16:10] VERBOSE[3012] loader.c:  chan_mobile.so => (Bluetooth Mobile Device Channel Driver)
[Aug  1 13:16:34] VERBOSE[3059] chan_mobile.c:     -- Bluetooth Device TRUNK has connected, initilizing...
[Aug  1 13:16:35] VERBOSE[3135] chan_mobile.c:     -- Error initializing Bluetooth device TRUNK.
[Aug  1 13:16:35] VERBOSE[3135] chan_mobile.c:     -- Bluetooth Device TRUNK has disconnected.
[Aug  1 13:17:27] VERBOSE[3059] chan_mobile.c:     -- Bluetooth Device TRUNK has connected, initilizing...
[Aug  1 13:17:27] VERBOSE[3137] chan_mobile.c:     -- Error initializing Bluetooth device TRUNK.
[Aug  1 13:17:27] VERBOSE[3137] chan_mobile.c:     -- Bluetooth Device TRUNK has disconnected.
[Aug  1 13:18:19] VERBOSE[3059] chan_mobile.c:     -- Bluetooth Device TRUNK has connected, initilizing...
[Aug  1 13:18:19] VERBOSE[3170] chan_mobile.c:     -- Error initializing Bluetooth device TRUNK.
[Aug  1 13:18:19] VERBOSE[3170] chan_mobile.c:     -- Bluetooth Device TRUNK has disconnected.
[Aug  1 13:19:09] DEBUG[3059] chan_mobile.c: connect() failed (112).
[Aug  1 13:19:13] VERBOSE[3059] chan_mobile.c:     -- Bluetooth Device TRUNK has connected, initilizing...
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: rfcomm_write() (24) [AT+BRSF=4
]
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: rfcomm_write() (24) [AT+CIND=?
]
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: rfcomm_write() (24) [AT+CIND?
]
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: rfcomm_write() (24) [AT+CMER=3,0,0,1
]
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: rfcomm_write() (24) [AT+CLIP=1
]
[Aug  1 13:19:13] DEBUG[3171] chan_mobile.c: [TRUNK] error enabling calling line notification
[Aug  1 13:19:13] VERBOSE[3171] chan_mobile.c:     -- Error initializing Bluetooth device TRUNK.
[Aug  1 13:19:13] VERBOSE[3171] chan_mobile.c:     -- Bluetooth Device TRUNK has disconnected.
[Aug  1 13:19:25] ERROR[3058] chan_mobile.c: ast_io_wait() failed for audio on adapter blue1
[Aug  1 13:19:25] ERROR[3057] chan_mobile.c: ast_io_wait() failed for audio on adapter blue

By: Matthew Nicholson (mnicholson) 2009-08-03 08:57:56

The responses from the bluetooth device are missing from the debug log.  Try attaching the debug log as a file instead of pasting it into a comment.

By: BrettS (ughnz) 2009-08-07 04:45:14

There are no responses from the phone in the log.

By: Matthew Nicholson (mnicholson) 2009-08-07 10:08:11

Asterisk should not have proceeded with the initialization if there was no response.  That is odd.  Please try again, make sure debug level is set to at least 1.

By: BrettS (ughnz) 2009-08-08 18:54:06

I set the debug level to 1 and looked at the entire log and did not see any responses. All that shows in the log is the information I posted, which was generated with debug level set to 1.

By: Matthew Nicholson (mnicholson) 2009-08-19 15:57:32

Apply the patch I just uploaded, test with debug level set to 2, then upload your debug log.  The patch I uploaded enables rfcomm read debug mode which will show me exactly what asterisk is receiving from the phone.

By: BrettS (ughnz) 2009-08-21 18:51:49

Attached log as requested.

By: BrettS (ughnz) 2009-10-10 20:43:17

Any further on this issue?

It would be nice to get the DISA going as it seems to not work with addons 1.6.1

By: Matthew Nicholson (mnicholson) 2009-10-12 15:38:44

I have looked at your log, and I see where this is failing in the code, but I am not yet sure exactly sure why it is failing.

By: BrettS (ughnz) 2009-10-13 02:21:05

From what I can see the phone is responding with a status message, which is an asynchronous message, and is masking the OK response.

From what my guess is the response code for the init needs to process the status messages and maybe ignore them?

I would assume the OK is at the end of the status message? and the code is ignoring the OK as a string compare fails?

By: Matthew Nicholson (mnicholson) 2009-10-13 08:44:46

That should not be possible.  The code should ignore the +BSIR response.

By: Matthew Nicholson (mnicholson) 2009-10-13 08:55:47

Test with the patch I just uploaded.  I added code to explicitly ignore BSIR messages.

By: Matthew Nicholson (mnicholson) 2009-10-13 09:06:58

The first patch had errors.  Try the second one.  As usual, test with debug level set to 2.

By: BrettS (ughnz) 2009-10-15 00:02:12

Hi,

Tried to patch against asterisk-addons-1.6.2-rc1 and the patch failed. It could not find the chan_mobile.c file. Looks like the patch was done against trunk?

By: Matthew Nicholson (mnicholson) 2009-10-15 09:49:08

Oh right.  I'll upload a new patch for 1.6.2.

By: Matthew Nicholson (mnicholson) 2009-10-15 09:52:56

I think I have found the problem.  Test with the patch I uploaded (mobile-ignore-unknown-fix1.diff) and see if it resolves this issue.  I have been looking for this issue in the trunk version of chan_mobile instead of the 1.6.2 version.

By: BrettS (ughnz) 2009-10-16 00:52:23

Hi

All is good with the trunk version.

Tried the patch and the result was the same. Did with debug set to 2. There was no responses listed from the phone. Here is the bits from the log:

[Oct 16 18:11:53] VERBOSE[19647] chan_mobile.c:     -- Bluetooth Device TRUNK has connected, initilizing...
[Oct 16 18:11:53] DEBUG[19692] chan_mobile.c: rfcomm_write() (32) [AT+BRSF=4
]
[Oct 16 18:11:53] DEBUG[19692] chan_mobile.c: rfcomm_write() (32) [AT+CIND=?
]
[Oct 16 18:11:53] DEBUG[19692] chan_mobile.c: rfcomm_write() (32) [AT+CIND?
]
[Oct 16 18:11:54] DEBUG[19692] chan_mobile.c: rfcomm_write() (32) [AT+CMER=3,0,0,1
]
[Oct 16 18:11:54] DEBUG[19692] chan_mobile.c: rfcomm_write() (32) [AT+CLIP=1
]
[Oct 16 18:11:54] DEBUG[19692] chan_mobile.c: [TRUNK] error enabling calling line notification
[Oct 16 18:11:54] VERBOSE[19692] chan_mobile.c:     -- Error initializing Bluetooth device TRUNK.
[Oct 16 18:11:54] VERBOSE[19692] chan_mobile.c:     -- Bluetooth Device TRUNK has disconnected.

By: Matthew Nicholson (mnicholson) 2009-10-16 09:16:01

Ok.  I will upload another debugging patch to try and provide more information about what exactly is failing.

By: Matthew Nicholson (mnicholson) 2009-10-16 10:31:42

I should have seen this sooner.  This will not work on 1.6.2 without major changes to the way initialization works.  It should work fine on trunk, because in that version, the initialization code was rewritten to support cases like this (as your testing indicates).

In 1.6.2 the code will not handle unsolicited result messages during initialization, so when the device sends the BSIR message, the code rejects it because it was expecting an OK message.  In trunk this has been completely reworked so that the code will ignore unsolicited result codes, or deal with them separately.

Your best option is probably to backport the trunk version of chan_mobile to 1.6.2.  This should not be very difficult.