Re: Bluetooth support

[Antti Kaijanmäki]

On Wed, 2009-01-14 at 12:27 -0500, Dan Williams wrote:
> On Tue, 2009-01-13 at 19:11 +0200, Antti Kaijanmäki wrote:

> > Now we are focusing on GSM and CDMA so there are NMGsmInterface and
> > NMCdmaInterface which pretty much contain the code currently present in
> > NMGsmDevice and NMCdmaDevice. Then there are corresponding
> > NMBluetoothGsmDevice, NMDeviceKitGsmDevice, NMBluetoothCdmaDevice and
> > NMDeviceKitCdmaDevice implementing the interfaces.
> 
> Yeah, though given that we've already had a few different HAL-type
> things over the lifetime of NM, I'm a bit reluctant to use "DeviceKit"
> in the HAL/DeviceKit/udev discovered devices.

And given that most devices are discovered using these services it
should be perfectly clear not to state "DeviceKit" or anything else,
just think it as default if nothing else is stated. But I would like to
prefix Bluetooth devices for example with "NMBT".


> > I don't know.. The chart seems kind off messy. Would there actually be
> > any differences between, say, NMDeviceKitCdmaDevice and
> > NMDeviceKitGsmDevice; both just look at the device properties from
> > DeviceKit to determine the path to serial port, what else?
> 
> There may be later on, though if more functionality is moved to
> ModemManager the difference between the two gets less.  Still makes some
> sense to me to keep them separate for now, and they will be pretty small
> if we do our jobs correctly.

OK.


> > Oh, and btw, I added NMSerialGsmDevice and NMSerialCdmaDevice for serial
> > devices with arbitrary serial port paths. Settings would be something
> > like:
> 
> Arbitrary device node entry shouldn't be part of NM anywhere.  Nobody
> should have to type that in, nor does a field like that have any place
> in a UI.  The only type that *might* require that is old-school
> serial-attached RS232 modems for 56k POTS dialup, and those should get
> handled through directed probing instead.  NM would then pick up the
> udev capabilities of the device automatically and add it to the internal
> device list.

I have one mobile phone with RS232 connector for GRPS, but that falls
close to 56k use case. It's not a good idea to probe random devices that
are connected to COM-ports, but one solution would be to inject
necessary capabilities into DeviceKit, udev or whatever.


Back to discovering Bluetooth devices..
I'm not sure what would be the best way of doing this, but I would
suggest that we add a new settings-table "bluetooth" which can be
attached to appropriate connection hashes. For example adding
bluetooth-settings object to GSM connection hash would signal NM to
create a new Bluetooth GSM device. Same would go for Bluetooth PAN
devices. 

key  key type  value  notes
-
name STRINGbluetooth
address  STRINGXX:XX:XX:XX:XX:XX  bluetooth address of the device
aliasSTRING   optional, nice name for the
  device. if not set device remote
  name will be used


After we have BT address we can use SDP to query needed service on
remote device upon activation.


 -- Antti



signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Dan Williams]

On Tue, 2009-01-13 at 19:11 +0200, Antti Kaijanmäki wrote:
> On Mon, 2009-01-12 at 13:14 -0500, Dan Williams wrote:
> > On Mon, 2009-01-12 at 09:29 +0200, Antti Kaijanmäki wrote:
> > > On Thu, 2009-01-08 at 13:26 -0500, Dan Williams wrote:
> > > > > DUN on the other hand can not be made as a new device class as it's 
> > > > > just
> > > > > a way to get a serial device for NMGsmDevice and NMCdmaDevice. It 
> > > > > would
> > > > > be clear to separate NMSerialDevice to NMHalSerialDevice,
> > > > > NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> > > > > like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> > > > > NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice 
> > > > > we
> > > > > can't do the split; that would lead to NMBluetoothGsmDevice,
> > > > > NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> > > > > type enumeration.
> > > > > 
> > > > > Instead I suggest that we handle the different serial types inside
> > > > > NMSerialDevice. Let's add a 'type' option to serial configuration.
> > > > > NMSerialDevice would then handle these different types internally. The
> > > > > different types would be specified as an enumeration like {hal,
> > > > > bluetooth, path, irda, ...} The option would be optional and default 
> > > > > to
> > > > > HAL.
> > > > 
> > > > Or, make the GSM and CDMA bits GInterfaces instead that any particular
> > > > device can implement...  That's the cleaner route actually.
> > > 
> > > Wouldn't we still end up with HalGsmDevice, BtGsmDevice, ..., which
> > > would implement either GSM or CDMA interfaces? The only difference
> > > between e.g. HalGsmDevice and BtGsmDevice is the way how serial device
> > > is discovered and initialized and all GSM funtionality would have to be
> > > duplicated.. 
> > 
> > No, because you would make the GSM and CDMA code a GInterface which the
> > straight serial or BT class would implement, but of course all the
> > common code can still live in the GInterfaces.  As you correctly point
> > out, the behavior is the same once you have a serial port, so I doubt
> > the BT class would need to override much of anything in the
> > NMGsmInterface or NMCdmaInterface code.  GInterfaces are slightly
> > different than Java, for example, in that the interface itself can also
> > have a bunch of code and the class that implements it only needs to
> > override that code if necessary.
> 
> OK, sounds good. I was thinking about Java style interfaces, but now I
> see your point.
> 
> 
> > > IMO the right place for abstraction would be NMSerialDevice; we could
> > > turn that to a GInterface. We can't derive NMGsmDevice and NMCdmaDevice
> > > directly from GInterface, but we could have the NMSerialDevice as a
> > > member of those both classes. Then on device creation time just specify
> > > which class implementing NMSerialDevice interface you actually want. Of
> > > course this would prevent us from casting e.g. NMGsmDevice directly to
> > > NMSerialDevice and thus break backward compatibility;
> > > instead of  NM_SERIAL_DEVICE (foo)->bar ();
> > > we would do NM_GSM_DEVICE (foo)->get_serial_device ()->bar(); 
> > 
> > NMSerialDevice may well be the best place to put the abstraction, but I
> > don't think it needs to be done as you've described it.  Most of
> > NMSerialDevice will go away pretty soon and be replaced with
> > ModemManager, thus there will be a *lot* less code there that needs to
> > be shared.  All that's left is PPP handling.  We may well be able to get
> > away with killing NMSerialDevice as a class in the first place, and
> > putting its functionality into a small helper file instead.
> 
> 
> > Then we're left with NMBluetoothDevice, from which is derived
> > NMBTGsmDevice and NMBTCdmaDevice, and the old NMGsmDevice and
> > NMCdmaDevice which all just talk to ModemManager for the device setup,
> > and share the common PPP handler code.
> 
> I attached a quick UML chart; is that something we are after here?
> First off there's new device classes NMDeviceKitDevice and
> NMBluetoothDevice that indicate where the devices are coming from. Of
> course that might be over engineering, but anyway..

I'll take a look...

> Now we are focusing on GSM and CDMA so there are NMGsmInterface and
> NMCdmaInterface which pretty much contain the code currently present in
> NMGsmDevice and NMCdmaDevice. Then there are corresponding
> NMBluetoothGsmDevice, NMDeviceKitGsmDevice, NMBluetoothCdmaDevice and
> NMDeviceKitCdmaDevice implementing the interfaces.

Yeah, though given that we've already had a few different HAL-type
things over the lifetime of NM, I'm a bit reluctant to use "DeviceKit"
in the HAL/DeviceKit/udev discovered devices.

> I don't know.. The chart seems kind off messy. Would there actually be
> any differences between, say, NMDeviceKitCdmaDevice and
> NMDeviceKitGsmDevice; both just look at the device properties from
> DeviceKit to determine the path to serial port

Re: Bluetooth support

[Antti Kaijanmäki]

On Mon, 2009-01-12 at 13:14 -0500, Dan Williams wrote:
> On Mon, 2009-01-12 at 09:29 +0200, Antti Kaijanmäki wrote:
> > On Thu, 2009-01-08 at 13:26 -0500, Dan Williams wrote:
> > > > DUN on the other hand can not be made as a new device class as it's just
> > > > a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
> > > > be clear to separate NMSerialDevice to NMHalSerialDevice,
> > > > NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> > > > like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> > > > NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
> > > > can't do the split; that would lead to NMBluetoothGsmDevice,
> > > > NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> > > > type enumeration.
> > > > 
> > > > Instead I suggest that we handle the different serial types inside
> > > > NMSerialDevice. Let's add a 'type' option to serial configuration.
> > > > NMSerialDevice would then handle these different types internally. The
> > > > different types would be specified as an enumeration like {hal,
> > > > bluetooth, path, irda, ...} The option would be optional and default to
> > > > HAL.
> > > 
> > > Or, make the GSM and CDMA bits GInterfaces instead that any particular
> > > device can implement...  That's the cleaner route actually.
> > 
> > Wouldn't we still end up with HalGsmDevice, BtGsmDevice, ..., which
> > would implement either GSM or CDMA interfaces? The only difference
> > between e.g. HalGsmDevice and BtGsmDevice is the way how serial device
> > is discovered and initialized and all GSM funtionality would have to be
> > duplicated.. 
> 
> No, because you would make the GSM and CDMA code a GInterface which the
> straight serial or BT class would implement, but of course all the
> common code can still live in the GInterfaces.  As you correctly point
> out, the behavior is the same once you have a serial port, so I doubt
> the BT class would need to override much of anything in the
> NMGsmInterface or NMCdmaInterface code.  GInterfaces are slightly
> different than Java, for example, in that the interface itself can also
> have a bunch of code and the class that implements it only needs to
> override that code if necessary.

OK, sounds good. I was thinking about Java style interfaces, but now I
see your point.


> > IMO the right place for abstraction would be NMSerialDevice; we could
> > turn that to a GInterface. We can't derive NMGsmDevice and NMCdmaDevice
> > directly from GInterface, but we could have the NMSerialDevice as a
> > member of those both classes. Then on device creation time just specify
> > which class implementing NMSerialDevice interface you actually want. Of
> > course this would prevent us from casting e.g. NMGsmDevice directly to
> > NMSerialDevice and thus break backward compatibility;
> > instead of  NM_SERIAL_DEVICE (foo)->bar ();
> > we would do NM_GSM_DEVICE (foo)->get_serial_device ()->bar(); 
> 
> NMSerialDevice may well be the best place to put the abstraction, but I
> don't think it needs to be done as you've described it.  Most of
> NMSerialDevice will go away pretty soon and be replaced with
> ModemManager, thus there will be a *lot* less code there that needs to
> be shared.  All that's left is PPP handling.  We may well be able to get
> away with killing NMSerialDevice as a class in the first place, and
> putting its functionality into a small helper file instead.


> Then we're left with NMBluetoothDevice, from which is derived
> NMBTGsmDevice and NMBTCdmaDevice, and the old NMGsmDevice and
> NMCdmaDevice which all just talk to ModemManager for the device setup,
> and share the common PPP handler code.

I attached a quick UML chart; is that something we are after here?
First off there's new device classes NMDeviceKitDevice and
NMBluetoothDevice that indicate where the devices are coming from. Of
course that might be over engineering, but anyway..

Now we are focusing on GSM and CDMA so there are NMGsmInterface and
NMCdmaInterface which pretty much contain the code currently present in
NMGsmDevice and NMCdmaDevice. Then there are corresponding
NMBluetoothGsmDevice, NMDeviceKitGsmDevice, NMBluetoothCdmaDevice and
NMDeviceKitCdmaDevice implementing the interfaces.

I don't know.. The chart seems kind off messy. Would there actually be
any differences between, say, NMDeviceKitCdmaDevice and
NMDeviceKitGsmDevice; both just look at the device properties from
DeviceKit to determine the path to serial port, what else?


Oh, and btw, I added NMSerialGsmDevice and NMSerialCdmaDevice for serial
devices with arbitrary serial port paths. Settings would be something
like:

==
name: serialpath
type: gsm, cdma
gsm-capabilities: GSM-07.07, GSM-07.10 (could be probed?)
path: [path to serial port character file]
===

When NM sees t

Re: Bluetooth support

[Dan Williams]

On Mon, 2009-01-12 at 09:29 +0200, Antti Kaijanmäki wrote:
> On Thu, 2009-01-08 at 13:26 -0500, Dan Williams wrote:
> > > DUN on the other hand can not be made as a new device class as it's just
> > > a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
> > > be clear to separate NMSerialDevice to NMHalSerialDevice,
> > > NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> > > like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> > > NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
> > > can't do the split; that would lead to NMBluetoothGsmDevice,
> > > NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> > > type enumeration.
> > > 
> > > Instead I suggest that we handle the different serial types inside
> > > NMSerialDevice. Let's add a 'type' option to serial configuration.
> > > NMSerialDevice would then handle these different types internally. The
> > > different types would be specified as an enumeration like {hal,
> > > bluetooth, path, irda, ...} The option would be optional and default to
> > > HAL.
> > 
> > Or, make the GSM and CDMA bits GInterfaces instead that any particular
> > device can implement...  That's the cleaner route actually.
> 
> Wouldn't we still end up with HalGsmDevice, BtGsmDevice, ..., which
> would implement either GSM or CDMA interfaces? The only difference
> between e.g. HalGsmDevice and BtGsmDevice is the way how serial device
> is discovered and initialized and all GSM funtionality would have to be
> duplicated.. 

No, because you would make the GSM and CDMA code a GInterface which the
straight serial or BT class would implement, but of course all the
common code can still live in the GInterfaces.  As you correctly point
out, the behavior is the same once you have a serial port, so I doubt
the BT class would need to override much of anything in the
NMGsmInterface or NMCdmaInterface code.  GInterfaces are slightly
different than Java, for example, in that the interface itself can also
have a bunch of code and the class that implements it only needs to
override that code if necessary.

> IMO the right place for abstraction would be NMSerialDevice; we could
> turn that to a GInterface. We can't derive NMGsmDevice and NMCdmaDevice
> directly from GInterface, but we could have the NMSerialDevice as a
> member of those both classes. Then on device creation time just specify
> which class implementing NMSerialDevice interface you actually want. Of
> course this would prevent us from casting e.g. NMGsmDevice directly to
> NMSerialDevice and thus break backward compatibility;
> instead of  NM_SERIAL_DEVICE (foo)->bar ();
> we would do NM_GSM_DEVICE (foo)->get_serial_device ()->bar(); 

NMSerialDevice may well be the best place to put the abstraction, but I
don't think it needs to be done as you've described it.  Most of
NMSerialDevice will go away pretty soon and be replaced with
ModemManager, thus there will be a *lot* less code there that needs to
be shared.  All that's left is PPP handling.  We may well be able to get
away with killing NMSerialDevice as a class in the first place, and
putting its functionality into a small helper file instead.

Then we're left with NMBluetoothDevice, from which is derived
NMBTGsmDevice and NMBTCdmaDevice, and the old NMGsmDevice and
NMCdmaDevice which all just talk to ModemManager for the device setup,
and share the common PPP handler code.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Antti Kaijanmäki]

On Thu, 2009-01-08 at 13:26 -0500, Dan Williams wrote:
> > DUN on the other hand can not be made as a new device class as it's just
> > a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
> > be clear to separate NMSerialDevice to NMHalSerialDevice,
> > NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> > like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> > NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
> > can't do the split; that would lead to NMBluetoothGsmDevice,
> > NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> > type enumeration.
> > 
> > Instead I suggest that we handle the different serial types inside
> > NMSerialDevice. Let's add a 'type' option to serial configuration.
> > NMSerialDevice would then handle these different types internally. The
> > different types would be specified as an enumeration like {hal,
> > bluetooth, path, irda, ...} The option would be optional and default to
> > HAL.
> 
> Or, make the GSM and CDMA bits GInterfaces instead that any particular
> device can implement...  That's the cleaner route actually.

Wouldn't we still end up with HalGsmDevice, BtGsmDevice, ..., which
would implement either GSM or CDMA interfaces? The only difference
between e.g. HalGsmDevice and BtGsmDevice is the way how serial device
is discovered and initialized and all GSM funtionality would have to be
duplicated.. 

IMO the right place for abstraction would be NMSerialDevice; we could
turn that to a GInterface. We can't derive NMGsmDevice and NMCdmaDevice
directly from GInterface, but we could have the NMSerialDevice as a
member of those both classes. Then on device creation time just specify
which class implementing NMSerialDevice interface you actually want. Of
course this would prevent us from casting e.g. NMGsmDevice directly to
NMSerialDevice and thus break backward compatibility;
instead of  NM_SERIAL_DEVICE (foo)->bar ();
we would do NM_GSM_DEVICE (foo)->get_serial_device ()->bar(); 

 -- Antti




signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Dan Williams]

On Fri, 2008-12-26 at 23:35 +0200, Antti Kaijanmäki wrote:
> On Tue, 2008-12-23 at 10:09 -0500, Nathaniel McCallum wrote:
> > I've been working on it up until recently.  The main wall that I've
> > hit is that NMDevice assumes that the "device" (whatever that means;
> > in bluetooth land, its not so clear) lifecycle is greater than the
> > NMDevice lifecycle and that the device exists in HAL.  I've not really
> > found a way around that, but perhaps dcbw would like to comment...
> > 
> > Nathaniel
> 
> 
> Hello Nathaniel, list!
> 
> I'm working for a company[1] and I've been given a project in which I
> can work with NetworkManager. Oh, the joy! :)
> I haven't had the permission to discuss anything work related in public
> until now, but I'm very eager to co-operate with others to make NM rock
> even harder.
> 
> I am currently working on Bluetooth support among other things. I'm
> looking at Dial-up Networking (DUN) and Personal Area Networking (PAN).
> I have priority on DUN and I heard on #nm that someone is already
> working on PAN which is great news!
> 
> With PAN I think is clear that a completely new device class should be
> created. That's fine. Someone who is working with PAN should write to
> the list, so that the discussion gets documented and archived.
> 
> DUN on the other hand can not be made as a new device class as it's just
> a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
> be clear to separate NMSerialDevice to NMHalSerialDevice,
> NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
> like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
> NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
> can't do the split; that would lead to NMBluetoothGsmDevice,
> NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
> type enumeration.
> 
> Instead I suggest that we handle the different serial types inside
> NMSerialDevice. Let's add a 'type' option to serial configuration.
> NMSerialDevice would then handle these different types internally. The
> different types would be specified as an enumeration like {hal,
> bluetooth, path, irda, ...} The option would be optional and default to
> HAL.

Or, make the GSM and CDMA bits GInterfaces instead that any particular
device can implement...  That's the cleaner route actually.

Dan

> When a SettingsService signals a new GSM or CDMA connection with serial
> type set to 'bluetooth' NM would create the device object. Then the
> connection could be activated from nm-applet. Upon activation
> NM(SerialDevice) would ask BlueZ to create a bluez device object, query
> for DUN service on the remote device, and create a RFCOMM serial port.
> When the connection gets disconnected the RFCOMM port and BlueZ device
> object would be closed and released. When connection settings are
> deleted in SettingsService the device object would be destroyed.
> 
> Comments, suggestions?
> Let's get this ball moving!
> 
> 
> -- Antti
> 
> PS.
> you also reach me on #nm, I'm 'Wellark'
> 
> [1] http://www.nomovok.com
> 
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Antti Kaijanmäki]

On Tue, 2008-12-23 at 10:09 -0500, Nathaniel McCallum wrote:
> I've been working on it up until recently.  The main wall that I've
> hit is that NMDevice assumes that the "device" (whatever that means;
> in bluetooth land, its not so clear) lifecycle is greater than the
> NMDevice lifecycle and that the device exists in HAL.  I've not really
> found a way around that, but perhaps dcbw would like to comment...
> 
> Nathaniel


Hello Nathaniel, list!

I'm working for a company[1] and I've been given a project in which I
can work with NetworkManager. Oh, the joy! :)
I haven't had the permission to discuss anything work related in public
until now, but I'm very eager to co-operate with others to make NM rock
even harder.

I am currently working on Bluetooth support among other things. I'm
looking at Dial-up Networking (DUN) and Personal Area Networking (PAN).
I have priority on DUN and I heard on #nm that someone is already
working on PAN which is great news!

With PAN I think is clear that a completely new device class should be
created. That's fine. Someone who is working with PAN should write to
the list, so that the discussion gets documented and archived.

DUN on the other hand can not be made as a new device class as it's just
a way to get a serial device for NMGsmDevice and NMCdmaDevice. It would
be clear to separate NMSerialDevice to NMHalSerialDevice,
NMBluetoothSerialDevice, and NMPathSerialDevice (for arbitrary paths
like '/dev/ttyS0' or '/dev/foo/bar/proprietary69'), but because
NMGsmDevice and NMCdmaDevice are derived directly from NMSerialDevice we
can't do the split; that would lead to NMBluetoothGsmDevice,
NMHalGsmDevice, NMHalCdmaDevice, etc and also break the current device
type enumeration.

Instead I suggest that we handle the different serial types inside
NMSerialDevice. Let's add a 'type' option to serial configuration.
NMSerialDevice would then handle these different types internally. The
different types would be specified as an enumeration like {hal,
bluetooth, path, irda, ...} The option would be optional and default to
HAL.

When a SettingsService signals a new GSM or CDMA connection with serial
type set to 'bluetooth' NM would create the device object. Then the
connection could be activated from nm-applet. Upon activation
NM(SerialDevice) would ask BlueZ to create a bluez device object, query
for DUN service on the remote device, and create a RFCOMM serial port.
When the connection gets disconnected the RFCOMM port and BlueZ device
object would be closed and released. When connection settings are
deleted in SettingsService the device object would be destroyed.

Comments, suggestions?
Let's get this ball moving!


-- Antti

PS.
you also reach me on #nm, I'm 'Wellark'

[1] http://www.nomovok.com



signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Simon Geard]

On Tue, 2008-12-23 at 23:00 +, Yosef Akhtman wrote:
> It is surprising that something that can be relatively easily achieved 
> by editing a couple of config files plus running a couple of simple 
> instructions on the command line, may not be achieved with the whole 
> might of the NM framework.

Not really. Hacking things to work on their own is relatively easy.
Making them work as part of a framework with everything else is a much
more difficult problem.

Simon.


signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Yosef Akhtman]

It is surprising that something that can be relatively easily achieved 
by editing a couple of config files plus running a couple of simple 
instructions on the command line, may not be achieved with the whole 
might of the NM framework.


I am new to GNOME hacking, so I would not know the solutions to the 
issues you have mentioned, but I will continue to look into it just in 
case I might get lucky. Please, let me know if you happen to have 
progress on this.


Marry Christmas,
Jos

Nathaniel McCallum wrote:
I've been working on it up until recently.  The main wall that I've 
hit is that NMDevice assumes that the "device" (whatever that means; 
in bluetooth land, its not so clear) lifecycle is greater than the 
NMDevice lifecycle and that the device exists in HAL.  I've not really 
found a way around that, but perhaps dcbw would like to comment...


Nathaniel

On Tue, Dec 23, 2008 at 9:33 AM, Yosef Akhtman > wrote:


Hi

I'd love to help with the implementation of the GPRS over
Bluetooth in NM.
Is it an active project and is there any way I could contribute at
the moment?
I have it working using manual configuration on
Ubuntu 8.10
bluez-utils 4.12
Samsung D500 phone on a prepaid Vodaphone service in UK

All the best,
Jos

On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
> Hi
>
> I'd love to be able to have GPRS over Bluetooth work, even if it
> required properly configuring /etc/bluetooth/rfcomm.conf at first
> (it's the manual PPP stuff I hate).

We've got a plan, and BT is a top work item for NM 0.8, which I'll try
to detail soon on this list.  It won't involve any mucking with
rfcomm.conf since all that can be done automatically with the Bluez
D-Bus interface.  It may require a fairly recent version of Bluez
though
(like 3.29 or later).

> Is there any way I can help?

We'll need testing at some point, of course.  At the moment though,
we're in the planning stages.  What distro are you running and what
version of the bluez-utils packages do you have?

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org 
http://mail.gnome.org/mailman/listinfo/networkmanager-list




___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Nathaniel McCallum]

I've been working on it up until recently.  The main wall that I've hit is
that NMDevice assumes that the "device" (whatever that means; in bluetooth
land, its not so clear) lifecycle is greater than the NMDevice lifecycle and
that the device exists in HAL.  I've not really found a way around that, but
perhaps dcbw would like to comment...

Nathaniel

On Tue, Dec 23, 2008 at 9:33 AM, Yosef Akhtman  wrote:

> Hi
>
> I'd love to help with the implementation of the GPRS over Bluetooth in NM.
> Is it an active project and is there any way I could contribute at the
> moment?
> I have it working using manual configuration on
> Ubuntu 8.10
> bluez-utils 4.12
> Samsung D500 phone on a prepaid Vodaphone service in UK
>
> All the best,
> Jos
>
> On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
> > Hi
> >
> > I'd love to be able to have GPRS over Bluetooth work, even if it
> > required properly configuring /etc/bluetooth/rfcomm.conf at first
> > (it's the manual PPP stuff I hate).
>
> We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> to detail soon on this list.  It won't involve any mucking with
> rfcomm.conf since all that can be done automatically with the Bluez
> D-Bus interface.  It may require a fairly recent version of Bluez though
> (like 3.29 or later).
>
> > Is there any way I can help?
>
> We'll need testing at some point, of course.  At the moment though,
> we're in the planning stages.  What distro are you running and what
> version of the bluez-utils packages do you have?
>
> Dan
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Yosef Akhtman]

Hi

I'd love to help with the implementation of the GPRS over Bluetooth in NM. 
Is it an active project and is there any way I could contribute at the moment?
I have it working using manual configuration on 
Ubuntu 8.10
bluez-utils 4.12
Samsung D500 phone on a prepaid Vodaphone service in UK

All the best,
Jos

On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
> Hi
> 
> I'd love to be able to have GPRS over Bluetooth work, even if it
> required properly configuring /etc/bluetooth/rfcomm.conf at first
> (it's the manual PPP stuff I hate).

We've got a plan, and BT is a top work item for NM 0.8, which I'll try
to detail soon on this list.  It won't involve any mucking with
rfcomm.conf since all that can be done automatically with the Bluez
D-Bus interface.  It may require a fairly recent version of Bluez though
(like 3.29 or later).

> Is there any way I can help?

We'll need testing at some point, of course.  At the moment though,
we're in the planning stages.  What distro are you running and what
version of the bluez-utils packages do you have?

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Marcel Holtmann]

Hi Dan,

> > > > I'd love to be able to have GPRS over Bluetooth work, even if it
> > > > required properly configuring /etc/bluetooth/rfcomm.conf at first
> > > > (it's the manual PPP stuff I hate).
> > > 
> > > We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> > > to detail soon on this list.  It won't involve any mucking with
> > > rfcomm.conf since all that can be done automatically with the Bluez
> > > D-Bus interface.  It may require a fairly recent version of Bluez though
> > > (like 3.29 or later).
> > 
> > go more for something like 4.22 :)
> 
> Probably, but Fedora 9, which is the last release I care about, has
> 3.36.  3.29 is the latest version I can find that add support for the
> "new" interface.

except that we changed it in 4.x to make it even simpler. You just have
to find the right object path, call Connect() on it and then either get
a TTY or network device name as result.

Regards

Marcel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Maxim Levitsky]

On Thu, 2008-12-11 at 06:04 +1100, Mikel Ward wrote:
> On Thu, Dec 11, 2008 at 4:50 AM, Dan Williams <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
> >> Hi
> >>
> >> I'd love to be able to have GPRS over Bluetooth work, even if it
> >> required properly configuring /etc/bluetooth/rfcomm.conf at first
> >> (it's the manual PPP stuff I hate).
> >
> > We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> > to detail soon on this list.  It won't involve any mucking with
> > rfcomm.conf since all that can be done automatically with the Bluez
> > D-Bus interface.  It may require a fairly recent version of Bluez though
> > (like 3.29 or later).
> 
> Good to hear!
> 
> >> Is there any way I can help?
> >
> > We'll need testing at some point, of course.  At the moment though,
> > we're in the planning stages.  What distro are you running and what
> > version of the bluez-utils packages do you have?
> 
> Currently running Ubuntu 8.10 x86 with bluez 4.12-0ubuntu5.
Speaking of new features, how about L2TP?



> 
> Thanks
> 
> Mike
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Dan Williams]

On Wed, 2008-12-10 at 19:29 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > I'd love to be able to have GPRS over Bluetooth work, even if it
> > > required properly configuring /etc/bluetooth/rfcomm.conf at first
> > > (it's the manual PPP stuff I hate).
> > 
> > We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> > to detail soon on this list.  It won't involve any mucking with
> > rfcomm.conf since all that can be done automatically with the Bluez
> > D-Bus interface.  It may require a fairly recent version of Bluez though
> > (like 3.29 or later).
> 
> go more for something like 4.22 :)

Probably, but Fedora 9, which is the last release I care about, has
3.36.  3.29 is the latest version I can find that add support for the
"new" interface.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Mikel Ward]

On Thu, Dec 11, 2008 at 4:50 AM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
>> Hi
>>
>> I'd love to be able to have GPRS over Bluetooth work, even if it
>> required properly configuring /etc/bluetooth/rfcomm.conf at first
>> (it's the manual PPP stuff I hate).
>
> We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> to detail soon on this list.  It won't involve any mucking with
> rfcomm.conf since all that can be done automatically with the Bluez
> D-Bus interface.  It may require a fairly recent version of Bluez though
> (like 3.29 or later).

Good to hear!

>> Is there any way I can help?
>
> We'll need testing at some point, of course.  At the moment though,
> we're in the planning stages.  What distro are you running and what
> version of the bluez-utils packages do you have?

Currently running Ubuntu 8.10 x86 with bluez 4.12-0ubuntu5.

Thanks

Mike
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Marcel Holtmann]

Hi Dan,

> > I'd love to be able to have GPRS over Bluetooth work, even if it
> > required properly configuring /etc/bluetooth/rfcomm.conf at first
> > (it's the manual PPP stuff I hate).
> 
> We've got a plan, and BT is a top work item for NM 0.8, which I'll try
> to detail soon on this list.  It won't involve any mucking with
> rfcomm.conf since all that can be done automatically with the Bluez
> D-Bus interface.  It may require a fairly recent version of Bluez though
> (like 3.29 or later).

go more for something like 4.22 :)

Regards

Marcel


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bluetooth support

[Dan Williams]

On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote:
> Hi
> 
> I'd love to be able to have GPRS over Bluetooth work, even if it
> required properly configuring /etc/bluetooth/rfcomm.conf at first
> (it's the manual PPP stuff I hate).

We've got a plan, and BT is a top work item for NM 0.8, which I'll try
to detail soon on this list.  It won't involve any mucking with
rfcomm.conf since all that can be done automatically with the Bluez
D-Bus interface.  It may require a fairly recent version of Bluez though
(like 3.29 or later).

> Is there any way I can help?

We'll need testing at some point, of course.  At the moment though,
we're in the planning stages.  What distro are you running and what
version of the bluez-utils packages do you have?

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Bluetooth support

[Mikel Ward]

Hi

I'd love to be able to have GPRS over Bluetooth work, even if it
required properly configuring /etc/bluetooth/rfcomm.conf at first
(it's the manual PPP stuff I hate).

Is there any way I can help?

Mike
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Claudio Takahasi]

Hi Tom,

Sorry but I decided implement the Bluetooth PAN service at 
BlueZ level.  In my opinion this approach wil be better to embedded devices 
and open new perspectives to implement more Bluetooth Local Services
(eg: printer, data exchange, dialup networking, headset, ...)

If possible I expect contribute to NetworkManager project soon.

Thanks for your time.
Claudio.


On 4/29/05, Tom Parker <[EMAIL PROTECTED]> wrote:
> Claudio Takahasi wrote:
> > Thank you for your answer. The autoip.c file is visible
> > in the CVS repository only, It is not available in
> > the tarball.
> 
> The tarball is *very* old - last release was October 2004, which for a
> project moving as fast as NetworkManager is far too old to be working
> on. If you want to do any NM development, use the CVS copy.
> 
> > Is there any application to test the automatic ip
> > assignment? Is it working?
> 
> It should be! Currently the only path that uses it is the ad-hoc
> wireless code (which I think you can set off by right clicking on the
> panel applet and telling it to set up a new wireless network), but it
> would also be useful to be able to be able to setup an autoip address
> when DHCP fails (but marked as "replace if we can find anything better"
> i.e. if DHCP works later on - possibly by having two sets of addresses
> setup, one autoip as backup, and one "proper" one. If the proper one
> isn't currently setup (no dhcp, no other config data), then use the
> autoip one) - but that's something I haven't looked at in a while.
> 
> NM is in a continual state of change - there's new stuff being added,
> and we're constantly thinking of new bits and pieces to try and get
> closer to the whole "it just works" idea. On the other hand, it's also
> still very much a work-in-progress, so there are some things like this
> that haven't been fully explored yet. Contributions are welcomed!
> 
> Tom Parker
> 


-- 
___
Claudio Takahasi
INdT - Nokia Technology Institute
Phone: +55 81 21223034
Recife - Pernambuco - Brazil
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Tom Parker]

Claudio Takahasi wrote:
Thank you for your answer. The autoip.c file is visible
in the CVS repository only, It is not available in
the tarball.
The tarball is *very* old - last release was October 2004, which for a 
project moving as fast as NetworkManager is far too old to be working 
on. If you want to do any NM development, use the CVS copy.

Is there any application to test the automatic ip
assignment? Is it working?
It should be! Currently the only path that uses it is the ad-hoc 
wireless code (which I think you can set off by right clicking on the 
panel applet and telling it to set up a new wireless network), but it 
would also be useful to be able to be able to setup an autoip address 
when DHCP fails (but marked as "replace if we can find anything better" 
i.e. if DHCP works later on - possibly by having two sets of addresses 
setup, one autoip as backup, and one "proper" one. If the proper one 
isn't currently setup (no dhcp, no other config data), then use the 
autoip one) - but that's something I haven't looked at in a while.

NM is in a continual state of change - there's new stuff being added, 
and we're constantly thinking of new bits and pieces to try and get 
closer to the whole "it just works" idea. On the other hand, it's also 
still very much a work-in-progress, so there are some things like this 
that haven't been fully explored yet. Contributions are welcomed!

Tom Parker
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Claudio Takahasi]

Hi Tom,

Thank you for your answer. The autoip.c file is visible
in the CVS repository only, It is not available in
the tarball.

Is there any application to test the automatic ip
assignment? Is it working?


Regards,
Claudio.


On 4/28/05, Tom Parker <[EMAIL PROTECTED]> wrote:
> Claudio Takahasi wrote:
> > Dynamic Configuration of IPv4 Link-Local Address.
> > http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt
> 
> If you're going to look at that for Bluetooth, the obvious starting
> point would be the existing implementation of it in NetworkManager. See
> src/autoip.c for more details.
> 
> Tom Parker
> 


-- 
___
Claudio Takahasi
INdT - Nokia Technology Institute
Phone: +55 81 21223034
Recife - Pernambuco - Brazil
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Tom Parker]

Claudio Takahasi wrote:
Dynamic Configuration of IPv4 Link-Local Address.
http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt
If you're going to look at that for Bluetooth, the obvious starting 
point would be the existing implementation of it in NetworkManager. See 
src/autoip.c for more details.

Tom Parker
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Claudio Takahasi]

Hi Paul,

Sorry for such a late answer.

Currently, an user mode application or a DBUS application doesn't
have access to BlueZ daemons/applications. There is not library
to allow control connections.

Before I try including bluetooth DBUS service, I am
trying enhance BlueZ, adding a library to control the bluetooth
connections including dynamic configuration of IP. This 
proposal will be based on IETF draft:
Dynamic Configuration of IPv4 Link-Local Address.
http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt

If my proposal is interesting for this community I will appreciate
contribute.

Claudio.




On 4/19/05, Paul Ionescu <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On Tue, 19 Apr 2005 16:36:01 -0300, Claudio Takahasi wrote:
> 
> > Hi folks,
> >
> > I am writing to know if I can contribute with NetworkManager. My interest
> > is develop/enhance
> > the bluetooth PAN support.
> >
> > Everybody knows that setup a bluetooth PAN, assign IP address and control
> > the device role
> > are hard tasks. BlueZ (Bluetooth linux stack) provides tools to enable
> > setup Bluetooth PANs. However, It is not transparent enough and an user
> > mode application
> > is not able to control Bluetooth connections.
> >
> > Therefore, my objetive is remove this gap, enabling and controlling
> > seamless connections.
> >
> > Is this topic useful for this group?
> >
> > Claudio Takahasi.
> 
> Hello Claudio,
> 
> I want support for bluetooth in NM too.
> Bluetooth is in NM spec, so I think it is useful for this list.
> Right now I am using bluetooth with PAN in a manual way and works fine,
> but I would love to have it in NM.
> I can help with testing as I already have a PAN at home.
> It should be even more simple than wireless, as it does not have the
> complexity and multiple authentication types as wireless.
> Even more, the mess in wireless is because of different drivers with
> different behaviors, but in bluetooth, all drivers are from BlueZ stack.
> 
> Thx,
> Paul
> 
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
> 


-- 
___
Claudio Takahasi
INdT - Nokia Technology Institute
Phone: +55 81 21223034
Recife - Pernambuco - Brazil
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [NetworkManager] Bluetooth support

[Paul Ionescu]

Hi,

On Tue, 19 Apr 2005 16:36:01 -0300, Claudio Takahasi wrote:

> Hi folks,
> 
> I am writing to know if I can contribute with NetworkManager. My interest
> is develop/enhance
> the bluetooth PAN support.
> 
> Everybody knows that setup a bluetooth PAN, assign IP address and control
> the device role
> are hard tasks. BlueZ (Bluetooth linux stack) provides tools to enable
> setup Bluetooth PANs. However, It is not transparent enough and an user
> mode application
> is not able to control Bluetooth connections.
> 
> Therefore, my objetive is remove this gap, enabling and controlling
> seamless connections.
> 
> Is this topic useful for this group?
> 
> Claudio Takahasi.

Hello Claudio,

I want support for bluetooth in NM too.
Bluetooth is in NM spec, so I think it is useful for this list.
Right now I am using bluetooth with PAN in a manual way and works fine,
but I would love to have it in NM.
I can help with testing as I already have a PAN at home.
It should be even more simple than wireless, as it does not have the
complexity and multiple authentication types as wireless.
Even more, the mess in wireless is because of different drivers with
different behaviors, but in bluetooth, all drivers are from BlueZ stack.

Thx,
Paul

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[NetworkManager] Bluetooth support

[Claudio Takahasi]

Hi folks,

I am writing to know if I can contribute with NetworkManager. My
interest is develop/enhance
the bluetooth PAN support.

Everybody knows that setup a bluetooth PAN, assign IP address and
control the device role
are hard tasks. BlueZ (Bluetooth linux stack) provides tools to enable setup 
Bluetooth PANs. However, It is not transparent enough and an user mode
application
is not able to control Bluetooth connections.

Therefore, my objetive is remove this gap, enabling and controlling
seamless connections.

Is this topic useful for this group?

Claudio Takahasi.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list