No route to host for bluetooth devices
Eric Anderson
anderson at centtech.com
Mon Dec 5 08:40:26 PST 2005
Maksim Yevmenkin wrote:
> Eric,
>
>>>>> Well, here's more information. First, it's reproducable every
>>>>> time I boot up. Doing:
>>>>> /etc/rc.d/bluetooth start ubt0
>>>>> does not fix it by itself, but doing:
>>>>> /etc/rc.d/bluetooth stop ubt0
>>>>> /etc/rc.d/bluetooth start ubt0
>>>>> does.
>>>>
>>>>
>>>> now, i really puzzled. because device fails on to start at boot
>>>> time, /etc/rc.d/bluetooth should have backed out and removed all
>>>> netgraph nodes it tried to create (except device node and socket
>>>> nodes). so i do not understand why do you need to do 'stop' before
>>>> 'start'. 'stop' should really be a noop in this case.
>>>>
>>>> could you please do the following
>>>>
>>>> 1) do a fresh boot with bluetooth device turned on
>>>>
>>>> 2) after system boots (and bluetooth device failed to start) please
>>>> run as root
>>>>
>>>> # ngctl li
>>>
>>>
>>> There are 7 total nodes:
>>> Name: ngctl992 Type: socket ID: 0000001d Num
>>> hooks: 0
>>> Name: ubt0l2cap Type: l2cap ID: 00000017 Num
>>> hooks: 3
>>> Name: ubt0hci Type: hci ID: 00000013 Num
>>> hooks: 3
>>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num
>>> hooks: 1
>>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num
>>> hooks: 1
>>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num
>>> hooks: 1
>>> Name: ubt0 Type: ubt ID: 00000001 Num
>>> hooks: 1
>>
>
> hmm... that does not make much sense to me. somehow you still have all
> nodes connected even if bluetooth device failed to initialize! that
> explains why do you need 'stop' command before 'start'.
>
> just a crazy idea. please double that you are not initializing device
> twice, i.e. you use new rc.d scripts and some leftovers from old
> system. or may be you have devd(8) configuration in both /etc in
> /usr/local/etc?
>
>>>>> I also tried a fresh boot, then switching the bluetooth off,
>>>>> waiting about 20 seconds, and flipping it back on, which *did* in
>>>>> fact work. I may not have waited long enough the previous time
>>>>> that failed.
>>>>
>>>>
>>>> ah, ok. could you please check the /var/log/messages file to see if
>>>> you get a message saying ubt0 is detached/attached?
>>>
>>>
>>> Here's the snippet upon boot:
>>>
>>> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3
>>> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3
>>> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 0 endpoints:
>>> interrupt=0x81, bulk-in=0x82, bulk-out=0x2
>>> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 1 (alt.config 5)
>>> endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6,
>>> buffer size=294
>>
>
> [...]
>
>>> Nov 17 19:31:41 neutrino kernel: ng_hci_process_command_timeout:
>>> ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout
>>
>
> device failed to initialize and rc.d/bluetooth should have cleaned the
> nodes, but it did not happen
>
>>> Nov 17 19:31:45 neutrino sdpd[659]: Could not bind control socket.
>>> Permission denied (13)
>>
>
> hmm... this is bad too. can you double check if you have sdpd running?
>
>>> now I'll run the bluetooth stop, which produces no output.
>>>
>>> ngctl li now looks like:
>>> There are 5 total nodes:
>>> Name: ngctl1015 Type: socket ID: 00000020 Num
>>> hooks: 0
>>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num
>>> hooks: 0
>>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num
>>> hooks: 0
>>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num
>>> hooks: 0
>>> Name: ubt0 Type: ubt ID: 00000001 Num
>>> hooks: 0
>>
>
> that is fine. that is what the output should look like when device is
> failed to initialize.
>
>>> Now I ran bluetooth start, which produces no output, and nothing in
>>> /var/log/messages.
>>>
>>> ngctl li now looks like this:
>>> There are 7 total nodes:
>>> Name: ngctl1045 Type: socket ID: 0000002c Num
>>> hooks: 0
>>> Name: ubt0l2cap Type: l2cap ID: 00000026 Num
>>> hooks: 3
>>> Name: ubt0hci Type: hci ID: 00000022 Num
>>> hooks: 3
>>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num
>>> hooks: 1
>>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num
>>> hooks: 1
>>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num
>>> hooks: 1
>>> Name: ubt0 Type: ubt ID: 00000001 Num
>>> hooks: 1
>>
>
> and that is fine too - this is what output should look like when all
> nodes are properly connected.
>
>>> Now I wiggle my mouse, and I see this in /var/log/messages:
>>> Nov 17 19:47:58 neutrino bthidd[603]: Accepted control connection
>>> from 00:07:61:31:27:15
>>> Nov 17 19:47:58 neutrino bthidd[603]: Accepted interrupt connection
>>> from 00:07:61:31:27:15
>>>
>>> and my mouse now works.
>>>
>>>>> Oddly enough, I never had a problem before now. I previously
>>>>> started the bluetooth stuff from rc.local. The only things I have
>>>>> changed are: updated to latest -current, removed inet6 from
>>>>> kernel, rebuilt world/kernel, switched to new rc.d bluetooth
>>>>> scripts. I can try anything you like.
>>>>
>>>>
>>>> one thing you could try to do is to comment out ubt0 section in
>>>> /etc/devd.conf and go back to old style rc.bluetooth script to see
>>>> if you have the same problem. if you do - then its not bluetooth
>>>> related, if you dont - then its related to new bluetooth rc.d scripts.
>>>
>>>
>>> I can do that if you'd like..
>>
>
> yes please, if you can.
>
>> Something else I just tried: booted up, no mouse as usual. Ran
>> /etc/rc.d/bluetooth start ubt0, and got this error:
>>
>> # /etc/rc.d/bluetooth start ubt0
>> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for
>> device ubt0
>>
>> and mouse still does not work..
>>
>> Then, ran it again:
>> # /etc/rc.d/bluetooth start ubt0
>>
>> no error, and voila! my mouse works. Didn't run the 'stop' part at
>> all, just the 'start' twice.
>
>
> again the explanation for this is: after the boot device failed to
> initialize, but for whatever reason, all nodes are still connected.
> when you do the 'start' command it tries to connect nodes, but it
> fails because nodes are already connected. because it fails - it tries
> to clean up after itself and removes all the nodes. thus resetting
> back to defaults. the next 'start' runs fine, because now everything
> as it should be.
>
> we need to figure out why nodes are still connected after your device
> failed on boot.
>
> thanks,
> max
After upgrading to the latest current, this problem is gone. Go
figure. Maybe I caught it somewhere in between, I have no idea.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
More information about the freebsd-bluetooth
mailing list