RE: [Bluez-devel] Qualification Testing

[Marcel Holtmann <marcel@rvs.uni-bielefeld.de>]

Hi Daryl,

> > I was going to just drop the frame and log an error. The 
> > thing is, if the packet header is corrupted (i.e. wrong 
> > length, etc) we can't really trust its content. I mean if 
> > length is wrong how do we know that CID is right. It means 
> > that we don't really know which channel should be closed 
> > (i.e. which app should be notified).
> 
> Here's Cetecom's response to your comment:
> 
> "Good point ! I agree, in a messed up remote L2CAP stack, CID could be wrong
> as well if length is wrong. But I think it is a good approach to check
> first, if that CID exists and if yes, notify the app about that channel."
> 
> So how about we do this:  As above, if it exists then we close it. If not,
> we log an error.

the proposal from Cetecom makes no sense.

If you have one channel with correct data and you get a wrong packet
which was for another channel, but the CID is corrupt and show now the
value of the correct channel. You will infect a correct working channel
with a false packet.

The main problem is that wrong packets should not arrive at the L2CAP
layer. If they do and we decect them (like a length mismatch), we have
to close down all channels and remove the infected ACL link.

Max, what do you think? This way is a little bit radical, but I think it
is an acceptable way of handling these errors. And with this method we
will pass this test.

Regards

Marcel




-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel