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
On Tue, 2010-04-27 at 12:30 -0300, Gustavo F. Padovan wrote:
> Hi Bastien,
>
>
> * Bastien Nocera <[email protected]> [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.
Hi Bastien,
* Bastien Nocera <[email protected]> [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
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
"Gustavo F. Padovan" <[email protected]> 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
Hi Kalle,
* Kalle Valo <[email protected]> [2010-04-27 09:03:05 +0300]:
> "Gustavo F. Padovan" <[email protected]> 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
"Gustavo F. Padovan" <[email protected]> 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
Hi Padovan,
Gustavo F. Padovan wrote:
> Hi Zhenhua,
>
> * Zhang, Zhenhua <[email protected]> [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
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
Hi Zhenhua,
* Zhang, Zhenhua <[email protected]> [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
Hi Marcel,
* Marcel Holtmann <[email protected]> [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
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
> [email protected]
> http://lists.ofono.org/listinfo/ofono
Regards,
Zhenhua
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