Hello Edouard, Just a quick reply, more tomorrow.
> I just dropped the test. See if it makes CRC problems appear again. Just dropping the test for pos > 1536 shouldn't change anything afaict. Remember I inserted the else after that check. Also I always saw both "Idiotic frame length"s and CRC errors at the same time (before I inserted the else). That would suggest that dropping the first test shouldn't make a difference. > The lbuf usage is still needed, it's the reading buffer. unused_cell is > just a pointer that keeps tracks of pppoa3 progress into the read buffer if > there are still ATM cells left in. Then that should be changed back. The current patch doesn't seem to use lbuf at all. > I have just a doubt about the case where: > - num_bytes_read < 0 > > It seems to me, that this case should be checked and invalidate the > unused_cell data. Isn't unused_cells set to NULL by aal5_frame_from_atm_cell() after the whole frame has been processed? I did not check that. Again, I only submitted this patch because it addresses the CRC issue, I am not stating that it is entirely correct yet. This probably needs a little discussion (please refer to Ok Overbeek as well) and shouldn't be pushed to beta3 in 24 hours. > Can you check if a test like this one hurst the CRC solving: > if (num_bytes_read<0) unused_cells = NULL; > after the pos = 0; statement. I'll look at this tomorrow. Plus see above. By the way, num_bytes_read is the absolute number of bytes read so it will never be less than 0. And again, I assume unused_cells is set to NULL by aal5_frame_from_atm_cell(). Bye, Leonard. -- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se d�sinscrire : mailto:[EMAIL PROTECTED]
