misc/102523: [patch] Virtual serial port server code for bluetooth/rfcomm_sppd

[Dave Eckhardt]

>Number:         102523
>Category:       misc
>Synopsis:       [patch] Virtual serial port server code for bluetooth/rfcomm_sppd
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 25 23:00:42 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Dave Eckhardt
>Release:        FreeBSD 6.1-RELEASE i386
>Organization:
Carnegie Mellon University
>Environment:
FreeBSD memex 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May  7 04:32:43 UTC 2006    root at opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
While there is already code which enables synchronization
of a PalmOS device over Bluetooth using DUN (dial-up
networking), that seems unnecessarily heavyweight and
harder to secure than the other approach, synchronizing
over an RFCOMM "virtual serial port".

Enclosed please find a patch to rfcomm_sppd which adds
"server mode" code.  I have gone back and forth on whether
server mode should contain a loop around the existing
single-transaction code, but figured I'd send in what I
have now and let the maintainer make the policy decision.

I don't have an obvious way to test the (original) client-side
RFCOMM behavior, so it would probably be a good idea to make
sure I haven't broken that, though I tried not to.  Also, feel
free to let me know if this approach seems wrong in some way.
>How-To-Repeat:
See directions at http://howto.pilot-link.org/bluesync/ and
ask yourself if it wouldn't be better to skip all the dialup
networking setup on both the Palm device and the host--and
also close that worrisome "-p net:any" door.
>Fix:
http://www.cs.cmu.edu/~davide/howto/hotsync_bluetooth_serial.html  
>Release-Note:
>Audit-Trail:
>Unformatted: