7:58 a.m.
Hi All,
i recently noticed that the at driver did not reach the state "registered".
marcel pointer me to the message
+CMER not supported by this modem. If this is an error please submit
patches to support this hardware
and i started digging. problem was parsing of the response
+CMER: (0,3),(0,2),0,(0-1),0
that expresses the allowed options of CMER. neither (a list of) single integer
"(0,3)" (in opposite to range "(0-1)") nor missing brackets
"0" were supported
by ofono so i added this (see patch).
i'm not sure if missing brackets are allowed or espress something different,
maybe a AT-guru can tell. for now "(0)" behaves like "0".
i assume that also other response-parsing flows in ofono have that problem
so either a generic aproach should be implemented or other places be reviewed.
marcel already pointer out that a generic aproach may be unnecessarily complex
where i agree if it comes to strings and nested brackets but for plain integer
cases it would be quite useful to get this done in one place for all. if
interested i could implement such stuff into gatchat/gatresult.c which then can
be used for the integer-only cases. what do you think?
regards,
michael
--
M. Dietrich
2:28 p.m.
Hi Michael,
On 01/07/2013 02:58 PM, M. Dietrich wrote:
Hi All,
i recently noticed that the at driver did not reach the state "registered".
marcel pointer me to the message
+CMER not supported by this modem. If this is an error please submit
patches to support this hardware
and i started digging. problem was parsing of the response
+CMER: (0,3),(0,2),0,(0-1),0
This is quite obviously wrong. Quoting v.250:
"When the action accepts a single numeric subparameter, or the parameter
accepts only one numeric value, the set of supported values may be
presented in the information text as an ordered list of
values. The list shall be preceded by a left parenthesis ("(", IA5 2/8),
and is followed by a right parenthesis (")", IA5 2/9). If only a single
value is supported, it shall appear between the parentheses. If more
than one value is supported, then the values may be listed individually,
separated by comma characters (IA5 2/12), or, when a continuous range of
values is supported, by the first value in the range, followed by a
hyphen character (IA5 2/13), followed by the last value in the range.
The specification of single values and ranges of values may be
intermixed within a single information text. In all cases, the supported
values shall be indicated in ascending order."
that expresses the allowed options of CMER. neither (a list of) single integer
I'm pretty sure that this is supported by GAtChat.
"(0,3)" (in opposite to range "(0-1)") nor
missing brackets "0" were supported
by ofono so i added this (see patch).
i'm not sure if missing brackets are allowed or espress something different,
maybe a AT-guru can tell. for now "(0)" behaves like "0".
i assume that also other response-parsing flows in ofono have that problem
so either a generic aproach should be implemented or other places be reviewed.
It is only a problem if the modem is broken, in which case you need to
use a quirk and parsing the result of CMER=? is likely unnecessary. For
broken devices it is likely easier to simply skip CMER probing and just
set the wanted CMER settings.
marcel already pointer out that a generic aproach may be
unnecessarily complex
where i agree if it comes to strings and nested brackets but for plain integer
cases it would be quite useful to get this done in one place for all. if
interested i could implement such stuff into gatchat/gatresult.c which then can
be used for the integer-only cases. what do you think?
Not sure what you're asking here, can you elaborate?
Regards,
-Denis
9:44 a.m.
Hi,
On Wed, Jan 16, 2013 at 09:28:22PM -0600, Denis Kenzior wrote:
It is only a problem if the modem is broken, in which case you need
to
use a quirk and parsing the result of CMER=? is likely unnecessary.
For broken devices it is likely easier to simply skip CMER probing and
just set the wanted CMER settings.
i assume more or less all modems are in one or the other way
"broken". even the spec is (in my opinion) broken.
so if only the output of an option list just does not follow the spec
but most other stuff of the modem works fine why not be more tolerant
parsing the option list?
if you instead have a quirk for this and only this modem you fixed only
a single one. i assume that also other modems are broken in this way and
fixing it in the parser would enable more modems to work.
>marcel already pointer out that a generic aproach may be
>unnecessarily complex where i agree if it comes to strings and nested
>brackets but for plain integer cases it would be quite useful to get
>this done in one place for all. if interested i could implement such
>stuff into gatchat/gatresult.c which then can be used for the
>integer-only cases. what do you think?
Not sure what you're asking here, can you elaborate?
the AT parser code for the option list is redundant, a re-use of a
single implementation would make some sense and i offered a more generic
way of parsing an option list. marcel pointed out that a completly
generic parser would be unnecessarily complex and i agree. so i suggest
a re-usable code for integer option lists.
anyway i would like to see the patch in ofono. on the one side it does
not break any existing modem, on the other side it makes some modem
work.
regards,
michael
--
M. Dietrich
11:05 a.m.
Hi,
so if only the output of an option list just does not follow the
spec
but most other stuff of the modem works fine why not be more tolerant
parsing the option list?
Actually we do not want to be tolerant. If something is broken, we want
to make sure that any work-around code-path is explicitly called out.
There are many reasons for this, one of the main ones being code
efficiency. The other code readability. Over time such 'workarounds'
pollute the code base and make it ugly; and the reasons for why it is
that way are either lost or become murky. Case in point your patch,
which doesn't even contain a code comment block on what it is trying to
accomplish. (And by the way your coding style is still wrong in several
places...)
if you instead have a quirk for this and only this modem you fixed
only
a single one. i assume that also other modems are broken in this way and
fixing it in the parser would enable more modems to work.
I do not accept your assumption. We have been using almost the exact
same structure for parsing parameter lists in the SMS driver for over 3
years. So far you are the first to report a modem that behaves in this
manner when it comes to parameter lists.
Regards,
-Denis
5:28 a.m.
Hi Denis,
On Fri, Jan 18, 2013 at 06:05:08PM -0600, Denis Kenzior wrote:
Case in point your patch, which doesn't even contain a code
comment block on
what it is trying to accomplish.
i understood the response of the modem follows the spec so i thought this would
be standard. but you are deeper in the specs and i won't tell otherwise.
(And by the way your coding style is still wrong in several
places...)
i just tried to intuitively follow the code standard i found in ofono, sorry if
i got that wrong.
So far you are the first to report a modem that behaves in this
manner when
it comes to parameter lists.
yes, because i am probably the first that investigated the problem in depth. i
saw alot of complains that the registration state is not reached from many
ofono users. cause for that is exactly the +CMER answer of those modems.
as the modem in question is used in many thinkpads and other notebooks i assume
that the many people can't use ofono out of this reason.
so what do you suggest to support this modem? how would a quirk as you
suggested look like?
regards,
michael
--
M. Dietrich
6:05 a.m.
Hi Michael,
> So far you are the first to report a modem that behaves in this
manner when
> it comes to parameter lists.
yes, because i am probably the first that investigated the problem in depth. i
saw alot of complains that the registration state is not reached from many
ofono users. cause for that is exactly the +CMER answer of those modems.
Please understand, I'm not denying there's a problem, just that it is
the first I've heard of it. Please mention these reports on IRC or the
Mailing List to me in the future so we can get them addressed quicker.
as the modem in question is used in many thinkpads and other
notebooks i assume
that the many people can't use ofono out of this reason.
Can you actually tell me what this modem is? Maybe I can test it on my end?
so what do you suggest to support this modem? how would a quirk as you
suggested look like?
The CMER parser was introduced in commit b87619. It was essentially a
straight forward port from the SMS driver and meant to fix the
particular behaviors of the Telit devices. This was early September,
surprising that no one complained in 4 months...
The way I suggest to fix it would be to skip probing CMER if a quirk is
enabled for your particular device and simply send the appropriate CMER
command. Prior to September oFono simply used to send 'AT+CMER=3,0,0,1'
Regards,
-Denis
3529
days inactive
3541
days old
5 comments
2 participants
participants (2)
-
Denis Kenzior -
M. Dietrich