[BRLTTY] Bluetooth

[Stéphane Doyon]

On Fri, 18 Jan 2008, Dave Mielke wrote:

> [quoted lines by Stéphane Doyon on 2008/01/18 at 10:22 -0500]
>
>> I would have the PIN as part of the configuration. Unless I'm missing an
>> important use case, I don't see any point in trying to prompt for it,
>> since the user is most likely trying to get his display working and
>> probably has no way to read the prompt.
>
> The issue to me is whether or not we should be adding complexity in order to
> hide the PIN.

Well of course PINs of 1234 are laughable... so having a utility to change 
that would be the first order of business for someone who cares.

But yes I think we should make some effort to keep the PIN secret, just 
because it's the right thing to do.

> Using the bluez-supplied passkey-agent, however, already puts the
> PIN on full display for clever ps users and /proc analyzers.

The Fedora version does, not Ubuntu's. But these passkey-agent utilities 
really look like an after thought, I would guess their interfaces are 
likely to change. Plus running them adds yet another process sitting there 
for no reason. Plus they are sometimes released and they exit for reasons 
not entirely clear to me:
-In Fedora, if you're not using --default but rather you specify an 
address, once it's provided the PIN it exits. Presumably because the link 
key gets cached and so it expects it won't be asked again.
-On restarting the bluetooth stack service, I believe the agents exit too.

>> Well... as I said, brltty just kept going. That would seem to imply that
>> there were no read errors. Is there something specific I should try?
>
> Could you please try logging read errors right in readBaumPacket(), or at an
> even lower level, just to see if an error like ENOTCONN is being lost somewhere
> in the higher levels?

The code looks OK to me.

brl_readCommand() calls protocol->updateKeys(). On failure, it checks 
errno, if EAGAIN returns EOF, else BRL_CMD_RESTARTBRL. So any error causes 
reinit.

updateBaumKeys() calls getBaumPacket() calls readBaumPacket() calls 
readByte() calls readBluetoothBytes() calls readChunk(). In some 
conditions errno is set explicitely to EAGAIN, but other than that it 
seems straightforward.

readChunk() will already LogError() any error except errno == EINTR or 
EAGAIN. And only the write errors were in my log.

>> Instead of adding support for pending commands, perhaps we could define an
>> error case for brl_writeWindow() that would cause a reset,
>
> It's always sort of bothered me that it doesn't do this already so maybe this
> is a good excuse to finally do it.

There are actually two alternating write errors: one from writeData() or 
something underneath it, plus the LogError("Baum Bluetooth write");. The 
alternation prevents syslog from collapsing the messages, so your disk 
starts crunching...

We should perhaps ignore only specific recognized errors, and reset on 
anything else (and not just ENOTCONN), like we do for reads.

-- 
Stéphane Doyon
<s.doyon at videotron.ca>
http://pages.videotron.com/sdoyon/