The way to install proper driver for 3G dongle in oFono

The way to install proper driver for 3G dongle in oFono

[Deng, Ying An]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Hi,

We are facing a problem in oFono when using 3G modems:
A CDMA2000 modem can have same PID with WCDMA modem, or TDS-CDMA modem - 3G modem vendors already confirm they do that.
That's to say, if following current strategy, it will be a problem to install proper driver for this kind of 3G modem.

So, is it feasible to find out a solution such as to probe the modem firstly, find out what kind of network modes it supports, and then install the driver?
The way to probe the modem could be some action as to read the capability or get system mode, or issue some specific AT command that only response to certain network mode?

Best regards,
DengYingAn

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5694 bytes --]

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

Hi Deng,

On 20/12/2011 09:44, Deng, Ying An wrote:
>
> Hi,
>
> We are facing a problem in oFono when using 3G modems:
>
> A CDMA2000 modem can have same PID with WCDMA modem, or TDS-CDMA modem 
> -- 3G modem vendors already confirm they do that.
>
> That's to say, if following current strategy, it will be a problem to 
> install proper driver for this kind of 3G modem.
>
> So, is it feasible to find out a solution such as to probe the modem 
> firstly, find out what kind of network modes it supports, and then 
> install the driver?
>
> The way to probe the modem could be some action as to read the 
> capability or get system mode, or issue some specific AT command that 
> only response to certain network mode?
>

Indeed, we could use for Huawei modems for instance the AT^SYSINFO 
command and retrieve the sys_mode field and parse it, I have found this 
in public Huawei specifications:

<sys_mode>: System mode. The values are as follows:
0 No service.
1 AMPS mode
2 CDMA mode
3 GSM/GPRS mode
4 HDR mode
5 WCDMA mode
8 CDMA/HDR HYBRID mode

Thus we can chose accordingly the drivers to create oFono atoms.

Kind regards,
Guillaume

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4122 bytes --]

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Hi again,

On 20/12/2011 12:02, Guillaume Zajac wrote:
> Hi Deng,
>
> On 20/12/2011 09:44, Deng, Ying An wrote:
>>
>> Hi,
>>
>> We are facing a problem in oFono when using 3G modems:
>>
>> A CDMA2000 modem can have same PID with WCDMA modem, or TDS-CDMA 
>> modem -- 3G modem vendors already confirm they do that.
>>
>> That's to say, if following current strategy, it will be a problem to 
>> install proper driver for this kind of 3G modem.
>>
>> So, is it feasible to find out a solution such as to probe the modem 
>> firstly, find out what kind of network modes it supports, and then 
>> install the driver?
>>
>> The way to probe the modem could be some action as to read the 
>> capability or get system mode, or issue some specific AT command that 
>> only response to certain network mode?
>>
>
> Indeed, we could use for Huawei modems for instance the AT^SYSINFO 
> command and retrieve the sys_mode field and parse it, I have found 
> this in public Huawei specifications:
>
> <sys_mode>: System mode. The values are as follows:
> 0 No service.
> 1 AMPS mode
> 2 CDMA mode
> 3 GSM/GPRS mode
> 4 HDR mode
> 5 WCDMA mode
> 8 CDMA/HDR HYBRID mode
>
> Thus we can chose accordingly the drivers to create oFono atoms.

After some investigations, it seems SYSINFO won't be enough to get the 
modem type because with this AT command we will have to be registered to 
the network to get the system mode.
The only way I found until now is using the AT+GCAP to check whether the 
modem is CDMA or GSM type.
However if we do the AT+GCAP request for each constructor plugin 
(huawei, zte, ...) it will bring some duplicated code.
Does someone see any better solution?

Thanks.

Kind regards,
Guillaume

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4996 bytes --]

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

Hi Guillaume,

> >> We are facing a problem in oFono when using 3G modems:
> >>
> >> A CDMA2000 modem can have same PID with WCDMA modem, or TDS-CDMA 
> >> modem -- 3G modem vendors already confirm they do that.
> >>
> >> That's to say, if following current strategy, it will be a problem to 
> >> install proper driver for this kind of 3G modem.
> >>
> >> So, is it feasible to find out a solution such as to probe the modem 
> >> firstly, find out what kind of network modes it supports, and then 
> >> install the driver?
> >>
> >> The way to probe the modem could be some action as to read the 
> >> capability or get system mode, or issue some specific AT command that 
> >> only response to certain network mode?
> >>
> >
> > Indeed, we could use for Huawei modems for instance the AT^SYSINFO 
> > command and retrieve the sys_mode field and parse it, I have found 
> > this in public Huawei specifications:
> >
> > <sys_mode>: System mode. The values are as follows:
> > 0 No service.
> > 1 AMPS mode
> > 2 CDMA mode
> > 3 GSM/GPRS mode
> > 4 HDR mode
> > 5 WCDMA mode
> > 8 CDMA/HDR HYBRID mode
> >
> > Thus we can chose accordingly the drivers to create oFono atoms.
> 
> After some investigations, it seems SYSINFO won't be enough to get the 
> modem type because with this AT command we will have to be registered to 
> the network to get the system mode.
> The only way I found until now is using the AT+GCAP to check whether the 
> modem is CDMA or GSM type.
> However if we do the AT+GCAP request for each constructor plugin 
> (huawei, zte, ...) it will bring some duplicated code.
> Does someone see any better solution?

I like to see that we do proper homework here. The first question is
actually can you execute AT+GCAP if not SIM card has been inserted or is
actually locked? And if not does, ATI provide an extra +GCAP response.
Without a SIM atom you will not be able to unlock the modem. And you can
only create the SIM atom if you know what modem technology you are
using. Additionally of course additionally, what are the responses for
various modem models and manufactures. Are they doing this actually
properly.

We need OFONO_AT_DEBUG traces for all the various permutations of this
behavior. This needs to be documented first. Feel free to send patches
to add the results to doc/ directory inside oFono.

Just randomly hacking around will get us in trouble and will make well
behaved modems like MBM or IFX fail or suffer for no apparent reasons.

Regards

Marcel

RE: The way to install proper driver for 3G dongle in oFono

[Deng, Ying An]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

>-----Original Message-----
>From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf
>Of Marcel Holtmann
>Sent: Wednesday, December 21, 2011 12:41 AM
>To: ofono(a)ofono.org
>Subject: Re: The way to install proper driver for 3G dongle in oFono
>
>Hi Guillaume,
>
>> >> We are facing a problem in oFono when using 3G modems:
>> >>
>> >> A CDMA2000 modem can have same PID with WCDMA modem, or
>TDS-CDMA
>> >> modem -- 3G modem vendors already confirm they do that.
>> >>
>> >> That's to say, if following current strategy, it will be a problem to
>> >> install proper driver for this kind of 3G modem.
>> >>
>> >> So, is it feasible to find out a solution such as to probe the modem
>> >> firstly, find out what kind of network modes it supports, and then
>> >> install the driver?
>> >>
>> >> The way to probe the modem could be some action as to read the
>> >> capability or get system mode, or issue some specific AT command that
>> >> only response to certain network mode?
>> >>
>> >
>> > Indeed, we could use for Huawei modems for instance the AT^SYSINFO
>> > command and retrieve the sys_mode field and parse it, I have found
>> > this in public Huawei specifications:
>> >
>> > <sys_mode>: System mode. The values are as follows:
>> > 0 No service.
>> > 1 AMPS mode
>> > 2 CDMA mode
>> > 3 GSM/GPRS mode
>> > 4 HDR mode
>> > 5 WCDMA mode
>> > 8 CDMA/HDR HYBRID mode
>> >
>> > Thus we can chose accordingly the drivers to create oFono atoms.
>>
>> After some investigations, it seems SYSINFO won't be enough to get the
>> modem type because with this AT command we will have to be registered to
>> the network to get the system mode.
>> The only way I found until now is using the AT+GCAP to check whether the
>> modem is CDMA or GSM type.
>> However if we do the AT+GCAP request for each constructor plugin
>> (huawei, zte, ...) it will bring some duplicated code.
>> Does someone see any better solution?
>
>I like to see that we do proper homework here. The first question is
>actually can you execute AT+GCAP if not SIM card has been inserted or is
>actually locked? And if not does, ATI provide an extra +GCAP response.
>Without a SIM atom you will not be able to unlock the modem. And you can
>only create the SIM atom if you know what modem technology you are
>using. Additionally of course additionally, what are the responses for
>various modem models and manufactures. Are they doing this actually
>properly.
>
>We need OFONO_AT_DEBUG traces for all the various permutations of this
>behavior. This needs to be documented first. Feel free to send patches
>to add the results to doc/ directory inside oFono.
>
>Just randomly hacking around will get us in trouble and will make well
>behaved modems like MBM or IFX fail or suffer for no apparent reasons.
>
>Regards
>
>Marcel
>

The at+gcap command only effective after SIM card inserted.
It is feasible to firstly find the vendor, then choose specific method to detect
if it is wcdma/cdma2k, then install proper driver?

>_______________________________________________
>ofono mailing list
>ofono(a)ofono.org
>http://lists.ofono.org/listinfo/ofono

RE: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3541 bytes --]

Hi Ying An,

> >> >> We are facing a problem in oFono when using 3G modems:
> >> >>
> >> >> A CDMA2000 modem can have same PID with WCDMA modem, or
> >TDS-CDMA
> >> >> modem -- 3G modem vendors already confirm they do that.
> >> >>
> >> >> That's to say, if following current strategy, it will be a problem to
> >> >> install proper driver for this kind of 3G modem.
> >> >>
> >> >> So, is it feasible to find out a solution such as to probe the modem
> >> >> firstly, find out what kind of network modes it supports, and then
> >> >> install the driver?
> >> >>
> >> >> The way to probe the modem could be some action as to read the
> >> >> capability or get system mode, or issue some specific AT command that
> >> >> only response to certain network mode?
> >> >>
> >> >
> >> > Indeed, we could use for Huawei modems for instance the AT^SYSINFO
> >> > command and retrieve the sys_mode field and parse it, I have found
> >> > this in public Huawei specifications:
> >> >
> >> > <sys_mode>: System mode. The values are as follows:
> >> > 0 No service.
> >> > 1 AMPS mode
> >> > 2 CDMA mode
> >> > 3 GSM/GPRS mode
> >> > 4 HDR mode
> >> > 5 WCDMA mode
> >> > 8 CDMA/HDR HYBRID mode
> >> >
> >> > Thus we can chose accordingly the drivers to create oFono atoms.
> >>
> >> After some investigations, it seems SYSINFO won't be enough to get the
> >> modem type because with this AT command we will have to be registered to
> >> the network to get the system mode.
> >> The only way I found until now is using the AT+GCAP to check whether the
> >> modem is CDMA or GSM type.
> >> However if we do the AT+GCAP request for each constructor plugin
> >> (huawei, zte, ...) it will bring some duplicated code.
> >> Does someone see any better solution?
> >
> >I like to see that we do proper homework here. The first question is
> >actually can you execute AT+GCAP if not SIM card has been inserted or is
> >actually locked? And if not does, ATI provide an extra +GCAP response.
> >Without a SIM atom you will not be able to unlock the modem. And you can
> >only create the SIM atom if you know what modem technology you are
> >using. Additionally of course additionally, what are the responses for
> >various modem models and manufactures. Are they doing this actually
> >properly.
> >
> >We need OFONO_AT_DEBUG traces for all the various permutations of this
> >behavior. This needs to be documented first. Feel free to send patches
> >to add the results to doc/ directory inside oFono.
> >
> >Just randomly hacking around will get us in trouble and will make well
> >behaved modems like MBM or IFX fail or suffer for no apparent reasons.
>
> The at+gcap command only effective after SIM card inserted.
> It is feasible to firstly find the vendor, then choose specific method to detect
> if it is wcdma/cdma2k, then install proper driver?

and how does this work if you can't execute AT+GCAP since either your
SIM card is not present of actually locked. As I said above, you can
only unlock the SIM card with the SIM atom loaded. And for loading the
SIM atom you need to know which technology you are operating on.

I really prefer that the mentioned homework is done properly and
information are first gathers. Wild guessing is not going to help here
and random assumption on how things are suppose to work will eventually
fail because of the nature of this hardware. So lets get real facts
first and then we see what we do to solve this problem.

Regards

Marcel

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]

Hi Marcel,

On 21/12/2011 17:05, Marcel Holtmann wrote:
> Hi Ying An,
>
>>>>>> We are facing a problem in oFono when using 3G modems:
>>>>>>
>>>>>> A CDMA2000 modem can have same PID with WCDMA modem, or
>>> TDS-CDMA
>>>>>> modem -- 3G modem vendors already confirm they do that.
>>>>>>
>>>>>> That's to say, if following current strategy, it will be a problem to
>>>>>> install proper driver for this kind of 3G modem.
>>>>>>
>>>>>> So, is it feasible to find out a solution such as to probe the modem
>>>>>> firstly, find out what kind of network modes it supports, and then
>>>>>> install the driver?
>>>>>>
>>>>>> The way to probe the modem could be some action as to read the
>>>>>> capability or get system mode, or issue some specific AT command that
>>>>>> only response to certain network mode?
>>>>>>
>>>>> Indeed, we could use for Huawei modems for instance the AT^SYSINFO
>>>>> command and retrieve the sys_mode field and parse it, I have found
>>>>> this in public Huawei specifications:
>>>>>
>>>>> <sys_mode>: System mode. The values are as follows:
>>>>> 0 No service.
>>>>> 1 AMPS mode
>>>>> 2 CDMA mode
>>>>> 3 GSM/GPRS mode
>>>>> 4 HDR mode
>>>>> 5 WCDMA mode
>>>>> 8 CDMA/HDR HYBRID mode
>>>>>
>>>>> Thus we can chose accordingly the drivers to create oFono atoms.
>>>> After some investigations, it seems SYSINFO won't be enough to get the
>>>> modem type because with this AT command we will have to be registered to
>>>> the network to get the system mode.
>>>> The only way I found until now is using the AT+GCAP to check whether the
>>>> modem is CDMA or GSM type.
>>>> However if we do the AT+GCAP request for each constructor plugin
>>>> (huawei, zte, ...) it will bring some duplicated code.
>>>> Does someone see any better solution?
>>> I like to see that we do proper homework here. The first question is
>>> actually can you execute AT+GCAP if not SIM card has been inserted or is
>>> actually locked? And if not does, ATI provide an extra +GCAP response.
>>> Without a SIM atom you will not be able to unlock the modem. And you can
>>> only create the SIM atom if you know what modem technology you are
>>> using. Additionally of course additionally, what are the responses for
>>> various modem models and manufactures. Are they doing this actually
>>> properly.
>>>
>>> We need OFONO_AT_DEBUG traces for all the various permutations of this
>>> behavior. This needs to be documented first. Feel free to send patches
>>> to add the results to doc/ directory inside oFono.
>>>
>>> Just randomly hacking around will get us in trouble and will make well
>>> behaved modems like MBM or IFX fail or suffer for no apparent reasons.
>> The at+gcap command only effective after SIM card inserted.
>> It is feasible to firstly find the vendor, then choose specific method to detect
>> if it is wcdma/cdma2k, then install proper driver?
> and how does this work if you can't execute AT+GCAP since either your
> SIM card is not present of actually locked. As I said above, you can
> only unlock the SIM card with the SIM atom loaded. And for loading the
> SIM atom you need to know which technology you are operating on.
>
> I really prefer that the mentioned homework is done properly and
> information are first gathers. Wild guessing is not going to help here
> and random assumption on how things are suppose to work will eventually
> fail because of the nature of this hardware. So lets get real facts
> first and then we see what we do to solve this problem.

I have made some tests on a dozen of dongles from Huawei and ZTE.
I have remove the sim card for each dongle in order to be in the use 
case you mentionned.
I used minicom in order the modem not to be intialized.
For all GSM one there is an answer to ATI but none to AT+GCAP.

Huawei GSM AT+GCAP ATI answer:
======================
AT+GCAP
+CME ERROR: SIM failure

ATI
Manufacturer: huawei
Model: E1552
Revision: 11.608.10.00.309
IMEI: 353143036552488
+GCAP: +CGSM,+DS,+ES    --> this is a GSM modem

This is the case for ALL Huawei GSM dongles we got.

Huawei CDMA AT+GCAP ATI answers:
=======================
AT+GCAP
+GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS

ATI
Manufacturer: +GMI: HUAWEI TECHNOLOGIES CO., LTD
Model: EC152
Revision: TCPU_HWEC152DT01
ESN: +GSN:80aad6fd
+GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS -->this is CDMA modem 
(no +CGSM label)

The Huawei CDMAdongle above with ROM SIM answers to both AT+GCAP and ATI.
This is the case for ALL Huawei CDMA dongles we got.

Concerning ZTE we got only GSM modems.

ZTE AT+GCAP ATI answer:
================
AT+GCAP
ERROR

ATI
Manufacturer: ZTE INCORPORATED
Model: MF668
Revision: BD_INRELMF668V1.0.0B01
IMEI: 355987033958538
+GCAP: +CGSM,+DS,+ES

This is the case for ALL ZTE GSM dongles we got.


According to the result, it might be interesting to send ATI when the 
constructor plugin is probe by oFono.
Thus with +GCAP info we can decide which driver to use.

Kind regards,
Guillaume

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 6091 bytes --]

Hi Guillaume,

> >>>>>> We are facing a problem in oFono when using 3G modems:
> >>>>>>
> >>>>>> A CDMA2000 modem can have same PID with WCDMA modem, or
> >>> TDS-CDMA
> >>>>>> modem -- 3G modem vendors already confirm they do that.
> >>>>>>
> >>>>>> That's to say, if following current strategy, it will be a problem to
> >>>>>> install proper driver for this kind of 3G modem.
> >>>>>>
> >>>>>> So, is it feasible to find out a solution such as to probe the modem
> >>>>>> firstly, find out what kind of network modes it supports, and then
> >>>>>> install the driver?
> >>>>>>
> >>>>>> The way to probe the modem could be some action as to read the
> >>>>>> capability or get system mode, or issue some specific AT command that
> >>>>>> only response to certain network mode?
> >>>>>>
> >>>>> Indeed, we could use for Huawei modems for instance the AT^SYSINFO
> >>>>> command and retrieve the sys_mode field and parse it, I have found
> >>>>> this in public Huawei specifications:
> >>>>>
> >>>>> <sys_mode>: System mode. The values are as follows:
> >>>>> 0 No service.
> >>>>> 1 AMPS mode
> >>>>> 2 CDMA mode
> >>>>> 3 GSM/GPRS mode
> >>>>> 4 HDR mode
> >>>>> 5 WCDMA mode
> >>>>> 8 CDMA/HDR HYBRID mode
> >>>>>
> >>>>> Thus we can chose accordingly the drivers to create oFono atoms.
> >>>> After some investigations, it seems SYSINFO won't be enough to get the
> >>>> modem type because with this AT command we will have to be registered to
> >>>> the network to get the system mode.
> >>>> The only way I found until now is using the AT+GCAP to check whether the
> >>>> modem is CDMA or GSM type.
> >>>> However if we do the AT+GCAP request for each constructor plugin
> >>>> (huawei, zte, ...) it will bring some duplicated code.
> >>>> Does someone see any better solution?
> >>> I like to see that we do proper homework here. The first question is
> >>> actually can you execute AT+GCAP if not SIM card has been inserted or is
> >>> actually locked? And if not does, ATI provide an extra +GCAP response.
> >>> Without a SIM atom you will not be able to unlock the modem. And you can
> >>> only create the SIM atom if you know what modem technology you are
> >>> using. Additionally of course additionally, what are the responses for
> >>> various modem models and manufactures. Are they doing this actually
> >>> properly.
> >>>
> >>> We need OFONO_AT_DEBUG traces for all the various permutations of this
> >>> behavior. This needs to be documented first. Feel free to send patches
> >>> to add the results to doc/ directory inside oFono.
> >>>
> >>> Just randomly hacking around will get us in trouble and will make well
> >>> behaved modems like MBM or IFX fail or suffer for no apparent reasons.
> >> The at+gcap command only effective after SIM card inserted.
> >> It is feasible to firstly find the vendor, then choose specific method to detect
> >> if it is wcdma/cdma2k, then install proper driver?
> > and how does this work if you can't execute AT+GCAP since either your
> > SIM card is not present of actually locked. As I said above, you can
> > only unlock the SIM card with the SIM atom loaded. And for loading the
> > SIM atom you need to know which technology you are operating on.
> >
> > I really prefer that the mentioned homework is done properly and
> > information are first gathers. Wild guessing is not going to help here
> > and random assumption on how things are suppose to work will eventually
> > fail because of the nature of this hardware. So lets get real facts
> > first and then we see what we do to solve this problem.
> 
> I have made some tests on a dozen of dongles from Huawei and ZTE.
> I have remove the sim card for each dongle in order to be in the use 
> case you mentionned.
> I used minicom in order the modem not to be intialized.
> For all GSM one there is an answer to ATI but none to AT+GCAP.
> 
> Huawei GSM AT+GCAP ATI answer:
> ======================
> AT+GCAP
> +CME ERROR: SIM failure
> 
> ATI
> Manufacturer: huawei
> Model: E1552
> Revision: 11.608.10.00.309
> IMEI: 353143036552488
> +GCAP: +CGSM,+DS,+ES    --> this is a GSM modem
> 
> This is the case for ALL Huawei GSM dongles we got.
> 
> Huawei CDMA AT+GCAP ATI answers:
> =======================
> AT+GCAP
> +GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS
> 
> ATI
> Manufacturer: +GMI: HUAWEI TECHNOLOGIES CO., LTD
> Model: EC152
> Revision: TCPU_HWEC152DT01
> ESN: +GSN:80aad6fd
> +GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS -->this is CDMA modem 
> (no +CGSM label)
> 
> The Huawei CDMAdongle above with ROM SIM answers to both AT+GCAP and ATI.
> This is the case for ALL Huawei CDMA dongles we got.
> 
> Concerning ZTE we got only GSM modems.
> 
> ZTE AT+GCAP ATI answer:
> ================
> AT+GCAP
> ERROR
> 
> ATI
> Manufacturer: ZTE INCORPORATED
> Model: MF668
> Revision: BD_INRELMF668V1.0.0B01
> IMEI: 355987033958538
> +GCAP: +CGSM,+DS,+ES
> 
> This is the case for ALL ZTE GSM dongles we got.

and what about the case when the SIM card is present, but PIN locked?

> According to the result, it might be interesting to send ATI when the 
> constructor plugin is probe by oFono.
> Thus with +GCAP info we can decide which driver to use.

Is sending +GCAP after ATI really a standard? Have we tried anything
else besides Huawei or ZTE?

Also you do realize that the GAtChat object and thus the file descriptor
is owned by the modem plugin. The plugin itself is the only one that
should do any kind of IO.

So if we require to run ATI first to identify if we are GSM or CDMA,
then this is a per modem manufacture specific detail. And we rather add
a helper function like we did for CPIN polling that makes this easier.

The udev plugins will not open any file descriptors and randomly trying
to execute commands, then close them again and just hope for the best.
It is the modem plugin (and only that one) that is allowed to do IO. It
is fully responsible for driving the modem.

Regards

Marcel

RE: The way to install proper driver for 3G dongle in oFono

[Deng, Ying An]

[-- Attachment #1: Type: text/plain, Size: 7140 bytes --]

>Hi Guillaume,
>
>> >>>>>> We are facing a problem in oFono when using 3G modems:
>> >>>>>>
>> >>>>>> A CDMA2000 modem can have same PID with WCDMA modem, or
>> >>> TDS-CDMA
>> >>>>>> modem -- 3G modem vendors already confirm they do that.
>> >>>>>>
>> >>>>>> That's to say, if following current strategy, it will be a problem to
>> >>>>>> install proper driver for this kind of 3G modem.
>> >>>>>>
>> >>>>>> So, is it feasible to find out a solution such as to probe the modem
>> >>>>>> firstly, find out what kind of network modes it supports, and then
>> >>>>>> install the driver?
>> >>>>>>
>> >>>>>> The way to probe the modem could be some action as to read the
>> >>>>>> capability or get system mode, or issue some specific AT command
>that
>> >>>>>> only response to certain network mode?
>> >>>>>>
>> >>>>> Indeed, we could use for Huawei modems for instance the AT^SYSINFO
>> >>>>> command and retrieve the sys_mode field and parse it, I have found
>> >>>>> this in public Huawei specifications:
>> >>>>>
>> >>>>> <sys_mode>: System mode. The values are as follows:
>> >>>>> 0 No service.
>> >>>>> 1 AMPS mode
>> >>>>> 2 CDMA mode
>> >>>>> 3 GSM/GPRS mode
>> >>>>> 4 HDR mode
>> >>>>> 5 WCDMA mode
>> >>>>> 8 CDMA/HDR HYBRID mode
>> >>>>>
>> >>>>> Thus we can chose accordingly the drivers to create oFono atoms.
>> >>>> After some investigations, it seems SYSINFO won't be enough to get the
>> >>>> modem type because with this AT command we will have to be
>registered to
>> >>>> the network to get the system mode.
>> >>>> The only way I found until now is using the AT+GCAP to check whether
>the
>> >>>> modem is CDMA or GSM type.
>> >>>> However if we do the AT+GCAP request for each constructor plugin
>> >>>> (huawei, zte, ...) it will bring some duplicated code.
>> >>>> Does someone see any better solution?
>> >>> I like to see that we do proper homework here. The first question is
>> >>> actually can you execute AT+GCAP if not SIM card has been inserted or is
>> >>> actually locked? And if not does, ATI provide an extra +GCAP response.
>> >>> Without a SIM atom you will not be able to unlock the modem. And you
>can
>> >>> only create the SIM atom if you know what modem technology you are
>> >>> using. Additionally of course additionally, what are the responses for
>> >>> various modem models and manufactures. Are they doing this actually
>> >>> properly.
>> >>>
>> >>> We need OFONO_AT_DEBUG traces for all the various permutations of
>this
>> >>> behavior. This needs to be documented first. Feel free to send patches
>> >>> to add the results to doc/ directory inside oFono.
>> >>>
>> >>> Just randomly hacking around will get us in trouble and will make well
>> >>> behaved modems like MBM or IFX fail or suffer for no apparent reasons.
>> >> The at+gcap command only effective after SIM card inserted.
>> >> It is feasible to firstly find the vendor, then choose specific method to detect
>> >> if it is wcdma/cdma2k, then install proper driver?
>> > and how does this work if you can't execute AT+GCAP since either your
>> > SIM card is not present of actually locked. As I said above, you can
>> > only unlock the SIM card with the SIM atom loaded. And for loading the
>> > SIM atom you need to know which technology you are operating on.
>> >
>> > I really prefer that the mentioned homework is done properly and
>> > information are first gathers. Wild guessing is not going to help here
>> > and random assumption on how things are suppose to work will eventually
>> > fail because of the nature of this hardware. So lets get real facts
>> > first and then we see what we do to solve this problem.
>>
>> I have made some tests on a dozen of dongles from Huawei and ZTE.
>> I have remove the sim card for each dongle in order to be in the use
>> case you mentionned.
>> I used minicom in order the modem not to be intialized.
>> For all GSM one there is an answer to ATI but none to AT+GCAP.
>>
>> Huawei GSM AT+GCAP ATI answer:
>> ======================
>> AT+GCAP
>> +CME ERROR: SIM failure
>>
>> ATI
>> Manufacturer: huawei
>> Model: E1552
>> Revision: 11.608.10.00.309
>> IMEI: 353143036552488
>> +GCAP: +CGSM,+DS,+ES    --> this is a GSM modem
>>
>> This is the case for ALL Huawei GSM dongles we got.
>>
>> Huawei CDMA AT+GCAP ATI answers:
>> =======================
>> AT+GCAP
>> +GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS
>>
>> ATI
>> Manufacturer: +GMI: HUAWEI TECHNOLOGIES CO., LTD
>> Model: EC152
>> Revision: TCPU_HWEC152DT01
>> ESN: +GSN:80aad6fd
>> +GCAP: +CIS707-A,CIS-856-A,+MS, +ES, +DS, +FCLASS -->this is CDMA modem
>> (no +CGSM label)
>>
>> The Huawei CDMAdongle above with ROM SIM answers to both AT+GCAP and
>ATI.
>> This is the case for ALL Huawei CDMA dongles we got.
>>
>> Concerning ZTE we got only GSM modems.
>>
>> ZTE AT+GCAP ATI answer:
>> ================
>> AT+GCAP
>> ERROR
>>
>> ATI
>> Manufacturer: ZTE INCORPORATED
>> Model: MF668
>> Revision: BD_INRELMF668V1.0.0B01
>> IMEI: 355987033958538
>> +GCAP: +CGSM,+DS,+ES
>>
>> This is the case for ALL ZTE GSM dongles we got.
>
>and what about the case when the SIM card is present, but PIN locked?
>
>> According to the result, it might be interesting to send ATI when the
>> constructor plugin is probe by oFono.
>> Thus with +GCAP info we can decide which driver to use.
>
>Is sending +GCAP after ATI really a standard? Have we tried anything
>else besides Huawei or ZTE?

I tried with more dongles from different vendors, as attached table.
The scenarios include:
With valid sim card, sim card PIN locked, no sim card, sim card locked.
N(ROM) in table indicates the SIM in ROM already.
ATI command can always return GCAP content in all tests.

>
>Also you do realize that the GAtChat object and thus the file descriptor
>is owned by the modem plugin. The plugin itself is the only one that
>should do any kind of IO.
>
>So if we require to run ATI first to identify if we are GSM or CDMA,
>then this is a per modem manufacture specific detail. And we rather add
>a helper function like we did for CPIN polling that makes this easier.
>

In current code the 'driver' is hardcoded by comparing with vendor_list[].
So if it possible to break the step into several:
vendor_list[] in udevng just cares about vendor - by comparing vendor ID only,
and add all possible drivers according to that vendor - (for example add 
WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged in),
and the probe interface in each driver does real probe work as to issue
ATI command to ensure only correct driver will be loaded?

>The udev plugins will not open any file descriptors and randomly trying
>to execute commands, then close them again and just hope for the best.
>It is the modem plugin (and only that one) that is allowed to do IO. It
>is fully responsible for driving the modem.
>
>Regards
>
>Marcel
>
>
>_______________________________________________
>ofono mailing list
>ofono(a)ofono.org
>http://lists.ofono.org/listinfo/ofono

[-- Attachment #2: Test_ATGCAP_ATI_CMD.pdf --]
[-- Type: application/pdf, Size: 113124 bytes --]

RE: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Hi Ying An,

> >and what about the case when the SIM card is present, but PIN locked?
> >
> >> According to the result, it might be interesting to send ATI when the
> >> constructor plugin is probe by oFono.
> >> Thus with +GCAP info we can decide which driver to use.
> >
> >Is sending +GCAP after ATI really a standard? Have we tried anything
> >else besides Huawei or ZTE?
> 
> I tried with more dongles from different vendors, as attached table.
> The scenarios include:
> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> N(ROM) in table indicates the SIM in ROM already.
> ATI command can always return GCAP content in all tests.

and what about other manufactures other than Huawei, ZTE and SpeedUp?
What about Sierra, Ericsson etc.?

> >Also you do realize that the GAtChat object and thus the file descriptor
> >is owned by the modem plugin. The plugin itself is the only one that
> >should do any kind of IO.
> >
> >So if we require to run ATI first to identify if we are GSM or CDMA,
> >then this is a per modem manufacture specific detail. And we rather add
> >a helper function like we did for CPIN polling that makes this easier.
> >
> 
> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> So if it possible to break the step into several:
> vendor_list[] in udevng just cares about vendor - by comparing vendor ID only,
> and add all possible drivers according to that vendor - (for example add 
> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged in),
> and the probe interface in each driver does real probe work as to issue
> ATI command to ensure only correct driver will be loaded?

As I said before, the only time IO can be started is when the ->enable()
callback of the modem plugin is called. Not a second earlier.

Regards

Marcel

RE: The way to install proper driver for 3G dongle in oFono

[Deng, Ying An]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

>Hi Ying An,
>
>> >and what about the case when the SIM card is present, but PIN locked?
>> >
>> >> According to the result, it might be interesting to send ATI when the
>> >> constructor plugin is probe by oFono.
>> >> Thus with +GCAP info we can decide which driver to use.
>> >
>> >Is sending +GCAP after ATI really a standard? Have we tried anything
>> >else besides Huawei or ZTE?
>>
>> I tried with more dongles from different vendors, as attached table.
>> The scenarios include:
>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>> N(ROM) in table indicates the SIM in ROM already.
>> ATI command can always return GCAP content in all tests.
>
>and what about other manufactures other than Huawei, ZTE and SpeedUp?
>What about Sierra, Ericsson etc.?

Just checked Dell 5530 with Ericsson module, 
With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
But the ATI only returns: D5530

>
>> >Also you do realize that the GAtChat object and thus the file descriptor
>> >is owned by the modem plugin. The plugin itself is the only one that
>> >should do any kind of IO.
>> >
>> >So if we require to run ATI first to identify if we are GSM or CDMA,
>> >then this is a per modem manufacture specific detail. And we rather add
>> >a helper function like we did for CPIN polling that makes this easier.
>> >
>>
>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>> So if it possible to break the step into several:
>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID only,
>> and add all possible drivers according to that vendor - (for example add
>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged in),
>> and the probe interface in each driver does real probe work as to issue
>> ATI command to ensure only correct driver will be loaded?
>
>As I said before, the only time IO can be started is when the ->enable()
>callback of the modem plugin is called. Not a second earlier.

But if done after enable() called, from semantic aspect the correct driver has been 
chosen. Indeed the probe() interface in each driver is not doing something to probe,
then can the work be done in probe()? As set CFUN=1 then doing some dongle vendor 
specific work as query model or network mode by ATI, AT+GCAP command, etc..? After 
that disable dongle when quit probe()?

>
>Regards
>
>Marcel
>
>
>_______________________________________________
>ofono mailing list
>ofono(a)ofono.org
>http://lists.ofono.org/listinfo/ofono

RE: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]

Hi Ying An,

> >> >and what about the case when the SIM card is present, but PIN locked?
> >> >
> >> >> According to the result, it might be interesting to send ATI when the
> >> >> constructor plugin is probe by oFono.
> >> >> Thus with +GCAP info we can decide which driver to use.
> >> >
> >> >Is sending +GCAP after ATI really a standard? Have we tried anything
> >> >else besides Huawei or ZTE?
> >>
> >> I tried with more dongles from different vendors, as attached table.
> >> The scenarios include:
> >> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >> N(ROM) in table indicates the SIM in ROM already.
> >> ATI command can always return GCAP content in all tests.
> >
> >and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >What about Sierra, Ericsson etc.?
> 
> Just checked Dell 5530 with Ericsson module, 
> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> But the ATI only returns: D5530

I think it is clear that we need to do our homework here and properly
document the different manufacturers. Someone sending patches for our
doc/ directory?

> >> >Also you do realize that the GAtChat object and thus the file descriptor
> >> >is owned by the modem plugin. The plugin itself is the only one that
> >> >should do any kind of IO.
> >> >
> >> >So if we require to run ATI first to identify if we are GSM or CDMA,
> >> >then this is a per modem manufacture specific detail. And we rather add
> >> >a helper function like we did for CPIN polling that makes this easier.
> >> >
> >>
> >> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >> So if it possible to break the step into several:
> >> vendor_list[] in udevng just cares about vendor - by comparing vendor ID only,
> >> and add all possible drivers according to that vendor - (for example add
> >> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged in),
> >> and the probe interface in each driver does real probe work as to issue
> >> ATI command to ensure only correct driver will be loaded?
> >
> >As I said before, the only time IO can be started is when the ->enable()
> >callback of the modem plugin is called. Not a second earlier.
> 
> But if done after enable() called, from semantic aspect the correct driver has been 
> chosen. Indeed the probe() interface in each driver is not doing something to probe,
> then can the work be done in probe()? As set CFUN=1 then doing some dongle vendor 
> specific work as query model or network mode by ATI, AT+GCAP command, etc..? After 
> that disable dongle when quit probe()?

The probe() callback is for accepting the driver and allocating required
local data structures. It is not for IO. And as you can see it has no
callback handling like enable() with set_powered().

As I said before, no AT commands before enable() has been called. That
is how it is suppose to be. We are not changing this.

Regards

Marcel

RE: The way to install proper driver for 3G dongle in oFono

[Deng, Ying An]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

>Hi Ying An,
>
>> >> >and what about the case when the SIM card is present, but PIN locked?
>> >> >
>> >> >> According to the result, it might be interesting to send ATI when the
>> >> >> constructor plugin is probe by oFono.
>> >> >> Thus with +GCAP info we can decide which driver to use.
>> >> >
>> >> >Is sending +GCAP after ATI really a standard? Have we tried anything
>> >> >else besides Huawei or ZTE?
>> >>
>> >> I tried with more dongles from different vendors, as attached table.
>> >> The scenarios include:
>> >> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>> >> N(ROM) in table indicates the SIM in ROM already.
>> >> ATI command can always return GCAP content in all tests.
>> >
>> >and what about other manufactures other than Huawei, ZTE and SpeedUp?
>> >What about Sierra, Ericsson etc.?
>>
>> Just checked Dell 5530 with Ericsson module,
>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>> But the ATI only returns: D5530
>
>I think it is clear that we need to do our homework here and properly
>document the different manufacturers. Someone sending patches for our
>doc/ directory?

There're many vendors of 3G dongle..
Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
We can try with them step by step, but can we work out the 2 biggest firstly?
Looks ATI command can work for both Huawei and ZTE dongles.

>
>> >> >Also you do realize that the GAtChat object and thus the file descriptor
>> >> >is owned by the modem plugin. The plugin itself is the only one that
>> >> >should do any kind of IO.
>> >> >
>> >> >So if we require to run ATI first to identify if we are GSM or CDMA,
>> >> >then this is a per modem manufacture specific detail. And we rather add
>> >> >a helper function like we did for CPIN polling that makes this easier.
>> >> >
>> >>
>> >> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>> >> So if it possible to break the step into several:
>> >> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>only,
>> >> and add all possible drivers according to that vendor - (for example add
>> >> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>in),
>> >> and the probe interface in each driver does real probe work as to issue
>> >> ATI command to ensure only correct driver will be loaded?
>> >
>> >As I said before, the only time IO can be started is when the ->enable()
>> >callback of the modem plugin is called. Not a second earlier.
>>
>> But if done after enable() called, from semantic aspect the correct driver has
>been
>> chosen. Indeed the probe() interface in each driver is not doing something to
>probe,
>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>vendor
>> specific work as query model or network mode by ATI, AT+GCAP command,
>etc..? After
>> that disable dongle when quit probe()?
>
>The probe() callback is for accepting the driver and allocating required
>local data structures. It is not for IO. And as you can see it has no
>callback handling like enable() with set_powered().
>
>As I said before, no AT commands before enable() has been called. That
>is how it is suppose to be. We are not changing this.
>
>Regards
>
>Marcel
>
>
>_______________________________________________
>ofono mailing list
>ofono(a)ofono.org
>http://lists.ofono.org/listinfo/ofono

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 4577 bytes --]

Hi Marcel and Ying An,

On 23/12/2011 15:03, Deng, Ying An wrote:
>> Hi Ying An,
>>
>>>>>> and what about the case when the SIM card is present, but PIN locked?
>>>>>>
>>>>>>> According to the result, it might be interesting to send ATI when the
>>>>>>> constructor plugin is probe by oFono.
>>>>>>> Thus with +GCAP info we can decide which driver to use.
>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
>>>>>> else besides Huawei or ZTE?
>>>>> I tried with more dongles from different vendors, as attached table.
>>>>> The scenarios include:
>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>>>>> N(ROM) in table indicates the SIM in ROM already.
>>>>> ATI command can always return GCAP content in all tests.
>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
>>>> What about Sierra, Ericsson etc.?
>>> Just checked Dell 5530 with Ericsson module,
>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>>> But the ATI only returns: D5530
>> I think it is clear that we need to do our homework here and properly
>> document the different manufacturers. Someone sending patches for our
>> doc/ directory?
> There're many vendors of 3G dongle..
> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> We can try with them step by step, but can we work out the 2 biggest firstly?
> Looks ATI command can work for both Huawei and ZTE dongles.
>

I agree here, the work to be done over all manufacturers will be 
fastidious and might require a lot of dongles that we don't have currently.
Maybe we could do as Ying An proposed as we are sure ATI works for 
Huawei and ZTE (at least the ones we have).
However, conerning ZTE I haven't seen any CDMA dongle for the moment.

>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
>>>>>> is owned by the modem plugin. The plugin itself is the only one that
>>>>>> should do any kind of IO.
>>>>>>
>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
>>>>>> then this is a per modem manufacture specific detail. And we rather add
>>>>>> a helper function like we did for CPIN polling that makes this easier.
>>>>>>
>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>>>>> So if it possible to break the step into several:
>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>> only,
>>>>> and add all possible drivers according to that vendor - (for example add
>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>> in),
>>>>> and the probe interface in each driver does real probe work as to issue
>>>>> ATI command to ensure only correct driver will be loaded?
>>>> As I said before, the only time IO can be started is when the ->enable()
>>>> callback of the modem plugin is called. Not a second earlier.
>>> But if done after enable() called, from semantic aspect the correct driver has
>> been
>>> chosen. Indeed the probe() interface in each driver is not doing something to
>> probe,
>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>> vendor
>>> specific work as query model or network mode by ATI, AT+GCAP command,
>> etc..? After
>>> that disable dongle when quit probe()?
>> The probe() callback is for accepting the driver and allocating required
>> local data structures. It is not for IO. And as you can see it has no
>> callback handling like enable() with set_powered().
>>
>> As I said before, no AT commands before enable() has been called. That
>> is how it is suppose to be. We are not changing this.

First, ATI command is working without sending AT+CFUN=1, we could keep 
CFUN=1 into enable() as we do some vendor/modem type specific job there.

Then vendor plugin can be chosen using udevng using Vendor ID, however 
driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard 
to chose the right vendor plugin with right type.
And if we can't send AT command before enable() time we will face to bag 
end e.g. :
For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during 
the enable() time.
We are also querying the sim state using polling mechanism that might 
fail for CDMA modems that is not using SIM.
What would you suggest here?

Kind regards,
Guillaume

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

Hi Guillaume,

> >>>>>> and what about the case when the SIM card is present, but PIN locked?
> >>>>>>
> >>>>>>> According to the result, it might be interesting to send ATI when the
> >>>>>>> constructor plugin is probe by oFono.
> >>>>>>> Thus with +GCAP info we can decide which driver to use.
> >>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
> >>>>>> else besides Huawei or ZTE?
> >>>>> I tried with more dongles from different vendors, as attached table.
> >>>>> The scenarios include:
> >>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >>>>> N(ROM) in table indicates the SIM in ROM already.
> >>>>> ATI command can always return GCAP content in all tests.
> >>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >>>> What about Sierra, Ericsson etc.?
> >>> Just checked Dell 5530 with Ericsson module,
> >>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> >>> But the ATI only returns: D5530
> >> I think it is clear that we need to do our homework here and properly
> >> document the different manufacturers. Someone sending patches for our
> >> doc/ directory?
> > There're many vendors of 3G dongle..
> > Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> > Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> > We can try with them step by step, but can we work out the 2 biggest firstly?
> > Looks ATI command can work for both Huawei and ZTE dongles.
> >
> 
> I agree here, the work to be done over all manufacturers will be 
> fastidious and might require a lot of dongles that we don't have currently.
> Maybe we could do as Ying An proposed as we are sure ATI works for 
> Huawei and ZTE (at least the ones we have).
> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
> 
> >>>>>> Also you do realize that the GAtChat object and thus the file descriptor
> >>>>>> is owned by the modem plugin. The plugin itself is the only one that
> >>>>>> should do any kind of IO.
> >>>>>>
> >>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
> >>>>>> then this is a per modem manufacture specific detail. And we rather add
> >>>>>> a helper function like we did for CPIN polling that makes this easier.
> >>>>>>
> >>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >>>>> So if it possible to break the step into several:
> >>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
> >> only,
> >>>>> and add all possible drivers according to that vendor - (for example add
> >>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
> >> in),
> >>>>> and the probe interface in each driver does real probe work as to issue
> >>>>> ATI command to ensure only correct driver will be loaded?
> >>>> As I said before, the only time IO can be started is when the ->enable()
> >>>> callback of the modem plugin is called. Not a second earlier.
> >>> But if done after enable() called, from semantic aspect the correct driver has
> >> been
> >>> chosen. Indeed the probe() interface in each driver is not doing something to
> >> probe,
> >>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
> >> vendor
> >>> specific work as query model or network mode by ATI, AT+GCAP command,
> >> etc..? After
> >>> that disable dongle when quit probe()?
> >> The probe() callback is for accepting the driver and allocating required
> >> local data structures. It is not for IO. And as you can see it has no
> >> callback handling like enable() with set_powered().
> >>
> >> As I said before, no AT commands before enable() has been called. That
> >> is how it is suppose to be. We are not changing this.
> 
> First, ATI command is working without sending AT+CFUN=1, we could keep 
> CFUN=1 into enable() as we do some vendor/modem type specific job there.
> 
> Then vendor plugin can be chosen using udevng using Vendor ID, however 
> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard 
> to chose the right vendor plugin with right type.
> And if we can't send AT command before enable() time we will face to bag 
> end e.g. :
> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during 
> the enable() time.
> We are also querying the sim state using polling mechanism that might 
> fail for CDMA modems that is not using SIM.
> What would you suggest here?

as I said before, no AT commands before ->enable() callback from the
core.

The callback ->probe() is for accepting the modem driver binding and
allocating modem specific data memory. The callback ->remove() is for
cleanup.

The callbacks ->enable(), ->disable() and ->set_online() are the only IO
entry points for every modem driver. And we need to keep it like this.

The callback ->pre_sim(), ->post_sim() and ->post_online() are the entry
points for selecting atom drivers. These are not allowed to do IO
directly either.

Regards

Marcel

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 5789 bytes --]

Hi Marcel,

On 04/01/2012 16:29, Marcel Holtmann wrote:
> Hi Guillaume,
>
>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
>>>>>>>>
>>>>>>>>> According to the result, it might be interesting to send ATI when the
>>>>>>>>> constructor plugin is probe by oFono.
>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
>>>>>>>> else besides Huawei or ZTE?
>>>>>>> I tried with more dongles from different vendors, as attached table.
>>>>>>> The scenarios include:
>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>>>>>>> N(ROM) in table indicates the SIM in ROM already.
>>>>>>> ATI command can always return GCAP content in all tests.
>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
>>>>>> What about Sierra, Ericsson etc.?
>>>>> Just checked Dell 5530 with Ericsson module,
>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>>>>> But the ATI only returns: D5530
>>>> I think it is clear that we need to do our homework here and properly
>>>> document the different manufacturers. Someone sending patches for our
>>>> doc/ directory?
>>> There're many vendors of 3G dongle..
>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
>>> We can try with them step by step, but can we work out the 2 biggest firstly?
>>> Looks ATI command can work for both Huawei and ZTE dongles.
>>>
>> I agree here, the work to be done over all manufacturers will be
>> fastidious and might require a lot of dongles that we don't have currently.
>> Maybe we could do as Ying An proposed as we are sure ATI works for
>> Huawei and ZTE (at least the ones we have).
>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
>>
>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
>>>>>>>> should do any kind of IO.
>>>>>>>>
>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
>>>>>>>>
>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>>>>>>> So if it possible to break the step into several:
>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>>>> only,
>>>>>>> and add all possible drivers according to that vendor - (for example add
>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>>>> in),
>>>>>>> and the probe interface in each driver does real probe work as to issue
>>>>>>> ATI command to ensure only correct driver will be loaded?
>>>>>> As I said before, the only time IO can be started is when the ->enable()
>>>>>> callback of the modem plugin is called. Not a second earlier.
>>>>> But if done after enable() called, from semantic aspect the correct driver has
>>>> been
>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
>>>> probe,
>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>>>> vendor
>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
>>>> etc..? After
>>>>> that disable dongle when quit probe()?
>>>> The probe() callback is for accepting the driver and allocating required
>>>> local data structures. It is not for IO. And as you can see it has no
>>>> callback handling like enable() with set_powered().
>>>>
>>>> As I said before, no AT commands before enable() has been called. That
>>>> is how it is suppose to be. We are not changing this.
>> First, ATI command is working without sending AT+CFUN=1, we could keep
>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
>>
>> Then vendor plugin can be chosen using udevng using Vendor ID, however
>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
>> to chose the right vendor plugin with right type.
>> And if we can't send AT command before enable() time we will face to bag
>> end e.g. :
>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
>> the enable() time.
>> We are also querying the sim state using polling mechanism that might
>> fail for CDMA modems that is not using SIM.
>> What would you suggest here?
> as I said before, no AT commands before ->enable() callback from the
> core.
>
> The callback ->probe() is for accepting the modem driver binding and
> allocating modem specific data memory. The callback ->remove() is for
> cleanup.
>
> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
> entry points for every modem driver. And we need to keep it like this.

Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
Then depending on the ATI answer:
     - tag the huawei modem data with GSM / CDMA type.
     - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.

We should not longer make the difference between "huawei" and 
"huaweicdma" into udevng.
It also means there is one unified plugin.

> The callback ->pre_sim(), ->post_sim() and ->post_online() are the entry
> points for selecting atom drivers. These are not allowed to do IO
> directly either.

Here, using the tagged type, the plugin can decide which driver to use 
to create atom.
Does it sound ok to you?

Kind regards,
Guillaume

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

Hi Guillaume,

> >>>>>>>> and what about the case when the SIM card is present, but PIN locked?
> >>>>>>>>
> >>>>>>>>> According to the result, it might be interesting to send ATI when the
> >>>>>>>>> constructor plugin is probe by oFono.
> >>>>>>>>> Thus with +GCAP info we can decide which driver to use.
> >>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
> >>>>>>>> else besides Huawei or ZTE?
> >>>>>>> I tried with more dongles from different vendors, as attached table.
> >>>>>>> The scenarios include:
> >>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >>>>>>> N(ROM) in table indicates the SIM in ROM already.
> >>>>>>> ATI command can always return GCAP content in all tests.
> >>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >>>>>> What about Sierra, Ericsson etc.?
> >>>>> Just checked Dell 5530 with Ericsson module,
> >>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> >>>>> But the ATI only returns: D5530
> >>>> I think it is clear that we need to do our homework here and properly
> >>>> document the different manufacturers. Someone sending patches for our
> >>>> doc/ directory?
> >>> There're many vendors of 3G dongle..
> >>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> >>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> >>> We can try with them step by step, but can we work out the 2 biggest firstly?
> >>> Looks ATI command can work for both Huawei and ZTE dongles.
> >>>
> >> I agree here, the work to be done over all manufacturers will be
> >> fastidious and might require a lot of dongles that we don't have currently.
> >> Maybe we could do as Ying An proposed as we are sure ATI works for
> >> Huawei and ZTE (at least the ones we have).
> >> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
> >>
> >>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
> >>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
> >>>>>>>> should do any kind of IO.
> >>>>>>>>
> >>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
> >>>>>>>> then this is a per modem manufacture specific detail. And we rather add
> >>>>>>>> a helper function like we did for CPIN polling that makes this easier.
> >>>>>>>>
> >>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >>>>>>> So if it possible to break the step into several:
> >>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
> >>>> only,
> >>>>>>> and add all possible drivers according to that vendor - (for example add
> >>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
> >>>> in),
> >>>>>>> and the probe interface in each driver does real probe work as to issue
> >>>>>>> ATI command to ensure only correct driver will be loaded?
> >>>>>> As I said before, the only time IO can be started is when the ->enable()
> >>>>>> callback of the modem plugin is called. Not a second earlier.
> >>>>> But if done after enable() called, from semantic aspect the correct driver has
> >>>> been
> >>>>> chosen. Indeed the probe() interface in each driver is not doing something to
> >>>> probe,
> >>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
> >>>> vendor
> >>>>> specific work as query model or network mode by ATI, AT+GCAP command,
> >>>> etc..? After
> >>>>> that disable dongle when quit probe()?
> >>>> The probe() callback is for accepting the driver and allocating required
> >>>> local data structures. It is not for IO. And as you can see it has no
> >>>> callback handling like enable() with set_powered().
> >>>>
> >>>> As I said before, no AT commands before enable() has been called. That
> >>>> is how it is suppose to be. We are not changing this.
> >> First, ATI command is working without sending AT+CFUN=1, we could keep
> >> CFUN=1 into enable() as we do some vendor/modem type specific job there.
> >>
> >> Then vendor plugin can be chosen using udevng using Vendor ID, however
> >> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
> >> to chose the right vendor plugin with right type.
> >> And if we can't send AT command before enable() time we will face to bag
> >> end e.g. :
> >> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
> >> the enable() time.
> >> We are also querying the sim state using polling mechanism that might
> >> fail for CDMA modems that is not using SIM.
> >> What would you suggest here?
> > as I said before, no AT commands before ->enable() callback from the
> > core.
> >
> > The callback ->probe() is for accepting the modem driver binding and
> > allocating modem specific data memory. The callback ->remove() is for
> > cleanup.
> >
> > The callbacks ->enable(), ->disable() and ->set_online() are the only IO
> > entry points for every modem driver. And we need to keep it like this.
> 
> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.

the first command has to be always ATE0 +CMEE=1 since otherwise you a)
can not use the permissive syntax parser and b) your error values will
be useless.

But yes, after that it is fine to send ATI.

> Then depending on the ATI answer:
>      - tag the huawei modem data with GSM / CDMA type.
>      - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.

What different commands depending on GSM or CDMA do you actually have?

The AT^RFSWITCH=? is exactly designed to handle if that command is
supported or not. There are plenty of GSM versions of the Huawei that do
not support AT^RFSWITCH. You do need to know if this is supported or
not.

Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
into offline mode. The only time you send AT+CFUN=1 is if you have
hardware that does not support online/offline distinction. So if this is
true for Huawei CDMA modems, then the obvious questions is why that is
the case? Or is this a bug with our CDMA support not supporting offline
mode.

> We should not longer make the difference between "huawei" and 
> "huaweicdma" into udevng.
> It also means there is one unified plugin.

That is totally fine.

> > The callback ->pre_sim(), ->post_sim() and ->post_online() are the entry
> > points for selecting atom drivers. These are not allowed to do IO
> > directly either.
> 
> Here, using the tagged type, the plugin can decide which driver to use 
> to create atom.
> Does it sound ok to you?

Fine with me.

Regards

Marcel

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 7322 bytes --]

Hi Marcel,

On 04/01/2012 17:12, Marcel Holtmann wrote:
> Hi Guillaume,
>
>>>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
>>>>>>>>>>
>>>>>>>>>>> According to the result, it might be interesting to send ATI when the
>>>>>>>>>>> constructor plugin is probe by oFono.
>>>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
>>>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
>>>>>>>>>> else besides Huawei or ZTE?
>>>>>>>>> I tried with more dongles from different vendors, as attached table.
>>>>>>>>> The scenarios include:
>>>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>>>>>>>>> N(ROM) in table indicates the SIM in ROM already.
>>>>>>>>> ATI command can always return GCAP content in all tests.
>>>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
>>>>>>>> What about Sierra, Ericsson etc.?
>>>>>>> Just checked Dell 5530 with Ericsson module,
>>>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>>>>>>> But the ATI only returns: D5530
>>>>>> I think it is clear that we need to do our homework here and properly
>>>>>> document the different manufacturers. Someone sending patches for our
>>>>>> doc/ directory?
>>>>> There're many vendors of 3G dongle..
>>>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
>>>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
>>>>> We can try with them step by step, but can we work out the 2 biggest firstly?
>>>>> Looks ATI command can work for both Huawei and ZTE dongles.
>>>>>
>>>> I agree here, the work to be done over all manufacturers will be
>>>> fastidious and might require a lot of dongles that we don't have currently.
>>>> Maybe we could do as Ying An proposed as we are sure ATI works for
>>>> Huawei and ZTE (at least the ones we have).
>>>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
>>>>
>>>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
>>>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
>>>>>>>>>> should do any kind of IO.
>>>>>>>>>>
>>>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
>>>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
>>>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
>>>>>>>>>>
>>>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>>>>>>>>> So if it possible to break the step into several:
>>>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>>>>>> only,
>>>>>>>>> and add all possible drivers according to that vendor - (for example add
>>>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>>>>>> in),
>>>>>>>>> and the probe interface in each driver does real probe work as to issue
>>>>>>>>> ATI command to ensure only correct driver will be loaded?
>>>>>>>> As I said before, the only time IO can be started is when the ->enable()
>>>>>>>> callback of the modem plugin is called. Not a second earlier.
>>>>>>> But if done after enable() called, from semantic aspect the correct driver has
>>>>>> been
>>>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
>>>>>> probe,
>>>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>>>>>> vendor
>>>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
>>>>>> etc..? After
>>>>>>> that disable dongle when quit probe()?
>>>>>> The probe() callback is for accepting the driver and allocating required
>>>>>> local data structures. It is not for IO. And as you can see it has no
>>>>>> callback handling like enable() with set_powered().
>>>>>>
>>>>>> As I said before, no AT commands before enable() has been called. That
>>>>>> is how it is suppose to be. We are not changing this.
>>>> First, ATI command is working without sending AT+CFUN=1, we could keep
>>>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
>>>>
>>>> Then vendor plugin can be chosen using udevng using Vendor ID, however
>>>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
>>>> to chose the right vendor plugin with right type.
>>>> And if we can't send AT command before enable() time we will face to bag
>>>> end e.g. :
>>>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
>>>> the enable() time.
>>>> We are also querying the sim state using polling mechanism that might
>>>> fail for CDMA modems that is not using SIM.
>>>> What would you suggest here?
>>> as I said before, no AT commands before ->enable() callback from the
>>> core.
>>>
>>> The callback ->probe() is for accepting the modem driver binding and
>>> allocating modem specific data memory. The callback ->remove() is for
>>> cleanup.
>>>
>>> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
>>> entry points for every modem driver. And we need to keep it like this.
>> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
> the first command has to be always ATE0 +CMEE=1 since otherwise you a)
> can not use the permissive syntax parser and b) your error values will
> be useless.
>
> But yes, after that it is fine to send ATI.
>

Ok

>> Then depending on the ATI answer:
>>       - tag the huawei modem data with GSM / CDMA type.
>>       - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.
> What different commands depending on GSM or CDMA do you actually have?
>
> The AT^RFSWITCH=? is exactly designed to handle if that command is
> supported or not. There are plenty of GSM versions of the Huawei that do
> not support AT^RFSWITCH. You do need to know if this is supported or
> not.

I see, so we can send AT^RFSWITCH for both type. If it is not supported, 
it will be ignored using terminator and then use
default AT+CFUN=5.

> Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
> into offline mode. The only time you send AT+CFUN=1 is if you have
> hardware that does not support online/offline distinction. So if this is
> true for Huawei CDMA modems, then the obvious questions is why that is
> the case? Or is this a bug with our CDMA support not supporting offline
> mode.
>

For the moment, CDMA modems are not using ->set_online() callback (it is 
automatically set online into modem.c).
We will have to make some test to check AT+CFUN=5 is working on CDMA modems.

>> We should not longer make the difference between "huawei" and
>> "huaweicdma" into udevng.
>> It also means there is one unified plugin.
> That is totally fine.
>
>>> The callback ->pre_sim(), ->post_sim() and ->post_online() are the entry
>>> points for selecting atom drivers. These are not allowed to do IO
>>> directly either.
>> Here, using the tagged type, the plugin can decide which driver to use
>> to create atom.
>> Does it sound ok to you?
> Fine with me.
>
> Regards
>
> Marcel

Kind regards,
Guillaume

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 7707 bytes --]

Hi Guillaume,

> >>>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
> >>>>>>>>>>
> >>>>>>>>>>> According to the result, it might be interesting to send ATI when the
> >>>>>>>>>>> constructor plugin is probe by oFono.
> >>>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
> >>>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
> >>>>>>>>>> else besides Huawei or ZTE?
> >>>>>>>>> I tried with more dongles from different vendors, as attached table.
> >>>>>>>>> The scenarios include:
> >>>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >>>>>>>>> N(ROM) in table indicates the SIM in ROM already.
> >>>>>>>>> ATI command can always return GCAP content in all tests.
> >>>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >>>>>>>> What about Sierra, Ericsson etc.?
> >>>>>>> Just checked Dell 5530 with Ericsson module,
> >>>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> >>>>>>> But the ATI only returns: D5530
> >>>>>> I think it is clear that we need to do our homework here and properly
> >>>>>> document the different manufacturers. Someone sending patches for our
> >>>>>> doc/ directory?
> >>>>> There're many vendors of 3G dongle..
> >>>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> >>>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> >>>>> We can try with them step by step, but can we work out the 2 biggest firstly?
> >>>>> Looks ATI command can work for both Huawei and ZTE dongles.
> >>>>>
> >>>> I agree here, the work to be done over all manufacturers will be
> >>>> fastidious and might require a lot of dongles that we don't have currently.
> >>>> Maybe we could do as Ying An proposed as we are sure ATI works for
> >>>> Huawei and ZTE (at least the ones we have).
> >>>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
> >>>>
> >>>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
> >>>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
> >>>>>>>>>> should do any kind of IO.
> >>>>>>>>>>
> >>>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
> >>>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
> >>>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
> >>>>>>>>>>
> >>>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >>>>>>>>> So if it possible to break the step into several:
> >>>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
> >>>>>> only,
> >>>>>>>>> and add all possible drivers according to that vendor - (for example add
> >>>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
> >>>>>> in),
> >>>>>>>>> and the probe interface in each driver does real probe work as to issue
> >>>>>>>>> ATI command to ensure only correct driver will be loaded?
> >>>>>>>> As I said before, the only time IO can be started is when the ->enable()
> >>>>>>>> callback of the modem plugin is called. Not a second earlier.
> >>>>>>> But if done after enable() called, from semantic aspect the correct driver has
> >>>>>> been
> >>>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
> >>>>>> probe,
> >>>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
> >>>>>> vendor
> >>>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
> >>>>>> etc..? After
> >>>>>>> that disable dongle when quit probe()?
> >>>>>> The probe() callback is for accepting the driver and allocating required
> >>>>>> local data structures. It is not for IO. And as you can see it has no
> >>>>>> callback handling like enable() with set_powered().
> >>>>>>
> >>>>>> As I said before, no AT commands before enable() has been called. That
> >>>>>> is how it is suppose to be. We are not changing this.
> >>>> First, ATI command is working without sending AT+CFUN=1, we could keep
> >>>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
> >>>>
> >>>> Then vendor plugin can be chosen using udevng using Vendor ID, however
> >>>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
> >>>> to chose the right vendor plugin with right type.
> >>>> And if we can't send AT command before enable() time we will face to bag
> >>>> end e.g. :
> >>>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
> >>>> the enable() time.
> >>>> We are also querying the sim state using polling mechanism that might
> >>>> fail for CDMA modems that is not using SIM.
> >>>> What would you suggest here?
> >>> as I said before, no AT commands before ->enable() callback from the
> >>> core.
> >>>
> >>> The callback ->probe() is for accepting the modem driver binding and
> >>> allocating modem specific data memory. The callback ->remove() is for
> >>> cleanup.
> >>>
> >>> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
> >>> entry points for every modem driver. And we need to keep it like this.
> >> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
> > the first command has to be always ATE0 +CMEE=1 since otherwise you a)
> > can not use the permissive syntax parser and b) your error values will
> > be useless.
> >
> > But yes, after that it is fine to send ATI.
> >
> 
> Ok
> 
> >> Then depending on the ATI answer:
> >>       - tag the huawei modem data with GSM / CDMA type.
> >>       - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.
> > What different commands depending on GSM or CDMA do you actually have?
> >
> > The AT^RFSWITCH=? is exactly designed to handle if that command is
> > supported or not. There are plenty of GSM versions of the Huawei that do
> > not support AT^RFSWITCH. You do need to know if this is supported or
> > not.
> 
> I see, so we can send AT^RFSWITCH for both type. If it is not supported, 
> it will be ignored using terminator and then use
> default AT+CFUN=5.
> 
> > Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
> > into offline mode. The only time you send AT+CFUN=1 is if you have
> > hardware that does not support online/offline distinction. So if this is
> > true for Huawei CDMA modems, then the obvious questions is why that is
> > the case? Or is this a bug with our CDMA support not supporting offline
> > mode.
> >
> 
> For the moment, CDMA modems are not using ->set_online() callback (it is 
> automatically set online into modem.c).
> We will have to make some test to check AT+CFUN=5 is working on CDMA modems.

The Huawei GSM support is using ->set_online() callback. And so this
means that you need it also for CDMA support. Otherwise you are back at
square one.

Actually you need to test the full CDMA support and if it can properly
handle ->set_online() support. If not, then this needs fixing.

Also I am still not seeing proper support for CDMA SIM atom. We need to
stop hacking around here. The core functionality needs to be implemented
first. Without it, the modem plugins can not function properly.

So why are we wasting time with modem details here. If I remember
correctly, Denis and I made it pretty clear that SIM atom and network
registration atom is a fundamental requirement for CDMA support.

Regards

Marcel

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 8127 bytes --]

Hi Marcel,

>>>>>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
>>>>>>>>>>>>
>>>>>>>>>>>>> According to the result, it might be interesting to send ATI when the
>>>>>>>>>>>>> constructor plugin is probe by oFono.
>>>>>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
>>>>>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
>>>>>>>>>>>> else besides Huawei or ZTE?
>>>>>>>>>>> I tried with more dongles from different vendors, as attached table.
>>>>>>>>>>> The scenarios include:
>>>>>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>>>>>>>>>>> N(ROM) in table indicates the SIM in ROM already.
>>>>>>>>>>> ATI command can always return GCAP content in all tests.
>>>>>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
>>>>>>>>>> What about Sierra, Ericsson etc.?
>>>>>>>>> Just checked Dell 5530 with Ericsson module,
>>>>>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>>>>>>>>> But the ATI only returns: D5530
>>>>>>>> I think it is clear that we need to do our homework here and properly
>>>>>>>> document the different manufacturers. Someone sending patches for our
>>>>>>>> doc/ directory?
>>>>>>> There're many vendors of 3G dongle..
>>>>>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
>>>>>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
>>>>>>> We can try with them step by step, but can we work out the 2 biggest firstly?
>>>>>>> Looks ATI command can work for both Huawei and ZTE dongles.
>>>>>>>
>>>>>> I agree here, the work to be done over all manufacturers will be
>>>>>> fastidious and might require a lot of dongles that we don't have currently.
>>>>>> Maybe we could do as Ying An proposed as we are sure ATI works for
>>>>>> Huawei and ZTE (at least the ones we have).
>>>>>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
>>>>>>
>>>>>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
>>>>>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
>>>>>>>>>>>> should do any kind of IO.
>>>>>>>>>>>>
>>>>>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
>>>>>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
>>>>>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
>>>>>>>>>>>>
>>>>>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>>>>>>>>>>> So if it possible to break the step into several:
>>>>>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>>>>>>>> only,
>>>>>>>>>>> and add all possible drivers according to that vendor - (for example add
>>>>>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>>>>>>>> in),
>>>>>>>>>>> and the probe interface in each driver does real probe work as to issue
>>>>>>>>>>> ATI command to ensure only correct driver will be loaded?
>>>>>>>>>> As I said before, the only time IO can be started is when the ->enable()
>>>>>>>>>> callback of the modem plugin is called. Not a second earlier.
>>>>>>>>> But if done after enable() called, from semantic aspect the correct driver has
>>>>>>>> been
>>>>>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
>>>>>>>> probe,
>>>>>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>>>>>>>> vendor
>>>>>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
>>>>>>>> etc..? After
>>>>>>>>> that disable dongle when quit probe()?
>>>>>>>> The probe() callback is for accepting the driver and allocating required
>>>>>>>> local data structures. It is not for IO. And as you can see it has no
>>>>>>>> callback handling like enable() with set_powered().
>>>>>>>>
>>>>>>>> As I said before, no AT commands before enable() has been called. That
>>>>>>>> is how it is suppose to be. We are not changing this.
>>>>>> First, ATI command is working without sending AT+CFUN=1, we could keep
>>>>>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
>>>>>>
>>>>>> Then vendor plugin can be chosen using udevng using Vendor ID, however
>>>>>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
>>>>>> to chose the right vendor plugin with right type.
>>>>>> And if we can't send AT command before enable() time we will face to bag
>>>>>> end e.g. :
>>>>>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
>>>>>> the enable() time.
>>>>>> We are also querying the sim state using polling mechanism that might
>>>>>> fail for CDMA modems that is not using SIM.
>>>>>> What would you suggest here?
>>>>> as I said before, no AT commands before ->enable() callback from the
>>>>> core.
>>>>>
>>>>> The callback ->probe() is for accepting the modem driver binding and
>>>>> allocating modem specific data memory. The callback ->remove() is for
>>>>> cleanup.
>>>>>
>>>>> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
>>>>> entry points for every modem driver. And we need to keep it like this.
>>>> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
>>> the first command has to be always ATE0 +CMEE=1 since otherwise you a)
>>> can not use the permissive syntax parser and b) your error values will
>>> be useless.
>>>
>>> But yes, after that it is fine to send ATI.
>>>
>> Ok
>>
>>>> Then depending on the ATI answer:
>>>>        - tag the huawei modem data with GSM / CDMA type.
>>>>        - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.
>>> What different commands depending on GSM or CDMA do you actually have?
>>>
>>> The AT^RFSWITCH=? is exactly designed to handle if that command is
>>> supported or not. There are plenty of GSM versions of the Huawei that do
>>> not support AT^RFSWITCH. You do need to know if this is supported or
>>> not.
>> I see, so we can send AT^RFSWITCH for both type. If it is not supported,
>> it will be ignored using terminator and then use
>> default AT+CFUN=5.
>>
>>> Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
>>> into offline mode. The only time you send AT+CFUN=1 is if you have
>>> hardware that does not support online/offline distinction. So if this is
>>> true for Huawei CDMA modems, then the obvious questions is why that is
>>> the case? Or is this a bug with our CDMA support not supporting offline
>>> mode.
>>>
>> For the moment, CDMA modems are not using ->set_online() callback (it is
>> automatically set online into modem.c).
>> We will have to make some test to check AT+CFUN=5 is working on CDMA modems.
> The Huawei GSM support is using ->set_online() callback. And so this
> means that you need it also for CDMA support. Otherwise you are back at
> square one.
>
> Actually you need to test the full CDMA support and if it can properly
> handle ->set_online() support. If not, then this needs fixing.
>
> Also I am still not seeing proper support for CDMA SIM atom. We need to
> stop hacking around here. The core functionality needs to be implemented
> first. Without it, the modem plugins can not function properly.
>
> So why are we wasting time with modem details here. If I remember
> correctly, Denis and I made it pretty clear that SIM atom and network
> registration atom is a fundamental requirement for CDMA support.

I agree we need SIM support for CDMA modem.
However we have no info about AT commands to manage the SIM  and its 
file system from the vendor.
Every CDMA modems are Qualcomm based and their drivers are not open-sourced.
Unless you have some specifications concerning CDMA drivers I don't 
think we will be able to manage completely any SIM atom for CDMA modems.

Kind regards,
Guillaume

Kind regards,
Guillaume

Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 8674 bytes --]

Hi Guillaume,

> >>>>>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> According to the result, it might be interesting to send ATI when the
> >>>>>>>>>>>>> constructor plugin is probe by oFono.
> >>>>>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
> >>>>>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
> >>>>>>>>>>>> else besides Huawei or ZTE?
> >>>>>>>>>>> I tried with more dongles from different vendors, as attached table.
> >>>>>>>>>>> The scenarios include:
> >>>>>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >>>>>>>>>>> N(ROM) in table indicates the SIM in ROM already.
> >>>>>>>>>>> ATI command can always return GCAP content in all tests.
> >>>>>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >>>>>>>>>> What about Sierra, Ericsson etc.?
> >>>>>>>>> Just checked Dell 5530 with Ericsson module,
> >>>>>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> >>>>>>>>> But the ATI only returns: D5530
> >>>>>>>> I think it is clear that we need to do our homework here and properly
> >>>>>>>> document the different manufacturers. Someone sending patches for our
> >>>>>>>> doc/ directory?
> >>>>>>> There're many vendors of 3G dongle..
> >>>>>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> >>>>>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> >>>>>>> We can try with them step by step, but can we work out the 2 biggest firstly?
> >>>>>>> Looks ATI command can work for both Huawei and ZTE dongles.
> >>>>>>>
> >>>>>> I agree here, the work to be done over all manufacturers will be
> >>>>>> fastidious and might require a lot of dongles that we don't have currently.
> >>>>>> Maybe we could do as Ying An proposed as we are sure ATI works for
> >>>>>> Huawei and ZTE (at least the ones we have).
> >>>>>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
> >>>>>>
> >>>>>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
> >>>>>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
> >>>>>>>>>>>> should do any kind of IO.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
> >>>>>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
> >>>>>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
> >>>>>>>>>>>>
> >>>>>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >>>>>>>>>>> So if it possible to break the step into several:
> >>>>>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
> >>>>>>>> only,
> >>>>>>>>>>> and add all possible drivers according to that vendor - (for example add
> >>>>>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
> >>>>>>>> in),
> >>>>>>>>>>> and the probe interface in each driver does real probe work as to issue
> >>>>>>>>>>> ATI command to ensure only correct driver will be loaded?
> >>>>>>>>>> As I said before, the only time IO can be started is when the ->enable()
> >>>>>>>>>> callback of the modem plugin is called. Not a second earlier.
> >>>>>>>>> But if done after enable() called, from semantic aspect the correct driver has
> >>>>>>>> been
> >>>>>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
> >>>>>>>> probe,
> >>>>>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
> >>>>>>>> vendor
> >>>>>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
> >>>>>>>> etc..? After
> >>>>>>>>> that disable dongle when quit probe()?
> >>>>>>>> The probe() callback is for accepting the driver and allocating required
> >>>>>>>> local data structures. It is not for IO. And as you can see it has no
> >>>>>>>> callback handling like enable() with set_powered().
> >>>>>>>>
> >>>>>>>> As I said before, no AT commands before enable() has been called. That
> >>>>>>>> is how it is suppose to be. We are not changing this.
> >>>>>> First, ATI command is working without sending AT+CFUN=1, we could keep
> >>>>>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
> >>>>>>
> >>>>>> Then vendor plugin can be chosen using udevng using Vendor ID, however
> >>>>>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
> >>>>>> to chose the right vendor plugin with right type.
> >>>>>> And if we can't send AT command before enable() time we will face to bag
> >>>>>> end e.g. :
> >>>>>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
> >>>>>> the enable() time.
> >>>>>> We are also querying the sim state using polling mechanism that might
> >>>>>> fail for CDMA modems that is not using SIM.
> >>>>>> What would you suggest here?
> >>>>> as I said before, no AT commands before ->enable() callback from the
> >>>>> core.
> >>>>>
> >>>>> The callback ->probe() is for accepting the modem driver binding and
> >>>>> allocating modem specific data memory. The callback ->remove() is for
> >>>>> cleanup.
> >>>>>
> >>>>> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
> >>>>> entry points for every modem driver. And we need to keep it like this.
> >>>> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
> >>> the first command has to be always ATE0 +CMEE=1 since otherwise you a)
> >>> can not use the permissive syntax parser and b) your error values will
> >>> be useless.
> >>>
> >>> But yes, after that it is fine to send ATI.
> >>>
> >> Ok
> >>
> >>>> Then depending on the ATI answer:
> >>>>        - tag the huawei modem data with GSM / CDMA type.
> >>>>        - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.
> >>> What different commands depending on GSM or CDMA do you actually have?
> >>>
> >>> The AT^RFSWITCH=? is exactly designed to handle if that command is
> >>> supported or not. There are plenty of GSM versions of the Huawei that do
> >>> not support AT^RFSWITCH. You do need to know if this is supported or
> >>> not.
> >> I see, so we can send AT^RFSWITCH for both type. If it is not supported,
> >> it will be ignored using terminator and then use
> >> default AT+CFUN=5.
> >>
> >>> Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
> >>> into offline mode. The only time you send AT+CFUN=1 is if you have
> >>> hardware that does not support online/offline distinction. So if this is
> >>> true for Huawei CDMA modems, then the obvious questions is why that is
> >>> the case? Or is this a bug with our CDMA support not supporting offline
> >>> mode.
> >>>
> >> For the moment, CDMA modems are not using ->set_online() callback (it is
> >> automatically set online into modem.c).
> >> We will have to make some test to check AT+CFUN=5 is working on CDMA modems.
> > The Huawei GSM support is using ->set_online() callback. And so this
> > means that you need it also for CDMA support. Otherwise you are back at
> > square one.
> >
> > Actually you need to test the full CDMA support and if it can properly
> > handle ->set_online() support. If not, then this needs fixing.
> >
> > Also I am still not seeing proper support for CDMA SIM atom. We need to
> > stop hacking around here. The core functionality needs to be implemented
> > first. Without it, the modem plugins can not function properly.
> >
> > So why are we wasting time with modem details here. If I remember
> > correctly, Denis and I made it pretty clear that SIM atom and network
> > registration atom is a fundamental requirement for CDMA support.
> 
> I agree we need SIM support for CDMA modem.
> However we have no info about AT commands to manage the SIM  and its 
> file system from the vendor.
> Every CDMA modems are Qualcomm based and their drivers are not open-sourced.
> Unless you have some specifications concerning CDMA drivers I don't 
> think we will be able to manage completely any SIM atom for CDMA modems.

you need to make sure that the core modem state logic with transitions
from pre_sim, post_sim and post_online in conjunction with set_online is
working smoothly for CDMA. And of course not breaking GSM.

I do not see how this can be done properly without having SIM atom
support in place.

Regards

Marcel

Re: The way to install proper driver for 3G dongle in oFono

[Guillaume Zajac]

[-- Attachment #1: Type: text/plain, Size: 9836 bytes --]

Hi Marcel,

>>>>>>>>>>>>>> and what about the case when the SIM card is present, but PIN locked?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> According to the result, it might be interesting to send ATI when the
>>>>>>>>>>>>>>> constructor plugin is probe by oFono.
>>>>>>>>>>>>>>> Thus with +GCAP info we can decide which driver to use.
>>>>>>>>>>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
>>>>>>>>>>>>>> else besides Huawei or ZTE?
>>>>>>>>>>>>> I tried with more dongles from different vendors, as attached table.
>>>>>>>>>>>>> The scenarios include:
>>>>>>>>>>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
>>>>>>>>>>>>> N(ROM) in table indicates the SIM in ROM already.
>>>>>>>>>>>>> ATI command can always return GCAP content in all tests.
>>>>>>>>>>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
>>>>>>>>>>>> What about Sierra, Ericsson etc.?
>>>>>>>>>>> Just checked Dell 5530 with Ericsson module,
>>>>>>>>>>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
>>>>>>>>>>> But the ATI only returns: D5530
>>>>>>>>>> I think it is clear that we need to do our homework here and properly
>>>>>>>>>> document the different manufacturers. Someone sending patches for our
>>>>>>>>>> doc/ directory?
>>>>>>>>> There're many vendors of 3G dongle..
>>>>>>>>> Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
>>>>>>>>> Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
>>>>>>>>> We can try with them step by step, but can we work out the 2 biggest firstly?
>>>>>>>>> Looks ATI command can work for both Huawei and ZTE dongles.
>>>>>>>>>
>>>>>>>> I agree here, the work to be done over all manufacturers will be
>>>>>>>> fastidious and might require a lot of dongles that we don't have currently.
>>>>>>>> Maybe we could do as Ying An proposed as we are sure ATI works for
>>>>>>>> Huawei and ZTE (at least the ones we have).
>>>>>>>> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
>>>>>>>>
>>>>>>>>>>>>>> Also you do realize that the GAtChat object and thus the file descriptor
>>>>>>>>>>>>>> is owned by the modem plugin. The plugin itself is the only one that
>>>>>>>>>>>>>> should do any kind of IO.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
>>>>>>>>>>>>>> then this is a per modem manufacture specific detail. And we rather add
>>>>>>>>>>>>>> a helper function like we did for CPIN polling that makes this easier.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
>>>>>>>>>>>>> So if it possible to break the step into several:
>>>>>>>>>>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
>>>>>>>>>> only,
>>>>>>>>>>>>> and add all possible drivers according to that vendor - (for example add
>>>>>>>>>>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
>>>>>>>>>> in),
>>>>>>>>>>>>> and the probe interface in each driver does real probe work as to issue
>>>>>>>>>>>>> ATI command to ensure only correct driver will be loaded?
>>>>>>>>>>>> As I said before, the only time IO can be started is when the ->enable()
>>>>>>>>>>>> callback of the modem plugin is called. Not a second earlier.
>>>>>>>>>>> But if done after enable() called, from semantic aspect the correct driver has
>>>>>>>>>> been
>>>>>>>>>>> chosen. Indeed the probe() interface in each driver is not doing something to
>>>>>>>>>> probe,
>>>>>>>>>>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
>>>>>>>>>> vendor
>>>>>>>>>>> specific work as query model or network mode by ATI, AT+GCAP command,
>>>>>>>>>> etc..? After
>>>>>>>>>>> that disable dongle when quit probe()?
>>>>>>>>>> The probe() callback is for accepting the driver and allocating required
>>>>>>>>>> local data structures. It is not for IO. And as you can see it has no
>>>>>>>>>> callback handling like enable() with set_powered().
>>>>>>>>>>
>>>>>>>>>> As I said before, no AT commands before enable() has been called. That
>>>>>>>>>> is how it is suppose to be. We are not changing this.
>>>>>>>> First, ATI command is working without sending AT+CFUN=1, we could keep
>>>>>>>> CFUN=1 into enable() as we do some vendor/modem type specific job there.
>>>>>>>>
>>>>>>>> Then vendor plugin can be chosen using udevng using Vendor ID, however
>>>>>>>> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard
>>>>>>>> to chose the right vendor plugin with right type.
>>>>>>>> And if we can't send AT command before enable() time we will face to bag
>>>>>>>> end e.g. :
>>>>>>>> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during
>>>>>>>> the enable() time.
>>>>>>>> We are also querying the sim state using polling mechanism that might
>>>>>>>> fail for CDMA modems that is not using SIM.
>>>>>>>> What would you suggest here?
>>>>>>> as I said before, no AT commands before ->enable() callback from the
>>>>>>> core.
>>>>>>>
>>>>>>> The callback ->probe() is for accepting the modem driver binding and
>>>>>>> allocating modem specific data memory. The callback ->remove() is for
>>>>>>> cleanup.
>>>>>>>
>>>>>>> The callbacks ->enable(), ->disable() and ->set_online() are the only IO
>>>>>>> entry points for every modem driver. And we need to keep it like this.
>>>>>> Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
>>>>> the first command has to be always ATE0 +CMEE=1 since otherwise you a)
>>>>> can not use the permissive syntax parser and b) your error values will
>>>>> be useless.
>>>>>
>>>>> But yes, after that it is fine to send ATI.
>>>>>
>>>> Ok
>>>>
>>>>>> Then depending on the ATI answer:
>>>>>>         - tag the huawei modem data with GSM / CDMA type.
>>>>>>         - send the GSM / CDMA specific AT commands followed by AT+CFUN=1.
>>>>> What different commands depending on GSM or CDMA do you actually have?
>>>>>
>>>>> The AT^RFSWITCH=? is exactly designed to handle if that command is
>>>>> supported or not. There are plenty of GSM versions of the Huawei that do
>>>>> not support AT^RFSWITCH. You do need to know if this is supported or
>>>>> not.
>>>> I see, so we can send AT^RFSWITCH for both type. If it is not supported,
>>>> it will be ignored using terminator and then use
>>>> default AT+CFUN=5.
>>>>
>>>>> Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem
>>>>> into offline mode. The only time you send AT+CFUN=1 is if you have
>>>>> hardware that does not support online/offline distinction. So if this is
>>>>> true for Huawei CDMA modems, then the obvious questions is why that is
>>>>> the case? Or is this a bug with our CDMA support not supporting offline
>>>>> mode.
>>>>>
>>>> For the moment, CDMA modems are not using ->set_online() callback (it is
>>>> automatically set online into modem.c).
>>>> We will have to make some test to check AT+CFUN=5 is working on CDMA modems.
>>> The Huawei GSM support is using ->set_online() callback. And so this
>>> means that you need it also for CDMA support. Otherwise you are back at
>>> square one.
>>>
>>> Actually you need to test the full CDMA support and if it can properly
>>> handle ->set_online() support. If not, then this needs fixing.
>>>
>>> Also I am still not seeing proper support for CDMA SIM atom. We need to
>>> stop hacking around here. The core functionality needs to be implemented
>>> first. Without it, the modem plugins can not function properly.
>>>
>>> So why are we wasting time with modem details here. If I remember
>>> correctly, Denis and I made it pretty clear that SIM atom and network
>>> registration atom is a fundamental requirement for CDMA support.
>> I agree we need SIM support for CDMA modem.
>> However we have no info about AT commands to manage the SIM  and its
>> file system from the vendor.
>> Every CDMA modems are Qualcomm based and their drivers are not open-sourced.
>> Unless you have some specifications concerning CDMA drivers I don't
>> think we will be able to manage completely any SIM atom for CDMA modems.
> you need to make sure that the core modem state logic with transitions
> from pre_sim, post_sim and post_online in conjunction with set_online is
> working smoothly for CDMA. And of course not breaking GSM.
>
> I do not see how this can be done properly without having SIM atom
> support in place.

We can have 3 states in CDMA (specified in Huawei documentation):
1: Valid UIM card status
240: ROMSIM version
255: UIM card not exist

Currently the problem is we have some CDMA modems with ROMSIM e.g. 
embedded SIM.
When we send AT+CPIN? it answers CME ERROR Sim not inserted.

I discussed with Denis about this issue and he recommended me not to 
create SIM atom when status is ROMSIM version.

However we have some other dongles with UIM whose state is 1: Valid UIM 
card status.
They support some AT commands from "atmodem" drivers (AT+CPIN and 
AT+CIMI only) but none to read the file system.
All the dongles we have let are not PIN locked:
AT+CPIN? answer is +CPIN: READY.

If you want a SIM atom it could be used for PIN management only but as I 
told you I have met none for the moment.
Concerning ->set_online() callback, it can work without SIM atom but we 
have to modify it into the unified plugin.

Even with SIM atom for CDMA modems, we will never be able to read the 
UIM file system (AT+CRSM is not supported).
We can only expect some support from manufacturers to support UIM file 
system management.

Kind regards,
Guillaume


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 13433 bytes --]