This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 212362 - Constant polling of phone... and still no new messages
Constant polling of phone... and still no new messages
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-phone-manager (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-26 11:08 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.10-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-20 05:29:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2006-10-26 11:08:29 EDT
Description of problem:
When gnome-phone-manager runs, it is _constantly_ polling the phone for
messages. Yet it still doesn't actually notify me when a new message arrives...

2006-10-26 18:06:09.713637 < ACL data: handle 46 flags 0x02 dlen 17
    L2CAP(d): cid 0x0040 len 13 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 9 fcs 0x9a 
      0000: 41 54 2b 43 50 4d 53 3f  0d                       AT+CPMS?.
2006-10-26 18:06:09.728546 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 46 packets 1
2006-10-26 18:06:09.752530 > ACL data: handle 46 flags 0x02 dlen 9
    L2CAP(d): cid 0x0040 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 1
2006-10-26 18:06:09.915529 > ACL data: handle 46 flags 0x02 dlen 69
    L2CAP(d): cid 0x0040 len 65 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 0 ilen 61 fcs 0x40 
      0000: 41 54 2b 43 50 4d 53 3f  0d 0d 0a 2b 43 50 4d 53  AT+CPMS?...+CPMS
      0010: 3a 20 22 4d 54 22 2c 35  33 2c 32 35 34 2c 22 4d  : "MT",53,254,"M
      0020: 45 22 2c 32 37 2c 32 35  34 2c 22 4d 54 22 2c 32  E",27,254,"MT",2
      0030: 36 2c 32 35 34 0d 0a 0d  0a 4f 4b 0d 0a           6,254....OK..
2006-10-26 18:06:09.929650 < ACL data: handle 46 flags 0x02 dlen 17
    L2CAP(d): cid 0x0040 len 13 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 9 fcs 0x9a 
      0000: 41 54 2b 43 50 4d 53 3f  0d                       AT+CPMS?.
2006-10-26 18:06:09.941543 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 46 packets 1
2006-10-26 18:06:09.959527 > ACL data: handle 46 flags 0x02 dlen 9
    L2CAP(d): cid 0x0040 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 1
2006-10-26 18:06:10.131561 > ACL data: handle 46 flags 0x02 dlen 69
    L2CAP(d): cid 0x0040 len 65 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 0 ilen 61 fcs 0x40 
      0000: 41 54 2b 43 50 4d 53 3f  0d 0d 0a 2b 43 50 4d 53  AT+CPMS?...+CPMS
      0010: 3a 20 22 4d 54 22 2c 35  33 2c 32 35 34 2c 22 4d  : "MT",53,254,"M
      0020: 45 22 2c 32 37 2c 32 35  34 2c 22 4d 54 22 2c 32  E",27,254,"MT",2
      0030: 36 2c 32 35 34 0d 0a 0d  0a 4f 4b 0d 0a           6,254....OK..
2006-10-26 18:06:10.145645 < ACL data: handle 46 flags 0x02 dlen 17
    L2CAP(d): cid 0x0040 len 13 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 9 fcs 0x9a 
      0000: 41 54 2b 43 50 4d 53 3f  0d                       AT+CPMS?.
2006-10-26 18:06:10.153523 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 46 packets 1
2006-10-26 18:06:10.177538 > ACL data: handle 46 flags 0x02 dlen 9
    L2CAP(d): cid 0x0040 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 1
2006-10-26 18:06:10.378532 > ACL data: handle 46 flags 0x02 dlen 69
    L2CAP(d): cid 0x0040 len 65 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 2 pf 0 ilen 61 fcs 0x40 
      0000: 41 54 2b 43 50 4d 53 3f  0d 0d 0a 2b 43 50 4d 53  AT+CPMS?...+CPMS
      0010: 3a 20 22 4d 54 22 2c 35  34 2c 32 35 34 2c 22 4d  : "MT",54,254,"M
      0020: 45 22 2c 32 37 2c 32 35  34 2c 22 4d 54 22 2c 32  E",27,254,"MT",2
      0030: 37 2c 32 35 34 0d 0a 0d  0a 4f 4b 0d 0a           7,254....OK..
Comment 1 Linus Walleij 2006-11-06 03:24:46 EST
I think you should file this bug in upstream, either for gnome-phone-manager
in http://bugzilla.gnome.org/ or in gnokii (the backend library) at
http://www.gnokii.org/.

I can only fix packaging bugs...
Comment 2 David Woodhouse 2006-11-06 04:01:47 EST
I don't think that's acceptable. If the package has no active maintainer in
Extras then it should be removed from Extras.
Comment 3 Linus Walleij 2006-11-06 04:13:17 EST
Yeah OK sorry then. We'll try to look a bit closer.

In order to debug and find the issue, please help out in debugging using
your phone and we'll hopefully be able to locate the problem together.
First: can you get the technical manual for your phone (which model?) to 
assure that your phone supports the AT+CPMS? command that is used to
poll messages off the phone?

Many phones does not support this command, and there is not way for the
program to tell whether it does or not...

If it doesn't it need to be notified in some way, perhaps you blacklisting
in gnokii so poll operations for new messages will fail properly on this
model.
Comment 4 David Woodhouse 2006-11-06 04:46:39 EST
As shown in the hcidump above, AT+CPMS? works OK on this phone:

AT+CPMS?                                             
+CPMS: "MT",43,254,"ME",21,254,"MT",22,254   

It's a Motorola L7 SLVR.        
Comment 5 Linus Walleij 2006-11-06 14:54:32 EST
Filed upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=371682
Comment 6 Linus Walleij 2006-11-08 03:56:08 EST
Internal notes:

Extended ETSI Hayes AT command parameters for SMS is used for polling
the phone. Sort of run-down of extended ETSI commands:
http://www.cellular.co.za/at_etsi.htm

AT+CPMS? is defined in ... hm. No standard reference.

What I'm trying to find out here is if the phone actually reports that
it recieved a new message by some parameter in the response to AT+CPMS?
as could be expected, or if it just saying "OK" and lining up some 
standard response that doesn't include what gnokii needs in order to
understand that a new message has arrived.

For example I think you should possibly expect one of the figures
returned to be increased by 1 when a new message arrives, indicating
that the message store now contains one new message.
Can you see if this happens?
Comment 7 David Woodhouse 2006-11-08 06:12:34 EST
(In reply to comment #6)
> AT+CPMS? is defined in ... hm. No standard reference.

ETSI GSM 07.05 (ETS 300 585): "Digital cellular telecommunication system
(Phase 2); Use of Data Terminal Equipment - Data Circuit terminating
Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell
Broadcast Service (CBS)".


> What I'm trying to find out here is if the phone actually reports that
> it recieved a new message by some parameter in the response to AT+CPMS?
> as could be expected, or if it just saying "OK" and lining up some 
> standard response that doesn't include what gnokii needs in order to
> understand that a new message has arrived.
> 
> For example I think you should possibly expect one of the figures
> returned to be increased by 1 when a new message arrives, indicating
> that the message store now contains one new message.
> Can you see if this happens?

Again, see the hcidump above.
Comment 8 Linus Walleij 2006-11-08 15:59:09 EST
> Again, see the hcidump above.

OK yes the last response changes +1 in two stores. Hm.

I'm trying to figure out if the problem is in g-p-m or
gnokkii here but I suspect gnokii.
Comment 9 Linus Walleij 2006-11-08 16:03:04 EST
g-p-m uses gnokii to handle messages, gnokii supoort these phones:
http://gnokii.org/faq.shtml#models

Motorola L7 SLVR is not in the list.

Is it an option to turn this into a documentation bug and get g-p-m to provide
a list of supported models?
Comment 10 David Woodhouse 2006-11-08 20:48:51 EST
Compatibility of the phone doesn't seem to be an issue here. While Motorola
screwed up a _lot_ on this phone, they didn't manage to screw up basic GSM 07.05
stuff (at least not AT+CPMS?
Comment 11 Linus Walleij 2006-11-09 03:38:22 EST
Yeah you've got a point it should be generic so as long as its working
as expect the model shouldn't matter.

I'm thinking about testing out if it works properly in gnokii so as to see
if we should file an upstream bug directly to gnokii instead of waiting
for g-p-m to react.
Comment 12 David Woodhouse 2006-11-19 10:15:51 EST
Have now arrived home and actually have some time to play. Will test in gnokii
-- that's a good suggestion; thanks.
Comment 13 Bastien Nocera 2007-07-09 10:40:11 EDT
(In reply to comment #10)
> Compatibility of the phone doesn't seem to be an issue here. While Motorola
> screwed up a _lot_ on this phone, they didn't manage to screw up basic GSM 07.05
> stuff (at least not AT+CPMS?

Probably not that, but Motorola suck as they don't support sending PDU messages,
despite the query AT command saying the contrary (although it might just be my
model).

Can you please follow the instructions in the upstream bug and let me know
whether getting messages works on your phone?
http://bugzilla.gnome.org/show_bug.cgi?id=330773#c6
and
http://bugzilla.gnome.org/show_bug.cgi?id=330773#c7
Comment 14 Bastien Nocera 2007-07-10 11:38:34 EDT
This should be fixed by gnokii CVS and gnome-phone-manager trunk. Testing gnokii
CVS is probably a good idea.
Comment 15 Linus Walleij 2007-07-25 17:38:23 EDT
Thanks for looking into this Bastien!
Comment 16 Bastien Nocera 2007-08-20 05:29:20 EDT
Should be fixed in gnome-phone-manager 0.10 in rawhide. Reopen if not.

Note You need to log in before you can comment on or make changes to this bug.