* Incoming sms problem on Motorola Droid 4 @ 2018-05-08 21:51 ` Pavel Machek 0 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-08 21:51 UTC (permalink / raw) To: ofono, kernel list, linux-arm-kernel, linux-omap, tony, sre, nekit1000, mpartap, merlijn [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Incoming sms problem on Motorola Droid 4 @ 2018-05-08 21:51 ` Pavel Machek 0 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-08 21:51 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Incoming sms problem on Motorola Droid 4 @ 2018-05-08 21:51 ` Pavel Machek 0 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-08 21:51 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 35+ messages in thread
* Incoming sms problem on Motorola Droid 4 @ 2018-05-08 21:51 ` Pavel Machek 0 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-08 21:51 UTC (permalink / raw) To: ofono-bdc2hr5oBkPYtjvyW6yDsg, kernel list, linux-arm-kernel, linux-omap-u79uwXL29TY76Z2rM5mHXA, tony-4v6yS6AI5VpBDgjK7y7TUQ, sre-DgEjT+Ai2ygdnm+yROfE0A, nekit1000-Re5JQEeQqe8AvxtiuMwx3w, mpartap-hi6Y0CQ0nG0, merlijn-tF0PIh4TN3odnm+yROfE0A [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-08 21:51 ` Pavel Machek ` (2 preceding siblings ...) (?) @ 2018-05-08 22:08 ` Denis Kenzior 2018-05-09 4:31 ` Marcel Holtmann 2018-05-09 6:50 ` Pavel Machek -1 siblings, 2 replies; 35+ messages in thread From: Denis Kenzior @ 2018-05-08 22:08 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-08 22:08 ` Denis Kenzior @ 2018-05-09 4:31 ` Marcel Holtmann 2018-05-09 8:18 ` Pavel Machek 2018-05-09 6:50 ` Pavel Machek 1 sibling, 1 reply; 35+ messages in thread From: Marcel Holtmann @ 2018-05-09 4:31 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 4:31 ` Marcel Holtmann @ 2018-05-09 8:18 ` Pavel Machek 2018-05-09 13:03 ` Denis Kenzior 0 siblings, 1 reply; 35+ messages in thread From: Pavel Machek @ 2018-05-09 8:18 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 8:18 ` Pavel Machek @ 2018-05-09 13:03 ` Denis Kenzior 2018-05-09 15:11 ` Pavel Machek 0 siblings, 1 reply; 35+ messages in thread From: Denis Kenzior @ 2018-05-09 13:03 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 13:03 ` Denis Kenzior @ 2018-05-09 15:11 ` Pavel Machek 2018-05-09 15:41 ` Denis Kenzior 0 siblings, 1 reply; 35+ messages in thread From: Pavel Machek @ 2018-05-09 15:11 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 15:11 ` Pavel Machek @ 2018-05-09 15:41 ` Denis Kenzior 2018-05-09 18:57 ` Pavel Machek 0 siblings, 1 reply; 35+ messages in thread From: Denis Kenzior @ 2018-05-09 15:41 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 15:41 ` Denis Kenzior @ 2018-05-09 18:57 ` Pavel Machek 2018-05-09 19:33 ` Denis Kenzior 0 siblings, 1 reply; 35+ messages in thread From: Pavel Machek @ 2018-05-09 18:57 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 18:57 ` Pavel Machek @ 2018-05-09 19:33 ` Denis Kenzior 2018-05-10 6:50 ` Marcel Holtmann 0 siblings, 1 reply; 35+ messages in thread From: Denis Kenzior @ 2018-05-09 19:33 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 19:33 ` Denis Kenzior @ 2018-05-10 6:50 ` Marcel Holtmann 2018-05-10 6:58 ` Pavel Machek 0 siblings, 1 reply; 35+ messages in thread From: Marcel Holtmann @ 2018-05-10 6:50 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-10 6:50 ` Marcel Holtmann @ 2018-05-10 6:58 ` Pavel Machek 2018-05-10 7:11 ` Marcel Holtmann 0 siblings, 1 reply; 35+ messages in thread From: Pavel Machek @ 2018-05-10 6:58 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-10 6:58 ` Pavel Machek @ 2018-05-10 7:11 ` Marcel Holtmann 2018-05-11 23:18 ` Voice calls over qmi was " Pavel Machek 2018-05-14 13:02 ` [rfc] Fix incoming sms on Droid 4 " Pavel Machek 0 siblings, 2 replies; 35+ messages in thread From: Marcel Holtmann @ 2018-05-10 7:11 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-10 7:11 ` Marcel Holtmann @ 2018-05-11 23:18 ` Pavel Machek 2018-05-12 0:47 ` Denis Kenzior 2018-05-12 1:02 ` Denis Kenzior 2018-05-14 13:02 ` [rfc] Fix incoming sms on Droid 4 " Pavel Machek 1 sibling, 2 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-11 23:18 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-11 23:18 ` Voice calls over qmi was " Pavel Machek @ 2018-05-12 0:47 ` Denis Kenzior 2018-05-12 3:09 ` Joey Hewitt 2018-05-12 1:02 ` Denis Kenzior 1 sibling, 1 reply; 35+ messages in thread From: Denis Kenzior @ 2018-05-12 0:47 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 0:47 ` Denis Kenzior @ 2018-05-12 3:09 ` Joey Hewitt 2018-05-12 11:02 ` Pavel Machek 2018-05-12 14:19 ` Alexander Couzens 0 siblings, 2 replies; 35+ messages in thread From: Joey Hewitt @ 2018-05-12 3:09 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 3:09 ` Joey Hewitt @ 2018-05-12 11:02 ` Pavel Machek 2018-05-12 14:19 ` Alexander Couzens 1 sibling, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-12 11:02 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 3:09 ` Joey Hewitt 2018-05-12 11:02 ` Pavel Machek @ 2018-05-12 14:19 ` Alexander Couzens 2018-05-13 10:33 ` Marcel Holtmann ` (2 more replies) 1 sibling, 3 replies; 35+ messages in thread From: Alexander Couzens @ 2018-05-12 14:19 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 14:19 ` Alexander Couzens @ 2018-05-13 10:33 ` Marcel Holtmann 2018-05-14 6:45 ` Pavel Machek 2018-05-14 16:19 ` Denis Kenzior 2 siblings, 0 replies; 35+ messages in thread From: Marcel Holtmann @ 2018-05-13 10:33 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 14:19 ` Alexander Couzens 2018-05-13 10:33 ` Marcel Holtmann @ 2018-05-14 6:45 ` Pavel Machek 2018-05-14 16:19 ` Denis Kenzior 2 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-14 6:45 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 14:19 ` Alexander Couzens 2018-05-13 10:33 ` Marcel Holtmann 2018-05-14 6:45 ` Pavel Machek @ 2018-05-14 16:19 ` Denis Kenzior 2 siblings, 0 replies; 35+ messages in thread From: Denis Kenzior @ 2018-05-14 16:19 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-11 23:18 ` Voice calls over qmi was " Pavel Machek 2018-05-12 0:47 ` Denis Kenzior @ 2018-05-12 1:02 ` Denis Kenzior 2018-05-12 7:37 ` Harald Welte 1 sibling, 1 reply; 35+ messages in thread From: Denis Kenzior @ 2018-05-12 1:02 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 1:02 ` Denis Kenzior @ 2018-05-12 7:37 ` Harald Welte 2018-05-16 15:10 ` Bob Ham 0 siblings, 1 reply; 35+ messages in thread From: Harald Welte @ 2018-05-12 7:37 UTC (permalink / raw) To: ofono [-- 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) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-12 7:37 ` Harald Welte @ 2018-05-16 15:10 ` Bob Ham 2018-05-16 16:12 ` Harald Welte 0 siblings, 1 reply; 35+ messages in thread From: Bob Ham @ 2018-05-16 15:10 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4 2018-05-16 15:10 ` Bob Ham @ 2018-05-16 16:12 ` Harald Welte 0 siblings, 0 replies; 35+ messages in thread From: Harald Welte @ 2018-05-16 16:12 UTC (permalink / raw) To: ofono [-- 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) ^ permalink raw reply [flat|nested] 35+ messages in thread
* [rfc] Fix incoming sms on Droid 4 was Re: Incoming sms problem on Motorola Droid 4 2018-05-10 7:11 ` Marcel Holtmann 2018-05-11 23:18 ` Voice calls over qmi was " Pavel Machek @ 2018-05-14 13:02 ` Pavel Machek 1 sibling, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-14 13:02 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-08 22:08 ` Denis Kenzior 2018-05-09 4:31 ` Marcel Holtmann @ 2018-05-09 6:50 ` Pavel Machek 1 sibling, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-09 6:50 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-08 21:51 ` Pavel Machek @ 2018-05-09 1:03 ` Tony Lindgren -1 siblings, 0 replies; 35+ messages in thread From: Tony Lindgren @ 2018-05-09 1:03 UTC (permalink / raw) To: Pavel Machek Cc: ofono, kernel list, linux-arm-kernel, linux-omap, sre, nekit1000, mpartap, merlijn * 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Incoming sms problem on Motorola Droid 4 @ 2018-05-09 1:03 ` Tony Lindgren 0 siblings, 0 replies; 35+ messages in thread From: Tony Lindgren @ 2018-05-09 1:03 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 2018-05-09 1:03 ` Tony Lindgren (?) @ 2018-05-09 8:48 ` Pavel Machek -1 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-09 8:48 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <20180509133506.GX77069@atomide.com>]
* Re: Incoming sms problem on Motorola Droid 4 [not found] <20180509133506.GX77069@atomide.com> @ 2018-05-09 13:38 ` Pavel Machek 2018-05-11 12:34 ` Pavel Machek 1 sibling, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-09 13:38 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Incoming sms problem on Motorola Droid 4 [not found] <20180509133506.GX77069@atomide.com> 2018-05-09 13:38 ` Pavel Machek @ 2018-05-11 12:34 ` Pavel Machek 1 sibling, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-11 12:34 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <20180511123926.GK77069@atomide.com>]
* Re: Incoming sms problem on Motorola Droid 4 [not found] <20180511123926.GK77069@atomide.com> @ 2018-05-14 9:01 ` Pavel Machek 0 siblings, 0 replies; 35+ messages in thread From: Pavel Machek @ 2018-05-14 9:01 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2018-05-16 16:12 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-08 21:51 Incoming sms problem on Motorola Droid 4 Pavel Machek 2018-05-08 21:51 ` Pavel Machek 2018-05-08 21:51 ` Pavel Machek 2018-05-08 21:51 ` Pavel Machek 2018-05-08 22:08 ` Denis Kenzior 2018-05-09 4:31 ` Marcel Holtmann 2018-05-09 8:18 ` Pavel Machek 2018-05-09 13:03 ` Denis Kenzior 2018-05-09 15:11 ` Pavel Machek 2018-05-09 15:41 ` Denis Kenzior 2018-05-09 18:57 ` Pavel Machek 2018-05-09 19:33 ` Denis Kenzior 2018-05-10 6:50 ` Marcel Holtmann 2018-05-10 6:58 ` Pavel Machek 2018-05-10 7:11 ` Marcel Holtmann 2018-05-11 23:18 ` Voice calls over qmi was " Pavel Machek 2018-05-12 0:47 ` Denis Kenzior 2018-05-12 3:09 ` Joey Hewitt 2018-05-12 11:02 ` Pavel Machek 2018-05-12 14:19 ` Alexander Couzens 2018-05-13 10:33 ` Marcel Holtmann 2018-05-14 6:45 ` Pavel Machek 2018-05-14 16:19 ` Denis Kenzior 2018-05-12 1:02 ` Denis Kenzior 2018-05-12 7:37 ` Harald Welte 2018-05-16 15:10 ` Bob Ham 2018-05-16 16:12 ` Harald Welte 2018-05-14 13:02 ` [rfc] Fix incoming sms on Droid 4 " Pavel Machek 2018-05-09 6:50 ` Pavel Machek 2018-05-09 1:03 ` Tony Lindgren 2018-05-09 1:03 ` Tony Lindgren 2018-05-09 8:48 ` Pavel Machek [not found] <20180509133506.GX77069@atomide.com> 2018-05-09 13:38 ` Pavel Machek 2018-05-11 12:34 ` Pavel Machek [not found] <20180511123926.GK77069@atomide.com> 2018-05-14 9:01 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.