Hello together,
it took me some time since my last post to fix some annoying bugs
regarding my implementation of flow control features in BlueZ.
Currently I have only three test devices: a Siemens S55 mobile phone, a
Siemens S75 mobile phone and another Acer laptop with the Windows XP
Bluetooth stack. I hope to get another USB adaptor with a Toshiba stack
within the next few days which may even work with the Apple Bluetooth
stack at my iMac G4.
I will go over some investigations and implementation specific things
now.
First of all I extended l2cap.h to provide some global constants for
Flow Control. The reject command (struct l2cap_cmd_rej) offers some
information data for two of the three possible reject reasons so I
figured out it might be interesting to see why this rejection applied
and added the variable length array ?data? as well as the three possible
reject reasons as constants.
The different configuration states (conf_states) have been extended,
too. All the other stuff should already be covered by one of my earlier
mails.
Secondly I worked on l2cap.c for most of the time.
Most of these functions didn't change since my last post. I fixed some
bugs in l2cap_config_rsp() and this is one function that might be still
erroneous (I couldn't validate the L2CAP_CONF_UNKNOWN and the default
cases), but it works with those three devices mentioned above.
l2cap_build_conf_rsp() was one of the trouble makers, which was
basically my fault. I removed the l2cap_conf_output() function and put
its functionality into l2cap_build_conf_rsp().
The reject command is now really handled by its own function
l2cap_command_rej() and corresponding debug messages are printed.
One major issue about my implementation (and the long delay) is the ?new
technique? that applies now: Instead of sending a configuration request
first, we start with an information request and do not send a
configuration request before we got an answer in form of an information
response. We can trust this model as it is stated in the specification:
?Information requests are used to request implementation
specific information from a remote L2CAP entity. L2CAP
implementations _shall_ respond to a valid Information Request
with an Information Response [...]? (section 4.10)
This assumption is rather hard, but we must send an information request
before we try to make use of flow control options in configuration
requests ... So the downside is now, that if the remote peer is not able
to send a simple information response (which is really simple) we do not
come into the stage of any configuration process.
The main problem was now to send a configuration request right after
getting (and parsing) the information response. This was problematic
because I was not able to retrieve the working socket from within our
l2cap_information_rsp() function. This took me some weeks but finally I
seem to have this issue solved. To retrieve the socket I use the
function l2cap_get_chan_by_ident(&conn->chan_list, cmd->ident) which
didn't work with the Windows stack but with my Siemens mobile phones. I
had to set the socket's identificator to the next available connection's
identificator instead of starting from 0, and use this socket's ident in
our l2cap_connect_rsp() function as the command code for our information
request.
Okay, so that's basically it. The current patch makes the configuration
process to work with my three devices. Unfortunately none of those three
devices wants to ?flow control? with me :-( The nearest one is the
Siemens S75 which claims to support all the extended features, including
flow control (explicitly) but when I start a configuration request
trying to use flow control, it responds with ?unacceptable parameters?
and states it wants to use the Basic L2CAP Mode ... Damn. Windows and
the S55 do not offer the extended features in an information response. I
hope to have more luck with the Toshiba and the Apple stack.
This patch does only set the flow control parameters and does not do
anything regarding the flow control process itself. If somebody has
devices with newer Bluetooth stacks (Widcomm for example) he is welcomed
to compile this patch and just initiate a send and receive action to see
if it still works.
Martin