In both net-wireless/bluez-5.15 & net-wireless/bluez-5.16 the option "-f" was moved from rfcomm, so init script can't start it correctly : # /etc/init.d/rfcomm start * Caching service dependencies ... [ ok ] * Starting rfcomm ... /usr/bin/rfcomm: invalid option -- 'f'
Created attachment 373750 [details, diff] conf.d/rfcomm
Created attachment 373752 [details, diff] init.d/rfcomm This should fix the issue
+*bluez-5.17 (30 Mar 2014) + + 30 Mar 2014; Pacho Ramos <pacho@gentoo.org> +bluez-5.17.ebuild: + Version bump + + 30 Mar 2014; Pacho Ramos <pacho@gentoo.org> +files/rfcomm-init.d-r1: + Fix rfcomm init.d script (#505786 by Christophe PEREZ and Bombino) +
Could this be reopened? It appears that bluez no longer even supports the "rfcomm bind all" configuration option. So the "fix" actually turns the rfcomm startup to a no-op - removes the error but not the underlying problem. Has upstream removed support for "rfcomm bind all"?
Apparently, the support for config file was removed quite a while ago: http://marc.info/?l=linux-bluetooth&m=134454445304533&w=2
And how should it be used now? :/ (I am not familiar with rfcomm) Looks like there is no distribution supplying any service file / init.d script for starting rfcomm with this way
Apparently, you now need to call rfcomm <device> <btaddr> [<channel>] for every device that used to be in the config file. So, if my /etc/bluetooth/rfcomm.conf looks like this: rfcomm0 { bind yes; device 00:AA:BB:CC:DD:EE; } I now have to call rfcomm bind rfcomm2 00:AA:BB:CC:DD:EE I think the best way would be to add some kind of config to /etc/conf.d/rfcomm, perhaps something along the lines of /etc/conf.d/net: device_rfcomm0="00:AA:BB:CC:DD:EE" channel_rfcomm0="5" # optinal which would be parsed by the init script and translated to appropriate rfcomm bind calls
What is the intention of running "rfcomm bind <addr>"? Looks surprising to me that this is not handled by udev rules (for example, when the address is detected) if really needed :/ Thanks!
(In reply to Pacho Ramos from comment #8) > What is the intention of running "rfcomm bind <addr>"? Looks surprising to > me that this is not handled by udev rules (for example, when the address is > detected) if really needed :/ rfcomm bind rfcomm0 00:AA:BB:CC:DD:EE creates "serial port" at /dev/rfcomm0 (or other device node, I guess this is the part that depends on udev), and binds it to rfcomm service on Bluetooth device with address 00:AA:BB:CC:DD:EE (on given channel, if that is set). I'm not very familiar with udev, but my guesses why this is not handled entirely there are: - Nearby Bluetooth devices are not propagated to udev. Anyway, you probably don't want your computer to automatically create rfcomm devices nodes for any Bluetooth gadget that happens to be around. - I can have the rfcomm device bound even if the corresponding Bluetooth device is not present. The Bluetooth connection is established only after I open the rfcomm device.
I've stumbled upon this bug while trying to make my ppp over 3G connection work again after upgrading bluez to the 5.x versions. Even with bluez-5.18 and calling rfcomm bind rfcomm<n> <hwaddr> the rfcomm devices are still broken for me. With 4.101-r8, /etc/bluetooth/rfcomm.conf and /etc/init.d/rfcomm calling rfcomm bind all my /dev/rfcomm* devices were working. Now with manual binds and 5.18, when I try to launch pppd I get : May 6 12:05:50 blade pppd[14878]: pppd 2.4.5 started by root, uid 0 May 6 12:05:50 blade pppd[14878]: Failed to open /dev/rfcomm0: No route to host May 6 12:05:50 blade pppd[14878]: Exit. rfcomm output : rfcomm0: 40:98:4E:31:4B:F2 channel 1 clean Bluetooth configuration has always been obscure for me, maybe I simply miss something... I just tried to revert to 4.101-r8 but it won't be trivial (lots of packages have been upgraded before I detected the problem and there are some >=bluez-5 deps now)
(In reply to Lionel Bouton from comment #10) > Now with manual binds and 5.18, when I try to launch pppd I get : > > May 6 12:05:50 blade pppd[14878]: pppd 2.4.5 started by root, uid 0 > May 6 12:05:50 blade pppd[14878]: Failed to open /dev/rfcomm0: No route to > host > May 6 12:05:50 blade pppd[14878]: Exit. I had no problems connecting after I bound the device. To me, "No route to host" seems like it cannot create Bluetooth connection. I would look into whether it is paired, in range, the rfcomm service is visible via sdptool browse, and so on.
(In reply to Petr Novak from comment #11) > (In reply to Lionel Bouton from comment #10) > > Now with manual binds and 5.18, when I try to launch pppd I get : > > > > May 6 12:05:50 blade pppd[14878]: pppd 2.4.5 started by root, uid 0 > > May 6 12:05:50 blade pppd[14878]: Failed to open /dev/rfcomm0: No route to > > host > > May 6 12:05:50 blade pppd[14878]: Exit. > > I had no problems connecting after I bound the device. To me, "No route to > host" seems like it cannot create Bluetooth connection. I would look into > whether it is paired, in range, the rfcomm service is visible via sdptool > browse, and so on. Found the problem and the solution might be useful to others. The root cause is that bluetoothd returns before the bluetooth stack is fully usable. It may be desirable to open a new bug for the behaviour I describe below but as I tuned it in an unusual way (see below) I'm not sure it's really appropriate. The bluez-5 behavior has an unfortunate side-effect worth keeping in mind : "use/need bluetooth" in init.d scripts might not work as intended. Here's a short description and solution in case other people come to this bug like me with the same problem. This is a timing problem in my scripts. On my laptop the bluetooth stack is disabled by default (to save power) and only enabled when I need it. For my 3G connection I scripted the connection with (roughly): /etc/init.d/bluetooth start rfcomm bind rfcomm0 ... pppd ... It turns out that the rfcomm device can exist without bluetooth being fully initialized. Then launching pppd too soon reports "No route to host". Waiting 0.5s isn't enough on my system but waiting 1s after the rfcomm bind (and more to the point the "bluetooth start") is enough to make it work. It seems that the bluez-4 init script/bluetoothd unlike bluez-5 didn't usually return before bluetooth is usable. I write "usually" because in fact I remember having occasional timing problems with bluez-4 but it worked most of the time.
maybe this can go into netifrc to create the interface as we create others like tap? just tried to use my cell and was surprised to see that I cannot.
OK, solved this using a simple service, can you please check it out? ln -s rfcomm /etc/init.d/rfcomm.rfcomm0 echo > /etc/conf.d/rfcomm.rfcomm0 << __EOF__ ADDRESS="xxxx" CHANNEL="n" __EOF__ At /etc/conf.d/net.ppp0 add: rc_net_ppp0_need="rfcomm.rfcomm0"
Created attachment 377056 [details] rfcomm
Created attachment 377088 [details] init.d/rfcomm (alternative) That seems to work, however I'm a bit biased against creating config files for individual devices, so I made an alternative script that uses a single conf.d file, inspired by /etc/conf.d/net format: rfcomm0_address="AA:BB:CC:DD:EE:FF" #rfcomm0_channel=6 # optional #rfcomm1_address="CC:DD:EE:00:00:00"
(In reply to Petr Novak from comment #16) > Created attachment 377088 [details] > init.d/rfcomm (alternative) > > That seems to work, however I'm a bit biased against creating config files > for individual devices, so I made an alternative script that uses a single > conf.d file, inspired by /etc/conf.d/net format: > > rfcomm0_address="AA:BB:CC:DD:EE:FF" > #rfcomm0_channel=6 # optional > #rfcomm1_address="CC:DD:EE:00:00:00" that's ok, but please try to avoid evals at global context.
Created attachment 377090 [details] init.d/rfcomm (alternative v2) (In reply to Alon Bar-Lev from comment #17) > that's ok, but please try to avoid evals at global context. Okay, evals moved to start().
Alon, if this works for you with openRC please feel free to commit
(In reply to Pacho Ramos from comment #19) > Alon, if this works for you with openRC please feel free to commit thanks! bluez-5.20-r1
all of this should be detailled somewhere and not only in a fixed bug.
