DUN client for oFono and BlueZ

DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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.

3. plugin/dun.c prototype. A simple prototype for 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.

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

7. ConnMan integration. Setup of the NAT and Internet Connections.


Comments are welcome. :)

-- 
Gustavo F. Padovan
http://padovan.org

DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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

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.

3. plugin/dun.c prototype. A simple prototype for 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.

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

7. ConnMan integration. Setup of the NAT and Internet Connections.


Comments are welcome. :)

-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Marcel Holtmann]

Hi Gustavo,

> 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.
> 
> 3. plugin/dun.c prototype. A simple prototype for 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.
> 
> 6. AT command parser and PPP stack integration with DUN. The biggest task,
> where the core of the project is.

this is pretty clear. oFono carries the GAtChat library that comes with
AT command and PPP support. So oFono should carry the DUN client.

Regards

Marcel

Re: DUN client for oFono and BlueZ

[Marcel Holtmann]

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

Hi Gustavo,

> 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.
> 
> 3. plugin/dun.c prototype. A simple prototype for 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.
> 
> 6. AT command parser and PPP stack integration with DUN. The biggest task,
> where the core of the project is.

this is pretty clear. oFono carries the GAtChat library that comes with
AT command and PPP support. So oFono should carry the DUN client.

Regards

Marcel

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

Hi Marcel,

* Marcel Holtmann <marcel@holtmann.org> [2010-04-27 04:07:13 +0200]:

> Hi Gustavo,
> 
> > 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.
> > 
> > 3. plugin/dun.c prototype. A simple prototype for 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.
> > 
> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
> > where the core of the project is.
> 
> this is pretty clear. oFono carries the GAtChat library that comes with
> AT command and PPP support. So oFono should carry the DUN client.

Absolutely, I forgot to mention that oFono should carry the DUN client. I'm
starting some working on it. I'll send patches soon. :)

Regards,


-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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

Hi Marcel,

* Marcel Holtmann <marcel@holtmann.org> [2010-04-27 04:07:13 +0200]:

> Hi Gustavo,
> 
> > 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.
> > 
> > 3. plugin/dun.c prototype. A simple prototype for 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.
> > 
> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
> > where the core of the project is.
> 
> this is pretty clear. oFono carries the GAtChat library that comes with
> AT command and PPP support. So oFono should carry the DUN client.

Absolutely, I forgot to mention that oFono should carry the DUN client. I'm
starting some working on it. I'll send patches soon. :)

Regards,


-- 
Gustavo F. Padovan
http://padovan.org

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

RE: DUN client for oFono and BlueZ

[Zhang, Zhenhua]

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

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(a)ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

Hi Zhenhua,

* Zhang, Zhenhua <zhenhua.zhang@intel.com> [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?
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

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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

Hi Zhenhua,

* Zhang, Zhenhua <zhenhua.zhang@intel.com> [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?
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

Re: DUN client for oFono and BlueZ

[Denis Kenzior]

Hi Zhenhua,

> 
> > 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.

Gustavo is working on DUN _client_, the ModemEmulator work is on the DUN 
_server_ roles.  There is a difference ;)

Regards,
-Denis

Re: DUN client for oFono and BlueZ

[Denis Kenzior]

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

Hi Zhenhua,

> 
> > 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.

Gustavo is working on DUN _client_, the ModemEmulator work is on the DUN 
_server_ roles.  There is a difference ;)

Regards,
-Denis

RE: DUN client for oFono and BlueZ

[Zhang, Zhenhua]

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> * Zhang, Zhenhua <zhenhua.zhang@intel.com> [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

RE: DUN client for oFono and BlueZ

[Zhang, Zhenhua]

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

Hi Padovan,

Gustavo F. Padovan wrote:
> Hi Zhenhua,
> 
> * Zhang, Zhenhua <zhenhua.zhang@intel.com> [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

Re: DUN client for oFono and BlueZ

[Kalle Valo]

"Gustavo F. Padovan" <gustavo@padovan.org> writes:

> Hi all,

Hello Gustavo,

> 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.

Excellent, I'm eagerly waiting for this. I hate cables =)

As soon as you have something working, please do send patches so that
people can test it.

> 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.

Sorry, I'm not familiar with HFP Agent, but what will this agent
actually do on a DUN connection?

> 6. AT command parser and PPP stack integration with DUN. The biggest task,
> where the core of the project is.
>
> 7. ConnMan integration. Setup of the NAT and Internet Connections.

Why NAT is needed? I guess only for connection sharing.

-- 
Kalle Valo

Re: DUN client for oFono and BlueZ

[Kalle Valo]

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

"Gustavo F. Padovan" <gustavo@padovan.org> writes:

> Hi all,

Hello Gustavo,

> 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.

Excellent, I'm eagerly waiting for this. I hate cables =)

As soon as you have something working, please do send patches so that
people can test it.

> 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.

Sorry, I'm not familiar with HFP Agent, but what will this agent
actually do on a DUN connection?

> 6. AT command parser and PPP stack integration with DUN. The biggest task,
> where the core of the project is.
>
> 7. ConnMan integration. Setup of the NAT and Internet Connections.

Why NAT is needed? I guess only for connection sharing.

-- 
Kalle Valo

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

Hi Kalle,

* Kalle Valo <kalle.valo@canonical.com> [2010-04-27 09:03:05 +0300]:

> "Gustavo F. Padovan" <gustavo@padovan.org> writes:
> 
> > Hi all,
> 
> Hello Gustavo,
> 
> > 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.
> 
> Excellent, I'm eagerly waiting for this. I hate cables =)
> 
> As soon as you have something working, please do send patches so that
> people can test it.
> 
> > 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.
> 
> Sorry, I'm not familiar with HFP Agent, but what will this agent
> actually do on a DUN connection

The agent can request a RFCOMM connection and receive the RFCOMM channel
via DBus fd-passing. The the DUN plugin can do the handshake.

> 
> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
> > where the core of the project is.
> >
> > 7. ConnMan integration. Setup of the NAT and Internet Connections.
> 
> Why NAT is needed? I guess only for connection sharing.

No idea yet, I guess Denis told me about the NAT, but that will be the last part
of the project, so I'm not caring about it now. I have to check on my
irc logs.


-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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

Hi Kalle,

* Kalle Valo <kalle.valo@canonical.com> [2010-04-27 09:03:05 +0300]:

> "Gustavo F. Padovan" <gustavo@padovan.org> writes:
> 
> > Hi all,
> 
> Hello Gustavo,
> 
> > 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.
> 
> Excellent, I'm eagerly waiting for this. I hate cables =)
> 
> As soon as you have something working, please do send patches so that
> people can test it.
> 
> > 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.
> 
> Sorry, I'm not familiar with HFP Agent, but what will this agent
> actually do on a DUN connection

The agent can request a RFCOMM connection and receive the RFCOMM channel
via DBus fd-passing. The the DUN plugin can do the handshake.

> 
> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
> > where the core of the project is.
> >
> > 7. ConnMan integration. Setup of the NAT and Internet Connections.
> 
> Why NAT is needed? I guess only for connection sharing.

No idea yet, I guess Denis told me about the NAT, but that will be the last part
of the project, so I'm not caring about it now. I have to check on my
irc logs.


-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Kalle Valo]

"Gustavo F. Padovan" <gustavo@padovan.org> writes:

> Hi Kalle,

Hi Gustavo,

>> > 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.
>> 
>> Sorry, I'm not familiar with HFP Agent, but what will this agent
>> actually do on a DUN connection
>
> The agent can request a RFCOMM connection and receive the RFCOMM channel
> via DBus fd-passing. The the DUN plugin can do the handshake.

Ah, that makes perfect sense. Thanks for explaining it.

>> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
>> > where the core of the project is.
>> >
>> > 7. ConnMan integration. Setup of the NAT and Internet Connections.
>> 
>> Why NAT is needed? I guess only for connection sharing.
>
> No idea yet, I guess Denis told me about the NAT, but that will be the
> last part of the project, so I'm not caring about it now. I have to
> check on my irc logs.

When I was using bt dun on my laptop (just manually running pppd with
debian's pon script) I didn't need nat at all.

-- 
Kalle Valo

Re: DUN client for oFono and BlueZ

[Kalle Valo]

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

"Gustavo F. Padovan" <gustavo@padovan.org> writes:

> Hi Kalle,

Hi Gustavo,

>> > 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.
>> 
>> Sorry, I'm not familiar with HFP Agent, but what will this agent
>> actually do on a DUN connection
>
> The agent can request a RFCOMM connection and receive the RFCOMM channel
> via DBus fd-passing. The the DUN plugin can do the handshake.

Ah, that makes perfect sense. Thanks for explaining it.

>> > 6. AT command parser and PPP stack integration with DUN. The biggest task,
>> > where the core of the project is.
>> >
>> > 7. ConnMan integration. Setup of the NAT and Internet Connections.
>> 
>> Why NAT is needed? I guess only for connection sharing.
>
> No idea yet, I guess Denis told me about the NAT, but that will be the
> last part of the project, so I'm not caring about it now. I have to
> check on my irc logs.

When I was using bt dun on my laptop (just manually running pppd with
debian's pon script) I didn't need nat at all.

-- 
Kalle Valo

Re: DUN client for oFono and BlueZ

[Bastien Nocera]

On Mon, 2010-04-26 at 22:20 -0300, 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.

Does this project include anything that will be reusable by non-oFono
based projects? Native BT PPP line discipline would have been nice.

Cheers

Re: DUN client for oFono and BlueZ

[Bastien Nocera]

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

On Mon, 2010-04-26 at 22:20 -0300, 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.

Does this project include anything that will be reusable by non-oFono
based projects? Native BT PPP line discipline would have been nice.

Cheers

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

Hi Bastien,


* Bastien Nocera <hadess@hadess.net> [2010-04-27 09:15:28 +0100]:

> On Mon, 2010-04-26 at 22:20 -0300, 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.
> 
> Does this project include anything that will be reusable by non-oFono
> based projects? Native BT PPP line discipline would have been nice.
> 

Yes, oFono will be only the Agent, you can implement a new one if you
want. Also oFono already does the PPP line discipline, so we don't need
to duplicate such feature in BlueZ.

-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Gustavo F. Padovan]

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

Hi Bastien,


* Bastien Nocera <hadess@hadess.net> [2010-04-27 09:15:28 +0100]:

> On Mon, 2010-04-26 at 22:20 -0300, 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.
> 
> Does this project include anything that will be reusable by non-oFono
> based projects? Native BT PPP line discipline would have been nice.
> 

Yes, oFono will be only the Agent, you can implement a new one if you
want. Also oFono already does the PPP line discipline, so we don't need
to duplicate such feature in BlueZ.

-- 
Gustavo F. Padovan
http://padovan.org

Re: DUN client for oFono and BlueZ

[Bastien Nocera]

On Tue, 2010-04-27 at 12:30 -0300, Gustavo F. Padovan wrote:
> Hi Bastien,
> 
> 
> * Bastien Nocera <hadess@hadess.net> [2010-04-27 09:15:28 +0100]:
> 
> > On Mon, 2010-04-26 at 22:20 -0300, 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.
> > 
> > Does this project include anything that will be reusable by non-oFono
> > based projects? Native BT PPP line discipline would have been nice.
> > 
> 
> Yes, oFono will be only the Agent, you can implement a new one if you
> want.

The ppp implementation in NetworkManager already works for me.

>  Also oFono already does the PPP line discipline, so we don't need
> to duplicate such feature in BlueZ.

I thought BT PPP line discipline was a kernel feature.

Re: DUN client for oFono and BlueZ

[Bastien Nocera]

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

On Tue, 2010-04-27 at 12:30 -0300, Gustavo F. Padovan wrote:
> Hi Bastien,
> 
> 
> * Bastien Nocera <hadess@hadess.net> [2010-04-27 09:15:28 +0100]:
> 
> > On Mon, 2010-04-26 at 22:20 -0300, 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.
> > 
> > Does this project include anything that will be reusable by non-oFono
> > based projects? Native BT PPP line discipline would have been nice.
> > 
> 
> Yes, oFono will be only the Agent, you can implement a new one if you
> want.

The ppp implementation in NetworkManager already works for me.

>  Also oFono already does the PPP line discipline, so we don't need
> to duplicate such feature in BlueZ.

I thought BT PPP line discipline was a kernel feature.