RE: [Bluez-devel] Qualification Testing

[Max Krasnyansky <maxk@qualcomm.com>]

On Fri, 2003-05-09 at 17:26, Marcel Holtmann wrote:
> > 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.
Yep. We could do that but it simply makes no sense. I'm glad our IP 
stack doesn't kill random sockets when it receives corrupted IP packets,
just because it wants to indicate an error to an application and port
number happened to exist :-).

> 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.
The key words is 'should not' here. I've seen it happen because of USB problems
or UART H4 problems. Not the wrong length but missing fragments and
stuff.  

> 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.
Yeah, I think it's a bit to aggressive. BNEP connection, for example,
survives missing frags and pretty much anything else just fine. 

I'd rather keep the current code. Which I fixed btw to correctly drop
frame if first fragment is too long. It was a real bug which could cause
kernel oops in certain conditions.

Max