Ok, the most obvious things to work on next would probably be the bugs and feature requests from Sourceforge. One thing which is however not there is to increase stability for Blunt. This covers two things: proper shutdown of the driver in error or disconnect cases to avoid the dreaded "communications port busy" error. And then safeguards to prevent crashes when talking to devices which I cannot test with. This concerns mostly Sony Ericsson devices which is actually a bit surprising. Ericsson has always been a good Bluetooth implementor, so I wonder if they interpret the standard a bit differently than I do. One thing they certainly can do is to be more agressive in their implementation since they know what should work.
I now have a PPP daemon running on my Cube, accepting incoming connections via Bluetooth. Works like a charm for mail and web surfing with my Newton, using Blunt. It's almost like WiFi, only the power consumption is lower. The setup is quite simple: Add a new serial port on the Mac via the Bluetooth Serial Utility, add a Bluetooth internet setup with the correct name server and other parameters, enable IP forwarding with ipfw and natd and start pppd on the new serial port.
These are the commands I used to enable IP forwarding (en1 is my outgoing interface):
/usr/sbin/natd -dynamic -interface en1
/sbin/ipfw -f flush
/sbin/ipfw add divert natd all from any to any via en1
/sbin/ipfw add pass all from any to any
/sbin/route add default 10.0.1.1
I'm behind a firewall, so there are no other fancy filtering rules. The firewall is at 10.0.1.1, so that should be the default route to the outside world. The pppd command line looks like this (Bluetooth-Serial is the name I gave to my serial port):
/usr/sbin/pppd /dev/tty.Bluetooth-Serial 230400 noauth local passive proxyarp asyncmap 0 silent persist :192.168.1.110
When discovering services from the Newton, there are now two serial ports, and one of them is the new serial port. The other is the PDA sync port. Unfortunately, the exact port numbers seem to change, but it's easy to find out using trial and error.
The latest changes to Blunt made the L2CAP connection establishment phase a bit more stable. It's not really clean, but works: Instead of using a timeout and retransmit in case the connection establishment stalls, I just send the packets twice, no matter what. They're marked using the same packet identifier so the peer can throw the second one away. Likewise, I ignore any duplicate response. A more difficult issue is connection closedown. It seems that proper disconnect at least in the RFCOMM layer is needed. Otherwise, peer devices don't finish an OBEX transfer (or discard the transfer such as MacOS X). It's a bit trickier to get into closedown since I'm not sure how much of the comm tool is still usable at that point. First attempts just caused a reboot.
Still open is also the SDP and some nasty crashes using the P800. I'm not sure why the P800 causes the crashes, but I'll probably have to add some safeguards. The SDP is likely easier to fix. Some improvements for Windows support are also needed in that area.
Unrelated to that, adding gzip support to Courier was certainly a success. 8k/sec over GPRS are quite nice. Still, NHttpLib could do well with a rewrite...