Marcel,

I think there is a race condition in the RFCOMM Socket -> TTY adaptation.  
Basically whenever a client device connects and starts sending data right 
away, the serial port will not receive it.

To see what I mean:

run 'rfcomm -r listen 0 15' on a server.

and run a simple test app that sends data right after connecting (one 
attached).

Once connection has been established, run 'cat /dev/rfcomm0' 

Using my Suse 10.2 desktop with kernel 2.6.18.8 and Neo with kernel 2.6.22.5 
(Nov 26 snapshot), about 95% of the time the initial data sent never shows up 
on the serial port.  If I reverse the roles, the desktop usually gets the 
initial chunk of data.  This inconsistency makes it hard to implement 
something like the DUN or Handsfree services where clients very frequently 
send data right away.

Looking at the kernel code it seems that the data is copied into the socket 
buf or into the serial buf from the rfcomm_recv_data.  It also seems that 
rfcomm_dev_add never copies what is in the socket buffer to what is in the 
serial buffer.  It would seem that rfomm_dev_add should also copy any pending 
data from a socket read buffer to the serial port read buffer whenever doing 
the conversion.  Or is there something else going on here?

-Denis