Re: Incoming sms problem on Motorola Droid 4

Re: Incoming sms problem on Motorola Droid 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1675 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.
> 
> OK is this over ttyUSB or ngsm port?

ttyUSB. ngsm port behaves too strangely for me.

> > > 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.
> 
> Hmm it occured to me that maybe the incoming messages are read
> using QMI over USB.
> 
> > 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?
> 
> I'm only seeing AT+CNMA=0,0 on dlci 9 after resume. I think that is
> used to query for new messages.
> 
> No CNMI in my logs it seems. But if QMI over USB is used to read
> the messages that would explain it only checks for new SMS.

Thanks for info. No real leads there :-(.
									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: 1088 bytes --]

Hi!

> > > And that's probably the incoming SMS size. But I don't see
> > > anything for what actually reads the incoming SMS.
> 
> Hmm it occured to me that maybe the incoming messages are read
> using QMI over USB.
> 
> > 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?
> 
> I'm only seeing AT+CNMA=0,0 on dlci 9 after resume. I think that is
> used to query for new messages.
> 
> No CNMI in my logs it seems. But if QMI over USB is used to read
> the messages that would explain it only checks for new SMS.

I tried debugging this some more, and it is rather frustrating :-(.

State of the modem is kept over tries, which makes me reboot rather
often.

Is there way to power cycle the modem without reboot? That should make
the debugging... less bad.

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: 1471 bytes --]

On Fri 2018-05-11 05:39:26, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180511 12:36]:
> > Is there way to power cycle the modem without reboot? That should make
> > the debugging... less bad.
> 
> Yeah you can currently do:
> 
> # rmmod ohci-platform
> # rmmod phy-mapphone-mdm6600
> # modprobe phy-mapphone-mdm6600
> # modprobe ohci-platform
> 
> Or rebind via sysfs. If the modem reboots, you should
> see the phy-mapphone-mdm6600 status interrupt trigger?

Rebind via sysfs works nicely. Note that rather long delay is needed,
otherwise modem is in state when it talks AT but is not fully ready.

Thanks!
									Pavel

	bus = "/sys/bus/platform/drivers/"
	phone = "phy-mapphone-mdm6600"
        ohci = "ohci-platform"
	os.system("sudo chown user "+bus+phone+"/unbind")
        os.system("sudo chown user "+bus+phone+"/bind")
        os.system("sudo chown user "+bus+ohci+"/unbind")
        os.system("sudo chown user "+bus+ohci+"/bind")
        os.system("echo 4a064800.ohci > "+bus+ohci+"/unbind")
        os.system("echo usb-phy(a)1 > "+bus+phone+"/unbind")
        os.system("echo usb-phy(a)1 > "+bus+phone+"/bind")
	os.system("echo 4a064800.ohci > "+bus+ohci+"/bind")
        # With sleep 3, modem is initialized, but +CSMS (etc) still fails       
        time.sleep(10)



-- 
(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

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: 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

[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

[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: 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: 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: 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: 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

[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: 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

[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

[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

[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

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 --]