I have been testing the host-to-host bluetooth system and it might be correct to have the following /etc/bluetooth/pin for external devices:
But in the case of interconnecting two computers through bluetooth, this file *MUST* be like the original version, that is:
I have tested it and you can check it here: http://forums.gentoo.org/viewtopic.php?t=194183
I hope you can bring a solution that satisfies both parts :)
-- Just in case, can someone test that indeed the provided /etc/bluetooth/pin works correctly for non-host bluetooth devices like PDAs, mobile phones and so on?
Steps to Reproduce:
what do you mean by "two interconnecting computers"? are you using ppp to connect through them?
I made no connection yet. The rfcomm part comes later... first I need pin synchronization. With interconnecting two computers I mean:
HOST1--BTadapter ))))))) BTadapter--HOST2
HOST1--BTadapter ((((((( BTadapter--HOST2
Two bluetooth adapters, one on each computer. With that, you can use hcitools and scan and detect them, but nothing else. In order to do a simple l2ping, you need to have paired the 2 adapters with the pin which is read from file /etc/bluetooth/pin.
ok, i think i know what you mean. let me see what we can do with it.
Alright, forget it! I've found a workaround.
This workaround also helps on bug 56157.
alright, there is a nice problem here:
# PIN helper
Alright, if we use the default pin helper, /usr/bin/bluepin, it doesn't work. If we use /etc/bluetooth/pin, it does work for out-going connections. Nice! But unfortunately not enough.
The sdpd daemon, still reads /etc/bluetooth/pin and needs the raw pin number in there.
So my suggestion to solve this is the following:
That is, to let sdpd have it's pin file there, while still allowing hcid.conf use the text mode pin helper.
Sorry for writting so many times 'alright'
It would perhaps be better to have the following pin-helper:
echo -n "PIN:"
sdpd is used for incoming connections and needs a /etc/bluetooth/pin like:
hcid is used for outgoing connections and, if using the /etc/bluetooth/pin helper (which I renamed to /etc/bluetooth/pin-helper), should be the bash-script one.
I have tested this right now so I can confirm this behaviour... it is also logical, sdpd is the service discovery protocol daemon, so it is expected that it recieves incomming connections.
reassigning to myself before i forget about this
I know yiu are with the 2004.2 release so... could I know when you could check this? The HOWTO is still waiting... :P
I'm interested in having this checked and fixed asap. Time estimation please... the fix is pretty simple.
sorry for the delay. i was waiting for the other changes associated with -r1 as well. it is now changed in 2.10-r1.