Marcel,
Another round of qualification testing has begun. The results so far seem
much less painful this time. :)
So far there is one definite failure. There are a couple others which are
being debated. All of these have appeared because the tests have changed
slightly since (or weren't required) the last time we tested.
Test COS/CFD/BV-12 fails because the IUT does not send result=3 in an l2cap
config response upon reception of an unknown option. Apparently we didn't
have to do this test last time. And it's clear in the code why it fails:
l2cap.c: /* FIXME: Reject unknown option */
I noticed in the spec that the response must contain the offending options:
"On an unknown option failure (Result=0x0003), the option types not
understood
by the recipient of the Request must be included in the Response.
Note that hints (defined in Section 6 on page 297), those options in the
Request that are skipped if not understood, must not be included in the
Response and must not be the sole cause for rejecting the Request."
I've been staring at the code pondering how to fix this cleanly. I've
attached an attempt at fixing it. The fix is not quite complete because I
believe it has a buffer overflow vulnerability. It is not fully tested
either. But I figured it was best to run it by you before going too far
because more than likely you'll want to change something. ;)
BTW - We're using 2.4.21-mh10.
-Daryl.
Hi Marcel,
> > An hcidump is attached. Though I don't think you'll learn
> much from it.
>
> actually I learned that hcidump can't deal with the hint bit
> and that it
> don't understand the QoS option. Both is fixed in CVS and
> looks now like
> this:
Good stuff.
> > L2CAP(s): Config req: dcid 0x0040 flags 0x0001 clen 4
> [MTU 672]
> < L2CAP(s): Config rsp: scid 0x0040 flags 0x0001 result 0 clen 0
> > L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 28
> [FlushTO 65535] [QoS 0x01 (Best effort)]
> < L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0
>
> We send two empty resposonses, but from my current
> understanding this is
> fine. All of the options have set the hint bit (indicated by
> []). Maybe
> I am missing something, but the specification says:
>
> option is a hint; if the option is not recognized then
> skip the option and continue processing
>
> So our responses are valid, because we answer both requests.
As far as I can tell it's fine too. I'm waiting for more information from
the test house. Will let you know what I find out.
> For you it is the best to go with the hack, because I don't
> think that I
> will backport such a change to the 2.4 kernel series.
Ok.
> However do you also have a hcidump from that test for me?
Attached.
-Daryl.
Hi Daryl,
> > do you have a hcidump or another trace for me?
>
> An hcidump is attached. Though I don't think you'll learn much from it.
actually I learned that hcidump can't deal with the hint bit and that it
don't understand the QoS option. Both is fixed in CVS and looks now like
this:
> L2CAP(s): Config req: dcid 0x0040 flags 0x0001 clen 4
[MTU 672]
< L2CAP(s): Config rsp: scid 0x0040 flags 0x0001 result 0 clen 0
> L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 28
[FlushTO 65535] [QoS 0x01 (Best effort)]
< L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0
We send two empty resposonses, but from my current understanding this is
fine. All of the options have set the hint bit (indicated by []). Maybe
I am missing something, but the specification says:
option is a hint; if the option is not recognized then
skip the option and continue processing
So our responses are valid, because we answer both requests.
> > Not at the moment and maybe not so fast. This needs a little bit more
> > work.
>
> Agreed - doing it right is probably not something that's going to happen
> quickly.
>
> We will probably have to go with the hack (probably with some overflow
> checking added) for the sake of expediency, unless one of us comes up with a
> better solution shortly.
For you it is the best to go with the hack, because I don't think that I
will backport such a change to the 2.4 kernel series.
However do you also have a hcidump from that test for me?
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> do you have a hcidump or another trace for me?
An hcidump is attached. Though I don't think you'll learn much from it.
> Not at the moment and maybe not so fast. This needs a little bit more
> work.
Agreed - doing it right is probably not something that's going to happen
quickly.
We will probably have to go with the hack (probably with some overflow
checking added) for the sake of expediency, unless one of us comes up with a
better solution shortly.
-Daryl.
Hi Daryl,
> I got word back on one of the unmentioned bugs and it appears to be a bug in
> the tester. So now there is only one outstanding item. I don't see why this
> is a failure:
>
> CFD/BV-01:
> Tester sends an l2cap config request in two pieces (using continuation flag)
> to the IUT. The tester expects to see one of two alternatives:
>
> 1. The IUT includes in the response to each request the requested options.
> 2. The IUT first sends an empty response and in its second response it sends
> all the requested options.
>
> We currently just send two empty responses. I think an empty response would
> be acceptable if all the requested options were in one request, so I don't
> see why this fails.
do you have a hcidump or another trace for me?
> > to be honest, I am already aware of this problem. I ran into it when I
> > first started to look at the support for L2CAP retransmission and flow
> > control. Our current way of handling the configuration must be changed
> > to deal better with L2CAP 1.2 devices and their features. It
> > is not that
> > easy to change and my time was too limited for it. However I
> > am open for
> > any ideas and I am sorry to say that, but your patch looks
> > like a dirty
> > hack.
>
> Ah yes, the expected response. ;) But you are right, it is a bit of a hack.
> As far as I can see it's either going to be a hack or a rewrite of that
> config request handling code. Do you have a better solution?
Not at the moment and maybe not so fast. This needs a little bit more
work.
> Is QoS one of the things you're thinking of?
Actually no. However this might come for free.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> lets go ahead and fix them all.
I got word back on one of the unmentioned bugs and it appears to be a =
bug in
the tester. So now there is only one outstanding item. I don't see why =
this
is a failure:
CFD/BV-01:
Tester sends an l2cap config request in two pieces (using continuation =
flag)
to the IUT. The tester expects to see one of two alternatives:
1. The IUT includes in the response to each request the requested =
options.
2. The IUT first sends an empty response and in its second response it =
sends
all the requested options.
We currently just send two empty responses. I think an empty response =
would
be acceptable if all the requested options were in one request, so I =
don't
see why this fails.
> to be honest, I am already aware of this problem. I ran into it when I
> first started to look at the support for L2CAP retransmission and flow
> control. Our current way of handling the configuration must be changed
> to deal better with L2CAP 1.2 devices and their features. It=20
> is not that
> easy to change and my time was too limited for it. However I=20
> am open for
> any ideas and I am sorry to say that, but your patch looks=20
> like a dirty
> hack.
Ah yes, the expected response. ;) But you are right, it is a bit of a =
hack.
As far as I can see it's either going to be a hack or a rewrite of that
config request handling code. Do you have a better solution?
Is QoS one of the things you're thinking of?
-Daryl.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daryl,
> Another round of qualification testing has begun. The results so far seem
> much less painful this time. :)
>
> So far there is one definite failure. There are a couple others which are
> being debated. All of these have appeared because the tests have changed
> slightly since (or weren't required) the last time we tested.
lets go ahead and fix them all.
> Test COS/CFD/BV-12 fails because the IUT does not send result=3 in an l2cap
> config response upon reception of an unknown option. Apparently we didn't
> have to do this test last time. And it's clear in the code why it fails:
> l2cap.c: /* FIXME: Reject unknown option */
>
> I noticed in the spec that the response must contain the offending options:
>
> "On an unknown option failure (Result=0x0003), the option types not
> understood
> by the recipient of the Request must be included in the Response.
> Note that hints (defined in Section 6 on page 297), those options in the
> Request that are skipped if not understood, must not be included in the
> Response and must not be the sole cause for rejecting the Request."
>
> I've been staring at the code pondering how to fix this cleanly. I've
> attached an attempt at fixing it. The fix is not quite complete because I
> believe it has a buffer overflow vulnerability. It is not fully tested
> either. But I figured it was best to run it by you before going too far
> because more than likely you'll want to change something. ;)
to be honest, I am already aware of this problem. I ran into it when I
first started to look at the support for L2CAP retransmission and flow
control. Our current way of handling the configuration must be changed
to deal better with L2CAP 1.2 devices and their features. It is not that
easy to change and my time was too limited for it. However I am open for
any ideas and I am sorry to say that, but your patch looks like a dirty
hack.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel