Re: PATCH: Support for Bluetooth NAP devices

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

> > > >> Bluetooth NAP devices are pretty simple really.   You connect and (at
> > > >> least in Linux) they emulate an ethernet device.
> > > >>
> > > >> However, NetworkManager doesn't work with these devices because HAL
> > > >> gives them the capability and category of "net.bluetooth".  Attached
> > > >> are a patch and a HAL fdi file.  To connect to a Bluetooth NAP device
> > > >> on Linux, do:
> > > >> pand -n -c $BSSID -d NAP
> > > >
> > > > the pand program is deprecated btw. You should look into the Bluetooth
> > > > network service.
> > > 
> > > Doesn't the bluetooth network service use the bnep kernel module?
> > > Is the bnep kernel module deprecated?
> > 
> > yes. Network service and pand use the same kernel layer.
> > 
> > > >> With the attached patch/fdi file, NetworkManager will automatically
> > > >> pick up the device and use it when connected.
> > > >
> > > > What is the FDI file for? I don't see its need, because HAL already
> > > > perfectly classifies the bnepX interfaces.
> > > 
> > > from src/nm-hal-manager.c:
> > > 
> > > static char *
> > > nm_get_device_driver_name (LibHalContext *ctx, const char *udi)
> > > {
> > >         char *origdev_udi;
> > >         char *driver_name = NULL;
> > > 
> > >         origdev_udi = libhal_device_get_property_string (ctx, udi,
> > > "net.originating_device", NULL);
> > >         if (!origdev_udi) {
> > >                 /* Older HAL uses 'physical_device' */
> > >                 origdev_udi = libhal_device_get_property_string (ctx,
> > > udi, "net.physical_device", NULL);
> > >         }
> > > 
> > >         if (origdev_udi && libhal_device_property_exists (ctx,
> > > origdev_udi, "info.linux.driver", NULL)) {
> > >                 char *drv = libhal_device_get_property_string (ctx,
> > > origdev_udi, "info.linux.driver", NULL);
> > >                 driver_name = g_strdup (drv);
> > >                 libhal_free_string (drv);
> > >         }
> > >         libhal_free_string (origdev_udi);
> > > 
> > >         return driver_name;
> > > }
> > > 
> > > ...
> > > 
> > > # device fails to create if driver doesn't exist
> > > driver = nm_get_device_driver_name (priv->hal_ctx, udi);
> > > device = (GObject *) nm_device_802_3_ethernet_new (udi, iface, driver, managed);
> > 
> > This is a bug within Network Manager. The driver name has no useful
> > input for it. At least not anymore. If we have no driver name, it should
> > fallback to sensible defaults.
> 
> The driver name gets pulled out of sysfs and is pretty important for
> debugging.  Basically, when you plug the thing in, what exact module is
> driving it?  I want the name of whatever module in drivers/bluetooth is
> driving the device.  It's not a bug in NM; we need the driver name.

except that in the Bluetooth case the driver makes no difference.
Bluetooth has a unified Host Controller Interface (HCI). And if you do
PAN/BNEP than the transport driver is always bnep. So no point here.

> That name is provided by HAL on the hciX device's parent device.  My
> "Kensington Bluetooth Adapter"
> is /org/freedesktop/Hal/devices/usb_device_47d_105d_XXXXXXXXXXXX_if0_bluetooth_hci_0 and it's parent device has an "info.linux.driver" key of "hci_usb".  That's great, that's exactly what I want.  The patch needs to pick this up.

Except that is not the one for the bnep0 device. In that case you get
the device of the ACL link and that has no driver. So you would need
parent of parent to get the right one. And then again, hci_usb is only a
host driver. It does nothing special to support BNEP.

Bluetooth will break all your assumptions. I am sorry about it, but that
technology works differently :)

Regards

Marcel