Incoming sms problem on Motorola Droid 4

Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi!

I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0

> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0

... unfortunately, with that configuration no messages are comming to
ofono and the other phone sees them as "delievery failed".

I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
PDU) messages. That works well enough for me.

Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
work well, either.

Any ideas how to debug this / what to try?

Thanks,

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 917 bytes --]

Hi!

I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0

> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0

... unfortunately, with that configuration no messages are comming to
ofono and the other phone sees them as "delievery failed".

I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
PDU) messages. That works well enough for me.

Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
work well, either.

Any ideas how to debug this / what to try?

Thanks,

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Incoming sms problem on Motorola Droid 4

[Pavel Machek]

Hi!

I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0

> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0

... unfortunately, with that configuration no messages are comming to
ofono and the other phone sees them as "delievery failed".

I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
PDU) messages. That works well enough for me.

Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
work well, either.

Any ideas how to debug this / what to try?

Thanks,

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180508/3f90d2c4/attachment.sig>

Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi!

I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0

> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0

... unfortunately, with that configuration no messages are comming to
ofono and the other phone sees them as "delievery failed".

I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
PDU) messages. That works well enough for me.

Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
work well, either.

Any ideas how to debug this / what to try?

Thanks,

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Hi Pavel,

On 05/08/2018 04:51 PM, Pavel Machek wrote:
> Hi!
> 
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> 
>> AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
>> AT+CNMI=1,2,2,1,0
> < OK
> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> 
> ... unfortunately, with that configuration no messages are comming to
> ofono and the other phone sees them as "delievery failed".

So you're saying the modem firmware is lying about supporting all these 
modes :)

> 
> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> PDU) messages. That works well enough for me.

oFono doesn't support text mode...

> 
> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> work well, either.

You could try using value of '1' for the <mt> parameter and see if the 
modem will route messages to memory first and send a +CMTI indication..

> 
> Any ideas how to debug this / what to try?
> 

I think you have to play with some combinations, not really sure what to 
tell you. Refer to 3GPP 27.005 for details on the SMS related AT commands.

Regards,
-Denis

Re: Incoming sms problem on Motorola Droid 4

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180508 21:53]:
> Hi!
> 
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> 
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> > AT+CNMI=1,2,2,1,0
> < OK
> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> 
> ... unfortunately, with that configuration no messages are comming to
> ofono and the other phone sees them as "delievery failed".
> 
> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> PDU) messages. That works well enough for me.
> 
> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> work well, either.
> 
> Any ideas how to debug this / what to try?

Well you can try to see what Android is doing for SMS with:

# echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level
# dmesg | grep ts27010 | grep AT

To send SMS, looks like Android RIL first does:

2 AT+CMGS=327 where 327 seems to be the size of the whatever
encoded message. Then the next packet to dlci 2 contains the
encoded message that is of size 327.

When receiving, mdm6600 sends these on dlci 1:
~+WAKEUP
~+WAKEUP
~+WAKEUP

Then mdm6600 sends this on dlci 9:
~+CMT=372

And that's probably the incoming SMS size. But I don't see
anything for what actually reads the incoming SMS.

Regards,

Tony

Incoming sms problem on Motorola Droid 4

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180508 21:53]:
> Hi!
> 
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> 
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> > AT+CNMI=1,2,2,1,0
> < OK
> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> 
> ... unfortunately, with that configuration no messages are comming to
> ofono and the other phone sees them as "delievery failed".
> 
> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> PDU) messages. That works well enough for me.
> 
> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> work well, either.
> 
> Any ideas how to debug this / what to try?

Well you can try to see what Android is doing for SMS with:

# echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level
# dmesg | grep ts27010 | grep AT

To send SMS, looks like Android RIL first does:

2 AT+CMGS=327 where 327 seems to be the size of the whatever
encoded message. Then the next packet to dlci 2 contains the
encoded message that is of size 327.

When receiving, mdm6600 sends these on dlci 1:
~+WAKEUP
~+WAKEUP
~+WAKEUP

Then mdm6600 sends this on dlci 9:
~+CMT=372

And that's probably the incoming SMS size. But I don't see
anything for what actually reads the incoming SMS.

Regards,

Tony

Re: Incoming sms problem on Motorola Droid 4

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

Hi Pavel,

>> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
>>> AT+CNMI=?
>> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
>> < OK
>> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
>> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
>>> AT+CNMI=1,2,2,1,0
>> < OK
>> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
>> ... unfortunately, with that configuration no messages are comming to
>> ofono and the other phone sees them as "delievery failed".
> 
> So you're saying the modem firmware is lying about supporting all these modes :)
> 
>> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
>> PDU) messages. That works well enough for me.
> 
> oFono doesn't support text mode…

and it is impossible to support in a sane and complete manner.

>> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
>> work well, either.
> 
> You could try using value of '1' for the <mt> parameter and see if the modem will route messages to memory first and send a +CMTI indication..

I remember vaguely that I dealt with a modem that had some issue with the indications. Maybe we already have a quirk for that in one of the drivers. So look for SIMCOM or CINTERION vendor quirks. There are bunch of comments in drivers/atmodem/sms.c for this. You need to figure out on what level this modem is broken.

Regards

Marcel

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

On Tue 2018-05-08 17:08:25, Denis Kenzior wrote:
> Hi Pavel,
> 
> On 05/08/2018 04:51 PM, Pavel Machek wrote:
> >Hi!
> >
> >I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> >
> >>AT+CNMI=?
> >< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> >< OK
> >ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> >ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> >>AT+CNMI=1,2,2,1,0
> >< OK
> >ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> >
> >... unfortunately, with that configuration no messages are comming to
> >ofono and the other phone sees them as "delievery failed".
> 
> So you're saying the modem firmware is lying about supporting all these
> modes :)

I'm saying this modem is broken in more than one way, yes. I tried
CNMI=1,1, but that did not work too well:

ofonod[2935]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb:
90, 00, 30
> AT+CNMI=1,1
< OK
ofonod[2935]: src/network.c:__ofono_netreg_add_status_watch() 0x53bbf0
...
ofonod[2935]: src/modem.c:get_modem_property() modem 0x53b000 property
SystemPath
ofonod[2935]: plugins/upower.c:battery_props_changed()
< +CMTI: "ME",-1
ofonod[2935]: Unable to parse CMTI notification
< +CIEV: 7,1

I'm getting the +CMTI: "ME",-1 indication in other cases, too :-(.

> >I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> >PDU) messages. That works well enough for me.
> 
> oFono doesn't support text mode...
> 
> >
> >Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> >work well, either.
> 
> You could try using value of '1' for the <mt> parameter and see if the modem
> will route messages to memory first and send a +CMTI indication..

Invalid SMTI indication, AFAICT :-(. Let me play some more...

> >Any ideas how to debug this / what to try?
> >
> 
> I think you have to play with some combinations, not really sure what to
> tell you. Refer to 3GPP 27.005 for details on the SMS related AT commands.

Thanks for the pointer.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Hi!

> >> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> >>> AT+CNMI=?
> >> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> >> < OK
> >> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> >> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> >>> AT+CNMI=1,2,2,1,0
> >> < OK
> >> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> >> ... unfortunately, with that configuration no messages are comming to
> >> ofono and the other phone sees them as "delievery failed".
> > 
> > So you're saying the modem firmware is lying about supporting all these modes :)
> > 
> >> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> >> PDU) messages. That works well enough for me.
> > 
> > oFono doesn't support text mode…
> 
> and it is impossible to support in a sane and complete manner.

Ok, so after some more experiments:

ofonod[3057]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3057]: src/network.c:__ofono_netreg_add_status_watch() 0x538bf0
ofonod[3057]: src/sms.c:sms_restore_tx_queue()
ofonod[3057]: plugins/push-notification.c:sms_watch() registered
ofonod[3057]: plugins/smart-messaging.c:sms_watch() registered
> AT+CMGL=4
< OK
ofonod[3057]: drivers/atmodem/sms.c:at_cmgl_done()
> AT+CGSMS=3
< OK
< +CMT: ,38
<PDU
0791247033801600200C91246040431330000081508022704280156FF3DBFD06CDD1EF3A9B0CBABFE56B90FB7D07
ofonod[3057]: drivers/atmodem/sms.c:at_cmt_notify() Got new SMS
Deliver PDU via CMT:
0791247033801600200C91246040431330000081508022704280156FF3DBFD06CDD1EF3A9B0CBABFE56B90FB7D07,
38
ofonod[3057]: src/sms.c:ofono_sms_deliver_notify() len 46 tpdu len 38
ofonod[3057]: src/sms.c:handle_deliver()
ofonod[3057]: src/sms.c:sms_dispatch()
ofonod[3057]: src/sms.c:sms_dispatch() dst -1 src -1
ofonod[3057]: drivers/atmodem/sms.c:at_ack_delivery()
PDU Len 2, strlen 4
PDU last char 48
0000^ZCNMA=1,2
<PR
0000^ZCNMA=1,2
< +CMS ERROR: 304
ofonod[3057]: CNMA acknowledgement failed: Further SMS reception is
not guaranteed
< +CIEV: 1,4

Modem does not like our CNMA acknowledgement. AFAICT, we are sending

AT+CNMA=1,2
0000^Z

If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that, either, but with +CMS ERROR: 500.

Is "0000" correct thing to send for message acknowledge?

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Hi!

> > > AT+CNMI=1,2,2,1,0
> > < OK

> Well you can try to see what Android is doing for SMS with:
> 
> # echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level
> # dmesg | grep ts27010 | grep AT
> 
> To send SMS, looks like Android RIL first does:
> 
> 2 AT+CMGS=327 where 327 seems to be the size of the whatever
> encoded message. Then the next packet to dlci 2 contains the
> encoded message that is of size 327.

Sending SMSes seems to work with ofono.

> When receiving, mdm6600 sends these on dlci 1:
> ~+WAKEUP
> ~+WAKEUP
> ~+WAKEUP
> 
> Then mdm6600 sends this on dlci 9:
> ~+CMT=372
> 
> And that's probably the incoming SMS size. But I don't see
> anything for what actually reads the incoming SMS.

That seems to be standard message
ftp://www.3gpp.org/tsg_t/TSG_T/TSGT_04/Docs/PDFs/TP-99129.pdf .

Do you see AT+CNMI during boot and AT+CNMA after message is received?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Hi Pavel,

<snip>

> PDU Len 2, strlen 4
> PDU last char 48
> 0000^ZCNMA=1,2
> <PR
> 0000^ZCNMA=1,2
> < +CMS ERROR: 304
> ofonod[3057]: CNMA acknowledgement failed: Further SMS reception is
> not guaranteed
> < +CIEV: 1,4
> 
> Modem does not like our CNMA acknowledgement. AFAICT, we are sending
> 
> AT+CNMA=1,2
> 0000^Z

That looks correct.  In fact that logic has been working for something 
like 8-9 years, but it doesn't hurt to be paranoid and double check.

> 
> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> not like that, either, but with +CMS ERROR: 500.

CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:

window.open();
window.throw(modem);

Regards,
-Denis

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

Hi!

> >PDU Len 2, strlen 4
> >PDU last char 48
> >0000^ZCNMA=1,2
> ><PR
> >0000^ZCNMA=1,2
> >< +CMS ERROR: 304
> >ofonod[3057]: CNMA acknowledgement failed: Further SMS reception is
> >not guaranteed
> >< +CIEV: 1,4
> >
> >Modem does not like our CNMA acknowledgement. AFAICT, we are sending
> >
> >AT+CNMA=1,2
> >0000^Z
> 
> That looks correct.  In fact that logic has been working for something like
> 8-9 years, but it doesn't hurt to be paranoid and double check.

Ah. Four zeros somehow looked too simple to me.

> >If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> >not like that, either, but with +CMS ERROR: 500.
> 
> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
> 
> window.open();
> window.throw(modem);

Heh :-). Well, there are two phones with reasonable Linux support:
N900 and Droid 4. N900 can't do voice calls of reasonable
quality. That leaves Droid 4... so I'd really like it to work.

Afaict.. In PDU mode we need either +CNMA, which is broken, or CMTI,
which reports '+CMTI: "ME",-1' which I assume is broken, too.

Is there chance that '+CMTI: "ME",-1' can be understood as '+CMTI:
"ME",1' ?

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi Pavel,

>>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>>> not like that, either, but with +CMS ERROR: 500.
>>
>> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
>>
>> window.open();
>> window.throw(modem);
> 
> Heh :-). Well, there are two phones with reasonable Linux support:
> N900 and Droid 4. N900 can't do voice calls of reasonable
> quality. That leaves Droid 4... so I'd really like it to work.

Is this actually an AT command modem or one of those modems where AT 
commands were only bolted on for carrier certification?  Does it support 
QMI or something maybe?

> 
> Afaict.. In PDU mode we need either +CNMA, which is broken, or CMTI,
> which reports '+CMTI: "ME",-1' which I assume is broken, too.
> 
> Is there chance that '+CMTI: "ME",-1' can be understood as '+CMTI:
> "ME",1' ?

ITU v.250, Section 5.3.1:
< number>
may be a string of one or more characters from "0" through "9" 
representing a decimal integer value. Commands that expect a < number>
are noted in the description of the command (see clause 6).

So strictly speaking negative numbers are not allowed.  But who reads 
specs anyway for something as unimportant as a communications device 
that lives might depend on.

Regards,
-Denis

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Hi!

> >>>If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> >>>not like that, either, but with +CMS ERROR: 500.
> >>
> >>CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
> >>
> >>window.open();
> >>window.throw(modem);
> >
> >Heh :-). Well, there are two phones with reasonable Linux support:
> >N900 and Droid 4. N900 can't do voice calls of reasonable
> >quality. That leaves Droid 4... so I'd really like it to work.
> 
> Is this actually an AT command modem or one of those modems where AT
> commands were only bolted on for carrier certification?  Does it support QMI
> or something maybe?

Ok, so ... this is complex. And maybe this is one of "those" modems.

There's USB with AT commands, USB with QMI protocol, then serial with
mux and U1234AT+XYZ commands.

It seems Android uses serial, but that is being worked on, so I'm
using AT commands for now.

> >Afaict.. In PDU mode we need either +CNMA, which is broken, or CMTI,
> >which reports '+CMTI: "ME",-1' which I assume is broken, too.
> >
> >Is there chance that '+CMTI: "ME",-1' can be understood as '+CMTI:
> >"ME",1' ?
> 
> ITU v.250, Section 5.3.1:
> < number>
> may be a string of one or more characters from "0" through "9" representing
> a decimal integer value. Commands that expect a < number>
> are noted in the description of the command (see clause 6).
> 
> So strictly speaking negative numbers are not allowed.  But who reads specs
> anyway for something as unimportant as a communications device that lives
> might depend on.

Would it be possible to re-scan the messages similar way we do scan on
startup when invalid +CMTI is received?

Any hints how I should hack it in?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

Hi Pavel,

On 05/09/2018 01:57 PM, Pavel Machek wrote:
> Hi!
> 
>>>>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>>>>> not like that, either, but with +CMS ERROR: 500.
>>>>
>>>> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
>>>>
>>>> window.open();
>>>> window.throw(modem);
>>>
>>> Heh :-). Well, there are two phones with reasonable Linux support:
>>> N900 and Droid 4. N900 can't do voice calls of reasonable
>>> quality. That leaves Droid 4... so I'd really like it to work.
>>
>> Is this actually an AT command modem or one of those modems where AT
>> commands were only bolted on for carrier certification?  Does it support QMI
>> or something maybe?
> 
> Ok, so ... this is complex. And maybe this is one of "those" modems.
> 
> There's USB with AT commands, USB with QMI protocol, then serial with
> mux and U1234AT+XYZ commands.
> 
> It seems Android uses serial, but that is being worked on, so I'm
> using AT commands for now.

Wow, okay.  You might want to try using the qmi driver family instead.

> 
>>> Afaict.. In PDU mode we need either +CNMA, which is broken, or CMTI,
>>> which reports '+CMTI: "ME",-1' which I assume is broken, too.
>>>
>>> Is there chance that '+CMTI: "ME",-1' can be understood as '+CMTI:
>>> "ME",1' ?
>>
>> ITU v.250, Section 5.3.1:
>> < number>
>> may be a string of one or more characters from "0" through "9" representing
>> a decimal integer value. Commands that expect a < number>
>> are noted in the description of the command (see clause 6).
>>
>> So strictly speaking negative numbers are not allowed.  But who reads specs
>> anyway for something as unimportant as a communications device that lives
>> might depend on.
> 
> Would it be possible to re-scan the messages similar way we do scan on
> startup when invalid +CMTI is received?

Possible.  You can try adding another vendor enumeration inside 
drivers/atmodem/vendor.h.  Make sure that that enumeration is passed to 
ofono_sms_create in your modem driver.  Then inside 
drivers/atmodem/sms.c modify the CMTI logic to issue a +CGML if the 
relevant vendor quirk is set.  Refer to 27.005 for the right parameter. 
I think at startup we use '4' which is to grab all of the messages. 
Here you might want to use '0' for received/unread.

Also, oFono does not manage the store itself and assumes that all 
messages are routed directly via +CMT.  If that is not possible, then it 
is assumed that the driver takes care of issuing +CMGD, etc.  So you 
would need to do that as well.

I think the logic issues a +CPMS properly already, but if not you might 
need to issue +CPMS with the right storage location first.

Regards,
-Denis

Re: Incoming sms problem on Motorola Droid 4

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Hi Pavel,

>>>>>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>>>>>> not like that, either, but with +CMS ERROR: 500.
>>>>> 
>>>>> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
>>>>> 
>>>>> window.open();
>>>>> window.throw(modem);
>>>> 
>>>> Heh :-). Well, there are two phones with reasonable Linux support:
>>>> N900 and Droid 4. N900 can't do voice calls of reasonable
>>>> quality. That leaves Droid 4... so I'd really like it to work.
>>> 
>>> Is this actually an AT command modem or one of those modems where AT
>>> commands were only bolted on for carrier certification?  Does it support QMI
>>> or something maybe?
>> Ok, so ... this is complex. And maybe this is one of "those" modems.
>> There's USB with AT commands, USB with QMI protocol, then serial with
>> mux and U1234AT+XYZ commands.
>> It seems Android uses serial, but that is being worked on, so I'm
>> using AT commands for now.
> 
> Wow, okay.  You might want to try using the qmi driver family instead.

I would switch to QMI since then you can also ignore this weird multiplexer.

Regards

Marcel

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

Hi!

> >>>>>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> >>>>>> not like that, either, but with +CMS ERROR: 500.
> >>>>> 
> >>>>> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
> >>>>> 
> >>>>> window.open();
> >>>>> window.throw(modem);
> >>>> 
> >>>> Heh :-). Well, there are two phones with reasonable Linux support:
> >>>> N900 and Droid 4. N900 can't do voice calls of reasonable
> >>>> quality. That leaves Droid 4... so I'd really like it to work.
> >>> 
> >>> Is this actually an AT command modem or one of those modems where AT
> >>> commands were only bolted on for carrier certification?  Does it support QMI
> >>> or something maybe?
> >> Ok, so ... this is complex. And maybe this is one of "those" modems.
> >> There's USB with AT commands, USB with QMI protocol, then serial with
> >> mux and U1234AT+XYZ commands.
> >> It seems Android uses serial, but that is being worked on, so I'm
> >> using AT commands for now.
> > 
> > Wow, okay.  You might want to try using the qmi driver family instead.
> 
> I would switch to QMI since then you can also ignore this weird multiplexer.

More explanation needed it seems:

I can already do USB with AT commands, no multiplexer needed. We'd
actually prefer to go over serial (with multiplexer), because USB
needs to be powered down in idle, and you still need communication
ovre serial to know that wakeup of USB is needed.

Yes, it is complex :-(.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Incoming sms problem on Motorola Droid 4

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hi Pavel,

>>>>>>>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>>>>>>>> not like that, either, but with +CMS ERROR: 500.
>>>>>>> 
>>>>>>> CNMA=1 is required to work in PDU mode according to 27.005 btw.  How about:
>>>>>>> 
>>>>>>> window.open();
>>>>>>> window.throw(modem);
>>>>>> 
>>>>>> Heh :-). Well, there are two phones with reasonable Linux support:
>>>>>> N900 and Droid 4. N900 can't do voice calls of reasonable
>>>>>> quality. That leaves Droid 4... so I'd really like it to work.
>>>>> 
>>>>> Is this actually an AT command modem or one of those modems where AT
>>>>> commands were only bolted on for carrier certification?  Does it support QMI
>>>>> or something maybe?
>>>> Ok, so ... this is complex. And maybe this is one of "those" modems.
>>>> There's USB with AT commands, USB with QMI protocol, then serial with
>>>> mux and U1234AT+XYZ commands.
>>>> It seems Android uses serial, but that is being worked on, so I'm
>>>> using AT commands for now.
>>> 
>>> Wow, okay.  You might want to try using the qmi driver family instead.
>> 
>> I would switch to QMI since then you can also ignore this weird multiplexer.
> 
> More explanation needed it seems:
> 
> I can already do USB with AT commands, no multiplexer needed. We'd
> actually prefer to go over serial (with multiplexer), because USB
> needs to be powered down in idle, and you still need communication
> ovre serial to know that wakeup of USB is needed.
> 
> Yes, it is complex :-(.

I missed the part that the weird serial multiplexer is wired independently. Then do everything via that serial multiplexer and never look back. However if that is as broken, then you will be really out of luck. Making this work reliable will be really hard.

While we have seen QMI protocol issues as well, but they have been less bad than the bolted on AT commands. Manufactures always get AT commands wrong since they let humans test it and not a real telephony stack like oFono.

Regards

Marcel

Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

Hi!

> > More explanation needed it seems:
> > 
> > I can already do USB with AT commands, no multiplexer needed. We'd
> > actually prefer to go over serial (with multiplexer), because USB
> > needs to be powered down in idle, and you still need communication
> > ovre serial to know that wakeup of USB is needed.
> > 
> > Yes, it is complex :-(.
> 
> I missed the part that the weird serial multiplexer is wired independently. Then do everything via that serial multiplexer and never look back. However if that is as broken, then you will be really out of luck. Making this work reliable will be really hard.
> 
> While we have seen QMI protocol issues as well, but they have been less bad than the bolted on AT commands. Manufactures always get AT commands wrong since they let humans test it and not a real telephony stack like oFono.
> 

Yes, I understand why AT commands are bad. IIRC messages should work
over qmi... but voice calls do not:

user(a)devuan:/my/ofono$ sudo python test/dial-number 604343103
Using modem /gobi_0
Traceback (most recent call last):
  File "test/dial-number", line 40, in <module>
      path = vcm.Dial(number, hide_callerid)
        File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line
	70, in __call__
	    return self._proxy_method(*args, **keywords)
 File "/usr/lib/python2.7/dist-packages/dbus/proxies.py",
 line 145, in __call__
 **keywords)
 File
 "/usr/lib/python2.7/dist-packages/dbus/connection.py",
 line 651, in call_blocking message, timeout) dbus.exceptions.DBusException:
 org.ofono.Error.NotImplemented: Implementation not provided
user(a)devuan:/my/ofono$
			

Communication with modem is definitely happening:

ofonod[7881]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[7881]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-55 dBm) on 5
ofonod[7881]: src/network.c:ofono_netreg_strength_notify() strength 80
ofonod[7881]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[7881]: drivers/qmimodem/network-registration.c:event_notify()
signal with 100%(-54 dBm) on 5

ofono supports voice calls over qmi, right? Is it possible that
mdm6600 does not support them?

qmicli has some voice options, but not option to do a call, either...

user(a)devuan:/my/ofono$ qmicli -d /dev/cdc-wdm0 --voice-get-config
error: couldn't open the QmiDevice: Cannot open device file '/dev/cdc-wdm0': Permission denied
user(a)devuan:/my/ofono$ sudo qmicli -d /dev/cdc-wdm0 --voice-get-config
[/dev/cdc-wdm0] Successfully retrieved Voice configuration:
Current TTY mode: 'off'Current Preferred Voice SO:
	NAM ID: '0'
	EVRC capability: 'enabled'
	Home Page Voice SO: 'evrc'
	Home Origination Voice SO: 'evrc'
	Roaming Origination Voice SO: 'evrc'
AMR Status:
	GSM: 'enabled'
	WCDMA: 'not-supported, gsm-hr-amr' (0x0005)
Current Voice Privacy Preference: 'enhanced'
user(a)devuan:/my/ofono$ sudo qmicli -d /dev/cdc-wdm0 --voice-get-supported-messages
error: couldn't get supported VOICE messages: QMI protocol error (71): 'InvalidQmiCommand'
user(a)devuan:/my/ofono$ 


Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

Hi Pavel,

> ofono supports voice calls over qmi, right? Is it possible that
> mdm6600 does not support them?

It looks like the QMI voicecall driver is just a stub with no operations 
actually implemented.

Regards,
-Denis

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hi Harald,

> ofono supports voice calls over qmi, right? Is it possible that
> mdm6600 does not support them?
> 

This reminds me... Weren't you the one who mentioned that you got 
voicecalls working on QMI devices?  Does that include the circuit 
switched control operations (e.g. dial, etc) as well?  Any chance that 
code might be upstream-able?

Regards,
-Denis

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Joey Hewitt]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Hi Denis and Pavel,

 > It looks like the QMI voicecall driver is just a stub with no 
operations actually implemented.

I hope I'm not stealing their thunder, but Alexander Couzens at sysmocom 
seems to be working on implementing it [0]. Last fall, I had 
incoming/outgoing calls in oFono working on my MSM8930-based Android 
phone with these patches. You will probably want to revert the 
"NOT_FOR_MERGE" commit(s).

I have some rough (outdated?) patches on top of theirs, for DTMF[1], and 
improving the implementation of release_specific()[2]. (I don't know 
some of the technical details of GSM and QMI, but those changes made 
declining incoming calls work the way I expected.)

-Joey

[0] https://git.sysmocom.de/ofono/log/?h=lynxis/master
[1] 
https://github.com/scintill/android_external_ofono/commit/306a3a6f19546b7b9b6b8df973d75710ce21bc3c
[2] 
https://github.com/scintill/android_external_ofono/commit/979fce83a1985b8a43f1b8f49ed746710792375f

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Hi Denis, Pavel, Marcel,

On Fri, May 11, 2018 at 08:02:01PM -0500, Denis Kenzior wrote:
> This reminds me... Weren't you the one who mentioned that you got voicecalls
> working on QMI devices?  Does that include the circuit switched control
> operations (e.g. dial, etc) as well?  Any chance that code might be
> upstream-able?

let me pull in Alexander "lynxis" Couzens into the loop, he has been doing all
QMI / ofono related developments for us in the Osmocom project.

My knowledge is that we're testing our network-side stack with voice calls
related tests (via ofono/QMI) for quite some months, but lynxis would know
all related details.

As there are no modems that reliably can deliver the actual audio data via USB
(aside some non-supported outdated experimental firmwares), we're only testing
the signaling plane so far.

We're building a custom board that contains four PCM bus slaves (at different clocks!)
in order to pick up the audio/voice data, but this doesn't exist yet.

See http://laforge.gnumonks.org/blog/20170902-cellular_modems-voice/ for more background
on the user/voice plane.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

Hi!

> > It looks like the QMI voicecall driver is just a stub with no operations
> actually implemented.
> 
> I hope I'm not stealing their thunder, but Alexander Couzens at sysmocom
> seems to be working on implementing it [0]. Last fall, I had
> incoming/outgoing calls in oFono working on my MSM8930-based Android phone
> with these patches. You will probably want to revert the "NOT_FOR_MERGE"
> commit(s).

Out of interest, what kind of phone how usable it is?

(Bacially everything works on Motorola Droid 4, with exception of
camera, and yes, I have some interesting hacks at places. That is with
current kernel and recent debian / Maemo Leste). 

https://pavelmachek.livejournal.com/141420.html?nojs=1

> I have some rough (outdated?) patches on top of theirs, for DTMF[1], and
> improving the implementation of release_specific()[2]. (I don't know some of
> the technical details of GSM and QMI, but those changes made declining
> incoming calls work the way I expected.)
> 
> -Joey
> 
> [0] https://git.sysmocom.de/ofono/log/?h=lynxis/master

Thanks for pointer.

include/ofono/call-list.h was missing; I provided a symlink to
include/call-list.h.

drivers/qmimodem/lde.c was missing. I provided an empty file. This
can't end well.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Alexander Couzens]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi Joey,

nice to hear, somebody else is using it.

The voicecall driver needs to be refactored as Denis already pointed
out on the mailinglist before it can go upstream.

The original idea of the voice_generated.c/h files was to create a
prototype how qmi generated files should look like and then write a
code generator for it, as the other qmi related projects already do.

I'ven't yet took a closer look on your patches together with modems and
a gsm network. Hopefully I can do it next week together with the
required refactoring for upstream.

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hi Joey,

> nice to hear, somebody else is using it.
> 
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.
> 
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look like and then write a
> code generator for it, as the other qmi related projects already do.

I think that code generation is a bad idea. And other projects are drinking some cool aid. So I really prefer not to have generated code for QMI support upstream. It is also a total waste of time. Using QMI is actually really simple.

Regards

Marcel

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4513 bytes --]

Hi!

> nice to hear, somebody else is using it.
> 
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.
> 
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look like and then write a
> code generator for it, as the other qmi related projects already do.
> 
> I'ven't yet took a closer look on your patches together with modems and
> a gsm network. Hopefully I can do it next week together with the
> required refactoring for upstream.

I got it to build, but quick test did not result in working call. I'm
using AT commands simultaneously on another channel.

Ideas welcome.

Best regards,
								Pavel

ce64aadfc798225807c25
Author: Alexander Couzens <lynxis@fe80.eu>
Date:   Tue Oct 17 10:11:19 2017 +0200

    call-list: fix a race condition in ofono_call_list_dial_callback

    If ofono_call_list_dial_callback is called later than
        ofono_call_list_notify, the new call is added, removed, added
	    again.

ofonod[6708]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 5
ofonod[6708]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 2
ofonod[6708]: src/gprs.c:registration_status_cb() /gobi_0 error 0
status 1
ofonod[6708]: src/gprs.c:ofono_gprs_status_notify() /gobi_0 status
registered (1)
ofonod[6708]: src/gprs.c:gprs_netreg_update() attach: 1,
driver_attached: 1
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
signal with -56 dBm on 5
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
signal with -56 dBm on 5
ofonod[6708]: drivers/qmimodem/gprs.c:ss_info_notify()
ofonod[6708]: drivers/qmimodem/gprs.c:handle_ss_info()
ofonod[6708]: drivers/qmimodem/gprs.c:extract_ss_info()
ofonod[6708]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 5
ofonod[6708]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 2
ofonod[6708]: src/gprs.c:ofono_gprs_status_notify() /gobi_0 status
registered (1)
ofonod[6708]: drivers/qmimodem/network-registration.c:ss_info_notify()
ofonod[6708]:
drivers/qmimodem/network-registration.c:extract_ss_info()
ofonod[6708]:
drivers/qmimodem/network-registration.c:extract_ss_info() serving
system status 1
ofonod[6708]:
drivers/qmimodem/network-registration.c:extract_ss_info() radio in use
5
ofonod[6708]:
drivers/qmimodem/network-registration.c:extract_ss_info() radio in use
2
ofonod[6708]:
drivers/qmimodem/network-registration.c:extract_ss_info() lac -1
cellid -1 tech -1
ofonod[6708]: src/network.c:ofono_netreg_status_notify() /gobi_0
status 1 tech -1 lac -1 ci -1
ofonod[6708]:
drivers/qmimodem/network-registration.c:qmi_current_operator()
ofonod[6708]: src/network.c:current_operator_callback() 0x5a0c98,
0x5a1f20
ofonod[6708]:
drivers/qmimodem/network-registration.c:qmi_signal_strength()
ofonod[6708]: src/gprs.c:netreg_status_changed() 1
ofonod[6708]: src/gprs.c:gprs_netreg_update() attach: 1,
driver_attached: 1
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
ofonod[6708]: drivers/qmimodem/network-registration.c:get_rssi_cb()
signal with -56 dBm on 5
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-55 dBm) on 5
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-56 dBm) on 5
ofonod[6708]: drivers/qmimodem/voicecall.c:dial_cb() QMI Error 3
ofonod[6708]: src/voicecall.c:dial_handle_result() Dial callback
returned error: Unknown error type
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-55 dBm) on 5
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-56 dBm) on 5
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
ofonod[6708]: drivers/qmimodem/network-registration.c:event_notify()
signal with 80%(-55 dBm) on 5



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[rfc] Fix incoming sms on Droid 4 was Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 11749 bytes --]

Hi!

> >>>>> Is this actually an AT command modem or one of those modems where AT
> >>>>> commands were only bolted on for carrier certification?  Does it support QMI
> >>>>> or something maybe?
> >>>> Ok, so ... this is complex. And maybe this is one of "those" modems.
> >>>> There's USB with AT commands, USB with QMI protocol, then serial with
> >>>> mux and U1234AT+XYZ commands.
> >>>> It seems Android uses serial, but that is being worked on, so I'm
> >>>> using AT commands for now.
> >>> 
> >>> Wow, okay.  You might want to try using the qmi driver family instead.
> >> 
> >> I would switch to QMI since then you can also ignore this weird multiplexer.
> > 
> > More explanation needed it seems:
> > 
> > I can already do USB with AT commands, no multiplexer needed. We'd
> > actually prefer to go over serial (with multiplexer), because USB
> > needs to be powered down in idle, and you still need communication
> > ovre serial to know that wakeup of USB is needed.
> > 
> > Yes, it is complex :-(.
> 
> I missed the part that the weird serial multiplexer is wired independently. Then do everything via that serial multiplexer and never look back. However if that is as broken, then you will be really out of luck. Making this work reliable will be really hard.
> 
> While we have seen QMI protocol issues as well, but they have been less bad than the bolted on AT commands. Manufactures always get AT commands wrong since they let humans test it and not a real telephony stack like oFono.
>

Ok, so it was a bit of a fight, and result is _not_ ready for
mergning, and probably not even ready for review.

But it works.. for me.

Trick is to use

AT+CSMS=0
AT+CNMI=1,2,2,1,0

combination and sabotage AT+CNMA commands. That way, ofono uses
PDU mode without acknowledgments, but we get working messages.

Best regards,
								Pavel


diff --git a/doc/location-reporting-api.txt b/doc/location-reporting-api.txt
index 21e346d4..ff0a35dc 100644
--- a/doc/location-reporting-api.txt
+++ b/doc/location-reporting-api.txt
@@ -13,7 +13,7 @@ Methods		dict GetProperties()
 		filedescriptor Request()
 
 			Asks to turn ON the NMEA stream and supplies the
-			gps device file descriptor. The external cliend should
+			gps device file descriptor. The external client should
 			use the file descriptor to receive the NMEA data.
 
 			Possible Errors: [service].Error.InProgress
diff --git a/drivers/atmodem/atutil.c b/drivers/atmodem/atutil.c
index 6f4e8a20..b63d5b33 100644
--- a/drivers/atmodem/atutil.c
+++ b/drivers/atmodem/atutil.c
@@ -381,9 +381,16 @@ gboolean at_util_parse_sms_index_delivery(GAtResult *result, const char *prefix,
 		st = AT_UTIL_SMS_STORE_BM;
 	else
 		return FALSE;
-
-	if (!g_at_result_iter_next_number(&iter, &index))
-		return FALSE;
+#if 0
+	if (g_at_result_iter_next(&iter, "-")) {
+	  printf("Unexpected - arrived, ignoring\n");
+	}
+#endif
+	if (!g_at_result_iter_next_number(&iter, &index)) {
+	  printf("iter next number parse failed, faking\n");
+	  index = 1;
+	  //return FALSE;
+	}
 
 	if (out_index)
 		*out_index = index;
diff --git a/drivers/atmodem/call-meter.c b/drivers/atmodem/call-meter.c
index 430d5461..3de3f59e 100644
--- a/drivers/atmodem/call-meter.c
+++ b/drivers/atmodem/call-meter.c
@@ -255,7 +255,7 @@ static void at_cpuc_query(struct ofono_call_meter *cm,
 	struct cb_data *cbd = cb_data_new(cb, data);
 
 	cbd->user = "+CPUC:";
-	if (g_at_chat_send(chat, "AT+CPUC?", cpuc_prefix,
+	if (g_at_chat_send(chat, "AT+CPnottodayUC?", cpuc_prefix,
 				cpuc_query_cb, cbd, g_free) > 0)
 		return;
 
diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c
index 68b89862..75dc6c6b 100644
--- a/drivers/atmodem/sms.c
+++ b/drivers/atmodem/sms.c
@@ -328,11 +328,13 @@ static inline void at_ack_delivery(struct ofono_sms *sms)
 
 	/* We must acknowledge the PDU using CNMA */
 	if (data->cnma_ack_pdu) {
-		switch (data->vendor) {
+		switch (0) {
 		case OFONO_VENDOR_CINTERION:
 			snprintf(buf, sizeof(buf), "AT+CNMA=1");
 			break;
 		default:
+		  printf("PDU Len %d, strlen %d\n", data->cnma_ack_pdu_len, strlen(data->cnma_ack_pdu));
+		  printf("PDU last char %d\n", data->cnma_ack_pdu[strlen(data->cnma_ack_pdu)-1]);
 			snprintf(buf, sizeof(buf), "AT+CNMA=1,%d\r%s",
 					data->cnma_ack_pdu_len,
 					data->cnma_ack_pdu);
@@ -340,7 +342,7 @@ static inline void at_ack_delivery(struct ofono_sms *sms)
 		}
 	} else {
 		/* Should be a safe fallback */
-		snprintf(buf, sizeof(buf), "AT+CNMA=0");
+		snprintf(buf, sizeof(buf), "AT");
 	}
 
 	g_at_chat_send(data->chat, buf, none_prefix, at_cnma_cb, NULL, NULL);
@@ -440,6 +442,8 @@ static void at_cmt_notify(GAtResult *result, gpointer user_data)
 	if (data->vendor != OFONO_VENDOR_SIMCOM)
 		at_ack_delivery(sms);
 
+	return;
+
 err:
 	ofono_error("Unable to parse CMT notification");
 }
@@ -832,9 +836,9 @@ static gboolean build_cnmi_string(char *buf, int *cnmi_opts,
 
 	/* Prefer to deliver SMS via +CMT if CNMA is supported */
 	if (!append_cnmi_element(buf, &len, cnmi_opts[1],
-					data->cnma_enabled ? "21" : "1", FALSE))
+					data->cnma_enabled ? "21" : "21", FALSE))
 		return FALSE;
-
+	
 	/* Always deliver CB via +CBM, otherwise don't deliver at all */
 	if (!append_cnmi_element(buf, &len, cnmi_opts[2], "20", FALSE))
 		return FALSE;
@@ -1204,8 +1208,8 @@ static void at_csms_status_cb(gboolean ok, GAtResult *result,
 		if (!g_at_result_iter_next_number(&iter, &mo))
 			goto out;
 
-		if (service == 1)
-			data->cnma_enabled = TRUE;
+		//if (service == 1)
+		//	data->cnma_enabled = TRUE;
 
 		if (mt == 1 && mo == 1)
 			supported = TRUE;
@@ -1255,6 +1259,9 @@ static void at_csms_query_cb(gboolean ok, GAtResult *result,
 		if (status_min <= 1 && 1 <= status_max)
 			cnma_supported = TRUE;
 
+	printf("Forcing cnma to false\n");
+	cnma_supported = FALSE;
+
 	DBG("CSMS query parsed successfully");
 
 out:
diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index e4c59c26..df2975bb 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -161,6 +161,7 @@ static void clcc_poll_cb(gboolean ok, GAtResult *result, gpointer user_data)
 			poll_again = TRUE;
 			goto poll_again;
 		}
+		goto poll_again;
 
 		ofono_error("We are polling CLCC and received an error");
 		ofono_error("All bets are off for call management");
@@ -420,6 +421,7 @@ static void at_dial(struct ofono_voicecall *vc,
 
 	strcat(buf, ";");
 
+	/* Need to make it non-blocking or something? */
 	if (g_at_chat_send(vd->chat, buf, atd_prefix,
 				atd_cb, cbd, g_free) > 0)
 		return;
diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c
index 3f290ac2..86ed1352 100644
--- a/gatchat/gatchat.c
+++ b/gatchat/gatchat.c
@@ -579,6 +579,8 @@ static void have_line(struct at_chat *p, char *str)
 	if (str == NULL)
 		return;
 
+	printf("< %s\n", str);
+
 	/* Check for echo, this should not happen, but lets be paranoid */
 	if (!strncmp(str, "AT", 2))
 		goto done;
@@ -650,6 +652,9 @@ static void have_pdu(struct at_chat *p, char *pdu)
 	if (pdu == NULL)
 		goto error;
 
+	printf("<PDU %s\n", pdu);
+
+
 	result.lines = g_slist_prepend(NULL, p->pdu_notify);
 	result.final_or_pdu = pdu;
 
@@ -764,11 +769,13 @@ static void new_bytes(struct ring_buffer *rbuf, gpointer user_data)
 			break;
 
 		case G_AT_SYNTAX_RESULT_PROMPT:
+		  printf("<PR\n");
 			chat_wakeup_writer(p);
 			ring_buffer_drain(rbuf, p->read_so_far);
 			break;
 
 		default:
+		  printf("<D\n");
 			ring_buffer_drain(rbuf, p->read_so_far);
 			break;
 		}
@@ -845,6 +852,7 @@ static gboolean can_write_data(gpointer data)
 	if (cmd == NULL)
 		return FALSE;
 
+	printf("> %s\n", cmd->cmd);
 	len = strlen(cmd->cmd);
 
 	/* For some reason write watcher fired, but we've already
@@ -1018,6 +1026,7 @@ static gboolean at_chat_set_wakeup_command(struct at_chat *chat,
 	return TRUE;
 }
 
+/* HERE ? */
 static guint at_chat_send_common(struct at_chat *chat, guint gid,
 					const char *cmd,
 					const char **prefix_list,
diff --git a/plugins/udevng.c b/plugins/udevng.c
index ff5d41af..a4b18488 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -233,10 +233,11 @@ static gboolean setup_gobi(struct modem_info *modem)
 		}
 	}
 
+	DBG("qmi=%s net=%s mdm=%s gps=%s diag=%s", qmi, net, mdm, gps, diag);
+	
 	if (qmi == NULL || mdm == NULL || net == NULL)
 		return FALSE;
 
-	DBG("qmi=%s net=%s mdm=%s gps=%s diag=%s", qmi, net, mdm, gps, diag);
 
 	ofono_modem_set_string(modem->modem, "Device", qmi);
 	ofono_modem_set_string(modem->modem, "Modem", mdm);
@@ -1250,6 +1251,7 @@ static struct {
 	{ "cinterion",	setup_serial_modem	},
 	{ "nokiacdma",	setup_serial_modem	},
 	{ "sim900",	setup_serial_modem	},
+	{ "g1",		setup_serial_modem	},
 	{ "wavecom",	setup_wavecom		},
 	{ "tc65",	setup_tc65		},
 	{ "ehs6",	setup_ehs6		},
@@ -1578,8 +1580,6 @@ static struct {
 	{ "mbm",	"cdc_ether",	"0930"		},
 	{ "mbm",	"cdc_ncm",	"0930"		},
 	{ "hso",	"hso"				},
-	{ "gobi",	"qmi_wwan"			},
-	{ "gobi",	"qcserial"			},
 	{ "sierra",	"qmi_wwan",	"1199"		},
 	{ "sierra",	"qcserial",	"1199"		},
 	{ "sierra",	"sierra"			},
@@ -1602,6 +1602,8 @@ static struct {
 	{ "telit",	"cdc_acm",	"1bc7", "0021"	},
 	{ "telitqmi",	"qmi_wwan",	"1bc7", "1201"	},
 	{ "telitqmi",	"option",	"1bc7", "1201"	},
+	{ "telitqmi",	"qmi_wwan",	"22b8", "2a70"	},
+	{ "telitqmi",	"option",	"22b8", "2a70"	},
 	{ "nokia",	"option",	"0421", "060e"	},
 	{ "nokia",	"option",	"0421", "0623"	},
 	{ "samsung",	"option",	"04e8", "6889"	},
@@ -1717,10 +1719,12 @@ static void check_device(struct udev_device *device)
 			return;
 	}
 
+#if 0
 	if ((g_str_equal(bus, "usb") == TRUE) ||
 			(g_str_equal(bus, "usbmisc") == TRUE))
 		check_usb_device(device);
 	else
+#endif
 		add_serial_device(device);
 
 }
@@ -1749,14 +1753,17 @@ static gboolean create_modem(gpointer key, gpointer value, gpointer user_data)
 		if (g_str_equal(driver_list[i].name, modem->driver) == FALSE)
 			continue;
 
+		DBG("Attempting modem setup, driver %s", modem->driver);
 		if (driver_list[i].setup(modem) == TRUE) {
 			ofono_modem_set_string(modem->modem, "SystemPath",
 								syspath);
 			ofono_modem_register(modem->modem);
 			return FALSE;
 		}
+		DBG("Modem setup failed, driver %s", modem->driver);		
 	}
 
+	DBG("Modem setup failed or not in driver_list?");
 	return TRUE;
 }
 
diff --git a/test/send-sms b/test/send-sms
index 98808aaf..cabe0652 100755
--- a/test/send-sms
+++ b/test/send-sms
@@ -6,6 +6,7 @@ import dbus
 if len(sys.argv) < 4:
 	print("Usage: %s [modem] <to> <message> <delivery report>" %\
 					(sys.argv[0]))
+        print("  where delivery report is 0|1")
 	sys.exit(1)
 
 bus = dbus.SystemBus()
diff --git a/test/test-location b/test/test-location
new file mode 100755
index 00000000..850e472b
--- /dev/null
+++ b/test/test-location
@@ -0,0 +1,20 @@
+import dbus
+import sys
+import glib
+
+bus = dbus.SystemBus()
+
+if len(sys.argv) == 2:
+        path = sys.argv[1]
+else:
+        manager = dbus.Interface(bus.get_object('org.ofono', '/'),
+                        'org.ofono.Manager')
+        modems = manager.GetModems()
+        path = modems[0][0]
+
+print("Connecting modem %s..." % path)
+modem = dbus.Interface(bus.get_object('org.ofono', path),
+                                                'org.ofono.LocationReporting')
+
+fd = modem.Request()
+


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hi Alexander, Joey,

On 05/12/2018 09:19 AM, Alexander Couzens wrote:
> Hi Joey,
> 
> nice to hear, somebody else is using it.
> 
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.

If it wasn't clear from my earlier mail, I would like to see these 
patches upstreamed.  Do you guys have plans to do so?  I'm happy to 
review/help these along...

> 
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look like and then write a
> code generator for it, as the other qmi related projects already do.

As you can tell we're not really sold on the whole code generation thing 
here :)  Can we simply stuff all structure definitions into voice.h and 
the parsers into qmiutils.[ch].

In the past we have parsed fairly complex TLV based objects using a 
common parsing function that took care of the various funny rules and 
corner cases.  Adding support for additional objects was then quite 
trivial.  See src/stkutil.[ch], start at 'parse_dataobj()'.  Perhaps 
this approach might be one for you to consider.

Regards,
-Denis

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Bob Ham]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On 12/05/18 08:37, Harald Welte wrote:

> As there are no modems that reliably can deliver the actual audio data via USB
> (aside some non-supported outdated experimental firmwares), we're only testing
> the signaling plane so far.

Hi Harald,

I'm alarmed to see this statement.  Can I ask what you mean here when 
you say "no modems"? :-)  Do you mean on the market in general?

I've been using the SIMCom SIM7100E which is specified as supporting 
audio data over a USB serial connection.  Unfortunately I've had a lot 
of trouble getting it to work but I've been collaborating with Stanislav 
Sinyagin (CC'd) who has a SIM7100E with an earlier firmware and who can 
reliably get audio by dd'ing /dev/ttyUSBX.  I'm waiting on our supplier 
to get the same firmware version.

There are earlier SIMCom modems with application notes describing how to 
get audio over USB too, for example the SIM5360.

Regards,

Bob

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]

Hi Bob,

On Wed, May 16, 2018 at 04:10:55PM +0100, Bob Ham wrote:
> On 12/05/18 08:37, Harald Welte wrote:
> 
> > As there are no modems that reliably can deliver the actual audio data via USB
> > (aside some non-supported outdated experimental firmwares), we're only testing
> > the signaling plane so far.
> 
> I'm alarmed to see this statement.  Can I ask what you mean here when you
> say "no modems"? :-)  Do you mean on the market in general?

I mean on the market in general, yes.  Sure you can find the odd outlier here or
there, but overall, I would estimate 90% or more modems do not support audio in the
first place, and 98% do not support it over USB.

The only "proper" approach I've ever seen was by Sierra Wireless, whose Qualcomm
based 3G modems for some time had an experimental firmware branch you could ask for,
which would then offer a composite USB device that had an USB audio class device
next to the usual other (cdc-ethernet, AT-command, QMI, MBIM, ...) interfaces.

However, that is discontinued and not supported for years, and there is no replacement.
FAEs are still handing it out on request, though.

> I've been using the SIMCom SIM7100E which is specified as supporting audio
> data over a USB serial connection.  Unfortunately I've had a lot of trouble
> getting it to work but I've been collaborating with Stanislav Sinyagin
> (CC'd) who has a SIM7100E with an earlier firmware and who can reliably get
> audio by dd'ing /dev/ttyUSBX.  I'm waiting on our supplier to get the same
> firmware version.

Which exactly reflects my statement:  It's very hard to get reliable,
working audio with commitment from a vendor.  Sure, you may find it more
or less accidentially working for some products in some firmware
version, but I yet have to find any vendor who would actually say "this
is a supported feature, we test it before every release, and we will
maintain it for every future firmware update".

> There are earlier SIMCom modems with application notes describing how to get
> audio over USB too, for example the SIM5360.

Yes, there have always been some (few) modules that offered audio codec
frames over (usb) serial.  You could find some Gemalto 3G modules that
also did this.  I find this a horrible hack, and at least on those
modules wehre I remember it always had some kind of side-effect, like
you had to give up the [virtual] UART that was normally used for GPS and
re-purpose that for the codec frames over serial.

With most of those modern 4G modems running Linux inside the modem, I
really cannot understand why none of them goes the extra mile and
enables a USB audio gadget so it simply shows up as usb-audio device on
the host.  I mean, USB audio profile is 1990ies... and we have 2018.

While doing reverse engineering on some Qualcomm LE based modems before,
I saw that the Qualcomm reference source code even appeared to include
usb-audio composite device capabilities.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Hi Stanislav,

On Fri, May 18, 2018 at 10:07:47PM +0200, Stanislav Sinyagin wrote:
> Simcom seems to be quite consistent in their support for this feature:
> it's available in 3 latest models, the 7100, 7500, and 7600 series,
> and they share the same AT command set for this.

Thanks a lot for pointing this out.  This is definitely good to know.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

Hi Stanislav,

On Wed, May 16, 2018 at 05:15:07PM +0200, Stanislav Sinyagin wrote:
> also most mPCIE modems deliver PCI voice over dedicated wires on their
> mPCIE socket. These wires are standardized as "reserved" and most
> standard boards with mPCIE don't connect them anywhere.

This is the "PCM" interface I was referring-to.  This means you need
a PCM slave interface to interface with it, as the modems typically all
insist on being a PCM master.  The intention here is that you attach
some external audio codec IC that converts from the PCM to analog audio.

This means you cannot interface this PCM interface e.g. with standard
USB-Audio bridge ICs, as all those USB-Audi bridge ICs (basically "USB
soundcard" ICs) all also only implement the "master" of the PCM
interface and not the slave.

See http://laforge.gnumonks.org/blog/20170902-cellular_modems-voice/

In the end, you have to use something like the SSC (synchronous serial)
peripheal of Atmel SAM3/SAM4/... devices, or an XMOS device in order to
interface with that audio.

Needless to say, the lack of a standard for where PCM lines are on mPCIe
slots means that you cannot build any base board that will interoperate
with mPCIe modules from different vendors.

> But if you develop your own PCB, you can actually retrieve the voice
> signal. It just needs a bit of hacking.

The fact that a PCM bus is present on the hardware pins of the mPCIe socket
or the pads of a LGA module also still doesn't mean that you actually will
have working audio.

Many modem module maker do not obtain patent licenses for audio/voice, as
they know/expect their modems are typically only used in machine2machine
or other data-only applications.

Finally, even if the firmware and hardware interface is present, in many
cases the modem manufacturers make you sign a declaration that you will
only use the voice interface as some kind of "emergency communication"
only, and not as part of your normal product.  Once again, patent
licensing differences for voice vs. data-only use cases are to be blamed
for that.

Oh, and I'm not even touching the question on whether audio will work in
circuit-switched 2G/3G only, or whether it will also work with VoLTE,
and particularly not whether they will do SRVCC, etc.  That adds yet
another dimension to the problem.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)