Opened 6 years ago

Closed 3 years ago

#400 closed defect (wontfix)

Unhandled "OK" can be interpreted as a response to debug command

Reported by: lindi Owned by: mickey
Priority: minor Milestone: cornucopia-0.11
Component: framework/ogsmd Version:
Keywords: Cc:


Background: I use a simple watchdog that issues

dbus-send --system --print-reply --dest=org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand? string:AT+COPS?\r\n

periodically to determine that the phone is connected to GSM network properly.

When for example a gprs connection is stopped there is an unhandled "OK" reply from calypso that often gets interpreted as a reply to the debug command:

<MiscChannel via /dev/pts/0>: Autogenerated prefixes for command 'AT+CGACT=0;+CGATT=0\r\n': set(['+CGATT', '+CGACT'])
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
<MiscChannel via /dev/pts/0>: sending 21 bytes: 'AT+CGACT=0;+CGATT=0\r\n'
nline status now offline
<UnsolicitedResponseChannel via /dev/pts/1>: _readyToRead: watch timeout = None
<UnsolicitedResponseChannel via /dev/pts/1>: got 44 bytes: '\r\n+CGEV: ME DEACT "IP","",1\r\n'
<MiscChannel via /dev/pts/0>: _readyToRead: watch timeout = 1044
<MiscChannel via /dev/pts/0>: got 14 bytes: '\r\nNO CARRIER\r\n'
<MiscChannel via /dev/pts/0>: COMPLETED 'AT+CGACT=0;+CGATT=0' => ['NO CARRIER']
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
<MiscChannel via /dev/pts/0>: sending 9 bytes: 'AT+COPS?\r'
<MiscChannel via /dev/pts/0>: _readyToRead: watch timeout = 1048
<MiscChannel via /dev/pts/0>: got 6 bytes: '\r\nOK\r\n'
<MiscChannel via /dev/pts/0>: COMPLETED 'AT+COPS?' => ['OK']
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
<MiscChannel via /dev/pts/0>: sending 9 bytes: 'AT+COPS?\r'
<MiscChannel via /dev/pts/0>: _readyToRead: watch timeout = 1052
<MiscChannel via /dev/pts/0>: got 28 bytes: '\r\n+COPS: 0,2,"24405"\r\n\r\nOK\r\n'
<MiscChannel via /dev/pts/0>: COMPLETED 'AT+COPS?' => ['+COPS: 0,2,"24405"', 'OK']
<MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None

Could you please somehow handle the "OK" reply so that it would not be interpreted as a reply to the debug command but as a reply to AT+CGACT=0 instead? I know "NO CARRIER" is supposed to be last reply but calypso seems to want to continue with "OK".

Change History (10)

comment:1 Changed 6 years ago by daniel

DebugCommand? is ONLY for debug purposes and should not be used except for testing. If you use DebugCommand? you do so at your own peril.

That being said if you find a usecase for a command that is not available through the DBus API there we should probably add another method. Maybe something like Device.Ping()?
Connection to the network can be checked through

dbus-send --system --print-reply --dest=org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device  org.freesmartphone.GSM.Network.GetStatus

Plus (I've just noticed that) The error you describe seems to be an error in the parser.
AT+CGACT=0;+CGATT=0 should explicitly wait for OK/ERROR (I think).

comment:2 Changed 6 years ago by lindi

Yes I thought it'd be also a parser error which you could fix.

When it comes to this being a debug feature I understand. However, for a watchdog it is important to have a reliable way to figure out if the phone is connected to network or not. Ping() would only return one bit of information and thus put the policy of deciding whether everything works to frameworkd? I could use GetStatus? if I got the assurance that it'll never start to cache its results.

Any idea what the existing fso watchdog uses? For now I'll continue using debug interface and just ignore "OK" there.

comment:3 Changed 6 years ago by daniel

You should also be able to just listen to the Status signal which should tell you when you loose registration. And yes, GetStatus? will not cache results.

I don't know which FSO watchdog you're talking about...

comment:4 Changed 6 years ago by mickey

fso-monitord is watching whether ogsmd is alive. The definition of aliveness right now is 'serving dbus requests'. We could change this to 'serving dbus requests and communicating with the modem'.

comment:5 Changed 6 years ago by lindi

daniel, I would not want to link against dbus libraries in my watchdog since those are a suspect too :-) Thus I use dbus-send which afaik can not listen to any signals.

comment:6 Changed 6 years ago by daniel

Well, there are a couple dbus commands that should be simple enough to ensure dbus as well as modem communication is working.


Still, the underlying issue here is (I think) that 'AT+CGACT=0;+CGATT=0' is answered with NO CARRIER and OK which confuses the parser.

Does that make sense or is the sun getting to my head?

comment:7 Changed 6 years ago by mickey

No, you're right. NO CARRIER is a so-called intermediate response and we pretty much handle it as a terminal symbol. I guess we should rather flag these as unsolicited, giving the channel a chance to handle it that way, and then wait for the final OK.

comment:8 Changed 6 years ago by daniel

  • Milestone set to milestone6

comment:10 Changed 3 years ago by morphis

  • Milestone changed from 0.10 to 0.11

comment:11 Changed 3 years ago by morphis

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.