Hello together,

I worked on some Flow Control mechanisms on the L2CAP layer for the past
few weeks/months and want to give everybody who is interested in this
work the opportunity to review the code, add comments or get an
overview.
The current status is that I can obtain all necessary information from
incoming information requests and responses as well as configuration
requests and responses. A valid configuration request is parsed and a
reasonable configuration response will be created.
The next step will include to create information requests by ourself and
(especially from the corresponding information responses) to create
configuration requests with all flow control options set.
After that real Flow Control needs to take place and all the logic
behind it will be implemented according to the procedures specified in
Section 8 of the current specification.

Some notes on the current patch:
In my last patch I already created the new function »l2cap_get_conf_opt«
which is only called from within l2cap_parse_conf_opt. This function
checks a parsed option for validity and returns the corresponding result
code (Success or Unacceptable Parameters). This will be the return code
for this specific option, say result[L2CAP_CONF_MTU] for the MTU or
equivalent. Refer to my mail from Feb 13 for more information about the
result codes.
The function »l2cap_parse_conf_opt« didn't change in logic but became
smaller as parts of the response building process is moved to the
function »l2cap_build_conf_rsp« which makes the data flow appear more
logically (the parse function should really only parse and not build
anything). Therefore the build_conf_rsp function is now much bigger as
we have to very specific about which option is to be included in our
response (see specification). Whenever we build a response option that
has to be put into a response packet, we call »l2cap_add_conf_opt« with
the appropriate data.
The function »l2cap_build_conf_req« is not done yet but should already
work for an MTU option as expected.
At the end I worked on the two functions »l2cap_information_req« and
»l2cap_information_rsp«. Both should be able to handle Flow Control
options, but couldn't be tested yet as I lack devices that make use of
this functionality :-/ The latter function sets the flow control bits in
the extended features mask (see section 4.12 in the spec). The next step
would be to use this information in the configuration request building
process (first send an information request, read the response and create
an appropriate configuration request).

That's it for now.

Martin