Re: ppp using NM



On Thu, 2007-11-29 at 15:48 +0200, Tambet Ingo wrote:
> On Nov 29, 2007 1:47 AM, Bastien Nocera <hadess hadess net> wrote:
> > I'll be more than happy writing the GPRS bits of it.
> 
> Awesome!
> 
> > Is there any
> > Bluetooth related code in the code you're writing?
> 
> No, the current code only handles communications with serial devices
> like opening, closing, configuring, sending (AT) commands, waiting for
> any/certain replies, etc. It also implements a GSM (while currently
> called UmtsDevice, we're looking for a better name for it) device that
> is implemented on top of serial device and handles the specific AT
> commands required to establish a connection.

Bluetooth DUN is the same, just that you would need a poke at hcid's
D-Bus interface telling it to create an rfcomm device for you. eg.
- Find the serial service using org.bluez.Manager.ListServices()
- ConnectService(<bluetooth address>, "DUN")

You get a device from ConnectService, and use that to connect. You need
to clean up when you disconnect though, DisconnectService(device)

> Although I have no idea how bluetooth devices work, I assume there's
> some magic that needs to happen and as a result there will be a serial
> device that takes AT commands? If so, then bluetooth (NM) device could
> be just a subclass of the current GSM device, do it's magic in the
> initialization phase and let the GSM device take care of everything
> else.

Yep.

> > I'm thinking specifically of the ppp-manager having a special casing for
> > devices that look like Bluetooth addresses, and having it create rfcomm
> > devices as appropriate (as pppd still doesn't have any native Bluetooth
> > support).
> 
> The way things currently work is that we call pppd only after the
> serial connection is already established. Can this be done with
> bluetooth devices as well?

Yep, that's possible as well.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]