No route to host for bluetooth devices

[Eric Anderson]

Maksim Yevmenkin wrote:
> Eric,
> 
>>>>>> Well, I've recently updated to the latest current, and while 
>>>>>> yesterday everything seemed to be working fine, this morning after 
>>>>>> booting up (no changes were made anywhere, except rebooting), I 
>>>>>> cannot use bluetooth devices.  Here's some quick info:
>>>>>>
>>>>>> snippets from /var/log/messages:
>>>>>> Nov 16 06:30:58 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, 
>>>>>> addr 3
>>>>>> Nov 16 06:30:58 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, 
>>>>>> addr 3
>>>>>> Nov 16 06:30:58 neutrino kernel: ubt0: Interface 0 endpoints: 
>>>>>> interrupt=0x81, bulk-in=0x82, bulk-out=0x2
>>>>>> Nov 16 06:30:58 neutrino kernel: ubt0: Interface 1 (alt.config 5) 
>>>>>> endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; 
>>>>>> nframes=6, buffer size=294
>>>>>> Nov 16 06:31:08 neutrino kernel: ng_hci_process_command_timeout: 
>>>>>> ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout
>>>>>
>>>>>
>>>>> device initialization failed. reset command has timed out. there 
>>>>> should be message like
>>>>>
>>>>> "Unable to setup Bluetooth stack for device"
>>>>>
>>>>> somewhere in your logs.
>>>>
>>>>
>>>> I could not find that message anywhere (dmesg, or 
>>>> /var/log/messages). Only thing I saw was:
>>>> WARNING: attempt to net_add_domain(bluetooth) after domainfinalize()
>>>> which I believe is harmless.
>>>
>>>
>>> /etc/rc.d/bluetooth uses err() and warn() from /etc/rc.subr to 
>>> complain about errors. both err() and warn() use /usr/bin/logger to 
>>> send messages. according to the logger(1) man page it uses default 
>>> user.notice priority.
>>>
>>> could you please try to run as root
>>>
>>> # logger foo
>>>
>>> and then check your /var/log/messages to see if you got "foo" line in 
>>> there.
>>
>>
>> As root or regular user, I see the foo message in /var/log/messages.
> 
> 
> thats good.
> 
>>> if you dont, then verify syslogd(8) is runnig and check your 
>>> /etc/syslog.conf to see where do you redirect *.notice messages (or 
>>> more specifically user.notice).
>>>
>>> i will double check if there is an ordering issue, i.e. devd(8) is 
>>> started before syslogd(8) and thus error messages are not logged.
>>
>>
>>
>> Here's my syslog.conf:
> 
> 
> [...]
> 
>> *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err 
> 
> 
> *.notice should go into /var/log/messages. so you should have seen the 
> error message from /etc/rc.d/bluetooth there. did you check 
> messages.{1,2,...} files? may be it was rotated?
> 
> i'm pretty sure that on my system syslogd(8) starts before devd(8). so 
> at this point i do not know why you did not get error message from 
> /etc/rc.d/bluetooth. i will try to simulate the error on boot to see 
> what is going on.
> 
> [...]
> 
>>>>> i will cvsup to -current today and try to reproduce it.
>>>>
>>>>
>>>> Ok, thanks.  This is a laptop, with an internal bluetooth adapter.  
>>>> I can reboot again and see if it does the same thing a second time.  
>>>> It could be a timing issue.
>>>
>>>
>>> i have updated my system to the most recent -current, and booted with 
>>> bluetooth usb dongle (3com) attached. no problem here. so i guess 
>>> there is something about your internal bluetooth adapter that makes 
>>> it bad. do you have, like, bluetooth on/off button on you laptop? 
>>> what laptop do you have?
>>
>>
>> I have a Sony VGN-A170P laptop, which does indeed include a switch.  I 
>> verified that the switch was on, and the blue light that indicates the 
>> bluetooth is running was lit.  The switch also controls the wireless 
>> card, which was working fine at the time.  I also tried switching it 
>> off, waiting until the blue light went away, and then switching it 
>> back on, with no change. Only running the bluetooth script helped.
> 
> 
> hmm... i'm surprised that switch did not help. on some laptops bluetooth 
> button/switch usually makes internal device to disconnect/connect. in 
> this case devd(8) will get detach/attach event which will trigger 
> 'bluetooth stop/start'. perhaps the switch only controls the light? or 
> may be the radio part of the device, i.e. device will always stay 
> attached, but the radio is powered off? did you try to turn switch off 
> and then bluetooth stop/start? does it give you the same timeout error?

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.

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.

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.

Eric



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------