RE: Using ofono HFP

[Zhang, Zhenhua]

Hi Silva,

Moises Silva wrote:
> On Tue, Sep 28, 2010 at 10:50 PM, Denis Kenzior
>  wrote:
>> The second descriptor (what ipc.c and ipc.h deal with) is used to
>> pass the SCO fd to PulseAudio or gStreamer.  This fd is used for
>> Audio. Marcel or Johan might know better, but I think the reason for
>> ipc.c and ipc.h was that DBus did not support fd-passing at the time
>> BlueZ audio integration work was being done.
> 
> Thanks for the help.
> 
> I have a few more questions. I got my own small app connecting to the
> audio server and I am able to read/write fromt he sco socket.
> 
> However it seems the MTU is hard-coded int audio/unix.c to 48.
> 
> Where does this 48 comes from? I come from the TDM open source world,
> where typical configuration for TDM devices is 160 (160 bytes of
> alaw/ulaw, 160 samples, each 20ms).
> 
> Is there any way to change that socket MTU to 160 or 320 (depending if
> it's either SLN16 or alaw/mulaw?

You might want to raise your question on bluez's IRC or mailing list. oFono 
takes care of call control logic while BlueZ/PulseAudio takes care of SCO audio 
packets.

> How can I know the format for the audio?

I think it should be PCM raw data from SCO packets but it could wrong maybe.

> I'll keep digging in pulseaudio to see if I find the answer ...
> 
> Moises Silva
> Senior Software Engineer
> Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON
> L3R 9R6 Canada t. 1 905 474 1990 x128 | e. m...@sangoma.com
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Using ofono HFP

[Zhang, Zhenhua]

Hi Silva,

Moises Silva wrote:
> On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua
>  wrote:
>> 
>> Right. See bluez/audio/unix.c for BlueZ part SCO code that
> cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX
>> type socks.
> 
> This put me in the right direction and I have a clearer idea of how to
> do it. I found odd though that it seems I need to copy the ipc.c and
> ipc.h files into my own app. Any reason they are not part of
> libbluetooth API? 

Marcel may know the answer for your question.

> Another thing that puzzles me is that supposedly DBUS >= 1.3 is needed
> to be able to pass file descriptors. However as you pointed out and
> per ipc.c the file descriptor is sent using a unix socket. Why the
> need for DBUS file descriptor passing?

DBUS file descriptor passing is used in BlueZ/oFono communication, to pass 
RFCOMM port file handler to another process. I guess dbus 1.3 has some wrapper 
for such file descriptor passing magic.

Marcel, any comments on Silva's question?

> I'm gonna start testing right away and most likely will be back with
> more questions (like what's the audio format, sampling rate and such)
> :-) 
> 
> Thanks,
> 
> --
> Moises Silva
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Using ofono HFP

[Zhang, Zhenhua]

Hi Silva, 

From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On 
Behalf Of Moises Silva
Sent: Tuesday, September 28, 2010 10:45 AM
To: ofono@ofono.org
Subject: Re: Using ofono HFP


On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua 
 wrote:


Right. See bluez/audio/unix.c for BlueZ part SCO code that 
cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX type socks.




Thanks a lot for the additional help. I just setup a quick wiki page to 
start documenting this: http://ofono.org/wiki/hands-free-profile

It's small and crappy, but it's a start. I will keep improving it as I 
go.

[Zhenhua] I have some experience on HFP as I am main contributor of HFP in the 
oFono. Would you mind me to update your wiki page to add detailed information 
related with HFP?

Btw, Could you send plain text format mail to the mailing list in the future as 
it's an formal upstream project. I tried but I cann't reply your mail propertly.

Thanks,
Zhenhua

Regards,

-
Moises Silva

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Using ofono HFP

[Zhang, Zhenhua]

Hi Moises,

Denis Kenzior wrote:
> Hi Moises,
> 
>> I was advised by padovan on IRC that I should try dbus >= 1.3 ... I
>> am going to try that today, I was putting that off cuz this seemed
>> like a lower level issue and upgrading dbus seemed like non-trivial
>> since many things depend on dbus and fedora 13 does not seem to
>> include rpm for dbus >= 1.3
> 
> Neither oFono nor BlueZ will enable the plugins for HFP support unless
> DBus-1.3 is installed (or alternatively a hacked dbus-1.2 with file
> descriptor passing support) 

Denis is right. For example, my ubuntu 10.04 has dbus-1.3.0 so HFP works 
smoothly on my laptop. I remember there's someone has a hacked dbus-1.2 with fd 
passing support. It does work but I would recommend you use dbus-1.3.

>> 
>> Can I somehow to try ofono connect to my cell and not the other way
>> around? 
> 
> The connection initiator is actually irrelevant.  You just need to
> make sure that BlueZ has paired with your device and the
> HandsfreeGateway interface is created for your device.
> 
>> The final goal here is NOT use this with pulseaudio, but rather have
>> access to the SCO socket so I can manipulate the audio.
> 
> If you want this, then you will need to eventually write your
> own plugin
> that will manage the RFCOMM and SCO sockets.  Today, BlueZ
> does this part...

Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with 
pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX type socks.

> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 0/1] Patch Description

[Zhang, Zhenhua]

Hi,

Yang Gu wrote:
> Phonesim is most of time a convenient way to test oFono. For example,
> it can be used to test MO call, as well as MT call. 
> And talking about test area, test automation is quite important
> regarding to both efficiency and effectiveness. In the test of MO
> call, scripts can be used to interact with oFono via D-Bus to make
> test automation possible. However, in the test of MT call, currently
> we have to enter the caller number and click some button in Phonesim
> GUI to simulate an incoming call, which makes test automation
> unrealistic. This patch is to enable Qt script (JavaScript following
> ECMAScript spec) in Phonesim, so that we can have some script control
> its GUI conveniently, and satisfy the test automation.   
> 
> With this patch, Phonesim can work in the following way:
> 1. It observes some specific directory (/tmp/scripts) to see if there
> is some test scripts added. 
> 2. Once Phonesim finds a new test script is added, it will parse and
> execute the script. 
> 3. You may add more and more test scripts to the specific directory
> with your test goes on. 
> 
> Below are two examples:
> # call.js (Simulate a MT call)
> tabRegistration.gbIncomingCall.leCaller.text = "12345";
> tabRegistration.gbIncomingCall.pbIncomingCall.click();
> 
> This script will help you enter the caller number as "12345", and
> click "Call" button in Phonesim GUI. Once this script is copied to
> the observed directory, oFono will get an incoming call.  
> 
> # sms.js (Simulate a MT sms)
> tabSMS.gbMessage1.leMessageSender.text = "Yang";
> tabSMS.gbMessage1.leSMSClass.text = "1";
> tabSMS.gbMessage1.teSMSText.setPlainText("This message is sent
> automatically from Phonesim"); 
> tabSMS.gbMessage1.pbSendSMSMessage.click();
> 
> This script will help you fill the sms sender, class, text, and then
> click the "Send Message" button for you. Once it's added into the
> specific directory, oFono will get an incoming message.  
> 
> Don't know if this is the best way to make Phonesim support test
> automation. So comments are welcome:) 

It's awesome! I tried the patch and simply copy call.js to /tmp/scripts and it 
makes a call to oFono like a magic. ;-)

> -
> Yang Gu (1):
>   Enable Qt Script
> 
>  configure.ac|2 +-
>  src/control.cpp |   60
>  +++ 2 files
> changed, 61 insertions(+), 1 deletions(-) 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/1] Add support to enable/disable specific plugin

[Zhang, Zhenhua]

Hi Holtmann,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> Support to load or not load specific plugin when ofono is started.
>> E.g., use 'ofonod -P hfp' to disable hfp plugin.
>> ---
>>  src/main.c |   11 ++-
>>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> patch has been applied. I did all the hard work - just forgot to hook
> it up properly ;)

Thanks.

>> -__ofono_plugin_init(NULL, NULL);
>> +__ofono_plugin_init(option_plugin, option_noplugin); +
>> +g_free(option_plugin);
>> +g_free(option_noplugin);
> 
> Please also send a ConnMan patch to fix the memory leak that ConnMan
> has here actually.

ConnMan does free the string propertly. So we don't need more fixes. :-)

Regards,
Zhenhua

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/1] hfp: Add faked sim driver to support SIM ready

[Zhang, Zhenhua]

Hi, Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
> On 08/30/2010 04:50 AM, Zhenhua Zhang wrote:
>> HFP modem doesn't have IMSI at all. In order to notify SIM ready to
>> the core, we create a special sim driver with a faked IMSI number.
> 
> Can you try after commit 88024972df46d4ababbaf39354615e8a8d603cfc?  I
> added magic which will skip sim_ready stuff completely for modems
> that do not add a sim atom. 

Yes. Your patch works well and fixes the problem in a generic way.

> Regards,
> -Denis

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About ppp_receive()

[Zhang, Zhenhua]

Hi Steven,

Steven wrote:
> Hi Zhenhua,
> 
> Zhang, Zhenhua wrote:
>> Hi Steven,
>> 
>> Steven wrote:
>>> Hi Zhenhua
>>> 
>>> Zhang, Zhenhua wrote:
>>>> Hi Steven,
>>>> 
>>>> Steven wrote:
>>>>> Hi,
>>>>> 
>>>>> In function ppp_receive, we first check the protocol type of this
>>>>> frame like: 
>>>>> 
>>>>>   guint16 protocol = ppp_proto(buf);
>>>>> 
>>>>> and here we assumed the length of the protocol field is 16 bits,
>>>>> but in RFC 1661, the protocol field should be one or two octets.
>>>>> 
>>>>> "The Protocol field is one or two octets, and its value identifies
>>>>> the datagram encapsulated in the Information field of the packet."
>>>>> 
>>>>> why we given the assumption that protocol field is 16 bit length?
>>>> First I am not ppp expert. :-).
>>>> 
>>>> If you take look at pppd source code, main.c, get_input() also
>>>> always fetch two bytes 'protocol' for struct protent as well.
>>>> 
>>>> Can you give a case we failed in our ppp stack?
>>> If you interested in this topic, you can reference RFC 1661 Section
>>> 6.5,
>>> which said
>>> 
>>> --
>>> This Configuration Option provides a method to negotiate the
>>> compression of the PPP Protocol field. By default, all
>>> implementations MUST transmit packets with two octet PPP Protocol
>>> fields. PPP Protocol field numbers are chosen such that some values
>>> may be compressed into a single octet form which is clearly
>>> distinguishable from the two octet form. This Configuration
>>> Option is sent to inform the peer that the implementation can
>>> receive such single octet Protocol fields.
>>> -
>>> 
>>> In our current source code, because we only negotiate two
>>> configuration options - REQ_OPTION_MRU and REQ_OPTION_ACCM. so it's
>>> okey for our PPP stack.
>> 
>> Yes. It's handled in the LCP layer. The code is majorly implemented
>> by Kristen and Denis. Maybe they could have more comments on that. 
>> 
>>> But some carriers, like China Telecom or Sprint Network etc, will
>>> support the full configuration
>>> options(Magic-Number,Protocol-Field-Compression,Address-and-Control-Field-Compression),
>>> So if PFC option is used ,our code will got wrong with
>>> ppp_receive(). 
>> 
>> Agree, we don't have pcompress, accompression like pppd yet. So
>> patches are welcome to improve that part. 
>> 
>> Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.
>> 
> 
> I will check it.
> 
>>> We should first check if PPP protocol field is compressed or not,
>>> and then get the right protocol value to form a 16 bits protocol
>>>   field, and pass this value to the rest functions.
>>> 
>>> Because of my company's security policy ,I can't provide a patch for
>>> this issue. But i can provide a method for doing this. Here it is.
>> 
>> I don't understand why having such policy at all. Your code
>> defintely won't leak any IP since we all follow with the standard
>> spec.  
>> 
> 
> 
> In my company, i can't using git, usb or any other thing which contact
> with the outer world, but the only thing i can use to contact with the
> outer world is MY THUNDERBIRD!!!:(, It's a awful thing.
> 
> Maybe i can commit my patch when i go home:), if my son doesn't annoy
> me. 

Sure. Git is so powerful that you can definitely work any place you like to. 
You only need the network when you do 'git pull' and 'git send-email'. ;-)

>>> First byte of PPP protocol field may be compressed, if the LS bit
>>> is 1 then this indicates that the upper protocol us compressed,
>>> because the upper byte should be even, the lower byte should be odd.
>>> 
>>>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>>>   support a compressed protocol field. Is there anything
>>>>> difference between GSM and CDMA? 
>>>>> 
>>>>> B.R
>>>>> 
>>>>> Steven
>>> B.R
>>> 
>>> Steven
> 
> 
> ---
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About ppp_receive()

[Zhang, Zhenhua]

Hi Steven,

Steven wrote:
> Hi Zhenhua
> 
> Zhang, Zhenhua wrote:
>> Hi Steven,
>> 
>> Steven wrote:
>>> Hi,
>>> 
>>> In function ppp_receive, we first check the protocol type of this
>>> frame like:
>>> 
>>>   guint16 protocol = ppp_proto(buf);
>>> 
>>> and here we assumed the length of the protocol field is 16 bits,
>>> but in RFC 1661, the protocol field should be one or two octets.
>>> 
>>> "The Protocol field is one or two octets, and its value identifies
>>> the datagram encapsulated in the Information field of the packet."
>>> 
>>> why we given the assumption that protocol field is 16 bit length?
>> 
>> First I am not ppp expert. :-).
>> 
>> If you take look at pppd source code, main.c, get_input() also
>> always fetch two bytes 'protocol' for struct protent as well. 
>> 
>> Can you give a case we failed in our ppp stack?
> 
> If you interested in this topic, you can reference RFC 1661 Section
> 6.5, 
> which said
> 
> --
> This Configuration Option provides a method to negotiate the
> compression of the PPP Protocol field. By default, all
> implementations MUST transmit packets with two octet PPP Protocol
> fields.
> PPP Protocol field numbers are chosen such that some values may be
> compressed into a single octet form which is clearly
> distinguishable from the two octet form. This Configuration
> Option is sent to inform the peer that the implementation can
> receive such single octet Protocol fields.
> -
> 
> In our current source code, because we only negotiate two
> configuration 
> options - REQ_OPTION_MRU and REQ_OPTION_ACCM. so it's okey for our PPP
> stack.

Yes. It's handled in the LCP layer. The code is majorly implemented by Kristen 
and Denis. Maybe they could have more comments on that.

> But some carriers, like China Telecom or Sprint Network etc, will
> support the full configuration
> options(Magic-Number,Protocol-Field-Compression,Address-and-Control-Field-Compression),
> So if PFC option is used ,our code will got wrong with ppp_receive().

Agree, we don't have pcompress, accompression like pppd yet. So patches are 
welcome to improve that part.

Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.

> We should first check if PPP protocol field is compressed or not, and
> then get the right protocol value to form a 16 bits protocol field,
>   and pass this value to the rest functions.
> 
> Because of my company's security policy ,I can't provide a patch for
> this issue. But i can provide a method for doing this. Here it is.

I don't understand why having such policy at all. Your code defintely won't 
leak any IP since we all follow with the standard spec.

> First byte of PPP protocol field may be compressed, if the LS bit is 1
> then this indicates that the upper protocol us compressed, because the
> upper byte should be even, the lower byte should be odd.
> 
>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>   support a compressed protocol field. Is there anything difference
>>> between GSM and CDMA?
>>> 
>>> B.R
>>> 
>>> Steven
> 
> B.R
> 
> Steven
> ---
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About ppp_receive()

[Zhang, Zhenhua]

Hi Steven,

Steven wrote:
> Hi,
> 
> In function ppp_receive, we first check the protocol type of this
> frame 
> like:
> 
>   guint16 protocol = ppp_proto(buf);
> 
> and here we assumed the length of the protocol field is 16 bits, but
> in 
> RFC 1661, the protocol field should be one or two octets.
> 
> "The Protocol field is one or two octets, and its value identifies
> the datagram encapsulated in the Information field of the packet."
> 
> why we given the assumption that protocol field is 16 bit length?

First I am not ppp expert. :-).

If you take look at pppd source code, main.c, get_input() also always fetch two 
bytes 'protocol' for struct protent as well.

Can you give a case we failed in our ppp stack?

Thanks.
Zhenhua

> In CDMA 2000 environment, just as the Sprint Network, PPP should
>   support a compressed protocol field. Is there anything difference
> between GSM 
> and CDMA?
> 
> B.R
> 
> Steven
> 
> ---
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About Connection between PPP and linux Sockets

[Zhang, Zhenhua]

Hi Steven,

Steven wrote:
> Hi Zhang,
> 
> Zhang, Zhenhua wrote:
>> Hi Steven,
>> 
>> Steven wrote:
>>> Hi Zhang
>>> Zhang, Zhenhua wrote:
>>>> Hi Marcel,
>>>> 
>>>> Marcel Holtmann wrote:
>>>>> Hi Steven,
>>>>> 
>>>>>> I have a little question just as the title said?
>>>>>> In Ofono how to connect PPP to Linux socket, when we receive
>>>>>> packet from network, how the packet go through the kernel to
>>>>>> application？ 
>>>>>> 
>>>>>> modem -->PPP-->? --> linux kernel(network part)--> socket -->
>>>>>> application?
>>>>> it is more like this:
>>>>> 
>>>>> modem -> TTY -> PPP -> TUN/TAP -> Kernel Net-Stack -> socket ->
>>>>> application. 
>>>>> 
>>>>> With the TTY being in kernel, the PPP being in userspace, and
>>>>> TUN/TAP etc. begin in the kernel again.
>>>>> 
>>>>> A future enhancement is to use the kernel PPP layer, but we
>>>>> haven't gotten there yet.
>>>> I am interested to know how could we use kernel PPP layer instead
>>>> of gatppp. Shall we add this item into our TODO?
>>>> 
>>> Maybe you can reference to RILD in Android, it used kernel PPP.
>> 
>> Thanks. Will take a look then.
> 
> This information is a good start point.
> http://www.devdiv.net/viewthread-26543
> 
> But only for Chinese people:(

Thanks. I have read this before. ;-). The original article is from maxleng's 
blog:

http://blog.csdn.net/maxleng/archive/2010/05/10/5576509.aspx

However, it's just a big picture about phone stack in Android. It said nothing 
about how Android works with kernel PPP layer.

> B.R
> 
> Steven
> 
> ---
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---
> ___   
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About Connection between PPP and linux Sockets

[Zhang, Zhenhua]

Hi Steven,

Steven wrote:
> Hi Zhang
> Zhang, Zhenhua wrote:
>> Hi Marcel,
>> 
>> Marcel Holtmann wrote:
>>> Hi Steven,
>>> 
>>>> I have a little question just as the title said?
>>>> In Ofono how to connect PPP to Linux socket, when we receive packet
>>>> from network, how the packet go through the kernel to application？
>>>> 
>>>> modem -->PPP-->? --> linux kernel(network part)--> socket -->
>>>> application?
>>> it is more like this:
>>> 
>>> modem -> TTY -> PPP -> TUN/TAP -> Kernel Net-Stack -> socket ->
>>> application. 
>>> 
>>> With the TTY being in kernel, the PPP being in userspace, and
>>> TUN/TAP etc. begin in the kernel again.
>>> 
>>> A future enhancement is to use the kernel PPP layer, but we haven't
>>> gotten there yet.
>> 
>> I am interested to know how could we use kernel PPP layer instead of
>> gatppp. Shall we add this item into our TODO? 
>> 
> 
> Maybe you can reference to RILD in Android, it used kernel PPP.

Thanks. Will take a look then.
 
> B.R
> 
> Steven
> 
> ---
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---
> ___   
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: About Connection between PPP and linux Sockets

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Steven,
> 
>> I have a little question just as the title said?
>> In Ofono how to connect PPP to Linux socket, when we receive packet
>> from network, how the packet go through the kernel to application？
>> 
>> modem -->PPP-->? --> linux kernel(network part)--> socket -->
>> application? 
> 
> it is more like this:
> 
> modem -> TTY -> PPP -> TUN/TAP -> Kernel Net-Stack -> socket ->
> application. 
> 
> With the TTY being in kernel, the PPP being in userspace, and TUN/TAP
> etc. begin in the kernel again.
> 
> A future enhancement is to use the kernel PPP layer, but we haven't
> gotten there yet.

I am interested to know how could we use kernel PPP layer instead of gatppp. 
Shall we add this item into our TODO?
 
> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Terminating emergency calls

[Zhang, Zhenhua]

Hi Sjur,

Sjur Br?ndeland wrote:
> Denis Kenzior  wrote:
>>> I thought of one more issue with voice calls.
>>> I don't think it is safe to to terminate emergency calls using
>>> release_specific, AT+CHLD=1X. At least this don't work for STE
>>> modems. 
>>> 
>>> I suggest calls in state active should be terminated using
>>> hangup_all or hangup_active. What do you think?
>> 
>> So in the case of a single call, the emergency call will be
>> terminated using hangup_all / hangup_active anyway.  I have relaxed
>> the single call restriction for active calls when hangup_active is
>> provided by the 
>> driver.  Refer to c7b13ec2fe664b122216a312f2442c9ca26f5f43
> 
> Yes, it seems to be ok for voicecall_hangup, but in manager_hangup_all
> the active call is still terminated with release_specific in
> voiceall_release_next.
> This implies that if you have an emergency call and terminate it with
> manager_hangup_all AT+CHLD=1X still will be used, right?
> 
> I suggest we change voicecall_release_next like this:
> 
>   if (vc->driver->hangup_active != NULL &&
>   (call->call->status == CALL_STATUS_ALERTING ||
>   call->call->status == CALL_STATUS_DIALING ||
> + call->call->status == CALL_STATUS_ACTIVE ||
>   call->call->status == CALL_STATUS_INCOMING))
>   vc->driver->hangup_active(vc, multirelease_callback, vc);
>   else
>   vc->driver->release_specific(vc, call->call->id,
>   multirelease_callback, vc);
> 
>> For mpty calls this gets tricky.  I'd like some answers to these
>> questions: 
>> 
>> - Can Emergency calls participate in mpty?
> 
> I have to verify this with some of my colleagues, but I am pretty sure
> emergency calls cannot be applied to the AT+CHLD command. i.e. they
> cannot be part of mpty.

If emergency calls cannot be part of mpty call, we can use either hangup_all or
hangup_active as Denis said. However, your suggested fix will break multiparty 
call
scenario since multiparty_hangup calls voicecall_release_next as well. Maybe we
should use call->type to indicate whether it's an emergy call. It looks to me 
that the
type flag in struct ofono_call hasn't been used yet. Correct me if I am wrong.

> 
> Regards
> Sjur
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 10/16] gprs: Add ofono_gprs_create_context method

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> DUN server may create one primary context if none of contexts
>> existing on the GPRS atom.
> 
> so Denis and I had a chat about this. And we agreed that oFono core
> should just create one Internet context if none exists. If the plugin
> driver registers a GPRS atom, we should just create one context
> anyway. ConnMan requires this anyway and it makes sense. We can also
> go one step ahead and fail to remove this default Internet context.
> It should be present all the time.

Thanks for update. I will update my patch to keep this context alive after
DUN client disconnect from us.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 04/16] emulator: Add APIs to send GAtServer result

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> Defines APIs to send final/intermediate/unsolicited result to DUN
>> client. ---
>>  include/emulator.h |2 ++
>>  src/emulator.c |   28 
>>  src/ofono.h|   11 +++
>>  3 files changed, 41 insertions(+), 0 deletions(-)
>> 
>> diff --git a/include/emulator.h b/include/emulator.h
>> index 29e87b9..2a45c65 100644
>> --- a/include/emulator.h
>> +++ b/include/emulator.h
>> @@ -36,6 +36,8 @@ enum ofono_emulator_status {
>>  OFONO_EMULATOR_STATUS_DESTROY,
>>  };
>> 
>> +enum _GAtServerResult;
>> +
> 
> this is not good. It should not be needed outside of GAtChat. Why not
> just include gatserver.h?

My original purpose is to avoid including another gatserver header in .h file.
So far, we don't include gatchat.h/gatserver.h in oFono core header file.

> And in addition the _GAt declaration should never be used. Why not use
> the typedef one?

If we allow to include gatserver.h, this problem is gone. We do have typedef
in gatserver.h.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 0/10] Unregister AT notifiers when removing drivers

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> This series unregister AT notifiers in removing various AT modem
>> drivers when modem goes to offline mode. Please review them. 
> 
> just a heads up here that Denis and I talked about this. And we are
> going to fix this inside GAtChat in the background for you. Trying to
> fix this single handed in every atom driver is wrong.
> 
> This approach creates too much of a maintenance burden. And additional
> code complexity and memory footprint doing it this way. So we have to
> tackle it in a central place. And that is GAtChat.

Thanks for update. Yes. The fix by Denis looks smart and make sense to
me. By using fa?ade pattern, we don't require user to track
register/unregister of AT notifers any more.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Crash in network-registration.c/creg_notify() when receiving unsolicited "+CREG: 0"

[Zhang, Zhenhua]

Hi Emmanuel,

Berthier, Emmanuel wrote:
> Hi,
> 
> I use ofono 0.25 and encounter a segmentation fault when
> trying to put the modem OffLine (flight mode).
> 
> The AT command sent to modem is:
> 
> AT+CFUN=4
> 
> The modem replies with:
>OK
>+CREG=0
> 
> Then, in creg_notify(), the user_data points to uninitialized
> (deallocated?) memory and access to “nd->vendor” causes the crash.
> 

I might know where is the problem. We should unregister all notifies from 
gatchat in at_netreg_remove. Same for gprs and other drivers as well. 
Currently, we don't do that well. I will send patches soon.

> 
> Effectivelly, user_data pointer is the one set by
> at_creg_set_cb(), and is freed by
> g_at_chat_finish_command()/at_command_destroy().
> 
> So, it seems that ofono does not manage unsolicited +CREG command.
> 
> 
> 
> What’s your feeing?
> 
> 
> 
> Thanks.
> 
> 
> 
> Emmanuel.
> 
> 
> 
> -
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196
> Meudon Cedex, France Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Huawei EM770W SIM card issues

[Zhang, Zhenhua]

Hi Florian,

Florian Mayer (Mayer Electronics) wrote:
> Hello,
> 
> we encountered the following problem with the EM770W: If the
> SIM card is
> plugged in after our test system is powered on, it is not
> recognised in
> ofono. Even if we restart ofonod after plugging in the SIM
> card. We use
> the 2.6.35~rc5 kernel from Meego 1.1 trunk because we encountered
> problems in the option driver with Kernel 2.6.33.3 (the communication
> got stuck from time to time). For ofono we use the latest 0.26 and
> for connman 0.55. 
> 
> Is this a bug relted to ofono or a limitation of the Huawei hardware?

I watch oFono chat with EM770W modem. If I restart ofonod after plugging
in the SIM card. We have:

ofonod[7871]: Pcui:< \r\n^SYSINFO:1,0,1,5,255,,4\r\n\r\nOK\r\n
ofonod[7871]: Pcui:> AT+CGMI\r
ofonod[7871]: Pcui:< \r\nhuawei\r\n\r\nOK\r\n
ofonod[7871]: Pcui:> AT+CGMM\r
ofonod[7871]: Pcui:< \r\nEM770W\r\n\r\nOK\r\n
ofonod[7871]: Pcui:> AT+CGMR\r
ofonod[7871]: Pcui:< \r\n11.126.08.01.00\r\n\r\nOK\r\n
ofonod[7871]: Pcui:> AT+CGSN\r
ofonod[7871]: Pcui:< \r\n357030020291346\r\n\r\nOK\r\n
ofonod[7871]: Pcui:< \r\n^BOOT:20291346,0,0,0,20\r\n

ofonod[7897]: Pcui:< \r\n^RSSI:15\r\n\r\n^SRVST:1\r\n
ofonod[7897]: Pcui:< \r\n^MODE:5,4\r\n

However, if I powered on modem with SIM card inserted, I have:

ofonod[7960]: Pcui:> AT+CGSN\r
ofonod[7960]: Pcui:< \r\n357030020291346\r\n\r\nOK\r\n
ofonod[7960]: Pcui:< \r\n^RSSI:1\r\n
ofonod[7960]: Pcui:< \r\n^BOOT:20291346,0,0,0,20\r\n
ofonod[7960]: Pcui:< \r\n^MODE:3,3\r\n\r\n^SIMST:1\r\n
ofonod[7960]: Pcui:> AT+CRSM=176,28590,0,0,1\r
ofonod[7960]: Pcui:< \r\n^SRVST:2\r\n\r\n^MODE:3,3\r\n
ofonod[7960]: Pcui:< \r\n+CRSM: 144,0,"03"\r\n\r\nOK\r\n
ofonod[7960]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 1
ofonod[7960]: Pcui:> AT+CPIN?\r
ofonod[7960]: Pcui:< \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[7960]: drivers/atmodem/sim.c:at_cpin_cb() crsm_pin_cb: READY

So looks like Huawei modem doesn't send us ^SIMST unsolicited
notification in the first case.

> Regards
> Florian Mayer
> Mayer Electronics
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/3] Bluetooth DUN modem prototype

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Add a still dummy DUN code, now it can only creates and removes
> modems. 
> The DUN plugin follows the HFP one a lot, the is basics a copy of some
> HFP plugin's parts.
> ---
>  Makefile.am |6 ++
>  drivers/dunmodem/dunmodem.c |   51 +++
>  drivers/dunmodem/dunmodem.h |   29 ++
>  plugins/bluetooth.c |   11 +++
>  plugins/bluetooth.h |2 +
>  plugins/dun.c   |  202
>  +++ 6 files changed, 301
>  insertions(+), 0 deletions(-) create mode 100644
>  drivers/dunmodem/dunmodem.c create mode 100644
>  drivers/dunmodem/dunmodem.h create mode 100644 plugins/dun.c
> 
> diff --git a/Makefile.am b/Makefile.am
> index e256841..a6f2bff 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -179,6 +179,9 @@ builtin_sources += drivers/atmodem/atutil.h \
>   drivers/hfpmodem/network-registration.c \
>   drivers/hfpmodem/call-volume.c
> 
> +builtin_modules += dunmodem
> +builtin_sources += drivers/dunmodem/dunmodem.h
> drivers/dunmodem/dunmodem.c +
>  builtin_modules += mbmmodem
>  builtin_sources += drivers/atmodem/atutil.h \
>   drivers/mbmmodem/mbmmodem.h \
> @@ -242,6 +245,9 @@ builtin_sources += plugins/bluetooth.c
>  plugins/bluetooth.h builtin_modules += hfp
>  builtin_sources += plugins/hfp.c plugins/bluetooth.h
> 
> +builtin_modules += dun
> +builtin_sources += plugins/dun.c
> +
>  builtin_modules += palmpre
>  builtin_sources += plugins/palmpre.c
> 
> diff --git a/drivers/dunmodem/dunmodem.c b/drivers/dunmodem/dunmodem.c
> new file mode 100644
> index 000..8658bee
> --- /dev/null
> +++ b/drivers/dunmodem/dunmodem.c
> @@ -0,0 +1,51 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
> + *  Copyright (C) 2010 Gustavo F. Padovan 
> + *
> + *  This program is free software; you can redistribute it and/or
> modify + *  it under the terms of the GNU General Public License
> version 2 as + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 
> 02110-1301  USA + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define OFONO_API_SUBJECT_TO_CHANGE
> +#include 
> +#include 
> +#include 
> +
> +#include "dunmodem.h"
> +
> +static int dunmodem_init(void)
> +{
> + return 0;
> +}
> +
> +static void dunmodem_exit(void)
> +{
> +}
> +
> +OFONO_PLUGIN_DEFINE(dunmodem, "Dial-up Networking Driver", VERSION,
> + OFONO_PLUGIN_PRIORITY_DEFAULT, dunmodem_init, dunmodem_exit)
> +
> diff --git a/drivers/dunmodem/dunmodem.h b/drivers/dunmodem/dunmodem.h
> new file mode 100644
> index 000..6bbf7b9
> --- /dev/null
> +++ b/drivers/dunmodem/dunmodem.h
> @@ -0,0 +1,29 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2010 Gustavo F. Padovan 
> + *
> + *  This program is free software; you can redistribute it and/or
> modify + *  it under the terms of the GNU General Public License
> version 2 as + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 
> 02110-1301  USA + *
> + */
> +#ifndef __DUN_MODEM_H__
> +#define __DUN_MODEM_H__
> +
> +struct dun_data {
> + char *dun_path;
> +};
> +
> +#endif
> +
> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
> index 5a85eaa..b7ec0d3 100644
> --- a/plugins/bluetooth.c
> +++ b/plugins/bluetooth.c
> @@ -218,6 +218,9 @@ static void has_uuid(DBusMessageIter *array,
>   gpointer user_data) if (!strcasecmp(uuid, HFP_AG_UUID))
>   *profiles |= HFP_AG;
> 
> + if (!strcasecmp(uuid, DUN_GW_UUID))
> + *profiles |= DUN_GW;
> +
>   dbus_message_iter_next(&value);
>   }
>  }
> @@ -276,6 +279,14 @@ static void device_properties_cb(DBusPendingCall
>   *call, gpointer user_data) profile->create(path, device_addr,
>   adapter_addr, alias); }
> 
> + if ((have_uuid & D

RE: [PATCH 2/3] Add dun_enable() function

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> dun_enable() is called by setting the Powered property to true.
> It creates a rfcomm link throught the BlueZ Serial API.
> ---
>  drivers/dunmodem/dunmodem.h |1 +
>  plugins/bluetooth.h |1 +
>  plugins/dun.c   |   61
>  +- 3 files changed, 61
> insertions(+), 2 deletions(-) 
> 
> diff --git a/drivers/dunmodem/dunmodem.h b/drivers/dunmodem/dunmodem.h
> index 6bbf7b9..16eb9e7 100644
> --- a/drivers/dunmodem/dunmodem.h
> +++ b/drivers/dunmodem/dunmodem.h
> @@ -23,6 +23,7 @@
> 
>  struct dun_data {
>   char *dun_path;
> + const char *rfcomm;
>  };
> 
>  #endif
> diff --git a/plugins/bluetooth.h b/plugins/bluetooth.h
> index 09e6efa..c20b36d 100644
> --- a/plugins/bluetooth.h
> +++ b/plugins/bluetooth.h
> @@ -22,6 +22,7 @@
>  #define  BLUEZ_MANAGER_INTERFACE BLUEZ_SERVICE ".Manager"
>  #define  BLUEZ_ADAPTER_INTERFACE BLUEZ_SERVICE ".Adapter"
>  #define  BLUEZ_DEVICE_INTERFACE  BLUEZ_SERVICE ".Device"
> +#define  BLUEZ_SERIAL_INTERFACE  BLUEZ_SERVICE ".Serial"
> 
>  #define HFP_AG_UUID  "111F--1000-8000-00805F9B34FB"
>  #define DUN_GW_UUID  "1103--1000-8000-00805F9B34FB"
> diff --git a/plugins/dun.c b/plugins/dun.c
> index 9b4288e..7dc8422 100644
> --- a/plugins/dun.c
> +++ b/plugins/dun.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -138,10 +139,66 @@ static void dun_remove(struct ofono_modem
>   *modem) ofono_modem_set_data(modem, NULL);
>  }
> 
> +static void dun_connect_reply(DBusPendingCall *call, gpointer
> user_data) +{
> + struct ofono_modem *modem = user_data;
> + struct dun_data *data = ofono_modem_get_data(modem);
> + const char *dev;
> + DBusError derr;
> + DBusMessage *reply, *msg;
> +
> + reply = dbus_pending_call_steal_reply(call);
> +
> + if (ofono_modem_get_powered(modem))
> + goto done;
> +
> + if (!dbus_message_get_args(reply, NULL, DBUS_TYPE_STRING, &dev,
> + DBUS_TYPE_INVALID))
> + goto done;
> +
> + data->rfcomm = dev;

One more comment here, I'd suggest to use g_strdup(dev). Because the device
String is from dbus reply and later we will unref the reply. What do you think?

> + dbus_error_init(&derr);
> + if (!dbus_set_error_from_message(&derr, reply))
> + goto done;
> +
> + DBG("Connect reply: %s", derr.message);
> +
> + if (dbus_error_has_name(&derr, DBUS_ERROR_NO_REPLY)) {
> + msg = dbus_message_new_method_call(BLUEZ_SERVICE,
> + data->dun_path,
> + BLUEZ_SERIAL_INTERFACE, "Disconnect");
> + if (!msg)
> + ofono_error("Disconnect failed");
> + else
> + g_dbus_send_message(connection, msg);
> + }
> +
> + ofono_modem_set_powered(modem, FALSE);
> +
> + dbus_error_free(&derr);
> +
> +done:
> + ofono_modem_set_powered(modem, TRUE);
> + dbus_message_unref(reply);
> +}
> +
>  static int dun_enable(struct ofono_modem *modem)
>  {
> - DBG("%p", modem);
> - return 0;
> + struct dun_data *data = ofono_modem_get_data(modem);
> + int status;
> + const char *uuid = DUN_GW_UUID;
> +
> + status = bluetooth_send_with_reply(data->dun_path,
> + BLUEZ_SERIAL_INTERFACE, "Connect",
> + dun_connect_reply, modem, NULL,
> + 15, DBUS_TYPE_STRING, &uuid,
> + DBUS_TYPE_INVALID);
> +
> + if (status < 0)
> + return -EINVAL;
> +
> + return -EINPROGRESS;
>  }
> 
>  static int dun_disable(struct ofono_modem *modem)



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/3] Add dun_enable() function

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> dun_enable() is called by setting the Powered property to true.
> It creates a rfcomm link throught the BlueZ Serial API.
> ---
>  drivers/dunmodem/dunmodem.h |1 +
>  plugins/bluetooth.h |1 +
>  plugins/dun.c   |   61
>  +- 3 files changed, 61
> insertions(+), 2 deletions(-) 
> 
> diff --git a/drivers/dunmodem/dunmodem.h b/drivers/dunmodem/dunmodem.h
> index 6bbf7b9..16eb9e7 100644
> --- a/drivers/dunmodem/dunmodem.h
> +++ b/drivers/dunmodem/dunmodem.h
> @@ -23,6 +23,7 @@
> 
>  struct dun_data {
>   char *dun_path;
> + const char *rfcomm;
>  };
> 
>  #endif
> diff --git a/plugins/bluetooth.h b/plugins/bluetooth.h
> index 09e6efa..c20b36d 100644
> --- a/plugins/bluetooth.h
> +++ b/plugins/bluetooth.h
> @@ -22,6 +22,7 @@
>  #define  BLUEZ_MANAGER_INTERFACE BLUEZ_SERVICE ".Manager"
>  #define  BLUEZ_ADAPTER_INTERFACE BLUEZ_SERVICE ".Adapter"
>  #define  BLUEZ_DEVICE_INTERFACE  BLUEZ_SERVICE ".Device"
> +#define  BLUEZ_SERIAL_INTERFACE  BLUEZ_SERVICE ".Serial"
> 
>  #define HFP_AG_UUID  "111F--1000-8000-00805F9B34FB"
>  #define DUN_GW_UUID  "1103--1000-8000-00805F9B34FB"
> diff --git a/plugins/dun.c b/plugins/dun.c
> index 9b4288e..7dc8422 100644
> --- a/plugins/dun.c
> +++ b/plugins/dun.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -138,10 +139,66 @@ static void dun_remove(struct ofono_modem
>   *modem) ofono_modem_set_data(modem, NULL);
>  }
> 
> +static void dun_connect_reply(DBusPendingCall *call, gpointer
> user_data) +{
> + struct ofono_modem *modem = user_data;
> + struct dun_data *data = ofono_modem_get_data(modem);
> + const char *dev;
> + DBusError derr;
> + DBusMessage *reply, *msg;
> +
> + reply = dbus_pending_call_steal_reply(call);
> +
> + if (ofono_modem_get_powered(modem))
> + goto done;
> +
> + if (!dbus_message_get_args(reply, NULL, DBUS_TYPE_STRING, &dev,
> + DBUS_TYPE_INVALID))
> + goto done;
> +
> + data->rfcomm = dev;
> +
> + dbus_error_init(&derr);
> + if (!dbus_set_error_from_message(&derr, reply))
> + goto done;
> +
> + DBG("Connect reply: %s", derr.message);
> +
> + if (dbus_error_has_name(&derr, DBUS_ERROR_NO_REPLY)) {
> + msg = dbus_message_new_method_call(BLUEZ_SERVICE,
> + data->dun_path,
> + BLUEZ_SERIAL_INTERFACE, "Disconnect");
> + if (!msg)
> + ofono_error("Disconnect failed");
> + else
> + g_dbus_send_message(connection, msg);
> + }
> +
> + ofono_modem_set_powered(modem, FALSE);
> +
> + dbus_error_free(&derr);
> +
> +done:
> + ofono_modem_set_powered(modem, TRUE);

You might want to power on modem before jumping to this label. If there's any 
error
from dbus, you power off but then power on the modem again. It's wrong.

> + dbus_message_unref(reply);
> +}
> +
>  static int dun_enable(struct ofono_modem *modem)
>  {
> - DBG("%p", modem);
> - return 0;
> + struct dun_data *data = ofono_modem_get_data(modem);
> + int status;
> + const char *uuid = DUN_GW_UUID;
> +
> + status = bluetooth_send_with_reply(data->dun_path,
> + BLUEZ_SERIAL_INTERFACE, "Connect",
> + dun_connect_reply, modem, NULL,
> + 15, DBUS_TYPE_STRING, &uuid,
> + DBUS_TYPE_INVALID);

Shall we define a macro like DBUS_TIMEOUT instead of hard code 15 seconds?
What do you think?

> + if (status < 0)
> + return -EINVAL;
> +
> + return -EINPROGRESS;
>  }
> 
>  static int dun_disable(struct ofono_modem *modem)



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] Fix busylooped in ppp_disconnect for huawei modem

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
> On 07/26/2010 09:39 PM, Zhenhua Zhang wrote:
>> Huawei modem closes the modem port after PPP disconnect. So the
>> channel 
>> of gatchat is NULL in ppp_disconnect. In such case, we should not
>> resume 
>> the chat and call disconnect function when removing the context.
> 
> Please reword the last sentence, we should resume the chat, but the
> question is of timing...

It should be something like 'not resume the chat twice'. One is in
ppp_disconnect and the second is in at_gprs_context_remove.

>> Secondly, before removing the gprs context, we should reply the
>> pending 
>> DBus message to the client.
>> ---
>>  drivers/atmodem/gprs-context.c |   13 -
>>  1 files changed, 12 insertions(+), 1 deletions(-)
>> 
>> diff --git a/drivers/atmodem/gprs-context.c
>> b/drivers/atmodem/gprs-context.c 
>> index fea80b0..e2f291a 100644
>> --- a/drivers/atmodem/gprs-context.c
>> +++ b/drivers/atmodem/gprs-context.c
>> @@ -88,11 +88,22 @@ static void
>>  ppp_disconnect(GAtPPPDisconnectReason reason, gpointer user_data) 
>>  { struct ofono_gprs_context *gc = user_data; struct
>> gprs_context_data *gcd = ofono_gprs_context_get_data(gc); +  GAtIO
>> *io = g_at_chat_get_io(gcd->chat); 
>> 
>>  DBG("");
>> 
>>  g_at_ppp_unref(gcd->ppp);
>>  gcd->ppp = NULL;
>> +
>> +if (g_at_io_get_channel(io) == NULL) {
>> +CALLBACK_WITH_FAILURE(gcd->up_cb, NULL, FALSE, NULL,
>> +NULL, NULL, NULL, gcd->cb_data);
>> +gcd->active_context = 0;
>> +gcd->state = STATE_IDLE;
>> +g_at_chat_resume(gcd->chat);
>> +return;
>> +}
>> +
> 
> Instead of doing that, can't we simply move g_at_chat_resume to the
> bottom of the function and put in a comment this might cause
> gprs_context_remove to get called?

It's better than my current way. The updated patch will send out soon. Please 
review it.

>>  g_at_chat_resume(gcd->chat);
>> 
>>  switch (gcd->state) {
>> @@ -257,7 +268,7 @@ static void at_gprs_context_remove(struct
>> ofono_gprs_context *gc) 
>> 
>>  DBG("");
>> 
>> -if (gcd->state != STATE_IDLE) {
>> +if (gcd->state != STATE_IDLE && gcd->ppp) {
> 
> This along with the funny g_at_chat_resume logic is what seems to be
> causing the infinite loop.
> 
>>  g_at_ppp_unref(gcd->ppp);
>>  g_at_chat_resume(gcd->chat);
>>  }
> 
> Thanks,
> -Denis



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] Fix busylooped in ppp_disconnect for huawei modem

[Zhang, Zhenhua]

Hi Kalle,

Zhenhua Zhang wrote:
> Huawei modem closes the modem port after PPP disconnect. So the
> channel 
> of gatchat is NULL in ppp_disconnect. In such case, we should not
> resume 
> the chat and call disconnect function when removing the context.
> Secondly, before removing the gprs context, we should reply the
> pending 
> DBus message to the client.
> ---
>  drivers/atmodem/gprs-context.c |   13 -
>  1 files changed, 12 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/atmodem/gprs-context.c
> b/drivers/atmodem/gprs-context.c 
> index fea80b0..e2f291a 100644
> --- a/drivers/atmodem/gprs-context.c
> +++ b/drivers/atmodem/gprs-context.c
> @@ -88,11 +88,22 @@ static void ppp_disconnect(GAtPPPDisconnectReason
>  reason, gpointer user_data) {
>   struct ofono_gprs_context *gc = user_data;
>   struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> + GAtIO *io = g_at_chat_get_io(gcd->chat);
> 
>   DBG("");
> 
>   g_at_ppp_unref(gcd->ppp);
>   gcd->ppp = NULL;
> +
> + if (g_at_io_get_channel(io) == NULL) {
> + CALLBACK_WITH_FAILURE(gcd->up_cb, NULL, FALSE, NULL,
> + NULL, NULL, NULL, gcd->cb_data);
> + gcd->active_context = 0;
> + gcd->state = STATE_IDLE;
> + g_at_chat_resume(gcd->chat);
> + return;
> + }
> +
>   g_at_chat_resume(gcd->chat);
> 
>   switch (gcd->state) {
> @@ -257,7 +268,7 @@ static void at_gprs_context_remove(struct
> ofono_gprs_context *gc) 
> 
>   DBG("");
> 
> - if (gcd->state != STATE_IDLE) {
> + if (gcd->state != STATE_IDLE && gcd->ppp) {
>   g_at_ppp_unref(gcd->ppp);
>   g_at_chat_resume(gcd->chat);
>   }

Could you try my fix for this busy loop issue? It is not perfect but at least 
work for me.
The problem is: in ppp_disconnect, after g_at_chat_resume(), the gprs context 
has
been removed and recreated, so the rest gc and gcd are totally wrong.

Btw, I still meet the kernel warning or even Ubuntu crash after 
activate/deactivate gprs
context multiple times on E1552. Do you see such problem? the kernel dmesg is
attached for reference.

Regards,
Zhenhua
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301093] [ cut here 
]
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301106] WARNING: at 
/build/buildd/linux-2.6.32/drivers/usb/serial/usb-serial.c:406 
serial_write_room+0x75/0x80 [usbserial]()
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301108] Hardware name: 7661BL4
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301110] Modules linked in: 
nls_utf8 isofs option usbserial usb_storage aes_i586 aes_generic hidp rfcomm 
ppdev sco bnep l2cap binfmt_misc snd_hda_codec_analog fbcon tileblit font 
bitblit softcursor vga16fb vgastate joydev snd_hda_intel snd_hda_codec 
snd_hwdep snd_pcm_oss snd_mixer_oss thinkpad_acpi snd_pcm snd_seq_dummy 
snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq pcmcia 
iwlagn snd_timer iwlcore snd_seq_device i915 drm_kms_helper snd mac80211 drm 
uvcvideo videodev v4l1_compat btusb bluetooth nvram yenta_socket rsrc_nonstatic 
sdhci_pci sdhci led_class ricoh_mmc pcmcia_core psmouse serio_raw cfg80211 
intel_agp agpgart i2c_algo_bit video output soundcore snd_page_alloc lp parport 
usbhid hid ohci1394 ieee1394 e1000e
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301187] Pid: 2513, comm: ofonod 
Tainted: GW  2.6.32-21-generic #32-Ubuntu
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301189] Call Trace:
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301196]  [] 
warn_slowpath_common+0x72/0xa0
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301200]  [] ? 
serial_write_room+0x75/0x80 [usbserial]
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301204]  [] ? 
serial_write_room+0x75/0x80 [usbserial]
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301208]  [] 
warn_slowpath_null+0x1a/0x20
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301211]  [] 
serial_write_room+0x75/0x80 [usbserial]
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301216]  [] 
tty_write_room+0x1d/0x20
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301219]  [] 
n_tty_poll+0x177/0x190
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301222]  [] 
tty_poll+0x69/0x80
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301226]  [] ? 
_spin_lock_irq+0x18/0x20
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301229]  [] ? 
n_tty_poll+0x0/0x190
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301232]  [] 
do_poll+0xdb/0x230
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301236]  [] 
do_sys_poll+0x136/0x1f0
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301239]  [] ? 
__pollwait+0x0/0xe0
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301242]  [] ? 
pollwake+0x0/0x60
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301244]  [] ? 
pollwake+0x0/0x60
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301247]  [] ? 
pollwake+0x0/0x60
Jul 27 10:13:17 zzhan17-mobile kernel: [  599.301250]  [] ? 
pollwake+0x0

RE: Howto about Qt QML and Ofono

[Zhang, Zhenhua]

Hi Matthias,

Matthias Günther wrote:
> Hi Yang,
> 
>> http://matgnt.wordpress.com/2010/07/19/qt-ofono-d-bus-and-qml-part-1/
>> http://matgnt.wordpress.com/2010/07/19/qt-ofono-d-bus-and-qml-part-2/
>> http://matgnt.wordpress.com/2010/07/19/qt-ofono-d-bus-and-qml-part-3/
> 
> I hope this helps people out there to create cool new phone
> applications. You're welcome to leave a note here or on the howto
> directly. 
> 
 
 Your lovely program gives a good demo on how to writing an
 application based on 
>>> oFono. oFono does claim it will help on building application in a
>>> convenient way, so the prosperity of application will definitely
>>> bring feedback to oFono and make oFono grow better.
 I have two comments on your first part: 1) configure is not in the
 git tree of oFono, so 
>>> we will use bootstrap-configure instead. 2) I'm sure your phonesim
>>> works well. But we also have another phonesim derived from your
>>> repo, which we had some modification and enhancement in. The repo is
>>> "git://git.kernel.org/pub/scm/network/ofono/phonesim.git". The
>>> building command is same as oFono, and the execution command is
>>> "./phonesim -p 12345 -gui src/default.xml". 
>>> 
>>> Thanks Yang, I've added the ./bootstrap command to the listing. I
>>> also 
>>> wrote down a hint to the ofono branch of phonesim.
>> 
>> "bootstrap-configure" is a single script, rather than two different
>> ones. 
> 
> Thanks for your comment. As mentioned in the thread before, there are
> two scripts. The problem with "bootstrap-configure" is, that it
> enables the --enable-capng switch which may cause problems. It'll
> probably end up in missing files. Therefore I chose "bootstrap" to
> just create the configure script and then use it without any
> configuration arguments - just the defaults. For the purpose of the
> howto, the debug switches are not really necessary.

You could use 'sudo apt-get install libcap-ng-dev' or 'yum install -y 
libcap-ng-devel' to install this library.

One comment is that we normally call our project as 'oFono' instead 'Ofono'. :-)

> Best regards,
> Matthias
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: ISI drivers test simulator

[Zhang, Zhenhua]

Hi Remi,

Rémi Denis-Courmont wrote:
> On Tue, 20 Jul 2010 11:28:59 +0200, "Alan KREUTZ"
>  wrote:
>> 1-Is, the fact to test oFono ISI driver with a Nokia phone, the
>> only way to test ISI drivers or is there a simulator like phonesim
>> for ISI driver?
> 
> Yes.
> 
>> 2-How to test oFono with a Nokia mobile? I believe that the
>> plugin usbpnmodem.c must be used to communicate with modem via USB
>> and it seems that Maemo (or MeeGo) is mandatory too. Is this correct?
> 
> Yes and no. Some of the oFono atoms from the ISI driver do work with
> S60 phones and S40 phones too.
> 
>> 3-And last question, if a Nokia modem is connected via USB to a
>> PC, is the Nokia's modem disconnected from UI part in order to
>> receive and treat only messages from host (PC/oFono)?
> 
> Some features won't work, notably SMS reception.

One question I have: Can we install Meego image and use oFono to operate 
Nokia's 
modem natively on N900 now? Can we use voicecall/GPRS/SMS and other availabe
featueres in oFono?

> --
> Rémi Denis-Courmont
> http://www.remlab.net
> http://fi.linkedin.com/in/remidenis
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/6] emulator: Add ofono_emulator framework

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> I grabed code from obex to register&start DUN GW service
> when we parse adapter properties. From patch 6/6, you can see
> my current implementation is to find the first powered modem
> that having GRPS atom. Load settings from modem.conf could be
> another option. But what if the modem is detected from udev?
> It could be huawei0, huawei1 or huawei.
> 
> Doing it via .conf file is still possible.  E.g. we might be able to
> stipulate that only modems with a particular driver get exported (e.g.
> driver="huawei" or driver="isi")  Or perhaps a hardcoded path / first
> modem available.  I wouldn't worry about it for now, do whatever is
> easiest.  The more interesting part is getting the oFono core
> emulator bits working. 
> 
> Regards,
> -Denis

Sure. Will update the patches soon.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/6] emulator: Add ofono_emulator framework

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +#define OFONO_EMULATOR_INTERFACE "org.ofono.Emulator"
> 
> So my suggestion is to keep it simple and not include the D-Bus
> interface for the emulator at all for now.

That's fine. Will remove them.

>> +
>> +#include 
>> +
>> +struct ofono_emulator;
>> +
>> +enum ofono_emulator_type {
>> +OFONO_EMULATOR_TYPE_NONE,
> 
> Type NONE seems to be useless :)
> 
>> +OFONO_EMULATOR_TYPE_DUN,
>> +};
>> +
>> +struct ofono_emulator_driver {
>> +const char *name;
>> +enum ofono_emulator_type type;
>> +int (*probe)(struct ofono_emulator *e);
>> +void (*remove)(struct ofono_emulator *e);
>> +int (*enable)(struct ofono_emulator *e, int fd);
>> +int (*disable)(struct ofono_emulator *e);
>> +};
> 
> For the emulator we really don't need a driver, see below...

My original idea is that we need support DUN/HFPAG/SPP types of emulators. So 
we need a good framework to support it. Remember we could have both DUN/HFPAG 
atoms co-exist at the same time.

Your idea is better. It might work.

>> +
>> +const char *ofono_emulator_get_path(struct ofono_emulator *e);
>> +void ofono_emulator_set_data(struct ofono_emulator *e, void
>> *user_data); +void *ofono_emulator_get_data(struct ofono_emulator
>> *e); +
> 
> If there's no driver, then these are not required...
> 
>> +struct ofono_emulator *ofono_emulator_create(struct ofono_modem
>> *modem, +struct
> ofono_emulator_driver *driver);
> 
> So I think we should simply do it like this:
> 
> struct ofono_emulator *ofono_emulator_create(struct ofono_modem
> *modem, enum ofono_emulator_type type, int fd);
> 
> Once we have the fd we really don't need anything else.  If the fd
> goes away we can safely remove the atom.  If the modem is powered
> down, we can safely shut down the connection.
> 
>> +void ofono_emulator_remove(struct ofono_emulator *e);
>> +
> 
> This might or might not be necessary...
> 
>> +int ofono_emulator_driver_register(const struct
> ofono_emulator_driver *driver);
>> +void ofono_emulator_driver_unregister(
>> +const struct
> ofono_emulator_driver *driver);
>> +
> 
> These won't be necessary...
> 
> We then treat the emulator atom the same as any atom.  When
> the modem is
> powered off the atom is removed.  The bluetooth dun plugin can create
> look at the list of modems, establish the state watch (e.g. off/on
> pre_sim/offline/online) and register the DUN atom appropriately (most
> likely when the modem is turned on)
>
> It will be up to the plugin to figure out which Bluetooth adapter to
> register on (perhaps always the default one) and which modems to
> expose (maybe a configuration file?) 

I grabed code from obex to register&start DUN GW service when we parse adapter 
properties. From patch 6/6, you can see my current implementation is to find 
the first powered modem that having GRPS atom. Load settings from modem.conf 
could be another option. But what if the modem is detected from udev? It could 
be huawei0, huawei1 or huawei.
 
> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Ofono in Maemo scratchbox--compilation failed.

[Zhang, Zhenhua]

Hi Arun,

Marcel Holtmann wrote:
> Hi Arun,
> 
>> I am trying to compile Ofono in Maemo Scratchbox SDK enviornment.
>> 
>> Here is the bootstrap-configure output:
>> 
> ---
> ---
> -
>> [sbox-FREMANTLE_X86: ~/ofono] > ./bootstrap-configure
>> configure.ac: installing `./install-sh'
>> configure.ac: installing `./missing'
>> Makefile.am: installing `./compile'
>> Makefile.am: installing `./depcomp'
>> checking for a BSD-compatible install...
>> /scratchbox/tools/bin/install -c checking whether build environment
>> is sane... yes 
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether to enable maintainer-specific portions of
>> Makefiles... yes checking for pkg-config...
>> /scratchbox/tools/bin/pkg-config 
>> checking pkg-config is at least version 0.9.0... yes
>> checking for style of include used by make... GNU
>> checking for gcc... gcc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables...
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking dependency style of gcc... gcc3
>> checking for C/C++ restrict keyword... no
>> checking for gcc... (cached) gcc
>> checking whether we are using the GNU C compiler... (cached) yes
>> checking whether gcc accepts -g... (cached) yes
>> checking for gcc option to accept ISO C89... (cached) none needed
>> checking dependency style of gcc... (cached) gcc3
>> checking whether gcc and cc understand -c and -o together... yes
>> checking whether gcc accepts -fPIE... yes
>> checking for a BSD-compatible install...
>> /scratchbox/tools/bin/install -c checking for a sed that does not
>> truncate 
>> output... /scratchbox/tools/bin/sed
>> checking for gawk... (cached) gawk
>> checking build system type... i486-pc-linux-gnu
>> checking host system type... i486-pc-linux-gnu
>> checking for a sed that does not truncate
>> output... /scratchbox/tools/bin/sed
>> checking for grep that handles long lines and
>> -e... /scratchbox/tools/bin/grep
>> checking for egrep... /scratchbox/tools/bin/grep -E
>> checking for ld used by
>> gcc...
> /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld
>> checking if the linker
>> 
> (/scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu
> /bin/ld) is GNU ld... yes
>> checking
>> for
> /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/
> bin/ld option to reload object files... -r
>> checking for BSD-compatible nm... /scratchbox/compilers/bin/nm -B
>> checking whether ln -s works... yes
>> checking how to recognize dependent libraries... pass_all
>> checking how to run the C preprocessor... gcc -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking dlfcn.h usability... yes
>> checking dlfcn.h presence... yes
>> checking for dlfcn.h... yes
>> checking the maximum length of command line arguments... 98304
>> checking command to parse /scratchbox/compilers/bin/nm -B output
>> from gcc object... failed checking for objdir... .libs
>> checking for ar... ar
>> checking for ranlib... ranlib
>> checking for strip... strip
>> checking if gcc supports -fno-rtti -fno-exceptions... no
>> checking for gcc option to produce PIC... -fPIC
>> checking if gcc PIC flag -fPIC works... yes
>> checking if gcc static flag -static works... yes
>> checking if gcc supports -c -o file.o... yes
>> checking whether the gcc linker
>> 
> (/scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu
> /bin/ld) supports shared libraries... yes
>> checking whether -lc should be explicitly linked in... no
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> configure: creating libtool
>> checking for BSD-compatible nm...
>> (cached) /scratchbox/compilers/bin/nm -B
>> checking for signalfd in -lc... yes
>> checking for dlopen in -ldl... yes
>> checking for GLIB... yes
>> checking for DBUS... yes
>> checking for dbus_watch_get_unix_fd in -ldbus-1... yes
>> checking for dbus_connection_can_send_type in -ldbus-1... no
>> checking for UDEV... yes checking for CAPNG... yes
>> configure:

RE: [PATCH 2/6] bluetooth: Add register service for bluetooth

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> * Zhenhua Zhang  [2010-07-05 13:45:05 +0800]:
> 
>> Add bluetooth_register_service() and bluetooth_unregister_service()
>> where bluetooth profiles plugins like DUN GW can register themselves
>> per adapter. It shares existing bluetooth framework to listen
>> bluetooth events (new adapters, bluetoothd shutdown, etc..)
>> ---
>>  plugins/bluetooth.c |  125
> ++-
>>  plugins/bluetooth.h |8 +++
>>  2 files changed, 112 insertions(+), 21 deletions(-)
>> 
>> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
>> index 5a85eaa..3a3b5e6 100644
>> --- a/plugins/bluetooth.c
>> +++ b/plugins/bluetooth.c
>> @@ -38,8 +38,19 @@
>> 
>>  static DBusConnection *connection;
>>  static GHashTable *uuid_hash = NULL;
>> +static GHashTable *service_hash = NULL;
>>  static GHashTable *adapter_address_hash = NULL;
>> 
>> +static char *bluetooth_service_type_to_str(enum
>> bluetooth_service_type type) +{ +switch (type) {
>> +case DUN_GATEWAY:
>> +return "DUN";
>> +default:
>> +return "";
>> +}
>> +}
>> +
> 
> We actually don't need this function, you can put the
> 'enum bluetooth_service_type' value as hash key. Sounds better.

Agree. It seems the type string is not used in other place except hash table 
insert/remove. So  I will change that.

>>  void bluetooth_create_path(const char *dev_addr, const char
>>  *adapter_addr,  char *buf, int size) {
>> @@ -376,6 +387,9 @@ static void
> adapter_properties_cb(DBusPendingCall *call, gpointer user_data)
>>  GSList *device_list = NULL;
>>  GSList *l;
>>  const char *addr;
>> +GHashTableIter hash_iter;
>> +gpointer key, value;
>> +struct bluetooth_profile *profile;
>> 
>>  reply = dbus_pending_call_steal_reply(call);
>> 
>> @@ -393,6 +407,12 @@ static void
> adapter_properties_cb(DBusPendingCall *call, gpointer user_data)
>>  g_hash_table_insert(adapter_address_hash,
>>  g_strdup(path), g_strdup(addr));
>> 
>> +g_hash_table_iter_init(&hash_iter, service_hash);
>> +while (g_hash_table_iter_next(&hash_iter, &key, &value)) {
>> +profile = value; +  profile->create(path, NULL, 
>> addr, NULL);
> 
> You have to check if profile and profile->create is not NULL.
> It is more
> safe.

Sure. I will add check for both.

>> +}
>> +
>>  for (l = device_list; l; l = l->next) {
>>  const char *device = l->data;
>> 
>> @@ -492,10 +512,13 @@ static void
> bluetooth_remove_all_modem(gpointer key, gpointer value,
>> 
>>  static void bluetooth_disconnect(DBusConnection *connection, void
>> *user_data)  { 
>> -if (!uuid_hash)
>> -return;
>> +if (uuid_hash)
>> +g_hash_table_foreach(uuid_hash, bluetooth_remove_all_modem,
>> +NULL); 
>> 
>> -g_hash_table_foreach(uuid_hash,
> bluetooth_remove_all_modem, NULL);
>> +if (service_hash)
>> +g_hash_table_foreach(service_hash, bluetooth_remove_all_modem,
>>  +   NULL); }
>> 
>>  static guint bluetooth_watch;
>> @@ -503,12 +526,12 @@ static guint adapter_added_watch;
>>  static guint adapter_removed_watch;
>>  s.tatic guint property_watch;
>> 
>> -int bluetooth_register_uuid(const char *uuid, struct
>>  bluetooth_profile *profile) +static int bluetooth_init() {
> 
> So I prefer a real refcount structure here, and call this
> bluetooth_ref(). What do you think?

Good idea. Bluetooth_ref/unref makes more sense if we have both HFP and DUN 
existings on the system.

Actually I have an unrelated question here. Why we don't have something like 
DUN_GW_UUID string so that we can easily reuse your current code? For now, we 
need to register service and use a different hash table to record that.

>>  int err;
>> 
>> -if (uuid_hash)
>> -goto done;
>> +if (adapter_address_hash)
>> +return 0;
>> 
>>  connection = ofono_dbus_get_connection();
>> 
>> @@ -536,19 +559,9 @@ int bluetooth_register_uuid(const char
> *uuid, struct bluetooth_profile *profile)
>>  goto remove;
>>  }
>> 
>> -uuid_hash = g_hash_table_new_full(g_str_hash, g_str_equal,
>> -g_free, NULL);
>> -
>>  adapter_address_hash =
> g_hash_table_new_full(g_str_hash, g_str_equal,
>>  g_free, g_free);
>> 
>> -done:
>> -g_hash_table_insert(uuid_hash, g_strdup(uuid), profile); -
>> -bluetooth_send_with_reply("/", BLUEZ_MANAGER_INTERFACE,
>> "GetProperties", 
>> -manager_properties_cb, NULL, NULL, -1,
>> -DBUS_TYPE_INVALID);
>> -
>>  return 0;
>> 
>>  remove:
>> @@ -556,14 +569,13 @@ remove:
>>  g_dbus_remove_watch(connection, adapter_added_watch);
>>  g_dbus_remove_watch(connection, adapter_remove

RE: [PATCH 1/1] ppp: Add MAX_IPCP_FAILURE to avoid timeout quickly

[Zhang, Zhenhua]

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> We use IPCP NAK response to stall the progress of acquiring the
>> client IP address from DHCP server. So we need to increase the max
>> failure of NAKs in IPCP handshaking. ---
>>  gatchat/ppp_cp.c   |8 ++--
>>  gatchat/ppp_cp.h   |2 +-
>>  gatchat/ppp_ipcp.c |   10 +-
>>  gatchat/ppp_lcp.c  |2 +-
>>  4 files changed, 17 insertions(+), 5 deletions(-)
>> 
>> diff --git a/gatchat/ppp_cp.c b/gatchat/ppp_cp.c
>> index 647e241..e013283 100644
>> --- a/gatchat/ppp_cp.c
>> +++ b/gatchat/ppp_cp.c
>> @@ -997,7 +997,7 @@ void pppcp_set_local_options(struct pppcp_data
>> *pppcp,  } 
>> 
>>  struct pppcp_data *pppcp_new(GAtPPP *ppp, const struct pppcp_proto
>> *proto, -gboolean dormant) + 
>> gboolean dormant, int
>> max_failure) 
> 
> since the value is actually unsigned here, please also use guint and
> not int for this parameter.

Okay. Will resend the patch soon.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 11/15] emulator: Register mandatory AT command handlers

[Zhang, Zhenhua]

Hi Remi,

Marcel Holtmann wrote:
> Hi Remi,
> 
>>> +static void cfun_cb(GAtServerRequestType type, GAtResult *cmd,
>>> +   gpointer user_data) +{
>>> +   struct ofono_emulator *e = user_data;
>>> +   char buf[50];
>>> +
>>> +   switch (type) {
>>> +   case G_AT_SERVER_REQUEST_TYPE_SUPPORT:
>>> +   ofono_emulator_send_info(e, "+CFUN: (0-1)", TRUE);
>>> +   ofono_emulator_send_final(e, G_AT_SERVER_RESULT_OK); +  
>>> break;
>>> +   case G_AT_SERVER_REQUEST_TYPE_QUERY:
>>> +   snprintf(buf, sizeof(buf), "+CFUN: %d", e->modem_mode);
>>> +   ofono_emulator_send_info(e, buf, TRUE);
>>> +   ofono_emulator_send_final(e, G_AT_SERVER_RESULT_OK);
>>> +   break;
>> 
>> Does not make much sense. If mode is 0, the device has functionality
>> minimum, meaning usually power off or close to that. oFono does not
>> run in such stage, so it won't be there to answer CFUN: 0.
> 
> this is actually more fake than real. We are not mapping all commands
> 1:1 to the real modem. It is mainly to just make some dialers
> and things
> like Windows happy ;)

Marcel is right. Here I fake most AT commands like +CFUN to make DUN client 
happy. We don't need to power on/off real modem at all. See 
gatchat/test-server.c for similar implementation.

>>> +   case G_AT_SERVER_REQUEST_TYPE_SET:
>>> +   {
>>> +   GAtResultIter iter;
>>> +   int mode;
>>> +
>>> +   g_at_result_iter_init(&iter, cmd);
>>> +   g_at_result_iter_next(&iter, "+CFUN=");
>>> +
>>> +   if (g_at_result_iter_next_number(&iter, &mode) == FALSE)
>>> +   goto error; +
>>> +   if (mode != 0 && mode != 1)
>>> +   goto error;
>>> +
>>> +   DBG("set CFUN to %d", mode);
>>> +
>>> +   e->modem_mode = mode;
>>> +   g_timeout_add_seconds(1, send_ok, e);
>>> +   break;
>>> +   }
>> 
>> I might be missing something, but it does not look like AT+CFUN=0
>> will power off the system, which is more or less what it is expected
>> to do. 
> 
> Look again, it won't. It is an arbitrary delay for testing. If we
> would follow the Bluetooth DUN specification literally, then only the
> magic AT*99# syntax would be needed, but there are other commands
> that are expected to work. So in most cases we just fake them.
> 
>> +static void cops_cb(GAtServerRequestType type, GAtResult *result,
>>> +   gpointer user_data)
>>> +{
>>> +   struct ofono_emulator *e = user_data;
>>> +   char buf[50];
>>> +
>>> +   switch (type) {
>>> +   case G_AT_SERVER_REQUEST_TYPE_SUPPORT:
>>> +   ofono_emulator_send_final(e, G_AT_SERVER_RESULT_OK); +  
>>> break;
>>> +   case G_AT_SERVER_REQUEST_TYPE_QUERY:
>>> +   snprintf(buf, sizeof(buf), "+COPS: %d", e->modem_cops);
>>> +   ofono_emulator_send_info(e, buf, TRUE);
>>> +   ofono_emulator_send_final(e, G_AT_SERVER_RESULT_OK); +  
>>> break;
>>> +   case G_AT_SERVER_REQUEST_TYPE_SET:
>>> +   {
>>> +   GAtResultIter iter;
>>> +   int mode;
>>> +
>>> +   g_at_result_iter_init(&iter, result);
>>> +   g_at_result_iter_next(&iter, "+COPS=");
>>> +
>>> +   if (g_at_result_iter_next_number(&iter, &mode) == FALSE)
>>> +   goto error; +
>>> +   if (mode < 0 || mode > 2)
>>> +   goto error;
>>> +
>>> +   DBG("set GPRS cops status %d", mode);
>>> +
>>> +   e->modem_cops = mode;
>>> +   ofono_emulator_send_final(e, G_AT_SERVER_RESULT_OK);
>> 
>> You won't get away with this. You're supposed to
>> register/unregister/etc from the network here. Similarly, AT+CGATT
>> is wrong, GPRS should be attached/detached. Yes, that means you may
>> have to tear down someone else's GPRS context, which may seem evil.
> 
> Same here actually. We will fake COPS and CGATT for the
> client. Compared
> to the CFUN code this needs a bit more work since we should return an
> error when the real modem is not ready yet or GPRS is not attached.

For +COPS, we could fake one to the client. Do not register/unregister from the 
real network and stop sending +CREG/+CGREG unsolicited result to client.

For +CGATT, my current implementation (Patch 14/15) is still rough. GPRS atom 
will get notification from dun status watch and try to set GPRS attached if we 
have +CGATT=1. 

But if we have +CGATT=0, it seems we need to do more works (not done yet). Do 
not detach GPRS on real modem. Meanwhile, remove all dun created contexts.

Feel free to let me know your opinions.

> That said, there has to be done some work for CFUN as well if our
> modem is offline. However my take here is to just disable DUN
> service when the
> modems goes offline.
> 
>> Last, AT+CPIN should at the very least return PIN READY when
>> appropriate, if I read the spec right.
> 
> We will fake this again and always return READY here. If the physical
> modem is not ready 

[PATCH 0/15] Implement DUN server in oFono

[Zhang, Zhenhua]

Hi,

[Fix misleading title and content in previous 0/15 mail. Sorry for that.]

This series are based on the previous 6 patches "Add oFono DUN emulator" sent 
on July 5th. It implements the main functionality of DUN server and interact 
with GPRS atom to create DUN context. You can use gatchat/test-emulator to 
create a pseudo terminal and then use gsmdial to create a DUN client 
connection. 

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/2] gathdlc: Unset disconnect function in unref

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> @@ -278,6 +278,7 @@ void g_at_hdlc_unref(GAtHDLC *hdlc) 
>>  hdlc->record_fd = -1; }
>> 
>> +g_at_io_set_disconnect_function(hdlc->io, NULL, NULL);
> 
> Since GAtHDLC does not set the disconnect function, this really
> belongs in GAtPPP. 

How about unset io_disconnect() in GAtPPP? Since GAtPPP doesn't have 
suspend/resume, the io_disconnect always exist until ppp is dead.
 
>>  g_at_io_unref(hdlc->io);
>>  hdlc->io = NULL;
>> 
> 
> However, I really question why this patch is necessary.  The only way
> the disconnect function is not reset today is if the GAtIO is refed
> and g_at_chat_resume is not called.
> 
> We do call g_at_io_set_disconnect function in g_at_chat_resume.

Good catch. I fixed it in gatserver and will send a patch out soon. Yes, after 
reset the disconnect function, the problem is gone.
 
> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] test-server: Use cfmakeraw to set TTY raw mode

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> Use cfmakeraw to disable echoing and special characters processing.
>> If we don't turn off ICRNL, TTY layer translates \r\n to \n\n. ---
>>  gatchat/test-server.c |8 +++-
>>  1 files changed, 3 insertions(+), 5 deletions(-)
>> 
>> diff --git a/gatchat/test-server.c b/gatchat/test-server.c
>> index 25a1192..2911978 100644
>> --- a/gatchat/test-server.c
>> +++ b/gatchat/test-server.c
>> @@ -848,12 +848,10 @@ static void set_raw_mode(int fd)  {
>>  struct termios options;
>> 
>> +memset(&options, 0, sizeof(struct termios));
>>  tcgetattr(fd, &options);
>> -
>> -/* Set TTY as raw mode to disable echo back of input characters
>> - * when they are received from Modem to avoid feedback loop */
>> -options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); -
>> +tcflush(fd, TCIOFLUSH);
>> +cfmakeraw(&options);
>>  tcsetattr(fd, TCSANOW, &options);
>>  }
> 
> I am fine with using cfmakeraw. So patch has been applied.
> 
> Minor comment here that sizeof(options) would be better then
> referencing the struct itself. And in general we have used ti as
> variable name for termios options. Don't ask me really why. Just have
> done that in the patch. So feel free to send an cleanup patch.

The cleanup patch has been sent. Please review it.
 
> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/2] gathdlc: Unset disconnect function in unref

[Zhang, Zhenhua]

Hi,

Zhenhua Zhang wrote:
> If we destroy PPP instance from g_at_ppp_unref, we should not invoke
> io disconnect function. ---
> gatchat/gathdlc.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/gatchat/gathdlc.c b/gatchat/gathdlc.c
> index 08a1939..0186e46 100644
> --- a/gatchat/gathdlc.c
> +++ b/gatchat/gathdlc.c
> @@ -278,6 +278,7 @@ void g_at_hdlc_unref(GAtHDLC *hdlc)
>   hdlc->record_fd = -1; }
> 
> + g_at_io_set_disconnect_function(hdlc->io, NULL, NULL);
>   g_at_io_unref(hdlc->io); hdlc->io = NULL;

Here the problem is that disconnect function could be invoked if remote IO is 
disconnected after our ppp instance is freed. So we should avoid to invoke 
io_disconnect() in below case.

Entering new phase: 5
PPP: lcp: pppcp_timeout: current state 5:STOPPING
PPP: lcp: pppcp_generate_event: current state 5:STOPPING
PPP: event: 5 (TO-), action: 803, new_state: 3 (STOPPED)
PPP: lcp: pppcp_this_layer_finished: current state 3:STOPPED
Entering new phase: 0
ofonod[3114]: src/emulator.c:ppp_disconnect() 
Server: > \r\nNO CARRIER\r\n
ofonod[3114]: Pcui:< \r\n^BOOT:20291346,0,0,0,20\r\n
Server: < AT+CFUN=0\r
ofonod[3114]: src/emulator.c:cfun_cb() set CFUN to 0
Server: > \r\nOK\r\n


(gdb) bt
#0  0x0806faf6 in pppcp_generate_event (data=0x95bfde0, event_type=DOWN, 
packet=0x0, len=0)
at gatchat/ppp_cp.c:638
#1  0x0806e9cd in io_disconnect (user_data=0x95bfde8) at gatchat/gatppp.c:349
#2  0x001ea504 in g_source_callback_unref (cb_data=0x95a8678)
at /build/buildd/glib2.0-2.22.3/glib/gmain.c:1077
#3  0x001eaace in g_source_destroy_internal (source=0x95a86b0, context=, have_lock=1)
at /build/buildd/glib2.0-2.22.3/glib/gmain.c:856
#4  0x001eaedb in g_main_dispatch (context=0x95a5f80) at 
/build/buildd/glib2.0-2.22.3/glib/gmain.c:1985
#5  IA__g_main_context_dispatch (context=0x95a5f80) at 
/build/buildd/glib2.0-2.22.3/glib/gmain.c:2513
#6  0x001ee730 in g_main_context_iterate (context=0x95a5f80, block=, dispatch=1, 
self=0x95a6c58) at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2591
#7  0x001eeb9f in IA__g_main_loop_run (loop=0x95a5ef0) at 
/build/buildd/glib2.0-2.22.3/glib/gmain.c:2799
#8  0x08094548 in main (argc=1, argv=0xbffb8ba4) at src/main.c:227
(gdb) frame 1
#1  0x0806e9cd in io_disconnect (user_data=0x95bfde8) at gatchat/gatppp.c:349
349 pppcp_signal_down(ppp->lcp);
(gdb) p ppp
$6 = 
(gdb) info local
No locals.
(gdb) 

> --
> 1.6.3.3
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Modem emulator and DUN server side for oFono and BlueZ

[Zhang, Zhenhua]

Hi Suraj,

suraj wrote:
> Hi Zhenhua,
> 
> 
> On Wed, 2010-05-05 at 06:27 +0530, Zhang, Zhenhua wrote:
>> Hi Padovan,
>> 
>> Gustavo F. Padovan wrote:
>>> Hi Zhenhua,
>>> 
>>> * Zhang, Zhenhua  [2010-04-27 15:53:54
>>> +0800]: 
>>> 
>>>> Hi,
>>>> 
>>>> I am now working on modem emulator and one usage is for DUN
>>> server role. Since Padovan is working on client role, it's
>>> good to share my rough thinking for server side
>>> implementation. Here are the simple steps I have:
>>>> 
>>>> 1. Create an oFono emulator atom in oFono. It's the emulator
>>> manager that could create DUN, HFP AG or SPP type emulators.
>>> It exposes dbus methods like CreateEmulator, DestroyEmulator,
>>> GetProperty, etc.
>>>> 
>>>> 2. DUN agent server in BlueZ watch oFono and call
>>> CreateEmulator and pass the file descriptor to oFono. This
>>> server could further implement HFP AG and SPP connection.
>>> 
>>> 
>>> Shouldn't the emulator register itself on the BlueZ agent server?
>> 
>> It's fine to register the emulator like HFP client. In this
> way, we might able to share the agent with DUN server as well. Thanks.
>> 
>>> 
>>> --
>>> Gustavo F. Padovan
>>> http://padovan.org
>>> ___
>>> ofono mailing list
>>> ofono@ofono.org
>>> http://lists.ofono.org/listinfo/ofono
>> 
>> 
>> 
>> Regards,
>> Zhenhua
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-bluetooth" in the body of a message to
>> majord...@vger.kernel.org 
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Do you have DUNP server emulator implemented?
> I was thinking about implementing the same. But would like to use your
> implementation if you have already done it.
> 
> Regards
> Suraj

Yes, I am working DUN server part now. (I assume 'DUNP' you mentioned is 'DUN', 
dialing up networking). I am trying to submit patches to upstream now. Hope it 
could be ready asap so you can try it if interested. Thanks.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/5] test-server: Add PPP server support

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>>> static void server_destroy(gpointer user)
>>> @@ -706,15 +825,11 @@ static void server_destroy(gpointer user)
>>> 
>>> static void set_raw_mode(int fd)
>>> {
>>> -   struct termios options;
>>> -
>>> -   tcgetattr(fd,&options);
>>> -
>>> -   /* Set TTY as raw mode to disable echo back of input characters
>>> -* when they are received from Modem to avoid feedback loop */
>>> -   options.c_lflag&= ~(ICANON | ECHO | ECHOE | ISIG); +struct
>>> termios ti; 
>>> 
>>> -   tcsetattr(fd, TCSANOW,&options);
>>> +   tcflush(fd, TCIOFLUSH);
>>> +   cfmakeraw(&ti);
>>> +   tcsetattr(fd, TCSANOW,&ti);
>>> }
>>> 
>>> static gboolean create_tty(const char *modem_path)
>> 
>> I found above changes does not contain latest git tree. The
> part of change is necessary when I tried to use bluetooth
> serial proxy between two machines. Without cfmakeraw, the
> server responses:
>>  '\r\nOK\r\n'
>> would change to:
>>  '\n\nOK\n\n'
>> 
>> And this issue doesn't exist if both server and client on the same
>> machine. 
> 
> The above code was causing valgrind to complain, so I left it out,
> apologies for not mentioning it, had a bit of a filesystem disaster
> happen after I pushed :) 
> 
> The present code seems to be completely in line with man cfmakeraw. 
> The cause is probably more subtle or has to do with the RFCOMM tty
> layer in the kernel.  Could you please investigate some more?

The problem lies in that we don't turn off ICRNL flags. If we turns off ICRNL, 
the problem is gone.

ICRNL  Translate carriage return to newline on input (unless IGNCR is 
set).

I still recommend to replace current code with cfmakeraw(), so that we don't 
worry about lower level settings. We just want tty layer passing all characters 
to our peer correctly.

> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/5] test-server: Add PPP server support

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>>> static void server_destroy(gpointer user)
>>> @@ -706,15 +825,11 @@ static void server_destroy(gpointer user)
>>> 
>>> static void set_raw_mode(int fd)
>>> {
>>> -   struct termios options;
>>> -
>>> -   tcgetattr(fd,&options);
>>> -
>>> -   /* Set TTY as raw mode to disable echo back of input characters
>>> -* when they are received from Modem to avoid feedback loop */
>>> -   options.c_lflag&= ~(ICANON | ECHO | ECHOE | ISIG); +struct
>>> termios ti; 
>>> 
>>> -   tcsetattr(fd, TCSANOW,&options);
>>> +   tcflush(fd, TCIOFLUSH);
>>> +   cfmakeraw(&ti);
>>> +   tcsetattr(fd, TCSANOW,&ti);
>>> }
>>> 
>>> static gboolean create_tty(const char *modem_path)
>> 
>> I found above changes does not contain latest git tree. The
> part of change is necessary when I tried to use bluetooth
> serial proxy between two machines. Without cfmakeraw, the
> server responses:
>>  '\r\nOK\r\n'
>> would change to:
>>  '\n\nOK\n\n'
>> 
>> And this issue doesn't exist if both server and client on the same
>> machine. 
> 
> The above code was causing valgrind to complain, so I left it out,
> apologies for not mentioning it, had a bit of a filesystem disaster
> happen after I pushed :) 
> 
> The present code seems to be completely in line with man cfmakeraw. 
> The cause is probably more subtle or has to do with the RFCOMM tty
> layer in the kernel.  Could you please investigate some more?

Okay. I will investigate more about tty issues.

> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/3] huawei: Add Huawei EM770 modem support

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua Zhang,
> 
>> Huawei EM770W is a 3G WCDMA modem that supports
>> HSPA/UMTS/EDGE/GPRS/GSM data service and WCDMA/GSM short message
>> services. It also has voice call capability that supports both 2G
>>  and 3G network. --- plugins/huawei.c|   31
>>  ++- plugins/ofono.rules |3 +++
>>  plugins/udev.c  |3 +++
>>  3 files changed, 36 insertions(+), 1 deletions(-)
>> 
>> diff --git a/plugins/udev.c b/plugins/udev.c
>> index 09ee93e..7d34b0b 100644
>> --- a/plugins/udev.c
>> +++ b/plugins/udev.c
>> @@ -227,6 +227,9 @@ static void add_huawei(struct ofono_modem *modem,
>>  const char *name = udev_list_entry_get_name(entry);
>>  type = udev_list_entry_get_value(entry);
>> 
>> +if (g_str_equal(name, "ID_MODEL_ID") == TRUE)
>> +ofono_modem_set_string(modem, "Model", type);
>> +
> 
> so this is the part that I don't like. I prefer we have some udev
> rules that create OFONO_HUAWEI_VOICE=1 and we use that as indicator
> to enable voice capabilities or not. 

Okay. Will resend out patches and rebase it to latest git tree. Thanks.
 
> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Crash in at_gprs_context_remove()

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Hi Kalle,
> 
> Kalle Valo wrote:
>> Hi,
>> 
>> (gdb) bt
>> #0  0x7790b642 in IA__g_atomic_int_exchange_and_add   
>> (atomic=0x0, val=-1) at
>> /build/buildd/glib2.0-2.25.8/glib/gatomic-gcc.c:30 #1
>>0x004325a3 in g_at_ppp_unref (ppp=0x0) at
>> gatchat/gatppp.c:448 #2  0x00448e12 in
>> at_gprs_context_remove (gc=0x6e2f50) at
>> drivers/atmodem/gprs-context.c:260 #3  0x004923c9 in 
> 
> As Denis has pointed out, we can add a check for gcd->ppp in
> at_gprs_context_remove() to avoid this crash.
> 
> When I tried to activate & deactivate context on my Huawei
> EM770W modem, I see kernel module usb_serial warning.
> 
> [ cut here ]
> WARNING: at
> /build/buildd/linux-2.6.31/drivers/usb/serial/usb-serial.c:460
> serial_ioctl+0x99/0xa0 [usbserial]()
> Hardware name: 7661BL4
> Modules linked in: tun option usbserial usb_storage hidp
> aes_i586 aes_generic ppdev binfmt_misc bridge stp bnep btusb
> joydev snd_hda_codec_analog pcmcia snd_hda_intel snd_hda_codec
> snd_hwdep snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb
> snd_seq_dummy uvcvideo videodev v4l1_compat snd_seq_oss
> yenta_socket rsrc_nonstatic ricoh_mmc pcmcia_core iwlagn
> iwlcore mac80211 sdhci_pci sdhci psmouse serio_raw
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device cfg80211 thinkpad_acpi led_class nvram snd
> soundcore snd_page_alloc heci(C) lp parport usbhid dm_raid45
> xor fbcon tileblit font bitblit softcursor ohci1394 e1000e
> ieee1394 i915 drm i2c_algo_bit video output intel_agp agpgart
> Pid: 5180, comm: ofonod Tainted: G C 2.6.31-16-generic
> #53-Ubuntu Call Trace:
> [] warn_slowpath_common+0x6d/0xa0
> [] ? serial_ioctl+0x99/0xa0 [usbserial]
> [] ? serial_ioctl+0x99/0xa0 [usbserial]
> [] warn_slowpath_null+0x15/0x20
> [] serial_ioctl+0x99/0xa0 [usbserial]
> [] ? tty_buffer_flush+0x54/0xe0
> [] ? serial_ioctl+0x0/0xa0 [usbserial]
> [] tty_ioctl+0x77/0x620
> [] ? tty_ioctl+0x0/0x620
> [] vfs_ioctl+0x1c/0x90
> [] ? putname+0x26/0x40
> [] do_vfs_ioctl+0x71/0x310
> [] sys_ioctl+0x5f/0x80
> [] ? sys_open+0x29/0x40
> [] syscall_call+0x7/0xb
> ---[ end trace ac231b55ebb1fdca ]---
> 
> When I shutdown the oFono, kernel reports:
>   tty_port_close_start: tty->count = 1 port count = 0.
> 
> Any ideas?

I observed the warning shows up when /dev/ttyUSB2 send us any intermediate 
result. If I remove gprs atom and recreate it in huawei_disconnect, the kernel 
warning is gone. Does anyone see the same problem in other Huawei modem? If 
not, I assume it's a problem only for EM770 modem. (I don't have other Huawei 
modem at hand)

Thanks,
Zhenhua

>> 
>> --
>> Kalle Valo
>> ___
>> ofono mailing list
>> ofono@ofono.org
>> http://lists.ofono.org/listinfo/ofono
> 
> 
> 
> Regards,
> Zhenhua



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Crash in at_gprs_context_remove()

[Zhang, Zhenhua]

Hi Kalle,

Kalle Valo wrote:
> Hi,
> 
> (gdb) bt
> #0  0x7790b642 in IA__g_atomic_int_exchange_and_add
>(atomic=0x0, val=-1) at
> /build/buildd/glib2.0-2.25.8/glib/gatomic-gcc.c:30 #1 
> 0x004325a3 in g_at_ppp_unref (ppp=0x0) at
>gatchat/gatppp.c:448 #2  0x00448e12 in
> at_gprs_context_remove (gc=0x6e2f50) at
> drivers/atmodem/gprs-context.c:260 #3  0x004923c9 in

As Denis has pointed out, we can add a check for gcd->ppp in 
at_gprs_context_remove() to avoid this crash.

When I tried to activate & deactivate context on my Huawei EM770W modem, I see 
kernel module usb_serial warning.

[ cut here ]
WARNING: at /build/buildd/linux-2.6.31/drivers/usb/serial/usb-serial.c:460 
serial_ioctl+0x99/0xa0 [usbserial]()
Hardware name: 7661BL4
Modules linked in: tun option usbserial usb_storage hidp aes_i586 aes_generic 
ppdev binfmt_misc bridge stp bnep btusb joydev snd_hda_codec_analog pcmcia 
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss arc4 snd_pcm 
ecb snd_seq_dummy uvcvideo videodev v4l1_compat snd_seq_oss yenta_socket 
rsrc_nonstatic ricoh_mmc pcmcia_core iwlagn iwlcore mac80211 sdhci_pci sdhci 
psmouse serio_raw snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer 
snd_seq_device cfg80211 thinkpad_acpi led_class nvram snd soundcore 
snd_page_alloc heci(C) lp parport usbhid dm_raid45 xor fbcon tileblit font 
bitblit softcursor ohci1394 e1000e ieee1394 i915 drm i2c_algo_bit video output 
intel_agp agpgart
Pid: 5180, comm: ofonod Tainted: G C 2.6.31-16-generic #53-Ubuntu
Call Trace:
 [] warn_slowpath_common+0x6d/0xa0
 [] ? serial_ioctl+0x99/0xa0 [usbserial]
 [] ? serial_ioctl+0x99/0xa0 [usbserial]
 [] warn_slowpath_null+0x15/0x20
 [] serial_ioctl+0x99/0xa0 [usbserial]
 [] ? tty_buffer_flush+0x54/0xe0
 [] ? serial_ioctl+0x0/0xa0 [usbserial]
 [] tty_ioctl+0x77/0x620
 [] ? tty_ioctl+0x0/0x620
 [] vfs_ioctl+0x1c/0x90
 [] ? putname+0x26/0x40
 [] do_vfs_ioctl+0x71/0x310
 [] sys_ioctl+0x5f/0x80
 [] ? sys_open+0x29/0x40
 [] syscall_call+0x7/0xb
---[ end trace ac231b55ebb1fdca ]---

When I shutdown the oFono, kernel reports:
tty_port_close_start: tty->count = 1 port count = 0.

Any ideas?

> 
> --
> Kalle Valo
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua



em770.log
Description: em770.log
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/5] test-server: Add PPP server support

[Zhang, Zhenhua]

Hi Denis,

Zhenhua Zhang wrote:
> So that gsmdial and wvdial could talk to test-server and establish
> PPP connection. ---
> gatchat/test-server.c |  131
> ++---
> 1 files changed, 123 insertions(+), 8 deletions(-)
> 
> diff --git a/gatchat/test-server.c b/gatchat/test-server.c
> index 5c1cfa4..96faab4 100644
> --- a/gatchat/test-server.c
> +++ b/gatchat/test-server.c
>
<--snip-->

> static void server_destroy(gpointer user)
> @@ -706,15 +825,11 @@ static void server_destroy(gpointer user)
> 
> static void set_raw_mode(int fd)
> {
> - struct termios options;
> -
> - tcgetattr(fd, &options);
> -
> - /* Set TTY as raw mode to disable echo back of input characters
> -  * when they are received from Modem to avoid feedback loop */
> - options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); +   struct
> termios ti; 
> 
> - tcsetattr(fd, TCSANOW, &options);
> + tcflush(fd, TCIOFLUSH);
> + cfmakeraw(&ti);
> + tcsetattr(fd, TCSANOW, &ti);
> }
>
> static gboolean create_tty(const char *modem_path)

I found above changes does not contain latest git tree. The part of change is 
necessary when I tried to use bluetooth serial proxy between two machines. 
Without cfmakeraw, the server responses:
'\r\nOK\r\n'
would change to:
'\n\nOK\n\n'

And this issue doesn't exist if both server and client on the same machine.

> --
> 1.6.3.3
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/6] gatppp: Add PPP server extension

[Zhang, Zhenhua]

Hi Denis,

Zhang, Zhenhua wrote:
> Hi Denis,
> 
>> As mentioned above, if Primary / Secondary NBNS server is sent
>> by the client,
>> we need to Conf-Rej just those options to the client.  Any
>> other unrecognized
>> options should also be Conf-Rejected.  The order is important
>> here, read the
>> spec for details.  The IP Address, DNS1/DNS2 should not be
>> Conf-Rejected.
> 
> Looks like we need more Conf-Nak than Conf-Reject in ipcp_rcr. :-)
> 
> As PPP client, actually I think we don't need to send NBNS
> request at all. It's clear that pppd client only requests
> IP/DNS in Conf-Req. Secondly, if server sent us empty
> Conf-Req, the client should request server IP address in
> Conf-Nak response, instead of Conf-Rej all options. Once we
> get local_addr from server, we return Conf-Ack in ipcp_rcr and
> don't request server IP any more.
> 
> See attached pppd.log for details.

Ops, forgot the attachment. Attached again.
 
>>> +   if (ipcp->is_server) {
>>> +   guint8 *options;
>>> +   guint16 len;
>>> +
>>> +   /* Reject if we have not assign client address yet */
>>> +   if (ipcp->peer_addr == 0 && ipcp->dns1 == 0 && ipcp->dns2 == 0)
>>> +   goto reject;
>> 
>> Actually you should be NAKing here, not Rejecting.  Reject
>> means you don't
>> support this option at all.
> 
> Okay.
> 
>>> +
>>> +   /* Acknowledge client options if it matches with server options
>>> +*/ +   if (ipcp->peer_addr == peer_addr &&
>>> +   ipcp->dns1 == dns1 &&
>> ipcp->dns2 == dns2 &&
>>> +   ipcp->nbns1 == nbns1 &&
>> ipcp->nbns2 == nbns2)
>>> +   return RCR_ACCEPT;
>>> +
>>> +   /* Send client IP/DNS/NBNS information in the config options */
>>> +   options =
> ipcp_generate_peer_config_options(ipcp, &len); +  if
>>> (!options) +goto reject;
>>> +
>>> +   *new_len = len;
>>> +   *new_options = options;
>>> +
>>> +   return RCR_NAK;
>>> +   }
>>> +
>>> +   /* Client */
>>> +   if (peer_addr && ipcp->peer_addr == 0) {
>>> +   /* RFC 1332 section 3.3
>>> +* As client, accept the server IP as peer's address +  
>>>  */
>>> +   ipcp->peer_addr = peer_addr;
>>> +
> 
> As client, can we just accept peer_addr as long as it's no
> zero, and return Conf-Ack? No matter what ipcp->peer_addr is.
> 
>>> return RCR_ACCEPT;
>>> +   }
>>> 
>>> +reject:
>>> /* Reject all options */
>>> *new_len = ntohs(packet->length) - sizeof(*packet);
>>> *new_options = g_memdup(packet->data, *new_len);
>>> @@ -317,7 +446,7 @@ struct pppcp_data *ipcp_new(GAtPPP *ppp)}
>>> 
>>> pppcp_set_data(pppcp, ipcp);
>>> -   ipcp_reset_config_options(ipcp);
>>> +   ipcp_reset_client_config_options(ipcp);
>>> pppcp_set_local_options(pppcp, ipcp->options, ipcp->options_len);
>>> 
>>> return pppcp;
>>> 
>> 
>> Regards,
>> -Denis
> 
> 
> 
> Regards,
> Zhenhua
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua



pppd.log
Description: pppd.log
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/6] gatppp: Add PPP server extension

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> 1. Add interface to set PPP server info by g_at_ppp_set_server_info.
>> 2. Pass local and peer address through IPCP handshaking.
> 
> Ok getting pretty close now :)
> 
>> +static void ipcp_reset_server_config_options(struct ipcp_data
>> *ipcp) +{ +  ipcp->req_options = REQ_OPTION_IPADDR;
> 
> Might want to only request IP Addr if local_addr is not zero.
> Just like in
> set_server_info.

Ok. Local updated.
 
>> +
>> +ipcp_generate_config_options(ipcp);
>> +}
>> +
> 
> 
> 
>> @@ -167,7 +211,7 @@ static void ipcp_rca(struct pppcp_data *pppcp,
>> 
>>  switch (ppp_option_iter_get_type(&iter)) {
>>  case IP_ADDRESS:
>> -memcpy(&ipcp->ipaddr, data, 4);
>> +memcpy(&ipcp->local_addr, data, 4);
>>  break;
>>  case PRIMARY_DNS_SERVER:
>>  memcpy(&ipcp->dns1, data, 4);
> 
> You might not want to do anything here in the case of a server role.

Agree. So in case of a server role, we simply do nothing in ipcp_rca and 
ipcp_rcn_nak. Good catch.

>> @@ -204,7 +248,7 @@ static void ipcp_rcn_nak(struct pppcp_data
>>  *pppcp, case IP_ADDRESS: 
>> g_print("Setting suggested ip
>>  addr\n"); ipcp->req_options |= REQ_OPTION_IPADDR;
>> -memcpy(&ipcp->ipaddr, data, 4);
>> +memcpy(&ipcp->local_addr, data, 4);
>>  break;
>>  case PRIMARY_DNS_SERVER:
>>  g_print("Setting suggested dns1\n");
> 
> Again, probably don't want to set the local_addr in the case
> of a server role.
> 
>> @@ -269,17 +313,102 @@ static void ipcp_rcn_rej(struct pppcp_data
>>  *pppcp, pppcp_set_local_options(pppcp, ipcp->options,
>> ipcp->options_len);  } 
>> 
>> +static guint8 *ipcp_generate_peer_config_options(struct ipcp_data
>> *ipcp, + guint16
> *new_len)
>> +{
>> +guint8 *options;
>> +guint16 len = 0;
>> +
>> +options = g_try_new0(guint8, MAX_CONFIG_OPTION_SIZE); + if
>> (!options) + return NULL;
>> +
>> +FILL_IP(options, TRUE, IP_ADDRESS, &ipcp->peer_addr);
>> +FILL_IP(options, TRUE, PRIMARY_DNS_SERVER, &ipcp->dns1);
>> +FILL_IP(options, TRUE, SECONDARY_DNS_SERVER, &ipcp->dns2);
>> +FILL_IP(options, TRUE, PRIMARY_NBNS_SERVER, &ipcp->nbns1);
>> +FILL_IP(options, TRUE, SECONDARY_NBNS_SERVER, &ipcp->nbns2); +
>> +*new_len = MAX_CONFIG_OPTION_SIZE;
> 
> Don't use MAX_CONFIG_OPTION_SIZE, instead use len (which is
> filled properly by
> the FILL_IP macro)  Also, we shouldn't bother supporting NBNS,
> lets never
> suggest those options as a server or set them in set_server_info.

Fixed, so I have removed NBNS parameters for set_server_info() at all.

>> +
>> +return options;
>> +}
>> +
>>  static enum rcr_result ipcp_rcr(struct pppcp_data *pppcp,
>>  const struct
> pppcp_packet *packet,
>>  guint8 **new_options,
> guint16 *new_len)
>>  {
>>  struct ppp_option_iter iter;
>> +struct ipcp_data *ipcp = pppcp_get_data(pppcp);
>> +guint32 peer_addr = 0;
>> +guint32 dns1 = 0;
>> +guint32 dns2 = 0;
>> +guint32 nbns1 = 0;
>> +guint32 nbns2 = 0;
>> 
>>  ppp_option_iter_init(&iter, packet);
>> 
>> -if (ppp_option_iter_next(&iter) == FALSE)
>> +while (ppp_option_iter_next(&iter) == TRUE) {
>> +const guint8 *data = ppp_option_iter_get_data(&iter); +
>> +switch (ppp_option_iter_get_type(&iter)) {
>> +case IP_ADDRESS:
>> +memcpy(&peer_addr, data, 4);
>> +break;
>> +case PRIMARY_DNS_SERVER:
>> +memcpy(&dns1, data, 4);
>> +break;
>> +case SECONDARY_DNS_SERVER:
>> +memcpy(&dns2, data, 4);
>> +break;
>> +case PRIMARY_NBNS_SERVER:
>> +memcpy(&nbns1, data, 4);
>> +break;
>> +case SECONDARY_NBNS_SERVER:
>> +memcpy(&nbns2, data, 4);
>> +break;
>> +default:
>> +break;
>> +}
>> +}
>> +
> 
> As mentioned above, if Primary / Secondary NBNS server is sent
> by the client,
> we need to Conf-Rej just those options to the client.  Any
> other unrecognized
> options should also be Conf-Rejected.  The order is important
> here, read the
> spec for details.  The IP Address, DNS1/DNS2 should not be
> Conf-Rejected. 

Looks like we need more Conf-Nak than Conf-Reject in ipcp_rcr. :-)

As PPP client, actually I think we don't need to send NBNS request at all. It's 
clear that pppd client only requests IP/DNS in Conf-Req. Secondly, if server 
sent us empty Conf-Req, the client should request server IP address in Conf-Nak 
response, instead of Con

RE: [PATCH] mbmmodem: Fix ip netmask should be 255.255.255.255

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> Change static IP netmask to 255.255.255.255.
>> ---
>>  drivers/mbmmodem/gprs-context.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/drivers/mbmmodem/gprs-context.c
> b/drivers/mbmmodem/gprs-context.c
>> index cca5087..2d0e4e2 100644
>> --- a/drivers/mbmmodem/gprs-context.c
>> +++ b/drivers/mbmmodem/gprs-context.c
>> @@ -48,7 +48,7 @@
>> 
>>  #define MAX_DNS 5
>> 
>> -#define STATIC_IP_NETMASK "255.255.255.248"
>> +#define STATIC_IP_NETMASK "255.255.255.255"
>> 
>>  static const char *none_prefix[] = { NULL };
>>  static const char *e2ipcfg_prefix[] = { "*E2IPCFG:", NULL };
> 
> did you see a problem with this or why do you propose this change. The
> old f35xx gives this netmask back when using DHCP. What does the f36xx
> and later return when using DHCP?

I tested f3607gw again and found the netmask 255.255.255.248. Originally, I 
thought it should be consistent with atmodem netmask value. Why the netmask is 
xx.248 instead of xx.255? If I use wvdial to dial GPRS on f3607gw, the netmask 
is 255.255.255.255 from ifconfig output.
 
> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Demo client

[Zhang, Zhenhua]

Hi Andrew,

andrzej zaborowski wrote:
> Hi,
> 
> I have a minimal GUI client that I recently started using for testing
> some new ofono features, and thought that others might want to use
> something like that too.  It currently only supports Voicecall atom
> (two-party calls only), voicemail, PIN entry and Sim Toolkit menus.
> Adding new atoms is fairly easy, for example adding the menus only
> took about an hour.  It's a little rough as it's a quick development
> (for example error handling is poor).
> 
> git clone http://openstreetmap.pl/balrog/webfono.git
> 
> The program is browser based (in javascript) and needs a tiny http
> server running, the server is a 10kb python script excuted with
> ./gateway.py (depends on python3, glib and dbus bindings installed).
> The javascript part is only tested in Firefox.  It can run remotely
> but probably makes most sense on localhost or on ethernet.  If
> anything goes wrong, you can always hit Refresh (F5) and it should go
> back to a sane state. 
> 
> The sim toolkit support needs the patches I just sent, I tested it
> with the mbmmodem plugin, and three different SIMs (not only a certain
> AU vodafone card, also a local Polish one) and navigating the menu
> seems very stable, I can even go into "My Vodafone" and hit "STK
> version" and the sim gives some info about itself.
> (http://openstreetmap.pl/balrog/ofono-screen-stk0.png
> http://openstreetmap.pl/balrog/ofono-screen-stk1.png)

The GUI client looks awesome! I really like it. :-)

> Regards
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 03/11] gatppp: Add PPP server extension

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
 +void ipcp_set_server_info(struct pppcp_data *pppcp, guint32
 local_addr, +  guint32
> peer_addr, +  guint32 dns1, guint32 dns2,
 +  guint32 nbns1, guint32 nbns2)
 +{
 +  struct ipcp_data *ipcp = pppcp_get_data(pppcp);
 +
 +  ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
 +  REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
 +  REQ_OPTION_NBNS2;
 +
 +  ipcp->local_addr = local_addr;
 +  ipcp->peer_addr = peer_addr;
 +  ipcp->dns1 = dns1;
 +  ipcp->dns2 = dns2;
 +  ipcp->nbns1 = nbns1;
 +  ipcp->nbns2 = nbns2;
 +
 +  ipcp_generate_config_options(ipcp);
>>> 
>>> Please note that this function is currently having no effect,
>>> you're missing a call to pppcp_set_local_options.  However, in the
>>> case of a server, we actually do not want to request DNS or NBNS,
>>> and we should only send our local address to the peer if it is
>>> non-zero.  Please note that all PPP modems we have encountered so
>>> far, do not send their local IP address in a Configure- Request. 
>>> Thus calling ipcp_set_server_info should end up generating an empty
>>> Configure-Request or with only the local IP address present. 
>> 
>> It's confused me a little. Please correct me if I am wrong. I think
>>  PPP modem should send their local IP address to peer in a
>>  Configure-Request. So client could accept the peer address in
>> ipcp_rcr. 
> 
> This is correct if the PPP server wants to do so, it is perfectly OK
> for the server not to send its IP address (e.g. if it doesn't have
> one.)  This is what we observe on most PPP modems.

Okay. That's fine. At least, PPP server need to send peer_addr in Conf-Nak 
reply. Client 'thinks' it's server address.

>> 
>> In the case of a server, ipcp_set_server_info() should set local,
>>  peer, DNS and NBNS info and call pppcp_set_local_options(). And
>>  server only send our local address to peer in a Configure-Request.
> 
> I'd modify this slightly.  If ipcp_set_server_info is called with
> server's local address as 0, then don't even send IP-Address in a
> configure Request. This wouldn't make sense, in effect the server is
> asking the client to provide its IP address. Otherwise, go ahead and
> send it (as the client will simply ack).

No problems. If server local address is zero, we don't send IP in a configure 
request.

>> 
 +}
 +
  static void ipcp_reset_config_options(struct ipcp_data *ipcp)  {
ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
REQ_OPTION_NBNS2;
 -  ipcp->ipaddr = 0;
 +  ipcp->local_addr = 0;
>>> 
>>> In the case of a server, the local_address should not be reset.
>> 
>> It seems we need to add a flag in ipcp_data to indicate whether it's
>>  server or not. Does it make sense?
> 
> Might be a good idea.
> 
> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/5] gatppp: Add PPP server extension

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>>  static enum rcr_result ipcp_rcr(struct pppcp_data *pppcp,
>>  const struct
> pppcp_packet *packet,
>>  guint8 **new_options,
> guint16 *new_len)
>>  {
>>  struct ppp_option_iter iter;
>> +struct ipcp_data *ipcp = pppcp_get_data(pppcp);
>> +guint32 peer_addr = 0;
>> +guint32 dns1 = 0;
>> +guint32 dns2 = 0;
>> +guint32 nbns1 = 0;
>> +guint32 nbns2 = 0;
>> 
>>  ppp_option_iter_init(&iter, packet);
>> 
>> -if (ppp_option_iter_next(&iter) == FALSE)
>> -return RCR_ACCEPT;
>> +while (ppp_option_iter_next(&iter) == TRUE) {
>> +const guint8 *data = ppp_option_iter_get_data(&iter); +
>> +switch (ppp_option_iter_get_type(&iter)) {
>> +case IP_ADDRESS:
>> +memcpy(&peer_addr, data, 4);
>> +break;
>> +case PRIMARY_DNS_SERVER:
>> +memcpy(&dns1, data, 4);
>> +break;
>> +case SECONDARY_DNS_SERVER:
>> +memcpy(&dns2, data, 4);
>> +break;
>> +case PRIMARY_NBNS_SERVER:
>> +memcpy(&nbns1, data, 4);
>> +break;
>> +case SECONDARY_NBNS_SERVER:
>> +memcpy(&nbns2, data, 4);
>> +break;
>> +default:
>> +break;
>> +}
>> +}
>> +
>> +if (peer_addr) {
>> +if (ipcp->peer_addr == 0) {
>> +/* RFC 1332 section 3.3
>> + * As client, accept the server IP as peer's address +  
>>  */
>> +ipcp->peer_addr = peer_addr;
>> +
>> +return RCR_ACCEPT;
> 
> I'm still confused about this part.  As client we should
> accept server's IP
> address as long as its non-zero.  Otherwise Conf-Rej the option.

Right, initially, client know nothing about server, so client->peer_addr is 
zero. Once client get a non-zero IP from configure option, we fill this IP as 
peer's IP address.

Looks like this IP is exposed as gateway to Connman. Maybe I could change it 
like:
if (ipcp->is_server == FALSE && ipcp->peer_addr == 0)

>> +} else if (ipcp->peer_addr == peer_addr && ipcp->dns1 == dns1
>> +&& ipcp->nbns1 == nbns1 &&
> ipcp->nbns2 == nbns2)
>> +/* As server, verify the client's info
> and then send
>> + * acknowledgement back
>> + */
>> +return RCR_ACCEPT;
>> +} else {
>> +/* Client requests server to send IP/DNS/NBNS information in the
>> + * config options +  */
>> +if (ipcp->peer_addr) {
>> +guint8 *options;
>> +guint16 len;
>> +
>> +options =
> ipcp_generate_peer_config_options(ipcp, &len);
>> +if (!options)
>> +goto reject;
>> +
>> +*new_len = len;
>> +*new_options = options;
>> +return RCR_NAK;
>> +}
> 
> Here we want to ensure that we nak the client's options for as
> long as the
> options don't match.  Even ipcp->peer_addr is 0 (e.g. we're allocating
> client's address via DHCP or something)

In theory, it's true. But I don't see a PPP modem without client's address 
here. Even in drivers/atmodem/gprs-context.c, we assume the PPP interface has a 
static IP instead of dynamic one.

Anyway, I will modify this part.

> Overall I think this code path is a little too complicated.
> Can you see
> whether you can clean it up a bit?

Okay, I will try to elimiate some conditional branchs here.
 
> Regards,
> -Denis



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 0/5] Add PPP server support

[Zhang, Zhenhua]

Hi,

I updated patch 1/5 according to the comments. The rest 4 patches were 
unchanged with the previous version.

Please review them. Thanks!

Regards,
Zhenhua



___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 03/11] gatppp: Add PPP server extension

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> 1. Add interface to set PPP server info by g_at_ppp_set_server_info.
>> 2. Pass local and peer address through IPCP handshaking.
>> ---
> 
> Its great that you're working on the PPP Server extensions.
> Can I get you to
> submit a patch taking ownership of this task?  See ofono/TODO 'PPP
> Server support'.
> 
>> +static void ipcp_generate_peer_config_options(struct ipcp_data
>> *ipcp) +{ +  guint16 len = 0;
>> +
>> +FILL_IP(ipcp->req_options & REQ_OPTION_IPADDR,
>> +IP_ADDRESS, &ipcp->peer_addr);
>> +FILL_IP(ipcp->req_options & REQ_OPTION_DNS1,
>> +PRIMARY_DNS_SERVER,
> &ipcp->dns1);
>> +FILL_IP(ipcp->req_options & REQ_OPTION_DNS2,
>> +SECONDARY_DNS_SERVER,
> &ipcp->dns2);
>> +FILL_IP(ipcp->req_options & REQ_OPTION_NBNS1,
>> +PRIMARY_NBNS_SERVER,
> &ipcp->nbns1);
>> +FILL_IP(ipcp->req_options & REQ_OPTION_NBNS2,
>> +SECONDARY_NBNS_SERVER,
> &ipcp->nbns2);
>> +
> 
> Using ipcp->req_options is the wrong thing here.  That is used
> for options
> sent in a Configure-Req.  Here you're filling in options to be
> sent in a
> Configure-Nak, Configure-Reject or a Configure-Ack.  You
> should simply be filling
> these in ipcp_rcr.  Feel free to modify the FILL_IP macro to take an
> additional destination parameter.

Okay. I will do that.

>> +ipcp->options_len = len;
>> +}
>> +
>> +void ipcp_set_server_info(struct pppcp_data *pppcp, guint32
>> local_addr, +guint32 peer_addr, +
>> guint32 dns1, guint32 dns2,
>> +guint32 nbns1, guint32 nbns2)
>> +{
>> +struct ipcp_data *ipcp = pppcp_get_data(pppcp);
>> +
>> +ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
>> +REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
>> +REQ_OPTION_NBNS2;
>> +
>> +ipcp->local_addr = local_addr;
>> +ipcp->peer_addr = peer_addr;
>> +ipcp->dns1 = dns1;
>> +ipcp->dns2 = dns2;
>> +ipcp->nbns1 = nbns1;
>> +ipcp->nbns2 = nbns2;
>> +
>> +ipcp_generate_config_options(ipcp);
> 
> Please note that this function is currently having no effect,
> you're missing a
> call to pppcp_set_local_options.  However, in the case of a server, we
> actually do not want to request DNS or NBNS, and we should
> only send our local
> address to the peer if it is non-zero.  Please note that all
> PPP modems we
> have encountered so far, do not send their local IP address in
> a Configure-
> Request.  Thus calling ipcp_set_server_info should end up
> generating an empty
> Configure-Request or with only the local IP address present.

It's confused me a little. Please correct me if I am wrong. I think PPP modem 
should send their local IP address to peer in a Configure-Request. So client 
could accept the peer address in ipcp_rcr.

In the case of a server, ipcp_set_server_info() should set local, peer, DNS and 
NBNS info and call pppcp_set_local_options(). And server only send our local 
address to peer in a Configure-Request.

>> +}
>> +
>>  static void ipcp_reset_config_options(struct ipcp_data *ipcp)  {
>>  ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
>>  REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
>>  REQ_OPTION_NBNS2;
>> -ipcp->ipaddr = 0;
>> +ipcp->local_addr = 0;
> 
> In the case of a server, the local_address should not be reset.

It seems we need to add a flag in ipcp_data to indicate whether it's server or 
not. Does it make sense?

>> +ipcp->peer_addr = 0;
>>  ipcp->dns1 = 0;
>>  ipcp->dns2 = 0;
>>  ipcp->nbns1 = 0;
>> @@ -274,11 +321,54 @@ static enum rcr_result ipcp_rcr(struct
>>  pppcp_data *pppcp, guint8 **new_options, guint16 *new_len)
>>  {
>>  struct ppp_option_iter iter;
>> +struct ipcp_data *ipcp = pppcp_get_data(pppcp);
>> +guint32 peer_addr;
>> +guint32 dns1;
>> +guint32 dns2;
>> 
>>  ppp_option_iter_init(&iter, packet);
>> 
>> -if (ppp_option_iter_next(&iter) == FALSE)
>> -return RCR_ACCEPT;
> 
> Again, be careful here.  In the case of a client we should
> only accept the
> Server's IP-Address, nothing else.
> 
>> +while (ppp_option_iter_next(&iter) == TRUE) {
>> +const guint8 *data = ppp_option_iter_get_data(&iter); +
>> +switch (ppp_option_iter_get_type(&iter)) {
>> +case IP_ADDRESS:
>> +memcpy(&peer_addr, data, 4);
>> +break;
>> +case PRIMARY_DNS_SERVER:
>> +memcpy(&dns1, data, 4);
>> +break;
>> +case SECONDARY_DNS_SERVER:
>> +memcpy(&dns2, data, 4);
>> +break;
>> +default:
>> +break;
>>

RE: The error when run the /test/list-modems script

[Zhang, Zhenhua]

Hi, Ye,  

First, please send plain text mail to oFono mailing list next time. Please see 
my reply below.

Regards,
Zhenhua



From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On 
Behalf Of Huang, Ye
Sent: Monday, June 14, 2010 10:24 AM
To: ofono@ofono.org
Subject: The error when run the /test/list-modems script



Hi,

 

we meet the following problem when run ofonod

 

[test environment]

 OS: meego 0.90

 ofonod ver: 0.18

 modem : IFX6160

 test board : Intel CDK QS

 SIM card : 2g SIM card

 

[operation step]

1. power on test board(MRST CDK)

2. check ofonod has been startuped by ps command

3. run /usr/lib/ofono/test/list-modems test script

4. find below error.

 

could you help us analyze the possible reason of this problem?

i

 

＝＝

[r...@localhost test]# ./list-modems

[ /ifx_at ]

Powered = 1

Interfaces = org.ofono.DataConnectionManager org.ofono.Phonebook

org.ofono.NetworkRegistration org.ofono.CallMeter org.o

Model =  XMM2130

Manufacturer =  Ehs2agrRel6

Serial = *35955902412

Revision =  Undefined

[ org.ofono.DataConnectionManager ]

Status = registered

Powered = 1

Attached = 1

PrimaryContexts = /ifx_at/primarycontext1

RoamingAllowed = 1

[ org.ofono.Phonebook ]

[ org.ofono.NetworkRegistration ]

Status = registered

Strength = 87

LocationAreaCode = 4473

Mode = auto

Operator = CMCC

AvailableOperators = /ifx_at/operator/46000

Technology = GSM+EGPRS

CellId = 33258

[ org.ofono.CallMeter ]

[Zhenhua] It's clear that ofono meets some problems when get properties from 
CallMeter atom. Please kill ofonod and run 'OFONO_AT_DEBUG=1 ofonod -n -d '*'' 
to verbose ofono AT chat log. The log will help us to root cause the problem. 
Thanks.


Traceback (most recent call last):

  File "./list-modems", line 30, in 

object = dbus.Interface(bus.get_object('org.ofono', path),

  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 244, in

get_object

follow_name_owner_changes=follow_name_owner_changes)

  File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 241, in

__init__

self._named_service = conn.activate_name_owner(bus_name)

  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 183, in

activate_name_owner

self.start_service_by_name(bus_name)

  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 281, in

start_service_by_name

'su', (bus_name, flags)))

  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, 
in

call_blocking

message, timeout)

 

 

Best regards,
Ye 

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 11/11] gsmdial: Delay ppp_unref after IO processing

[Zhang, Zhenhua]

Hi,

Zhenhua Zhang wrote:
> ---
> gatchat/gsmdial.c |   17 +++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/gatchat/gsmdial.c b/gatchat/gsmdial.c
> index 59f1a5c..d6cacc5 100644
> --- a/gatchat/gsmdial.c
> +++ b/gatchat/gsmdial.c

I think we should delay the ppp shutdown stage until the LCP packet was well 
processed. I got valgrind result as below before I have patches 10/11 and 11/11.

Entering new phase: 0
PPP Link down: 6
==5332== Invalid write of size 2
==5332==at 0x805520D: new_bytes (gathdlc.c:154)
==5332==by 0x804F2E6: received_data (gatio.c:119)
==5332==by 0x40AFDAA: g_io_unix_dispatch (giounix.c:162)
==5332==by 0x4078E87: g_main_context_dispatch (gmain.c:1960)
==5332==by 0x407C72F: g_main_context_iterate (gmain.c:2591)
==5332==by 0x407CB9E: g_main_loop_run (gmain.c:2799)
==5332==by 0x804BE5D: main (gsmdial.c:702)
==5332==  Address 0x4382130 is 24 bytes inside a block of size 88 free'd
==5332==at 0x4024886: free (vg_replace_malloc.c:325)
==5332==by 0x4081195: g_free (gmem.c:190)
==5332==by 0x805557D: g_at_hdlc_unref (gathdlc.c:270)
==5332==by 0x8056316: g_at_ppp_unref (gatppp.c:463)
==5332==by 0x804AF20: ppp_disconnect (gsmdial.c:272)
==5332==by 0x8055CE9: ppp_dead (gatppp.c:204)
==5332==by 0x8055D1E: ppp_enter_phase (gatppp.c:214)
==5332==by 0x8055FE0: ppp_lcp_finished_notify (gatppp.c:317)
==5332==by 0x8057E27: lcp_finished (ppp_lcp.c:140)
==5332==by 0x80568DF: pppcp_this_layer_finished (ppp_cp.c:340)
==5332==by 0x8057446: pppcp_generate_event (ppp_cp.c:688)
==5332==by 0x8057B5B: pppcp_process_packet (ppp_cp.c:965)
==5332== 
==5332== Invalid write of size 4
==5332==at 0x8055216: new_bytes (gathdlc.c:155)
==5332==by 0x804F2E6: received_data (gatio.c:119)
==5332==by 0x40AFDAA: g_io_unix_dispatch (giounix.c:162)
==5332==by 0x4078E87: g_main_context_dispatch (gmain.c:1960)
==5332==by 0x407C72F: g_main_context_iterate (gmain.c:2591)
==5332==by 0x407CB9E: g_main_loop_run (gmain.c:2799)
==5332==by 0x804BE5D: main (gsmdial.c:702)
==5332==  Address 0x438212c is 20 bytes inside a block of size 88 free'd
==5332==at 0x4024886: free (vg_replace_malloc.c:325)
==5332==by 0x4081195: g_free (gmem.c:190)
==5332==by 0x805557D: g_at_hdlc_unref (gathdlc.c:270)
==5332==by 0x8056316: g_at_ppp_unref (gatppp.c:463)
==5332==by 0x804AF20: ppp_disconnect (gsmdial.c:272)
==5332==by 0x8055CE9: ppp_dead (gatppp.c:204)
==5332==by 0x8055D1E: ppp_enter_phase (gatppp.c:214)
==5332==by 0x8055FE0: ppp_lcp_finished_notify (gatppp.c:317)
==5332==by 0x8057E27: lcp_finished (ppp_lcp.c:140)
==5332==by 0x80568DF: pppcp_this_layer_finished (ppp_cp.c:340)
==5332==by 0x8057446: pppcp_generate_event (ppp_cp.c:688)
==5332==by 0x8057B5B: pppcp_process_packet (ppp_cp.c:965)
==5332== 
==5332== Invalid read of size 4
==5332==at 0x80552CB: new_bytes (gathdlc.c:167)
==5332==by 0x804F2E6: received_data (gatio.c:119)
==5332==by 0x40AFDAA: g_io_unix_dispatch (giounix.c:162)
==5332==by 0x4078E87: g_main_context_dispatch (gmain.c:1960)
==5332==by 0x407C72F: g_main_context_iterate (gmain.c:2591)
==5332==by 0x407CB9E: g_main_loop_run (gmain.c:2799)
==5332==by 0x804BE5D: main (gsmdial.c:702)
==5332==  Address 0x438216c is 84 bytes inside a block of size 88 free'd
==5332==at 0x4024886: free (vg_replace_malloc.c:325)
==5332==by 0x4081195: g_free (gmem.c:190)
==5332==by 0x805557D: g_at_hdlc_unref (gathdlc.c:270)
==5332==by 0x8056316: g_at_ppp_unref (gatppp.c:463)
==5332==by 0x804AF20: ppp_disconnect (gsmdial.c:272)
==5332==by 0x8055CE9: ppp_dead (gatppp.c:204)
==5332==by 0x8055D1E: ppp_enter_phase (gatppp.c:214)
==5332==by 0x8055FE0: ppp_lcp_finished_notify (gatppp.c:317)
==5332==by 0x8057E27: lcp_finished (ppp_lcp.c:140)
==5332==by 0x80568DF: pppcp_this_layer_finished (ppp_cp.c:340)
==5332==by 0x8057446: pppcp_generate_event (ppp_cp.c:688)
==5332==by 0x8057B5B: pppcp_process_packet (ppp_cp.c:965)
==5332== 
: > AT+CFUN=0\r
==5332== 
==5332== HEAP SUMMARY:
==5332== in use at exit: 8,854 bytes in 31 blocks
==5332==   total heap usage: 860 allocs, 829 frees, 3,139,527 bytes allocated
==5332== 
==5332== 248 bytes in 1 blocks are possibly lost in loss record 13 of 23
==5332==at 0x4023E7E: memalign (vg_replace_malloc.c:532)
==5332==by 0x4023EDB: posix_memalign (vg_replace_malloc.c:660)
==5332==by 0x409661D: slab_allocator_alloc_chunk (gslice.c:1136)
==5332==by 0x4097580: g_slice_alloc (gslice.c:661)
==5332==by 0x4076D75: g_list_prepend (glist.c:169)
==5332==by 0x4085A82: add_pending_null (goption.c:1119)
==5332==by 0x40868C6: parse_short_option (goption.c:1397)
==5332==by 0x4087EC1: g_option_context_parse (goption.c:1858)
==5332==by 0x804BB35: main (gsmdial.c:631)
==5332== 
==5332== 360 bytes in 3 blocks are possibly lost in loss record 14 of 23
==5332==at 0x4

RE: Huawei E1552 broken

[Zhang, Zhenhua]

Hi Kalle,

Kalle Valo wrote:
> Hi,
> 
> I mentioned this briefly on irc, but I'll inform it here as well. This
> patch broke ofono support for my Huawei E1552:
> 
> commit 6ab0b6f29acc8f6b2a5f3b94c02c405ee7318244
> Author: Marcel Holtmann 
> Date:   Sun Jun 6 15:51:36 2010 -0700
> 
>Fix detection of Huawei E220 and E270 modems
> 
> Huawei plugin uses /dev/ttyUSB1 for the event channel but for my modem
> it should be /dev/ttyUSB2. We need to solve this problem somehow, even
> if we need to add usb ids to ofono.rules.

Denis has already updated udev.c by commit 71ea72adf and now it detects 
interface number by ofono.rules. So I think you should add one more E1552 
specific item in ofono.rules with your product id and interface number, etc.
 
> --
> Kalle Valo
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH v2] atmodem: fix crash during context deactivation

[Zhang, Zhenhua]

Hi Valo,

Kalle Valo wrote:
> ---
> 
> drivers/atmodem/gprs-context.c |   56
> +---
> 1 files changed, 18 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/atmodem/gprs-context.c
> b/drivers/atmodem/gprs-context.c
> index ba5f0c0..794db8a 100644
> --- a/drivers/atmodem/gprs-context.c
> +++ b/drivers/atmodem/gprs-context.c
> @@ -65,22 +65,6 @@ struct gprs_context_data {
>   void *cb_data;  /*
> Callback data */
> };
> 
> -static void at_cgact_down_cb(gboolean ok, GAtResult *result,
> gpointer user_data) -{
> - struct cb_data *cbd = user_data;
> - ofono_gprs_context_cb_t cb = cbd->cb;
> - struct ofono_gprs_context *gc = cbd->user;
> - struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> - struct ofono_error error;
> -
> - if (ok)
> - gcd->active_context = 0;
> -
> - decode_at_error(&error, g_at_result_final_response(result)); -
> - cb(&error, cbd->data);
> -}
> -
> static void ppp_connect(const char *interface, const char *ip,
>   const char *dns1, const char *dns2,
>   gpointer user_data)
> @@ -104,13 +88,19 @@ static void
> ppp_disconnect(GAtPPPDisconnectReason reason, gpointer user_data)
>   struct ofono_gprs_context *gc = user_data;
>   struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> 
> + DBG("");
> +
> + g_at_chat_resume(gcd->chat);
> +
>   if (gcd->state == STATE_ENABLING) {
>   CALLBACK_WITH_FAILURE(gcd->up_cb, NULL, FALSE, NULL,
>   NULL, NULL, NULL, gcd->cb_data);
> - return;
> + } else if (gcd->state == STATE_DISABLING) {
> + CALLBACK_WITH_SUCCESS(gcd->down_cb, gcd->cb_data); +} else {
> + ofono_gprs_context_deactivated(gc, gcd->active_context);
> }
> 
> - ofono_gprs_context_deactivated(gc, gcd->active_context);
>   gcd->active_context = 0; gcd->state = STATE_IDLE;
> }
> @@ -118,13 +108,14 @@ static void
> ppp_disconnect(GAtPPPDisconnectReason reason, gpointer user_data)
> static gboolean setup_ppp(struct ofono_gprs_context *gc) {
>   struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> - GIOChannel *channel; +  GAtIO *io;
> +
> + io = g_at_chat_get_io(gcd->chat);
> 
> - channel = g_at_chat_get_channel(gcd->chat);
> - g_at_chat_unref(gcd->chat);
> + g_at_chat_suspend(gcd->chat);
> 
>   /* open ppp */
> - gcd->ppp = g_at_ppp_new(channel);
> + gcd->ppp = g_at_ppp_new_from_io(io);
> 
>   if (gcd->ppp == NULL)
>   return FALSE;

You should use g_at_chat_resume(gcd->chat) to resume the chat before you 
returns FALSE here.

> @@ -227,25 +218,14 @@ static void
> at_gprs_deactivate_primary(struct ofono_gprs_context *gc,
> ofono_gprs_context_cb_t cb, void *data)
> {
>   struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> - struct cb_data *cbd = cb_data_new(cb, data);
> - char buf[64];
> -
> - if (!cbd)
> - goto error;
> -
> - cbd->user = gc;
> 
> - snprintf(buf, sizeof(buf), "AT+CGACT=0,%u", id);
> + DBG("");
> 
> - if (g_at_chat_send(gcd->chat, buf, none_prefix,
> - at_cgact_down_cb, cbd, g_free) > 0)
> - return;
> -
> -error:
> - if (cbd)
> - g_free(cbd);
> + gcd->state = STATE_DISABLING;
> + gcd->down_cb = cb;
> + gcd->cb_data = data;
> 
> - CALLBACK_WITH_FAILURE(cb, data);
> + g_at_ppp_shutdown(gcd->ppp);
> }
> 
> static int at_gprs_context_probe(struct ofono_gprs_context *gc,
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 5/9] Move bluetooth utils from hfp.c to bluetooth.c

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> --- plugins/bluetooth.c |  482
> +++
> plugins/hfp.c   |  458
> 
> 2 files changed, 518 insertions(+), 422 deletions(-)
>
> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
> index b4fe676..fc89579 100644
> --- a/plugins/bluetooth.c
> +++ b/plugins/bluetooth.c
> +
> int bluetooth_register_uuid(const char *uuid, struct
> bluetooth_profile *profile) {
> + int err;
> +
>   if (uuid_hash)
>   goto done;
>
>   connection = ofono_dbus_get_connection();
>
> + bluetooth_watch = g_dbus_add_service_watch(connection,
> BLUEZ_SERVICE, +  NULL,
> bluetooth_disconnect, NULL, NULL);
> +
> + adapter_added_watch =
> g_dbus_add_signal_watch(connection, NULL, NULL,
> + BLUEZ_MANAGER_INTERFACE,
> + "AdapterAdded",
> + adapter_added,
> NULL, NULL);
> +
> + adapter_removed_watch =
> g_dbus_add_signal_watch(connection, NULL, NULL,
> + BLUEZ_MANAGER_INTERFACE,
> + "AdapterRemoved",
> +
> adapter_removed, NULL, NULL);
> +
> + property_watch = g_dbus_add_signal_watch(connection, NULL, NULL,
> + BLUEZ_DEVICE_INTERFACE,
> + "PropertyChanged",
> +
> property_changed, NULL, NULL);
> +
> + if (bluetooth_watch == 0 || adapter_added_watch == 0 ||
> + adapter_removed_watch == 0 ||
> property_watch == 0) {
> + err = -EIO;
> + goto remove;
> + }

I may introduce API to register service like bluetooth_register_service() 
later. So I wonder if we could put above the initialization code into 
bluetooth_init(). I'd like to introduce a hash table similar with uuid_hash so 
uuid_hash is NULL in my case.

>   uuid_hash = g_hash_table_new_full(g_str_hash, g_str_equal,
> g_free, NULL);
>
> @@ -56,7 +521,19 @@ int bluetooth_register_uuid(const char
> *uuid, struct bluetooth_profile *profile)
> done:
>   g_hash_table_insert(uuid_hash, g_strdup(uuid), profile);
>
> + send_method_call_with_reply(BLUEZ_SERVICE, "/",
> + BLUEZ_MANAGER_INTERFACE,
> "GetProperties",
> + manager_properties_cb, NULL, NULL, -1,
> + DBUS_TYPE_INVALID);
> +
>   return 0;
> +
> +remove:
> + g_dbus_remove_watch(connection, bluetooth_watch);
> + g_dbus_remove_watch(connection, adapter_added_watch);
> + g_dbus_remove_watch(connection, adapter_removed_watch);
> + g_dbus_remove_watch(connection, property_watch);
> + return err;
> }
>
> void bluetooth_unregister_uuid(const char *uuid)
> @@ -66,6 +543,11 @@ void bluetooth_unregister_uuid(const char *uuid)
>   if (g_hash_table_size(uuid_hash))
>   return;
>
> + g_dbus_remove_watch(connection, bluetooth_watch);
> + g_dbus_remove_watch(connection, adapter_added_watch);
> + g_dbus_remove_watch(connection, adapter_removed_watch);
> + g_dbus_remove_watch(connection, property_watch);
> +
>   g_hash_table_destroy(uuid_hash);
>   g_hash_table_destroy(adapter_address_hash);
>   uuid_hash = NULL;

Can we move g_dbus_remove_watch() to bluetooth_exit() as well?

> diff --git a/plugins/hfp.c b/plugins/hfp.c
> index aca6b4e..12e7daf 100644
> --- a/plugins/hfp.c
> +++ b/plugins/hfp.c
> @@ -62,8 +62,7 @@ static const char *cmer_prefix[] = { "+CMER:", NULL
> }; static const char *chld_prefix[] = { "+CHLD:", NULL };
>
> static DBusConnection *connection;
> -static GHashTable *uuid_hash = NULL;
> -static GHashTable *adapter_address_hash;
> +static GHashTable *modem_hash = NULL;
>
> static void hfp_debug(const char *str, void *user_data) {
> @@ -259,101 +258,6 @@ fail:
>   return err;
> }
>
> -typedef void (*PropertyHandler)(DBusMessageIter *iter,
> gpointer user_data);
> -
> -struct property_handler {
> - const char *property;
> - PropertyHandler callback;
> - gpointer user_data;
> -};
> -
> -static gint property_handler_compare(gconstpointer a, gconstpointer
> b) -{
> - const struct property_handler *handler = a;
> - const char *property = b;
> -
> - return strcmp(handler->property, property);
> -}
> -
> -static void parse_properties_reply(DBusMessage *reply,
> - const char *property, ...)
> -{
> - va_list args;
> - GSList *prop_handlers = NULL;
> - DBusMessageIter array, dict;
> -
> - va_start(args, property);
> -
> - while (property != NULL) {
> - struct property_handler *handler =
> - g_new0(struct
> property_handler, 1);
> -
> - handler->property = property;
> - hand

RE: commit "Fix Use hashtable to record udev path" breaks huawei

[Zhang, Zhenhua]

Hi Kalle,

Kalle Valo wrote:
> Kalle Valo  writes:
> 
>> while working on third version of my huawei gprs patches I noticed
>> that this commit breaks huawei:
>> 
>> commit af976f7e524746b1b55645967e11ab8250f593a8
>> Author: Zhenhua Zhang 
>> Date:   Tue May 11 09:04:28 2010 +0800
>> 
>> Fix Use hashtable to record udev path
>> 
>> Sometimes, Udev device 'remove' event could not report correct
>> parent node of current udev_device. Current code replies on the
>> devpath attached on the parent node to find modem and then
>> remove it. 
>> 
>> This fix is to change the way to store the devpath info into a
>> hashtable. So that we search hashtable to get devpath and remove
>> the modem. 
>> 
>> I reverted the commit and huawei works again for me. More details
>> later today.
> 
> Sorry, I was too hasty. The patch is fine, I was just testing
> inproperly. After a bit more testing I found out that problem
> always happens when I plugin the usb modem:
> 
> May 19 17:20:09 tukki connmand[30925]:
> plugins/ofono.c:modem_changed() path /huawei1 May 19 17:20:10
> tukki ofonod[672]: < ATE0\r\r\nOK\r\n May 19 17:20:10 tukki
> ofonod[672]: > AT+CFUN=1\r May 19 17:20:10 tukki ofonod[672]:
> < \r\nOK\r\n May 19 17:20:10 tukki ofonod[672]:
> plugins/huawei.c:cfun_enable() May 19 17:20:10 tukki
> ofonod[672]: > AT+CRC=1\r May 19 17:20:10 tukki ofonod[672]: <
> \r\n+CME ERROR: SIM busy\r\n May 19 17:20:10 tukki
> ofonod[672]: > AT+CLIP=1\r May 19 17:20:10 tukki ofonod[672]:
> < \r\n+CME ERROR: SIM busy\r\n May 19 17:20:10 tukki
> ofonod[672]: > AT+COLP=1\r May 19 17:20:10 tukki ofonod[672]:
> < \r\n+CME ERROR: SIM busy\r\n May 19 17:20:10 tukki
> ofonod[672]: > AT+CCWA=1\r May 19 17:20:10 tukki ofonod[672]:
> < \r\n+CME ERROR: SIM busy\r\n May 19 17:20:10 tukki
> ofonod[672]:
> drivers/atmodem/voicecall.c:at_voicecall_initialized()
> voicecall_init: registering to notifications May 19 17:20:10
> tukki ofonod[672]: src/sim.c:ofono_sim_add_state_watch()
> 0x132bcd0 May 19 17:20:10 tukki ofonod[672]: * <
> \r\n^STIN:0,0,0\r\n May 19 17:20:10 tukki ofonod[672]: >
> AT+CGMI\r May 19 17:20:10 tukki connmand[30925]:
> plugins/ofono.c:modem_changed() path /huawei1 May 19 17:20:10
> tukki ofonod[672]: < \r\nhuawei\r\n\r\nOK\r\n May 19 17:20:10
> tukki ofonod[672]: > AT+CRSM=176,28590,0,0,1\r May 19 17:20:10
> tukki connmand[30925]: plugins/ofono.c:modem_changed() path
> /huawei1 May 19 17:20:10 tukki ofonod[672]: < \r\n+CME ERROR:
> SIM busy\r\n May 19 17:20:10 tukki ofonod[672]: > AT+CLCC\r
> May 19 17:20:10 tukki ofonod[672]: < \r\n+CME ERROR: SIM
> busy\r\n May 19 17:20:10 tukki ofonod[672]: >
> AT+CRSM=192,28599\r May 19 17:20:10 tukki ofonod[672]: <
> \r\n+CME ERROR: SIM busy\r\n May 19 17:20:10 tukki
> ofonod[672]: src/voicecall.c:ecc_g2_read_cb() 0 May 19
> 17:20:10 tukki ofonod[672]: > AT+CGMM\r May 19 17:20:10 tukki
> ofonod[672]: < \r\nE1552\r\n\r\nOK\r\n
> 
> But if I start ofono while the usb modem is plugged in it works fine.
> Also modem disable and then enable workarounds it. Oh well.

My commit af976f7e524 should not impact modem detection and power up stage. If 
you found huawei modem still exists in oFono after you unplug the dungle, I 
guess something maybe wrong in my patch. :-)

Maybe you need to wait until SIM is settled to power on it. As Denis said, 
listen '^SIMST' notification should be a good idea.

> --
> Kalle Valo
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH v2 1/1] Add telephony_str_to_error to decode error code

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +static gboolean search_entry(const char *str, struct error_entry
>> *e, +int maxentries, +   
>> enum
> ofono_error_type type,
>> +struct
> ofono_error *error)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < maxentries; i++) {
>> +if (!strcmp(e[i].str, str)) {
>> +error->type = type;
>> +error->error = e[i].error;
>> +return TRUE;
>> +}
>> +}
>> +
>> +return FALSE;
>> +}
> 
> This doesn't really make sense, the errors from the modem
> usually come in the form of +CMS ERROR: 123 assuming we
> enabled +CMEE=1.  If we enabled +CMEE=2 then the numeric error
> code gets converted to a string.  The former is preferable as
> the string might be different from what oFono has.  What
> you're matching here will always result in an unknown error.
> 
> Regards,
> -Denis

My wrong. I will resend the patch soon.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: How to start ofono-phonesim in ubuntu-10.04 -reg

[Zhang, Zhenhua]

Hi Krishna,

From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On 
Behalf Of krishna k
Sent: Monday, May 10, 2010 4:13 PM
To: ofono@ofono.org
Subject: How to start ofono-phonesim in ubuntu-10.04 -reg


Hi Yoon, 

I placed modem.conf file under /etc/ofono, and i tried with 
./test/list-modems script. Still it is not showing any 
thing on command line.  I tried to enable the phonesim0 modem with 
following command and i am getting the same o/p

[Zhenhua] Do you build oFono with bootscrap-configure? If does, you will have 
'--prefix=/usr --sysconfdir=/etc ...' configuration. So oFono reads 
configuration from /etc/ofono. Without that, you might put modem.conf under 
/usr/local/etc/ofono. Btw, you could raise your question on our IRC room #ofono 
at irc.freenode.net as well.


==

./enable-modem /phonesim0

**etc.

dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.UnknownMethod: Method "SetProperty" 
with signature "sb" on interface "org.ofono.Modem" doesn't exist.


==

The same error as below. It is not able to detect the phonesim0?

regards,
Krishna K Kandula.

Hi Krishna,

You should put your modem.conf file under /etc/ofono/.

Thanks,
Yoon

From: ofono-bounces at ofono.org 
  [mailto:ofono-bounces at ofono.org 
 ] On Behalf Of krishna k
Sent: Monday, May 10, 2010 3:43 PM
To: ofono at ofono.org  
Subject: How to start ofono-phonesim in ubuntu-10.04 -reg


Hi Zhenhua,

Thanks for your reply..

I added the following code in /usr/share/alsa/pcm/modem.conf file...

1.
#
#Sample for using phone simulator
#
[phonesim]
Driver=phonesim
Address=127.0.0.1
port=12345


-
I tried to ./list_modems. I got nothing on command prompt. According to 
my knowledge i should get the available modems (atleast phonesim0)
I tried to enable  the modem using the following command..

./enable-modem /phonesim0

I got 
output as follows...


--

Connecting
 modem /phonesim0...

Traceback 
(most recent call last):

  File 
"./enable-modem", line 20, in 


modem.SetProperty("Powered", dbus.Boolean(1))

  File 
"/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__

return
 self._proxy_method(*args, **keywords)

  File 
"/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__


**keywords)

  File 
"/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in 
call_blocking


message, timeout)

dbus.exceptions.DBusException:
 org.freedesktop.DBus.Error.UnknownMethod: Method "SetProperty" with 
signature "sb" on interface "org.ofono.Modem" doesn't exist


--
Have a nice time.

Regards,
Krishna K Kandula




The battle for the FIH Hockey World Cup Drag n' drop 
  

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: How to start ofono-phonesim in ubuntu-10.04 -reg

[Zhang, Zhenhua]

Hi Krishna,

From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On 
Behalf Of krishna k
Sent: Monday, May 10, 2010 2:43 PM
To: ofono@ofono.org
Subject: How to start ofono-phonesim in ubuntu-10.04 -reg



Hi Zhenhua,

Thanks for your reply..

I added the following code in /usr/share/alsa/pcm/modem.conf file...

[Zhenhua] Please put modem.conf under /etc/ofono. You should see phonesim0 from 
list_modems output like your E71 modem.

1.
#
#Sample for using phone simulator
#
[phonesim]
Driver=phonesim
Address=127.0.0.1
port=12345


-
I tried to ./list_modems. I got nothing on command prompt. According to 
my knowledge i should get the available modems (atleast phonesim0)
I tried to enable  the modem using the following command..

./enable-modem /phonesim0

I got 
output as follows...


--

Connecting
 modem /phonesim0...

Traceback 
(most recent call last):

  File 
"./enable-modem", line 20, in 


modem.SetProperty("Powered", dbus.Boolean(1))

  File 
"/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__

return
 self._proxy_method(*args, **keywords)

  File 
"/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__


**keywords)

  File 
"/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in 
call_blocking


message, timeout)

dbus.exceptions.DBusException:
 org.freedesktop.DBus.Error.UnknownMethod: Method "SetProperty" with 
signature "sb" on interface "org.ofono.Modem" doesn't exist


--


Have a nice time.

Regards,
Krishna K Kandula





The battle for the FIH Hockey World Cup Drag n' drop 
  

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: How to start ofono-phonesim in ubuntu-10.04 -reg

[Zhang, Zhenhua]

Hi Krishna,

From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On 
Behalf Of krishna k
Sent: Monday, May 10, 2010 1:24 PM
To: ofono@ofono.org
Subject: How to start ofono-phonesim in ubuntu-10.04 -reg


Hi Yoon,

Thank very much for your guidance. I followed the same procedure ...

You already did following procedure.
1. ofono-phonesim -p 12345 -gui ~/data/moblin.xml
2. sudo ofonod -nd 

And then, you need to type following command to power up 
modem(phonesim).
3. dbus-send --system --print-reply --dest=org.ofono / phonesim0 
org.ofono.Modem.SetProperty string:Powered variant:boolean:true

[Zhenhua] I guess there's no space '/'  and 'phonesim0'. Alternatively, You can 
use 'test/list-modem' to get your modem name and then use 'test/enable-modem 
/phonesim0' to power on it.


I got below response

Must use org.mydomain.Interface.Method notation, no dot in "phonesim0"

Please see the ps ax | grep ofono*

-
 1609 pts/0S+ 0:00 ofono-phonesim -p 12345 -gui 
/home/kandukis/data/moblin.xml
 1654 pts/2S+ 0:00 ofonod -nd



Can you please suggest  how to get-rid from this problem.

regards,
Krishna K Kandula 



Catch the changing security environment Get it now. 
  

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/2] Fix check data device before register the modem

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> To avoid the race condition that modem is registered before we
> retrieve the data device property.
> ---

The second patch is for MBM modem only. We should retrieve data device property 
before register the modem. Please review it. Thanks.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/2] Fix Use hashtable to record udev path

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Sometimes, Udev device 'remove' event could not report correct
> parent node of current udev_device. Current code replies on
> the devpath attached on the parent node to find modem and then
> remove it.
> 
> This fix is to change the way to store the devpath info into a
> hashtable. So that we search hashtable to get devpath and
> remove the modem.
> ---

It's a proposed patch to fix Meego bug #395 [1].

oFono relies on udev to report device remove event. The devpath info of the 
modem is stored in the parent node of tty port. In below case, we try to find 
this parent node of /dev/ttyACM0. The expected path of node is ".../usb1/1-4", 
which is modem device itself. On Netbook, however, it returns ".../usb1" 
sometimes. In such case, we could not find the correct devpath and modem so 
that modem was never removed.

My idea is to use a hashtable to store the mapping between tty path and modem 
path. So that we could find the modem path without depending on 
udev_device_get_parent() in remove_modem.

Wrong log is listed below. The expected path is 
'/devices/pci:00/:00:1d.7/usb1/1-4/', but it returns 
'.../:00:1d.7/usb1', which is Linux USB host controller.

Wrong log 1:
remove_modem() device 0x9223820
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.1/tty/ttyACM0
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00
remove_modem() device 0x9222628
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.3/tty/ttyACM1
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00
remove_modem() device 0x92233a8
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.7/net/wwan0
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00
remove_modem() device 0x9224520
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.9/tty/ttyACM2
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00

Wrong log 2:
remove_modem() device 0x9226398
path #0 /1-4:1.1/tty/ttyACM0
remove_modem() device 0x9226398
path #0 /1-4:1.3/tty/ttyACM1
remove_modem() device 0x9226398
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.9/tty/ttyACM2
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00
remove_modem() device 0x9224880
path #0 /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.7/net/wwan0
path #1 /devices/pci:00/:00:1d.7/usb1
path #2 /devices/pci:00/:00:1d.7/usb1
path #3 /devices/pci:00/:00:1d.7
path #4 /devices/pci:00

[1] http://bugs.meego.com/show_bug.cgi?id=395

Regards,
Zhenhua

- Plug a USB dangle into netbook 
ofonod[1829]: plugins/udev.c:add_modem() device 0x9222e78 -> udev 0x9220ec8
ofonod[1829]: plugins/udev.c:add_modem() add path 
/devices/pci:00/:00:1d.7/usb1/1-4
ofonod[1829]: src/modem.c:ofono_modem_create() name: 3558620217367190, type: mbm
ofonod[1829]: src/modem.c:set_modem_property() modem 0x92236b8 property Path
ofonod[1829]: src/modem.c:set_modem_property() modem 0x92236b8 property 
Registered
ofonod[1829]: plugins/udev.c:add_mbm() desc: Dell Wireless 5530 HSPA Mobile 
Broadband Minicard Modem
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
Registered
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
ModemDevice
ofonod[1829]: src/modem.c:set_modem_property() modem 0x92236b8 property 
ModemDevice
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
ModemDevice
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
NetworkInterface
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property Path
ofonod[1829]: plugins/udev.c:add_mbm() desc: Dell Wireless 5530 HSPA Mobile 
Broadband Minicard NetworkAdapter
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
Registered
ofonod[1829]: src/modem.c:set_modem_property() modem 0x92236b8 property 
NetworkInterface
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
ModemDevice
ofonod[1829]: src/modem.c:get_modem_property() modem 0x92236b8 property 
NetworkInterface
ofonod[1829]: src/modem.c:set_modem_property() modem 0x92236b8 pr

RE: Modem emulator and DUN server side for oFono and BlueZ

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> * Zhang, Zhenhua  [2010-04-27 15:53:54
> +0800]: 
> 
>> Hi,
>> 
>> I am now working on modem emulator and one usage is for DUN
> server role. Since Padovan is working on client role, it's
> good to share my rough thinking for server side
> implementation. Here are the simple steps I have:
>> 
>> 1. Create an oFono emulator atom in oFono. It's the emulator
> manager that could create DUN, HFP AG or SPP type emulators.
> It exposes dbus methods like CreateEmulator, DestroyEmulator,
> GetProperty, etc.
>> 
>> 2. DUN agent server in BlueZ watch oFono and call
> CreateEmulator and pass the file descriptor to oFono. This
> server could further implement HFP AG and SPP connection.
> 
> 
> Shouldn't the emulator register itself on the BlueZ agent server?

It's fine to register the emulator like HFP client. In this way, we might able 
to share the agent with DUN server as well. Thanks.

> 
> --
> Gustavo F. Padovan
> http://padovan.org
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Modem emulator and DUN server side for oFono and BlueZ

[Zhang, Zhenhua]

Hi,

I am now working on modem emulator and one usage is for DUN server role. Since 
Padovan is working on client role, it's good to share my rough thinking for 
server side implementation. Here are the simple steps I have:

1. Create an oFono emulator atom in oFono. It's the emulator manager that could 
create DUN, HFP AG or SPP type emulators. It exposes dbus methods like 
CreateEmulator, DestroyEmulator, GetProperty, etc.

2. DUN agent server in BlueZ watch oFono and call CreateEmulator and pass the 
file descriptor to oFono. This server could further implement HFP AG and SPP 
connection.

3. Once an emulator is created, other atom like voicecall, grps, sms register 
their interested AT command handlers to it. The goal is that we could handle 
all mandatory AT commands defined in DUN profile spec.

4. Once a DUN emulator received ATD*99#, DUN client performs ppp connection so 
we forward ppp command to ppp stack. It is done by ppp server side extension. 
It should be the simple command forwarding.

5. Once the PPP link over DUN is established, DUN client performs ConnMan 
integration and setup IP address, DNS server, etc.

6. Once the Bluetooth link is disconnected, we destroy the PPP and DUN 
emulator. If emulator atom itself is destroyed, we destroy the PPP and the 
Bluetooth connection. If the PPP link is disconnected but Bluetooth link is 
alive, we destroy the PPP and stay emulator alive.

Comments are welcome. :)

Regards,
Zhenhua
 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: DUN client for oFono and BlueZ

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> * Zhang, Zhenhua  [2010-04-27 10:14:38
> +0800]: 
> 
>> Hi Padovan,
>> 
>> Gustavo F. Padovan wrote:
>>> Hi all,
>>> 
>>> I'm starting the DUN Client implementation for the Linux Stack. DUN
>>> is the Bluetooth dial-up network profile. It makes possible share
>>> internet connection between two Bluetooth devices. That is my Google
>>> Summer of Code project for this year.
>>> 
>>> Here follows a simple, and possible not complete, roadmap:
>>> 
>>> 1. Put send_method_call() and send_method_call_with_reply() on
>>> gdbus: those functions are very useful for DBus operations.
>>> You can send a DBus message just calling them with the right
>>> parameters. Patch for that work already on the mailing list.
>>> 
>>> 2. Create a bluetooth.c file with the bluetooth helpers. oFono
>>> plugins for HFP, DUN and SAP will be able to share the same
>>> bluetooth code to access BlueZ stuff. This is a ongoing work.
>> 
>> Is this bluetooth.c like a utility to watch BlueZ status,
> watch adapter change and signals? If I understand correctly,
> every plugin like HFP, DUN, SAP will add status callback for
> different event.
> 
> Exactly, that's the idea.
> 
>> 
>>> 3. plugin/dun.c prototype. A simple prototype for the DUN client.
>> 
>> Not quite sure whether we need this. Denis suggests to
> create an Emulator atom in the ofono core. I am now making a
> prototype to create this atom in oFono.
>> The structure is similar to voicecall.c. An emulator manager
> could create HFP AG, DUN or SPP type emulators. When one is
> created, other atom get notified and register their interested
> AT command handers to GAtServer. So in this way, agent server
> on BlueZ may call oFono CreateEmulator method and pass file
> descriptor directly to oFono.
> 
> If I understood correctly the Emulator will be useful for the
> DUN Gateway side. Right?

Yes. This is DUN gateway side. So I think we need to define a PPP command 
forwarding so that PPP command could be sent and received throught DUN properly.

> Right now I'm going to work on the DUN Client.
> 
>> 
>>> 4. Agent server on BlueZ. This one is very similar to the HFP Agent
>>> server. At the end of the DUN agent project I plan to merge the both
>>> agent servers. SAP will take advantage of that merge too.
>>> 
>>> 5. oFono DUN agent. Implement the agent handling for DUN.
>> 
>> Actually, my original prototype is quite simliar with yours.
> DUN, HFP and SPP are implemented as plugins. See my previous
> patches in the mailing list for details.
> 
> In my mind that will be similar to the HFP agent
> implementation I did inside oFono.
> 
>> 
>>> 6. AT command parser and PPP stack integration with DUN. The biggest
>>> task, where the core of the project is.
>> 
>> GAtServer and PPP are already there. We still need to add
> DUN specific command and callbacks.
>> 
>>> 7. ConnMan integration. Setup of the NAT and Internet Connections.
>>> 
> 
> Regards,
> 
> --
> Gustavo F. Padovan
> http://padovan.org



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: DUN client for oFono and BlueZ

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi all,
> 
> I'm starting the DUN Client implementation for the Linux
> Stack. DUN is the Bluetooth dial-up network profile. It makes
> possible share internet connection between two Bluetooth
> devices. That is my Google Summer of Code project for this year.
> 
> Here follows a simple, and possible not complete, roadmap:
> 
> 1. Put send_method_call() and send_method_call_with_reply() on
> gdbus: those functions are very useful for DBus operations.
> You can send a DBus message just calling them with the right
> parameters. Patch for that work already on the mailing list.
>
> 2. Create a bluetooth.c file with the bluetooth helpers. oFono
> plugins for HFP, DUN and SAP will be able to share the same
> bluetooth code to access BlueZ stuff. This is a ongoing work.

Is this bluetooth.c like a utility to watch BlueZ status, watch adapter change 
and signals? If I understand correctly, every plugin like HFP, DUN, SAP will 
add status callback for different event.

> 3. plugin/dun.c prototype. A simple prototype for the DUN client.

Not quite sure whether we need this. Denis suggests to create an Emulator atom 
in the ofono core. I am now making a prototype to create this atom in oFono.
The structure is similar to voicecall.c. An emulator manager could create HFP 
AG, DUN or SPP type emulators. When one is created, other atom get notified and 
register their interested AT command handers to GAtServer. So in this way, 
agent server on BlueZ may call oFono CreateEmulator method and pass file 
descriptor directly to oFono.

> 4. Agent server on BlueZ. This one is very similar to the HFP
> Agent server. At the end of the DUN agent project I plan to
> merge the both agent servers. SAP will take advantage of that merge
> too. 
> 
> 5. oFono DUN agent. Implement the agent handling for DUN.

Actually, my original prototype is quite simliar with yours. DUN, HFP and SPP 
are implemented as plugins. See my previous patches in the mailing list for 
details.

> 6. AT command parser and PPP stack integration with DUN. The
> biggest task, where the core of the project is.

GAtServer and PPP are already there. We still need to add DUN specific command 
and callbacks.

> 7. ConnMan integration. Setup of the NAT and Internet Connections.
> 
> 
> Comments are welcome. :)
> 
> --
> Gustavo F. Padovan
> http://padovan.org
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/5] Refactor the command parsing framework

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> ---
>>  gatchat/gatserver.c |  182
>>  +++---
>>  gatchat/gatserver.h |   7 ++- 2 files changed, 133 insertions(+),
>> 56 deletions(-) 
>> 
>> -at_command_notify(server, buf, prefix, type);
>> +notify = at_node_new(server, buf, prefix, type);
>> +if (!notify)
>> +goto error;
>> 
>>  /* Also consume the terminating null */
>> -return i + 1;
>> +server->read_pos += i + 1;
>> +server->notify_source = g_idle_add_full(G_PRIORITY_DEFAULT,
>> +at_command_notify, +
>> notify, g_free);
>> +
>> +return;
>> +
>> +error:
>> +g_free(notify);
>> +
>> +g_at_server_send_final(server, G_AT_SERVER_RESULT_ERROR);
>>  }
> 
> Err, OK stop right there.  This is really way too complicated.
> How about we simply set a flag before calling
> at_command_notify.  If after executing it send_final or
> send_ext_final response has been sent, then we continue
> processing, otherwise we restart when send_ext_final or
> send_final will be called again.  You really don't need to touch this
> function at all. 

OK. So the problem is if the at_command_notify is blocked by user callback, the 
mainloop won't have chance to read data in from non-blocking I/O I guess. 
That's the reason I added this. If we don't need to handle such case, then the 
logic could be much simplier. We could discuss it on IRC.

>> +typedef void (*GAtServerNotifyCallback)(gpointer user_data);
>> +
> 
> Get rid of this, not necessary.
> 
>>  typedef void (*GAtServerNotifyFunc)(GAtServerRequestType type,
>> -GAtResult *result,
> gpointer user_data);
>> +GAtResult *result,
>> +gpointer user_data,
>> +GAtServerNotifyCallback cb,
>> +gpointer cb_data);
>> 
> 
> Keep the NotifyFunc the way it is, your changes are really not
> required. 
> 
> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [RFC] HFP support into oFono and BlueZ

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
>> New version of the patches. Known issues:
>> "'org.bluez.HandsfreeAgent.Release' part not implemented" and it's
>> not working with more than one bluetooth devices in some cases.
>> Comments are welcome. 
>> 
> 
> Another new version of the patches. Now ofono query all bluetooth
> devices and searches for the ones with Gateway interface. Bluez has
> some fixes and now supports connection coming from the AG. 
> The patches are using a per-device agent as described by the last
> version of Handsfree API. 
> 
> I did not implemented yet 'org.bluez.HandsfreeAgent.Release'.
> 
> Comments are welcome. :)

Two small comments.

1. Remove unused variables.

make --no-print-directory all-am
  CC plugins/hfp.o
cc1: warnings being treated as errors
plugins/hfp.c: In function ‘get_properties_cb’:
plugins/hfp.c:500: error: unused variable ‘err’
plugins/hfp.c: In function ‘list_devices_cb’:
plugins/hfp.c:529: error: unused variable ‘modem’
plugins/hfp.c: In function ‘hfp_probe’:
plugins/hfp.c:656: error: unused variable ‘data’
make[1]: *** [plugins/hfp.o] Error 1
make: *** [all] Error 2

2. You may use Linux kernel /scripts/checkpatch.pl to check your patch.
E.g, there're trailing space in 0002.patch line 832.

Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: message history

[Zhang, Zhenhua]

Hi Feifei,

You can see ofono/plugins/example_history.c for getting history. You can 
customize your own plugin to record the sms/voicecall history into file or 
database as you want. You can "export OFONO_AT_DEBUG=1; ofono/src/ofonod -nd" 
to see oFono debug log.

Regards,
Zhenhua


From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of 
Feifei Hu
Sent: Wednesday, January 20, 2010 4:55 PM
To: ofono@ofono.org
Subject: message history


  I have installed ofono and phonesim , with which I tried sms-send ,but
   how can I get message history?
  Are there any python scripts or dbus APIs?
 Thanks!
 Best Regards,
   Feifei 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/4] Add gatutil.c to share common APIs with GAtServer

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +gboolean g_at_util_set_io(GIOChannel *io)
> 
> Rename this g_at_util_setup_io
> 
>> +typedef void (*GAtDisconnectFunc)(gpointer user_data); typedef void
>> +(*GAtDebugFunc)(const char *str, gpointer user_data);
> 
> These don't belong here, create a new file called gat.h and put them
> there. 
> 
> Regards,
> -Denis

Thanks for your comments. Updated patch is attached.

Regards,
Zhenhua


0001-Add-gatutil.c-to-share-common-APIs-with-GAtServer.patch
Description: 0001-Add-gatutil.c-to-share-common-APIs-with-GAtServer.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] Fix set default baud rate to 115200

[Zhang, Zhenhua]

Hi,

I found N900 could not be powered on by atgen driver due to baud rate problem.
If I add 'Baud=115200' into modem.conf, everything is fine. In gatchat/gattty.c,
the default baud rate is B0 which looks not correct, so I wonder whether we
should set the default baud rate to some values like minicom does.

My proposed fix was attached.

Regards,
Zhenhua
 


0001-Fix-set-default-baud-rate-to-115200.patch
Description: 0001-Fix-set-default-baud-rate-to-115200.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Merry Christmas to everyone

[Zhang, Zhenhua]

Xu, Martin wrote:
>> -Original Message-
>> From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On
>> Behalf Of Marcel Holtmann Sent: Friday, December 25, 2009 12:22 AM
>> To: ofono@ofono.org
>> Subject: Merry Christmas to everyone
>> 
>> Hello everyone,
>> 
>> and Santa is coming to town and bringing the 0.15 release with him.
>> Many
> 
> Marcel:
> You should give each contributor a small gift like Santa Claus. ;-)
> 
> My address is:
> No. 4 room 202, lane 1459, RD Luoxiu, Shanghai PRC
> 200237

Marcel IS a young and kindly Santa Claus. He will give the gift to the 
contributor sending him the address. ;-)

So mine is:
No. 3 room 401, lane 3105, Lao Huming Road, Shanghai PRC
201108

_
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 4/4] Fix schedule clcc poll in the ring notify

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Hi,
> 
> Zhang, Zhenhua wrote:
>> Similar to atmodem, We need schedule CLCC poll in the ring notify in
>> case AG doesn't send CLIP notification to us. If CLIP comes right
>> after RING, we cancel the CLCC poll. ---
>> drivers/hfpmodem/voicecall.c |   15 +++
>> 1 files changed, 15 insertions(+), 0 deletions(-)
>> 
> 
> Changed to add clip_timeout to notify the call directly if
> CLIP notification doesn't arrive. Please review it.
> 
> Regards,
> Zhenhua

Replace clcc_source to clip_source to make code be more clear.

Regards,
Zhenhua



0004-Add-clip_timeout-for-notify-incoming-call.patch
Description: 0004-Add-clip_timeout-for-notify-incoming-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/4] Add poll_clcc if we are in multiparty call

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Hi,
> 
> Zhang, Zhenhua wrote:
>> If we are in multiparty call, remote AG won't update indicator if any
>> call in multiparty call is released by CHLD=1x. So we have to poll
>> it periodically. --- drivers/hfpmodem/voicecall.c |   37
>> +
>> 1 files changed, 37 insertions(+), 0 deletions(-)
>> 
> 
> I updated this patch to reset vd->clcc_source in poll_clcc.
> And fix a style issue for num_active, num_held in
> clcc_poll_cb. Updated patch is attached.
> 
> Regards,
> Zhenhua

Update the patch title since it should be 3/4.

Regards,
Zhenhua



0003-Add-poll_clcc-if-we-are-in-multiparty-call.patch
Description: 0003-Add-poll_clcc-if-we-are-in-multiparty-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 4/4] Fix schedule clcc poll in the ring notify

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Similar to atmodem, We need schedule CLCC poll in the ring
> notify in case AG doesn't send CLIP notification to us. If
> CLIP comes right after RING, we cancel the CLCC poll. ---
> drivers/hfpmodem/voicecall.c |   15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
> 

Changed to add clip_timeout to notify the call directly if CLIP
notification doesn't arrive. Please review it.

Regards,
Zhenhua



0004-Add-clip_timeout-for-notify-incoming-call.patch
Description: 0004-Add-clip_timeout-for-notify-incoming-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/4] Add hfp_release_specific to release specific call

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Use AT+CHLD=1x to release a specific call if AG supports that. ---
> drivers/hfpmodem/voicecall.c |   51
> +-
> 1 files changed, 50 insertions(+), 1 deletions(-)
> 

Update the patch to initlize 'struct release_id_req *req' as NULL. 

Regards,
Zhenhua



0001-Add-hfp_release_specific-to-release-specific-call.patch
Description: 0001-Add-hfp_release_specific-to-release-specific-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/4] Add poll_clcc if we are in multiparty call

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> If we are in multiparty call, remote AG won't update indicator
> if any call in multiparty call is released by CHLD=1x. So we have to
> poll it periodically. ---
> drivers/hfpmodem/voicecall.c |   37
> +
> 1 files changed, 37 insertions(+), 0 deletions(-)
> 

I updated this patch to reset vd->clcc_source in poll_clcc. And fix a style
issue for num_active, num_held in clcc_poll_cb. Updated patch is attached.

Regards,
Zhenhua



0003-Add-poll_clcc-if-we-are-in-multiparty-call.patch
Description: 0003-Add-poll_clcc-if-we-are-in-multiparty-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/2] Fix remove all atoms in ofono_modem_set_powered

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> We should remove all atoms when we disable the modem. In
> function set_powered, we remove all atoms if modem is powered down by
> dbus call. ---
> src/modem.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> 

Let me explain more about this fix. In atmodem world, we use dbus call to 
power on/off modem and then it calls set_powered() to remove all atoms.

However, in hfpmodem, the plugin may receive signal from BlueZ that remote
has closed the service level connection with us. So we must power off the modem
through ofono_modem_set_powered(modem, FALSE).

I also tried phonesim and don't find problem. Let me know if any questions or
issues. Thanks.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/3] Add hfp_list_calls to get current call list

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> Use AT+CLCC to get current call list.
> 
> So I did things 'slightly' differently.  The new setup should
> be much simpler for both the plugin and the core.  I've tested
> it on phonesim, but not on HFP.
> Can you let me know if there are any issues?

It works fine on HFP and new code looks better than older
interface. I got 3 new PASS from PTS results. ;-)

> Regards,
> -Denis

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] Fix: Poll CLCC to replace the code in call_held=1

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
> 
>> When using CHLD=2x in multiparty call, call_held is 1 and we should
>> not swap all active->held. So we cannot save this pull in private
>> chat. ---
>>  drivers/hfpmodem/voicecall.c |   50
>> +
>>  1 files changed, 6 insertions(+), 44 deletions(-)
> 
> patch is corrupted. Please send again or better even use git
> send-email for sending it. 

Thanks Marcel. Patch has been attached. The evolution wrapped the line
that over 80 characters so the patch is corrupted. I will try to use git 
send-email next time.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua



0001-Fix-Poll-CLCC-to-replace-the-code-in-call_held-1.patch
Description: 0001-Fix-Poll-CLCC-to-replace-the-code-in-call_held-1.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/4] Fix: No need to put active call on hold

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> First, call->status should be 1 stead of 2 in the loop. Second, it's
>> incorrect to set status to hold because later callheld=1 will swap
>> call status back. So active->hold->active again is not correct.
> 
> Unfortunately we do need to put the calls on hold otherwise
> the core might pick the wrong call as the 'dialed' call. Instead we
> now ignore the callheld=1 indicator in this situation.  Let me know
> if this still doesn't fix this issue. 

Ok. So let's extend the ignore_callheld_1 to another case. If we already
put current active call on hold, user dial out another call from phone,
we also need set ignore_callheld_1 as TRUE so the held call won't
be active again.

> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 4/4] Fix: Fill in the phone number info for outgoing call

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +ofono_voicecall_notify(vc, call);
>> +
> 
> As I mentioned above, you do not need to do this.  oFono will
> synthesize the outgoing call properly.  Worst case we will
> send a PropertyChanged signal after CLCC is polled and the new number
> is obtained. 

I recreate the patch to use the way you mentioned. We notify the voicecall
to core after CLCC is polled. Instead of notify it in atd_cb. The comments
in patch is also updated.

> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua



0001-Fix-Fill-in-the-phone-number-info-for-outgoing-call.patch
Description: 0001-Fix-Fill-in-the-phone-number-info-for-outgoing-call.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/3] Add multi calls support for HFP voicecall driver

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +static void reset_to_single_call(struct voicecall_data *vd) {
>> +   struct ofono_call *oc = vd->calls->data;
>> +
>> +   vd->call = oc;
>> +   vd->cind_val[HFP_INDICATOR_CALL] = 1;
>> +
>> +   if (oc->direction == 1)
>> +   vd->cind_val[HFP_INDICATOR_CALLSETUP] = 1; +  
>> else +   vd->cind_val[HFP_INDICATOR_CALLSETUP] = 3; }
>> +
> 
> I don't see how this is supposed to work.  What if the last
> call is a held call?

Don't see any problem if it is a held call. Still can hang up correctly.
What's the problem you have see.

>> +if (c) {
>> +nc = c->data;
>> +
>> +if (memcmp(nc, oc, sizeof(struct ofono_call))) { +  
>> oc->status
>> = nc->status; +
>> +/* If phone does not support
> multiparty call,
>> + * there will have only one
> active call at one
>> + * time. +CHUP only hang up
> current active call.
>> + */
>> +if (oc->status == CALL_STATUS_ACTIVE)
>> +vd->call = oc;
> 
> Lets not set this silly variable anymore.  It has way too many
> meanings and uses throughout the code (most of which can be
> easily simplified) for the logic to be understandable.

As discussed on IRC, I will rename vd->call to vd->active. But the 
src/voicecall.c
has the similar variable in struct ofono_voicecall too.

>> +static void hfp_hold_all_active(struct ofono_voicecall *vc,
>> +ofono_voicecall_cb_t cb, void *data) {
>> +struct voicecall_data *vd = ofono_voicecall_get_data(vc); +
>> +if (check_mpty_feature(vc, AG_CHLD_2, cb, data)) {
>> +hfp_template("AT+CHLD=2", vc, generic_cb, 0, cb, data); +
>> +/* Some phones fail to send response back after CHLD=2.
>> + * But if we have another dialing out call, we should hold
>> + * +CLCC until AG creates the new call.
>> + */
>> +vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL,
>> +poll_clcc, vc);
> 
> This comment makes no sense.  If the phone doesn't respond
> after CHLD=2 the parser is stuck and we're not sending CLCC out
> anyway. 

I will update the comments. It means phone should send update notification
Like callheld=1. But some phones doesn't send CIEV update.

>> +static void hfp_set_udub(struct ofono_voicecall *vc,
>> +ofono_voicecall_cb_t cb, void *data) {
>> +unsigned int incoming_or_waiting = (1 << 4) | (1 << 5);
>> +struct voicecall_data *vd = ofono_voicecall_get_data(vc);
>> +struct ofono_call *call = vd->call;
>> +struct release_id_req *req;
>> +
>> +if (vd->ag_mpty_features & AG_CHLD_0)
>> +hfp_template("AT+CHLD=0", vc, generic_cb, incoming_or_waiting,
>> +cb, data); +else {
>> +req = g_try_new0(struct release_id_req, 1);
>> +
>> +if (!req || !call) {
>> +CALLBACK_WITH_FAILURE(cb, data);
>> +return;
>> +}
>> +
>> +req->vc = vc;
>> +req->cb = cb;
>> +req->data = data;
>> +req->id = call->id;
>> +
>> +g_at_chat_send(vd->chat, "AT+CHUP", none_prefix,
>> +release_id_cb, req, g_free);
>> +}
> 
> The core is quite specifically asking to set UDUB, not to
> hangup the call.  If this is not supported, then we should say
> so.  Please get rid of this.

Ok. Remove it and report errors.

>> +}
>> +
>> +static void hfp_release_all_active(struct ofono_voicecall *vc,
>> +ofono_voicecall_cb_t
> cb, void *data) {
>> +struct voicecall_data *vd = ofono_voicecall_get_data(vc); +
>> +if (check_mpty_feature(vc, AG_CHLD_1, cb, data)) {
>> +hfp_template("AT+CHLD=1", vc, generic_cb, 0x1, cb, data); +
>> +vd->clcc_source =
> g_timeout_add(POLL_CLCC_INTERVAL, poll_clcc,
>> +vc);
> 
> Why are we scheduling the CLCC before the CHLD returned?  We
> should wait until CHLD fails or succeeds.

It doesn't matter if we have 1 extra CLCC even if CHLD=1 is failed. Anyway,
I will move it into generic_cb.

>> +static void hfp_release_specific(struct ofono_voicecall *vc, int id,
>> +ofono_voicecall_cb_t cb, void *data) {
>> +if (vd->ag_features & AG_FEATURE_ENHANCED_CALL_CONTROL) {
>> +sprintf(buf, "AT+CHLD=1%d", id);
> 
> Should we be checking CHLD_1X feature?

You mean checking CHLD_1X instead of enhanced_call_control? In theoriy,
They are the same. I don't think the phone has CHLD_1X without CHLD=2X.
;-)

>> +
>> +g_at_chat_send(vd->chat, buf, none_prefix,
>> + 

RE: [PATCH 4/4] Fix: Fill in the phone number info for outgoing call

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> There're two cases of outgoing call: dial from HF or dial from phone.
>> 
>> In the first case, some phones may not support enhanced call status
>> (AT+CLCC) to query outgoing number. So we need to pass struct
>> atd_cb_data to fill in the number and type. Later, we invoke
>> AT+CLCC to query phone number and overwrite ours if we are wrong.
> 
> This is actually not necessary.  The core already tracks the
> outgoing number and fills it in if the dial returns before the
> new call is notified.  This should be always the case in HFP,
> since the ATD returns before CIEV is signaled, correct?

The reason to record outgoing number is for later clcc_poll_cb in multicall
hanlding, because HFP doesn't have COLP so it don't know the outgoing
number unless we do +CLCC poll. So we need to sync it.

>> +static GSList *parse_clcc(GAtResult *result) {
>> +GAtResultIter iter;
>> +GSList *l = NULL;
>> +int id, dir, status, type;
>> +struct ofono_call *call;
>> +
>> +g_at_result_iter_init(&iter, result);
>> +
>> +while (g_at_result_iter_next(&iter, "+CLCC:")) {
>> +const char *str = "";
>> +int number_type = 129;
>> +
>> +if (!g_at_result_iter_next_number(&iter, &id))
>> +continue;
>> +
>> +if (!g_at_result_iter_next_number(&iter, &dir))
>> +continue;
>> +
>> +if (!g_at_result_iter_next_number(&iter, &status)) +
>> continue;
>> +
>> +if (!g_at_result_iter_next_number(&iter, &type)) +  
>> continue;
>> +
>> +if (!g_at_result_iter_skip_next(&iter))
>> +continue;
>> +
>> +if (g_at_result_iter_next_string(&iter, &str))
>> +g_at_result_iter_next_number(&iter, &number_type); +
>> +call = g_try_new0(struct ofono_call, 1);
>> +
>> +if (!call)
>> +break;
>> +
>> +call->id = id;
>> +call->direction = dir;
>> +call->status = status;
>> +call->type = type;
>> +strncpy(call->phone_number.number, str,
>> +OFONO_MAX_PHONE_NUMBER_LENGTH);
>> +call->phone_number.type = number_type;
>> +
>> +if (strlen(call->phone_number.number) > 0)
>> +call->clip_validity = 0;
>> +else
>> +call->clip_validity = 2;
>> +
>> +l = g_slist_insert_sorted(l, call, at_util_call_compare); + 
>> }
>> +
>> +return l;
>> +}
> 
> If this function is a copy from atmodem, please put it into
> atutils instead of duplicating it here.

I will send a separate patch for that.

>> +ofono_voicecall_notify(vc, call);
>> +
> 
> As I mentioned above, you do not need to do this.  oFono will
> synthesize the outgoing call properly.  Worst case we will
> send a PropertyChanged signal after CLCC is polled and the new number
> is obtained. 
>
> Also, there's actually two separate cases here.  Ideally I'd
> like them separated into two patches.
> 
> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/2] Add call volume support for hfpmodem

[Zhang, Zhenhua]

Hi Denis,

Denis Kenzior wrote:
> Hi Zhenhua,
> 
>> +static void hfp_call_volume_initialized(gpointer user_data) {
>> +struct ofono_call_volume *cv = user_data;
>> +struct cv_data *vd = ofono_call_volume_get_data(cv); +
>> +DBG("");
>> +
>> +g_at_chat_register(vd->chat, "+VGS:", vgs_notify, FALSE, cv, NULL);
>> +g_at_chat_register(vd->chat, "+VGM:", vgm_notify, FALSE, cv,
>> NULL); + +   ofono_call_volume_register(cv);
>> +
>> +ofono_call_volume_set_microphone_volume(cv, vd->mic_volume);
>> +ofono_call_volume_set_speaker_volume(cv, vd->sp_volume);
> 
> Section 4.28.2 of HFP Spec.  Don't we need to perform volume level
> synchronization here? 

Good catch. I add the sync code in attached.
 
>> +}
>> +
>> +static int hfp_call_volume_probe(struct ofono_call_volume *cv,
>> +unsigned int vendor,
> void *data) {
> 
> 
> 
>> +memcpy(vd->cind_pos, d->cind_pos, HFP_INDICATOR_LAST);
>> +memcpy(vd->cind_val, d->cind_val, HFP_INDICATOR_LAST);
> 
> Useless

Fixed by remove cind_pos, cind_val from struct cv_data.

>> +
>> +ofono_call_volume_set_data(cv, vd);
>> +
>> +hfp_call_volume_initialized(cv);
>> +
>> +return 0;
>> +}
>> +
>> +static void hfp_call_volume_remove(struct ofono_call_volume *cv) {
>> +struct cv_data *vd = ofono_call_volume_get_data(cv);
> 
> Make sure to ofono_call_volume_set_data(cv, NULL) here.

I don't see ofono_call_volume_set_data(cv, NULL) or 
ofono_voicecall_set_data(vc, NULL)
from atmodem either. Anyway, I add the code in hfp_call_volume_remove.

>> +
>> +g_free(vd);
>> +}
>> +
> 
> Regards,
> -Denis
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua



0002-Add-call-volume-support-for-hfpmodem.patch
Description: 0002-Add-call-volume-support-for-hfpmodem.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 4/4] Fix: Fill in the phone number info for outgoing call

[Zhang, Zhenhua]

Hi,

Please ignore the mails I just sent today. It seems git-send-email cached my 
mail threads locally
and still try to resend them when I come back to the office.

The mail contents are exactly the same as I sent last week.

Regards,
Zhenhua

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 1/3] Move and rename call_compare and call_compare_by_status to atutil.c

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Hi,
> 
> Below patch is to rename call_compare and call_compare_by_status into
> atutil.c 
> so that they could be shared by atmodem and hfpmodem drivers.
> 
> ---
>  drivers/atmodem/atutil.c|   27 +++
>  drivers/atmodem/atutil.h|2 ++
>  drivers/atmodem/voicecall.c |   39
>  +++ 3 files changed, 36
> insertions(+), 32 deletions(-) 
> 
> diff --git a/drivers/atmodem/atutil.c b/drivers/atmodem/atutil.c
> index 5d9ceb8..465d258 100644
> --- a/drivers/atmodem/atutil.c
> +++ b/drivers/atmodem/atutil.c
> @@ -33,6 +33,7 @@
>  #include 
> 
>  #include "atutil.h"
> +#include "types.h"
> 

I removed #include "types.h" to avoid distcheck error. Other is
unchanged.

Regards,
Zhenhua


0001-Move-and-rename-call_compare-and-call_compare_by_sta.patch
Description: 0001-Move-and-rename-call_compare-and-call_compare_by_sta.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/3] Inline release_id in voicecall.c

[Zhang, Zhenhua]

Hi Marcel,

Marcel Holtmann wrote:
> Hi Zhenhua,
>>
>> +unsigned int at_util_alloc_next_id(unsigned int *id_list) +{
>> +   unsigned int i;
>> +
>> +   for (i = 1; i < sizeof(unsigned int) * 8; i++) {
>> +   if (*id_list & (0x1 << i))
>> +   continue;
>> +
>> +   *id_list |= (0x1 << i);
>> +   return i;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +inline void at_util_release_id(unsigned int *id_list, unsigned int
>> id) +{
>> +   *id_list &= ~(0x1 << id);
>> +}
> 
> what is this? Don't use inline at all and let the compiler decide. I
> also don't really understand how you think this works. There is
> nothing to inline here.
> 
> And while at it. Drop the 0x1 stuff. Using 1 is much more readable.

Ok. I update the patch to remove inline and replace 0x1 by 1. The
update version is attached.

> Regards
> 
> Marcel
> 
> 
> ___
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua


0002-Move-and-rename-alloc_next_id-and-release_id-into-at.patch
Description: 0002-Move-and-rename-alloc_next_id-and-release_id-into-at.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 3/3] Add voicecall driver for Handsfree profile update

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Hi,
> 
> HFP voicecall driver uses AT+CIEV indicator to notify call status
> update according to Bluetooth HFP spec v1.5. First version support
> single call, multi call support will be ready soon.
> 

I update voicecall driver a little bit. The changes are:

1. rename alloc_next_id and release_id by patch #2.
2. hfp_dial check clir and cug option and now return error if they are not
default value.
3. split single call notification into two functions, one for call notify and
another for callsetup notify.

Regards,
Zhenhua


0003-Add-voicecall-driver-for-Handsfree-profile-update.patch
Description: 0003-Add-voicecall-driver-for-Handsfree-profile-update.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH 2/3] Inline release_id in voicecall.c

[Zhang, Zhenhua]

Hi,

Zhang, Zhenhua wrote:
> Inline release_id() in voicecall.c
> ---
>  drivers/atmodem/voicecall.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
> index f0c8d93..51b3a19 100644
> --- a/drivers/atmodem/voicecall.c
> +++ b/drivers/atmodem/voicecall.c
> @@ -104,7 +104,7 @@ static unsigned int alloc_next_id(struct
>   voicecall_data *d) return 0;
>  }
> 
> -static void release_id(struct voicecall_data *d, unsigned int id)
> +static inline void release_id(struct voicecall_data *d, unsigned int
>  id) {
>   d->id_list &= ~(0x1 << id);
>  }

alloc_next_id and release_id are renamed to add 'at_util' prefix and
put into atutil.c. The parameter 'unsigned int *id_list' replaces 'struct
voicecall_data *d' so that we could share them by atmodem and
hfpmodem.

Please review attached update patch.

Regards,
Zhenhua


0002-Move-and-rename-alloc_next_id-and-release_id-into-at.patch
Description: 0002-Move-and-rename-alloc_next_id-and-release_id-into-at.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 3/3] Add voicecall driver for Handsfree profile update

[Zhang, Zhenhua]

Hi,

HFP voicecall driver uses AT+CIEV indicator to notify call status update
according to Bluetooth HFP spec v1.5. First version support single call, multi
call support will be ready soon.

---
 Makefile.am  |3 +-
 drivers/hfpmodem/hfpmodem.c  |3 +
 drivers/hfpmodem/voicecall.c |  622 ++
 plugins/hfp.c|3 +
 4 files changed, 630 insertions(+), 1 deletions(-)
 create mode 100644 drivers/hfpmodem/voicecall.c

diff --git a/Makefile.am b/Makefile.am
index 8247f9d..8e56568 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -125,7 +125,8 @@ builtin_sources += drivers/atmodem/atutil.h \
 builtin_modules += hfpmodem
 builtin_sources += drivers/atmodem/atutil.h \
drivers/hfpmodem/hfpmodem.h \
-   drivers/hfpmodem/hfpmodem.c
+   drivers/hfpmodem/hfpmodem.c \
+   drivers/hfpmodem/voicecall.c

 builtin_modules += mbmmodem
 builtin_sources += drivers/atmodem/atutil.h \
diff --git a/drivers/hfpmodem/hfpmodem.c b/drivers/hfpmodem/hfpmodem.c
index 615acd3..03b5ea0 100644
--- a/drivers/hfpmodem/hfpmodem.c
+++ b/drivers/hfpmodem/hfpmodem.c
@@ -41,11 +41,14 @@

 static int hfpmodem_init(void)
 {
+   hfp_voicecall_init();
+
return 0;
 }

 static void hfpmodem_exit(void)
 {
+   hfp_voicecall_exit();
 }

 OFONO_PLUGIN_DEFINE(hfpmodem, "Hands-Free Profile Driver", VERSION,
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
new file mode 100644
index 000..c1e1eed
--- /dev/null
+++ b/drivers/hfpmodem/voicecall.c
@@ -0,0 +1,622 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2009  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include "hfpmodem.h"
+
+#define AG_CHLD_0 0x01
+#define AG_CHLD_1 0x02
+#define AG_CHLD_1x 0x04
+#define AG_CHLD_2 0x08
+#define AG_CHLD_2x 0x10
+#define AG_CHLD_3 0x20
+#define AG_CHLD_4 0x40
+
+static const char *none_prefix[] = { NULL };
+static const char *chld_prefix[] = { "+CHLD:", NULL };
+
+struct voicecall_data {
+   GAtChat *chat;
+   GSList *calls;
+   struct ofono_call *call;
+   gboolean mpty_call;
+   unsigned int ag_features;
+   unsigned int ag_mpty_features;
+   unsigned char cind_pos[HFP_INDICATOR_LAST];
+   int cind_val[HFP_INDICATOR_LAST];
+   unsigned int id_list;
+   unsigned int local_release;
+};
+
+struct release_id_req {
+   struct ofono_voicecall *vc;
+   ofono_voicecall_cb_t cb;
+   void *data;
+   int id;
+};
+
+struct change_state_req {
+   struct ofono_voicecall *vc;
+   ofono_voicecall_cb_t cb;
+   void *data;
+   int affected_types;
+};
+
+static unsigned int alloc_next_id(struct voicecall_data *d)
+{
+   unsigned int i;
+
+   for (i = 1; i < sizeof(d->id_list) * 8; i++) {
+   if (d->id_list & (0x1 << i))
+   continue;
+
+   d->id_list |= (0x1 << i);
+   return i;
+   }
+
+   return 0;
+}
+
+static inline void release_id(struct voicecall_data *d, unsigned int id)
+{
+   d->id_list &= ~(0x1 << id);
+}
+
+static struct ofono_call *create_call(struct voicecall_data *d, int type,
+   int direction, int status,
+   const char *num, int num_type, int clip)
+{
+   struct ofono_call *call;
+
+   /* Generate a call structure for the waiting call */
+   call = g_try_new0(struct ofono_call, 1);
+
+   if (!call)
+   return NULL;
+
+   call->id = alloc_next_id(d);
+   call->type = type;
+   call->direction = direction;
+   call->status = status;
+
+   if (clip != 2) {
+   strncpy(call->phone_number.number, num,
+   OFONO_MAX_PHONE_NUMBER_LENGTH);
+   call->phone_number.type = num_type;
+   }
+
+   d->calls = g_slist_insert_sorted(d->calls, call, at_util_call_compare);
+
+   call->clip_validity = clip;
+
+   if (d->call)
+   d->mpty_call = TRUE;
+
+   d->call

[PATCH 1/3] Move and rename call_compare and call_compare_by_status to atutil.c

[Zhang, Zhenhua]

Hi,

Below patch is to rename call_compare and call_compare_by_status into atutil.c
so that they could be shared by atmodem and hfpmodem drivers.

---
 drivers/atmodem/atutil.c|   27 +++
 drivers/atmodem/atutil.h|2 ++
 drivers/atmodem/voicecall.c |   39 +++
 3 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/drivers/atmodem/atutil.c b/drivers/atmodem/atutil.c
index 5d9ceb8..465d258 100644
--- a/drivers/atmodem/atutil.c
+++ b/drivers/atmodem/atutil.c
@@ -33,6 +33,7 @@
 #include 
 
 #include "atutil.h"
+#include "types.h"
 
 void dump_response(const char *func, gboolean ok, GAtResult *result)
 {
@@ -55,3 +56,29 @@ void decode_at_error(struct ofono_error *error, const char 
*final)
error->error = 0;
}
 }
+
+gint at_util_call_compare_by_status(gconstpointer a, gconstpointer b)
+{
+   const struct ofono_call *call = a;
+   int status = GPOINTER_TO_INT(b);
+
+   if (status != call->status)
+   return 1;
+
+   return 0;
+}
+
+gint at_util_call_compare(gconstpointer a, gconstpointer b)
+{
+   const struct ofono_call *ca = a;
+   const struct ofono_call *cb = b;
+
+   if (ca->id < cb->id)
+   return -1;
+
+   if (ca->id > cb->id)
+   return 1;
+
+   return 0;
+}
+
diff --git a/drivers/atmodem/atutil.h b/drivers/atmodem/atutil.h
index c30c70b..ab9db05 100644
--- a/drivers/atmodem/atutil.h
+++ b/drivers/atmodem/atutil.h
@@ -21,6 +21,8 @@
 
 void decode_at_error(struct ofono_error *error, const char *final);
 void dump_response(const char *func, gboolean ok, GAtResult *result);
+gint at_util_call_compare_by_status(gconstpointer a, gconstpointer b);
+gint at_util_call_compare(gconstpointer a, gconstpointer b);
 
 struct cb_data {
void *cb;
diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index 22a802f..f0c8d93 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -109,31 +109,6 @@ static void release_id(struct voicecall_data *d, unsigned 
int id)
d->id_list &= ~(0x1 << id);
 }
 
-static gint call_compare_by_status(gconstpointer a, gconstpointer b)
-{
-   const struct ofono_call *call = a;
-   int status = GPOINTER_TO_INT(b);
-
-   if (status != call->status)
-   return 1;
-
-   return 0;
-}
-
-static gint call_compare(gconstpointer a, gconstpointer b)
-{
-   const struct ofono_call *ca = a;
-   const struct ofono_call *cb = b;
-
-   if (ca->id < cb->id)
-   return -1;
-
-   if (ca->id > cb->id)
-   return 1;
-
-   return 0;
-}
-
 static struct ofono_call *create_call(struct voicecall_data *d, int type,
int direction, int status,
const char *num, int num_type, int clip)
@@ -159,7 +134,7 @@ static struct ofono_call *create_call(struct voicecall_data 
*d, int type,
 
call->clip_validity = clip;
 
-   d->calls = g_slist_insert_sorted(d->calls, call, call_compare);
+   d->calls = g_slist_insert_sorted(d->calls, call, at_util_call_compare);
 
return call;
 }
@@ -213,7 +188,7 @@ static GSList *parse_clcc(GAtResult *result)
else
call->clip_validity = 2;
 
-   l = g_slist_insert_sorted(l, call, call_compare);
+   l = g_slist_insert_sorted(l, call, at_util_call_compare);
}
 
return l;
@@ -729,12 +704,12 @@ static void ring_notify(GAtResult *result, gpointer 
user_data)
 
/* See comment in CRING */
if (g_slist_find_custom(vd->calls, GINT_TO_POINTER(5),
-   call_compare_by_status))
+   at_util_call_compare_by_status))
return;
 
/* RING can repeat, ignore if we already have an incoming call */
if (g_slist_find_custom(vd->calls, GINT_TO_POINTER(4),
-   call_compare_by_status))
+   at_util_call_compare_by_status))
return;
 
/* Generate an incoming call of unknown type */
@@ -768,12 +743,12 @@ static void cring_notify(GAtResult *result, gpointer 
user_data)
 * when a waiting call exists (cannot have waiting + incoming in GSM)
 */
if (g_slist_find_custom(vd->calls, GINT_TO_POINTER(5),
-   call_compare_by_status))
+   at_util_call_compare_by_status))
return;
 
/* CRING can repeat, ignore if we already have an incoming call */
if (g_slist_find_custom(vd->calls, GINT_TO_POINTER(4),
-   call_compare_by_status))
+   at_util_call_compare_by_status))
return;
 
g_at_result_iter_init(&iter, result);
@@ -818,7 +793,7 @@ static void clip_notify(GAtResult *result, gpointer 
user_data)
   

[PATCH 2/3] Inline release_id in voicecall.c

[Zhang, Zhenhua]

Inline release_id() in voicecall.c

---
 drivers/atmodem/voicecall.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index f0c8d93..51b3a19 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -104,7 +104,7 @@ static unsigned int alloc_next_id(struct voicecall_data *d)
return 0;
 }
 
-static void release_id(struct voicecall_data *d, unsigned int id)
+static inline void release_id(struct voicecall_data *d, unsigned int id)
 {
d->id_list &= ~(0x1 << id);
 }
-- 
1.6.2.5


Regards,
Zhenhua
 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] Add voicecall driver for Handsfree profile

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> on compiling your code I got this:
> 
> cc1: warnings being treated as errors
> drivers/hfpmodem/voicecall.c: In function 'chld_cb':
> drivers/hfpmodem/voicecall.c:539: error: 'ag_mpty_feature' may be used
> uninitialized in this function
> make[1]: *** [drivers/hfpmodem/voicecall.o] Error 1
> make: *** [all] Error 2
> 

The ag_mpty_feature should be initialized as 0 in chld_cb. Thanks for your
comments. I will update patch and send out later.
 
>> 
>> Regards,
>> Zhenhua
>> 
>> 
>> ___
>> ofono mailing list
>> ofono@ofono.org
>> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] Replace Glib type with standard C type

[Zhang, Zhenhua]

Hi,

Below patch is to replace Glib type with standard C type in hfpmodem.h, like 
guint, guint8, etc.

Please review it.

Regards,
Zhenhua

---
 drivers/hfpmodem/hfpmodem.h |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/hfpmodem/hfpmodem.h b/drivers/hfpmodem/hfpmodem.h
index 6c6ab6f..c4e2a34 100644
--- a/drivers/hfpmodem/hfpmodem.h
+++ b/drivers/hfpmodem/hfpmodem.h
@@ -55,10 +55,10 @@ enum hfp_indicator {
 
 struct hfp_data {
GAtChat *chat;
-   guint ag_features;
-   guint hf_features;
-   guint8 cind_pos[HFP_INDICATOR_LAST];
-   gint cind_val[HFP_INDICATOR_LAST];
+   unsigned int ag_features;
+   unsigned int hf_features;
+   unsigned char cind_pos[HFP_INDICATOR_LAST];
+   unsigned int cind_val[HFP_INDICATOR_LAST];
 };
 
 extern void hfp_voicecall_init();
-- 
1.6.1.3
 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] Add voicecall driver for Handsfree profile

[Zhang, Zhenhua]

Hi,

The first patch is to handle right bracket in at command parser. It's
identical with the previous patch I sent in the list.

The second patch depends on the first one so I resend it again. It implements
voicecall driver for handsfree profile and use AT+CIEV indicator to notify call
status change. A field 'struct ofono_call *call' that point to the current call
is used to avoid searching call list each time. A boolean 'mpty_call' is to
indicate whether it is multi call or single call. The first version only
supports single call. The multicall patch will be based on this patch.

Please review it.

Regards,
Zhenhua
 


0002-Add-voicecall-driver-for-Handsfree-profile.patch
Description: 0002-Add-voicecall-driver-for-Handsfree-profile.patch


0001-Handle-right-bracket-in-g_at_result_iter_next_unquot.patch
Description: 0001-Handle-right-bracket-in-g_at_result_iter_next_unquot.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] Handle right bracket in g_at_result_iter_next_unquoted_string

[Zhang, Zhenhua]

Allow g_at_result_iter_next_unquoted_string to handle the bracket when parsing
string like chld (1, 2). Original, it returns '1' and '2)'. Now it returns '1'
and '2'. g_at_result_iter_close_list handles the right bracket later.
---
 gatchat/gatresult.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gatchat/gatresult.c b/gatchat/gatresult.c
index 1436ae3..3d07e13 100644
--- a/gatchat/gatresult.c
+++ b/gatchat/gatresult.c
@@ -131,12 +131,12 @@ gboolean 
g_at_result_iter_next_unquoted_string(GAtResultIter *iter,
goto out;
}
 
-   if (line[pos] == '"')
+   if (line[pos] == '"' || line[pos] == ')')
return FALSE;
 
end = pos;
 
-   while (end < len && line[end] != ',')
+   while (end < len && line[end] != ',' && line[end] != ')')
end += 1;
 
iter->buf[end] = '\0';

Regards,
Zhenhua
 
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] Handsfree profile plugins update

[Zhang, Zhenhua]

Hi,

Attached is update patch for handsfree profile plugin. I move most stuff in 
drivers/hfpmodem/hfp.c into plugins/hfp.c and simplify them. GSList *indies
is replaced as two indexable arrays (cind_names and cind_values), to improve
efficiency when we need access name and value by index. The whole logic is
the same comparing with previous patch.

Thanks for Denis and Gustavo for comments. Please review it.

Regards,
Zhenhua
 


0001-handsfree-profile-plugin-update.patch
Description: 0001-handsfree-profile-plugin-update.patch
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: fix handsfree profile patch

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> This patch fix compiler warnings into your HFP patch. I didn't looked
> to the code and what it does yet. 
> 

Thanks for your patch. I will turn on the maintainer mode from now on.

> Regards,
> 
> Gustavo



Regards,
Zhenhua
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono