empty ussd response although dongle received data

[GoogleCodeExporter]

chan_dongle seems to 'forget' ussd response

What steps will reproduce the problem?
1. dongle stop now dongle0
2. dongle start dongle0
3. dongle ussd dongle0 SomeUssdCommand

What is the expected output? What do you see instead?
expected: the ussd response
got: empty string
fixable by doing: module unload/reload, dongle start, ussd, then it works 
again?!

What version of the product are you using? On what operating system?
latest chan_dongle 1.1r10 from tgz
linux 2.6.32 with asterisk 1.8.4.4

Please provide any additional information below.
See also attached file including debug info
(note: some private details have been xxx-ed out, both in raw ussd response and 
in parsed response)

Using K3765 with version 11.126.03.06.00
But given the fact that debug info shows the reply coming in, I doubt this is 
an issue with firmware.

Original issue reported on code.google.com by mcbchand...@robuust.nl on 8 Aug 2011 at 12:10

Attachments:

• dongle_ussd_fail.txt

[GoogleCodeExporter]

Can provide +CUSD: string for both cases (ok decoding and failure) ?
differs in Data Coding Scheme ?

Bug may be here:
1) K3765  is not listed in at_response_cgmm() as seven_bit_modems
this mean cusd_use_ucs2_decoding and cusd_use_7bit_encoding unaffected by 
at_response_cgmm() for K3765

2) pvt_create() initialize cusd_use_ucs2_decoding = 1 and 
cusd_use_7bit_encoding = 0 (as ast_calloc do)

3) disconnect_dongle() reset cusd_use_ucs2_decoding to 0 instead of 1 

solution: 
1) reset cusd_use_ucs2_decoding and cusd_use_7bit_encoding to default before
look by seven_bit_modems in at_response_cgmm()

2) fix disconnect_dongle() for reset cusd_use_ucs2_decoding  to 1 and 
cusd_use_7bit_encoding to 0

Original comment by bg_...@mail.ru on 8 Aug 2011 at 9:34

• Changed state: Accepted

[GoogleCodeExporter]

please check r19 and report bug exist or resolved,
i has't K3765 

Original comment by bg_...@mail.ru on 8 Aug 2011 at 9:45

[GoogleCodeExporter]

Applied r19 patch to at_response.c, but not to chan_dongle.c.
Stop, start, ussd now works as expected.

I'd suggest to revert the chan_dongle.c patch, it does not really make sense to 
set cusd_use_ucs2_decoding to 1 there, while setting all other values to 'sane 
uninitialized' values.
One might even argue that the
                pvt->cusd_use_ucs2_decoding     =  1;
line (1385) in chan_dongle.c, function pvt_create could better be set to 0 as 
well.
(Tried that and it works!)

Extra question: at+cscs is used to try setting overall/sms charset to ucs2, and 
response to at+cscs is used to set/not set pvt->use_ucs2_decoding. Does this 
have any relation to the ussd charset capabilities?

Original comment by mcbchand...@robuust.nl on 9 Aug 2011 at 12:07