Here I have another question based on what I have got in my sniffer captures.. I see the retransmissions of the packet that got checksum error and I see the checksum being the same again. Now tcp_output function would force a recalculation of the checksum. If the data was corrupted during the transmission or after that, then its quite unlikely that the checksum calculated during the retransmission would just be the same - the new checksum calculated should not match the old one (well almost). The fact that the checksum calculated appears to be the same, keeps my doubts on the checksum calculator alive to a certain degree. Also looking at the data part, any signs of corruption is not quite evident.
Am I missing something here? - Sourath On 1/24/08, Sourath Roy <[EMAIL PROTECTED]> wrote: > > I too didn't find too much change to the checksum generator between > versions, so thought of asking. > > It could be some kind of data corruption too. Specially as it is > intermittent in nature. > I would further investigate into this. > > - Sourath > > On 1/24/08, Jonathan Larmour <[EMAIL PROTECTED]> wrote: > > > > Sourath Roy wrote: > > > Hello! > > > I am porting some network applications from Linux to lwIP stack. So > > far > > > the progress has been good, but while some stress tests I often see > > > checksum errors being reported by the network sniffer. > > > > I presume this occurs only with data sent from lwIP to linux. > > > > > The ethernet chip > > > does not have any checksum generation support, and so we rely on the > > > software algorithms available inside lwIP library. Have you guys seen > > > such a problem before? Endianness on the system is little-endian, but > > I > > > believe the algorithm already takes care of that. > > > > The checksum generation has not changed and has been working fine for a > > long time, including under stress. More likely it is not the checksum > > that > > is the problem, but rather the data being checksummed. For example, if > > you > > are changing data after it was sent, but did not tell the stack to copy > > the > > data. Or of course something in the ethernet driver implementation. > > > > I would suggest you check the payload for corruption, and if there is > > corruption, what pattern does the corruption have e.g. random, only > > after a > > certain point in the packet, etc. > > > > Jifl > > -- > > eCosCentric Limited http://www.eCosCentric.com/ The eCos > > experts > > Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 > > 245571 > > Registered in England and Wales: Reg No 4422071. > > ------["Si fractum non sit, noli id reficere"]------ > > Opinions==mine > > > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
