Hello together,
I'm currently trying to implement Flow Control on the L2CAP layer. I
already made some good progress but before things become too complicated
all of a sudden, I send my first lines of code to the list to give
everyone the opportuntiy to get an understanding of what I am doing.
So this ?patch? doesn't bring Flow Control into play, yet. But it
shouldn't break connections either.
I am only working on l2cap.h and l2cap.c
I added some basic constants to the header file as well as two macros
?SET_BIT? and ?HAS_BIT? which I need later to determine whether one of
the four possible options in a request has already been seen in this
request (imagine a request consisting of MTU + QoS + MTU). Further more
I added all the different parameter fields for our channel and socket
(struct l2cap_pinfo): o stands for outgoing, i for incoming and conf
reflects the parameters sent in a configuration request. Later on we
will have to deal with these conf parameters, compare them to reasonable
values and so on.
In l2cap.c I removed the function ?l2cap_get_conf_opt? because I think
we would run into trouble on Big Endian machines with this code. The
problem is that the basic MTU option consists of only one 16 bit wide
parameter so we can use __le16_to_cpu() for that, but in case of QoS or
my Flow Control, we have a bunch of unfortunately unaligned data fields.
Therefore I access those data fields directly (e.g. cap->conf_mode =
*(__u8*)(ptr + 2);).
The result flag corresponds to the result values of a configuration
request. We need more than just one, because to be standard compliant we
need to let the other side know, which options are unknown (in such a
case) or which parameters are unacceptable of which particular option.
So we have one basic result code for our responds (result[0]) -- this is
like the max function of {success; Failure/unacceptable parameters;
Failure/rejected; Failure/unknown options}. But we need to keep track of
our failures for a good responds.
The while loop extracts all options of a single request. We have some
basic error check mechanisms to avoid buffer overflow attacks by
corrupted requests.
Inside each option parser we use the HAS_BIT macro to make sure we will
only consider the first of possible multiple options of similar type
within one request. The hint is not processed yet.
This is only basic stuff to detect the different options and parse them
correctly. Now it becomes more complicated as we have to keep track of
all possible failures, parameters, result codes etc. I would write a
function l2cap_check_conf_opt(struct sock *sk, int option) to check the
individual parameters of a particular option. It gets harder to build
the configuration response individually.
That's it for now.
Martin
Status update to L2CAP Flow Control work.
In the function l2cap_parse_conf_req() I changed the result array to
have a size of 128 instead of 5, because we have to respond to each
request no matter which possible option is used. Currently the standard
defines 4 options (0x01 to 0x04) but in case the remote device sends a
request for option 0x42 we have to create an unknown option response
with the value of 0x42 as a parameter (that's why we need to keep track
of all incoming options). 128 reflects the maximum possible options
because the option type field is 8 bits long (256 in decimal) where the
most significant bit determines if the option is to be recognized as a
hint. The result value for each option is stored in result[OPTION] and
the overall result value of the request is stored in result[0] (nice
effect, that no option will ever have 0x00 as its option type value).
For a reasonable initialization we chose to use 255:
memset(result, 255, sizeof(result));
as this can never be used in a real request and 0 would have stated
SUCCESS for every single of the 127 possible options.
The default case for us is now an unknown option, therefore the use of
L2CAP_CONF_QOS and L2CAP_CONF_FLUSH_TO are currently commented out and
can be extended whenever somebody works on these parts.
Then I introduced a new function called ?l2cap_check_conf_opt()? for the
purpose of validity checks against all values that have been written to
the conf_* variables. This function will return a result code for this
one option that it has to check. MTU currently lacks completion but RFC
is already in progress. In case one value is not acceptable, we need to
generate a response with the values that would have been accepted if
sent in the original request. So in case we will end with
L2CAP_CONF_UNACCEPT we do not want to write or have written any value to
our outgoing channel configuration. That's why we will use the conf_*
variables as long as we do not know that the request is perfectly valid
(SUCCESS). So this function makes some basic checks even if I do not
know where I can retrieve acceptable values for the Retransmission
Timeout, the Monitor Timeout or the MPS/PDU size. That's definitely an
issue that needs to be solved. Perhaps somebody with more insight comes
with an idea?
Once the check function returned and we parsed each option of the
request, we need to differentiate between the major result code
result[0] and create corresponding response packets. For the case
everything is fine (L2CAP_CONF_SUCCESS) we write the conf_* values to
the corresponding o* variables.
So the next step is to rewrite the functions that create a response
packet as we would run into trouble again within the function
l2cap_add_conf_opt() on Big Endian machines. It becomes a bit more fuzzy
to keep track of different options that must be handled within one
request/response in a generic way that offers us enough power to create
the responses individualy.
That's it for today.
Martin
Hi Martin,
> after some months of coding, testing, deadlocks, debugging,
> book-readings, etc. I present my first working version of L2CAP flow
> control for the BlueZ stack. This is an early alpha release and may
> contain errors -- but hey, it is the first really working version here
> so be lenient toward me :-)
nice stuff and I decided to put out patch-2.6.17-mh6 with your patch
included to open it for a wider testing audience. I will boot up my
development system with this patch and see how it goes.
I haven't done any code review, but the obvious thing you missed is the
"select CRC16" in the Kconfig file.
The rumors have it that the Symbian OS 9.1 already supports L2CAP
retransmission and flow control (RFC) and this might be a good testing
system.
Keep up the good work.
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel