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
|