Leonard den Ottolander ([EMAIL PROTECTED]) wrote: > Is there a way to check the frame length against the negotiated length, or > do you just drop this check?
No, pppoa daemons are just sort of bridging pipe. It's just a dumb piece of software: read data on one side, copy it to the other side. I just dropped the test. See if it makes CRC problems appear again. > > - some cleanup concerning the effective payload used > > The way aal5_frame_from_atm_cells() is called probably needs checking. I > am not sure if the use of unused_cells instead of lbuf is correct. Might > just work for small frame sizes. Also it seems that currently lbuf is not > used at all so if the use of unused_cells instead of lbuf is correct you > might just drop all references to lbuf. 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. 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. > Once again, this patch was not written by me, I just did some cleanup > and separation of functionality. I did not verify all the details of > its inner working, but can verify that it fixes the CRC error problem > I saw when using the KQD6P2.eni firmware with the unpatched > driver. But it definitely needs another check ;) . 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. -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
