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
<[EMAIL PROTECTED]>
http://pages.videotron.com/sdoyon/
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
