|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
|
|
Checksum Incorrect caused by ConcatenationHi All,
I use the last CVS Head LWIP on LPC2468 with FreeRTOS. My embedded system communicates by IP with a PC. When the PC IP interfaces restart, I look for a checksum incorrect packet on Wireshark. This error seems to be a concatenate error. 172.17.2.173:my embedded system with LWIP; 172.17.2.172 : PC 111 7.819682 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=55493 Ack=0 Win=5840 Len=209 112 7.825543 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=55702 Win=65535 Len=0 113 7.993714 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=55702 Ack=0 Win=5840 Len=531 114 7.997536 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=56233 Win=65535 Len=0 115 8.211446 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [ACK] Seq=56233 Ack=0 Win=5840 Len=1460 116 8.301504 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=57693 Win=65535 Len=0 117 8.326219 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=57693 Ack=0 Win=5840 Len=197 118 8.333736 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=57890 Win=65535 Len=0 119 8.422016 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=57890 Ack=0 Win=5840 Len=1126 120 8.429543 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=59016 Win=65535 Len=0 121 8.632683 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=59016 Ack=0 Win=5840 Len=934 122 8.634010 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=59950 Win=65535 Len=0 123 8.869443 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [ACK] Seq=59950 Ack=0 Win=5840 Len=1460 <- Restart of the PC IP interfaces 125 8.871878 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [ACK] Seq=61410 Ack=0 Win=5840 Len=1460 129 8.874047 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 130 9.307578 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=62870 Ack=0 Win=5840 [TCP CHECKSUM INCORRECT] Len=740 <- this packet is a concatenation of the same packets than 111 and 113 131 9.309162 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [ACK] Seq=63610 Ack=0 Win=5840 Len=1460 132 9.309293 172.17.2.172 172.17.2.173 TCP [TCP Dup ACK 129#1] 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 142 9.789090 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=65070 Ack=0 Win=5840 [TCP CHECKSUM INCORRECT] Len=1323 <- this packet is a concatenation of the same packets than 117 and 119ss 153 10.003902 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [PSH, ACK] Seq=66393 Ack=0 Win=5840 Len=934 156 10.019539 172.17.2.172 172.17.2.173 TCP [TCP Dup ACK 129#2] 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 157 10.905015 172.17.2.173 172.17.2.172 TCP [TCP Retransmission] 5678 > 48955 [PSH, ACK] Seq=62870 Ack=0 Win=5840 [TCP CHECKSUM INCORRECT] Len=740 158 13.209979 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [PSH, ACK] Seq=0 Ack=62870 Win=65535 Len=1 159 13.210040 172.17.2.172 172.17.2.173 TCP 48955 > 5678 [FIN, ACK] Seq=1 Ack=62870 Win=65535 Len=0 160 13.210332 172.17.2.172 172.17.2.173 TCP 48956 > 5678 [SYN] Seq=0 Len=0 MSS=1460 TSV=1711037 TSER=0 WS=6 161 13.241498 172.17.2.173 172.17.2.172 TCP 5678 > 48955 [ACK] Seq=67327 Ack=2 Win=5838 Len=0 162 13.279770 172.17.2.173 172.17.2.172 TCP 5678 > 48956 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 163 13.279930 172.17.2.172 172.17.2.173 TCP 48956 > 5678 [ACK] Seq=1 Ack=1 Win=5840 Len=0 164 14.205872 172.17.2.173 172.17.2.172 TCP [TCP Retransmission] 5678 > 48955 [PSH, ACK] Seq=62870 Ack=2 Win=5838 [TCP CHECKSUM INCORRECT] Len=740 In the pbuf_cat function “p->next” must not be equal to “t”, but must be equal to “NULL”. And we must write “p->len+=t->len;”. And next after the call of “pbuf_cat(useg->p, queue->p);” in “tcp_enqueue fuction” tcp_out.c , we have Add two line: pbuf_cat(useg->p, queue->p); useg->len += queue->len; useg->next = queue->next; LWIP_DEBUGF(TCP_OUTPUT_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE, ("tcp_enqueue: chaining segments, new len %"U16_F"\n", useg->len)); if (seg == queue) { seg = useg; seglen = useg->len; queuelen--; //decrementation of the SND_QUEUELEN due to concatenation } memp_free(MEMP_TCP_SEG, queue); pbuf_free(queue->p); /dereference a pbuf chain due to concatenation Thanks to this modification I haven’t a TCP CHECKSUM INCORRECT in wireshark and the communication works fine. Can you tell me if this modification are the best and if they will not be cause of a problem. Thanks In advance, Hervé GARAT _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
Re: Checksum Incorrect caused by ConcatenationOn Mon, 2009-11-16 at 16:01 +0100, herve garat wrote:
> > In the pbuf_cat function “p->next” must not be equal to “t”, but must > be > equal to “NULL”. And we must write “p->len+=t->len;”. No, that's wrong. p->len refers to the length of each individual pbuf. We've added another pbuf to the chain, but not changed the length of each pbuf. Because the chain is longer, we increment the length of p->tot_len, but not the length of p->len. > And next after the > call of “pbuf_cat(useg->p, queue->p);” in “tcp_enqueue fuction” > tcp_out.c , > we have Add two line: > > pbuf_cat(useg->p, queue->p); > > useg->len += queue->len; > > useg->next = queue->next; > > LWIP_DEBUGF(TCP_OUTPUT_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE, > ("tcp_enqueue: chaining segments, new len %"U16_F"\n", useg->len)); > > if (seg == queue) > > { > > seg = useg; > > seglen = useg->len; > > queuelen--; //decrementation of the SND_QUEUELEN > due to > concatenation > > } Not sure about that: the header file says that snd_queuelen is a length in TCP segs, but we're using it in the code as meaning a length in pbufs. As we've not changed the number of pbufs by chaining one on to the other, we shouldn't change the queuelen. > memp_free(MEMP_TCP_SEG, queue); > > pbuf_free(queue->p); /dereference a pbuf chain due to > concatenation That would be wrong: the pbuf is still in use, it has been chained into the others. If you free it something else could try and use the same buffer and cause an error. It is odd that these changes have fixed a problem for you, as I would think they would make it worse. Kieran _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
|
|
|
Re: Checksum Incorrect caused by ConcatenationDid you read Kieran's response to your mail yesterday? I also doubt the changes are correct and find it quite strange that it makes things better, not worse. Simon "Hervé GARAT : Audemat" <Garat@...> wrote: > Hi All, > > I use the last CVS Head LWIP on LPC2468 with FreeRTOS. My embedded system > communicates by IP with a PC. When the PC IP interfaces restart, I look for > a checksum incorrect packet on Wireshark. > > This error seems to be a concatenate error. 172.17.2.173:my embedded > system with LWIP; 172.17.2.172 : PC > > 111 7.819682 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=55493 Ack=0 Win=5840 Len=209 > 112 7.825543 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=55702 Win=65535 Len=0 > 113 7.993714 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=55702 Ack=0 Win=5840 Len=531 > 114 7.997536 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=56233 Win=65535 Len=0 > 115 8.211446 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [ACK] Seq=56233 Ack=0 Win=5840 Len=1460 > 116 8.301504 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=57693 Win=65535 Len=0 > 117 8.326219 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=57693 Ack=0 Win=5840 Len=197 > 118 8.333736 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=57890 Win=65535 Len=0 > 119 8.422016 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=57890 Ack=0 Win=5840 Len=1126 > 120 8.429543 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=59016 Win=65535 Len=0 > 121 8.632683 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=59016 Ack=0 Win=5840 Len=934 > 122 8.634010 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=59950 Win=65535 Len=0 > 123 8.869443 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [ACK] Seq=59950 Ack=0 Win=5840 Len=1460 <- Restart of the > PC IP interfaces > 125 8.871878 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [ACK] Seq=61410 Ack=0 Win=5840 Len=1460 > 129 8.874047 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 > 130 9.307578 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=62870 Ack=0 Win=5840 [TCP CHECKSUM INCORRECT] > Len=740 <- this packet is a concatenation of the same packets than 111 and > 113 > 131 9.309162 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [ACK] Seq=63610 Ack=0 Win=5840 Len=1460 > 132 9.309293 172.17.2.172 172.17.2.173 TCP > [TCP Dup ACK 129#1] 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 > 142 9.789090 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=65070 Ack=0 Win=5840 [TCP CHECKSUM INCORRECT] > Len=1323 <- this packet is a concatenation of the same packets than 117 and > 119ss > 153 10.003902 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [PSH, ACK] Seq=66393 Ack=0 Win=5840 Len=934 > 156 10.019539 172.17.2.172 172.17.2.173 TCP > [TCP Dup ACK 129#2] 48955 > 5678 [ACK] Seq=0 Ack=62870 Win=65535 Len=0 > 157 10.905015 172.17.2.173 172.17.2.172 TCP > [TCP Retransmission] 5678 > 48955 [PSH, ACK] Seq=62870 Ack=0 Win=5840 [TCP > CHECKSUM INCORRECT] Len=740 > 158 13.209979 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [PSH, ACK] Seq=0 Ack=62870 Win=65535 Len=1 > 159 13.210040 172.17.2.172 172.17.2.173 TCP > 48955 > 5678 [FIN, ACK] Seq=1 Ack=62870 Win=65535 Len=0 > 160 13.210332 172.17.2.172 172.17.2.173 TCP > 48956 > 5678 [SYN] Seq=0 Len=0 MSS=1460 TSV=1711037 TSER=0 WS=6 > 161 13.241498 172.17.2.173 172.17.2.172 TCP > 5678 > 48955 [ACK] Seq=67327 Ack=2 Win=5838 Len=0 > 162 13.279770 172.17.2.173 172.17.2.172 TCP > 5678 > 48956 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 > 163 13.279930 172.17.2.172 172.17.2.173 TCP > 48956 > 5678 [ACK] Seq=1 Ack=1 Win=5840 Len=0 > 164 14.205872 172.17.2.173 172.17.2.172 TCP > [TCP Retransmission] 5678 > 48955 [PSH, ACK] Seq=62870 Ack=2 Win=5838 [TCP > CHECKSUM INCORRECT] Len=740 > > > In the pbuf_cat function "p->next" must not be equal to "t", but must be > equal to "NULL". And we must write "p->len+=t->len;". And next after the > call of "pbuf_cat(useg->p, queue->p);" in "tcp_enqueue fuction" tcp_out.c , > we have Add two line: > > pbuf_cat(useg->p, queue->p); > useg->len += queue->len; > useg->next = queue->next; > LWIP_DEBUGF(TCP_OUTPUT_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE, > ("tcp_enqueue: chaining segments, new len %"U16_F"\n", useg->len)); > if (seg == queue) > { > seg = useg; > seglen = useg->len; > queuelen--; //decrementation of the SND_QUEUELEN due > to concatenation > } > memp_free(MEMP_TCP_SEG, queue); > pbuf_free(queue->p); /dereference a pbuf chain due to concatenation > > > Thanks to this modification I haven't a TCP CHECKSUM INCORRECT in > wireshark and the communication works fine. > > Can you tell me if this modification are the best and if they will not > be cause of a problem. > > Thanks In advance, > > Hervé GARAT -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationKieran said: >No, that's wrong. p->len refers to the length of each individual pbuf. >We've added another pbuf to the chain, but not changed the length of >each pbuf. Because the chain is longer, we increment the length of >p->tot_len, but not the length of p->len. But in the inet_chksum_pseudo function,the len used to make checksum is p->len and not p->tot_len. However the message sent is long as p->tot_len, therefore the TCP checksum is Incorrect!! All the other change that I made(queuelen-- ;pbuf_free(p->queuelen);...)are made to have a valid checksum if LWIP do a concatenation. What's the best way to solve my problem? _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
Re: RE: Checksum Incorrect caused by ConcatenationJust sending a post a second time is normally not a way to attract much attention... "Hervé GARAT : Audemat" wrote: > > Kieran said: > >No, that's wrong. p->len refers to the length of each individual pbuf. > >We've added another pbuf to the chain, but not changed the length of > >each pbuf. Because the chain is longer, we increment the length of > >p->tot_len, but not the length of p->len. > > But in the inet_chksum_pseudo function,the len used to make checksum is > p->len and not p->tot_len. However the message sent is long as p->tot_len, > therefore the TCP checksum is Incorrect!! > > All the other change that I made(queuelen-- > ;pbuf_free(p->queuelen);...)are made to have a valid checksum if LWIP do a concatenation. As Kieran also said, the pbuf_free() is *wrong*, too. > > What's the best way to solve my problem? To be able to tell you that I would have to get your problem first. In my software, the same code path is executed and there is no error. Simon -- DSL-Preisknaller: DSL Komplettpakete von GMX schon für 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationSorry, but yersteday I thought that my first mail adress does not work well, cause I did not get an answer and I wrote the same message with a new mail adress. I'm newbie in mailing list, sorry again! My problem append when I use the pbuf_cat function, and I use this only if there is a communication problem. When I look for the execution code in debug mode, when my problem append, so LWIP go in pbuf_cat function and after inet_chksum calculate checksum with p->len but the message which is sent is p->tot_len long! And wireshark says TCP CHECKSUM INCORRECT and He's right! When you go in pbuf_cat function, after the TCP Checksum is OK? > -----Message d'origine----- > De : lwip-users-bounces+garat=worldcastsystems.com@... > [mailto:lwip-users-bounces+garat=worldcastsystems.com@...] De la > part de Simon Goldschmidt > Envoyé : mardi 17 novembre 2009 10:11 > À : Mailing list for lwIP users > Objet : Re: RE: [lwip-users] Checksum Incorrect caused by Concatenation > > > Just sending a post a second time is normally not a way to attract much > attention... > > > "Hervé GARAT : Audemat" wrote: > > > > Kieran said: > > >No, that's wrong. p->len refers to the length of each individual pbuf. > > >We've added another pbuf to the chain, but not changed the length of > > >each pbuf. Because the chain is longer, we increment the length of > > >p->tot_len, but not the length of p->len. > > > > But in the inet_chksum_pseudo function,the len used to make checksum is > > p->len and not p->tot_len. However the message sent is long as p- > >tot_len, > > therefore the TCP checksum is Incorrect!! > > > > All the other change that I made(queuelen-- > > ;pbuf_free(p->queuelen);...)are made to have a valid checksum if LWIP do > a concatenation. > > As Kieran also said, the pbuf_free() is *wrong*, too. > > > > > What's the best way to solve my problem? > > To be able to tell you that I would have to get your problem first. In my > software, the same code path is executed and there is no error. > > Simon > -- > DSL-Preisknaller: DSL Komplettpakete von GMX schon für > 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 > > > _______________________________________________ > lwip-users mailing list > lwip-users@... > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationOk, this modification seems to be WRONG! But If I use the LWIP code "as is", when LWIP use pbuf_cat, the segment which is sent has checksum error.
So I would like to know if in yours applications, you are using this function and if the checksum is OK. This checksum error is very exasperating because this message is never acknowledged and he's resent TCP_MAXRTX time. The solutions that I found are to reduce this TCP_MAXRTX to 1 or to comment code part where the concatenation is doing. But it seems not to be good ideas. I think there is a reason of this checksum error. Thanks for your Help _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationOn Tue, 2009-11-17 at 15:51 +0100, Hervé GARAT : Audemat wrote:
> So I would like to know if in yours applications, you are using this > function and if the checksum is OK. That code path in tcp_enqueue should be very common, so I think most people will be using it, and we've not seen other reports of a checksum error in this area. I think perhaps more likely there is a threading error in your code that results in list corruption (e.g. more than one thread active in the stack at the same time), or a problem in the driver handling pbuf chains. I would check these out. Kieran _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationOn Tue, 2009-11-17 at 10:01 +0100, Hervé GARAT : Audemat wrote:
> But in the inet_chksum_pseudo function,the len used to make checksum > is p->len and not p->tot_len. However the message sent is long as > p->tot_len, therefore the TCP checksum is Incorrect!! The inet_chksum_pseudo function iterates over all the pbufs in the chain, and checksums their contents individually, summing it all up for the final checksum. This is why it looks at p->len for each pbuf, not p->tot_len. For example, if you have a chain of three pbufs, each with 100 byte of data in, they will look like this: pbuf1: tot_len = 300, len = 100, payload = data1, next = pbuf2 pbuf2: tot_len = 200, len = 100, payload = data2, next = pbuf3 pbuf3: tot_len = 100, len = 100, payload = data3, next = NULL data1, data2, and data3 are all regions of length 100, so to checksum the contents of each pbuf we look at the len of each pbuf, not the tot_len of the chain. Hope that helps, Kieran _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationOn Tue, 2009-11-17 at 10:01 +0100, Hervé GARAT : Audemat wrote:
> However the message sent is long as p->tot_len, therefore the TCP > checksum is Incorrect!! Here's an possibility: when your driver sends the packet, does it just send p->tot_len byte starting from p->payload? That would be wrong. It must send p->len byte from p->payload, and then do the same for p->next, and so on, until it has sent p->tot_len in total. Kieran _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
|
|
RE: Checksum Incorrect caused by ConcatenationThanks for your answer kieran I looked for my driver and seem to have some problem if there is most than one pbuf in a chain. He was sending the both pbuf in the same descriptor as you said! Thanks a lot > -----Message d'origine----- > De : lwip-users-bounces+garat=worldcastsystems.com@... > [mailto:lwip-users-bounces+garat=worldcastsystems.com@...] De la > part de Kieran Mansley > Envoyé : mardi 17 novembre 2009 16:25 > À : Mailing list for lwIP users > Objet : RE: [lwip-users] Checksum Incorrect caused by Concatenation > > On Tue, 2009-11-17 at 10:01 +0100, Hervé GARAT : Audemat wrote: > > However the message sent is long as p->tot_len, therefore the TCP > > checksum is Incorrect!! > > Here's an possibility: when your driver sends the packet, does it just > send p->tot_len byte starting from p->payload? That would be wrong. It > must send p->len byte from p->payload, and then do the same for p->next, > and so on, until it has sent p->tot_len in total. > > Kieran > > > > _______________________________________________ > lwip-users mailing list > lwip-users@... > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@... http://lists.nongnu.org/mailman/listinfo/lwip-users |
| Free embeddable forum powered by Nabble | Forum Help |