sprintpcs treo 650 & blutooth & dialup networking

[Bakul Shah]

> that looks fine. one thing, you probably want to apply the following path
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/bluetooth/socket/ng_bt
> socket.c.diff?r1=1.7.2.1&r2=1.7.2.2&f=u

Thanks!

> aha! good old "reboot" fixes everything :)

The same thing happened with my -current laptop -- rebooting
the treo fixed it.  This time I knew what to do so I didn't
experiment around and the laptop didn't freeze either!

> > So I guess I had to reboot treo....  But it sure would be
> > nice to know what exactly went wrong....  Ah well.
> 
> if you have hcidump's from non-working sessions please send them to me.

I don't have them anymore but will try to recreate this condition.

Here are the steps needed to connect to the net via a
sprintpcs treo 650:

1. Load the kernel module for bluetooth.
	kldload ng_ubt
2. plug in the usb bt dongle.
3. You will need the bluetooth rc file.
	cp usr/share/examples/netgraph/bluetooth/rc.bluetooth  /etc/rc.bluetooth
	chmod +x /etc/rc.bluetooth
4. Now start it up.
	/etc/rc.bluetooth start ubt0
5. make sure your treo has the 1.12-SPCS firmware upgrade
   (you can see this on the phone info screen).
6. on the treo enable bluetooth & enable dialup networking
7. Now you need the treo's device addr.
	hccontrol -n ubt0hci inquiry
   It will spit out BD_ADDR for nearby devices.  If you have
   multiple devices nearby, for each <addr> do
       hccontrol -n ubt0hci remote_name_request <addr>
   and match the returned name with the device name you gave
   the treo (as seen on the bluetooth screen).  Enter this
   addr in /etc/bluetooth/hosts and give it a name such as
   mytreo
8. add a device entry for the device to /etc/bluetooth/hcsecd.conf
	device {
	    bdaddr  <addr>;
	    name    "mytreo";
	    key     nokey;
	    pin     <pin>;
	}
    <addr> is your treo's addr in aa:bb:cc:dd:ee:ff notation.
    <pin> is a string for example "1234".
10. start hcsecd
11. on the treo enable pairing.  On the bluetooth screen
    click on [setup devices], then on [trusted devices],
    then [add devices].  This will make treo search
    for nearby devices.  When you see your computer's name
    in its list, select it and when it asks for the pin, type
    in the number you out in hcsecd.conf.  If successful, the
    computer name will show up in its trusted device list.
12. Add an rfcomm-dialup section to /etc/ppp/ppp.conf:
	rfcomm-dialup:
	 # This is IMPORTANT option
	 enable force-scripts

	 # You might want to change these
	 set authname
	 set authkey
	 set phone "#777"

	 # You might want to adjust dial string as well
	 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
		   \"\" AT OK-AT-OK ATE1Q0 OK \\dATD\\T TIMEOUT 40 CONNECT"
	 set login
	 set timeout 60
	 enable dns
	 resolv rewrite

	 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
	 add default HISADDR

13. Soft Reset the treo.
14. Start the ppp connection
	rfcomm_pppd -a mytreo -c -C 1 -d -l rfcomm-dialup
15. ifconfig tun0 should show an ip address if everything worked.

Debugging hints:
- read the bluetooth section in the handbook
- hccontrol may fail to connect.  if so retry!
- /var/log/ppp.log can tell you what went wrong.  You may
  have to turn on all logging and then selectively turn
  things off in /etc/ppp/ppp.conf
- make sure your treo is within 10 ft while you are debugging.

Meta-comment:
We sorely need a unified way of connecting to the net and
dealing with computer mobility.  An an example, my laptop
connects via ethernet, wifi, cell, dialup.  I do this at home
(kitchen, office, backyard), at work and while travelling.  I
prefer to never reboot so manually I do something like
	/etc/rc.d/netif stop <interface1>
        /etc/rc.d/netif start <interface2>
but rfcomm_pppd doesn't fit in this scheme as bunch of
steps are not automated.

Ideally the machine finds the most preferred interface and
connects to the net via it.  When it goes away, it will try
the next preferred one.  If a more preferred interface shows
up, the net connection is seamlessly switched to it.  If I
switch from home to work environment, my home connections
remain valid through use of a VPN.  If I switch from work to
home my work connections remail valid through a VPN. Etc.
I suspend the machine in one environment and resume in another,
it still works as one would expect.

What is needed is a `netplumber' that will always find a path
to the net regardless of where your machine is physically
located and tries to keep all open connections alive.