lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Queued segments not being sent


From: Bill Auerbach
Subject: RE: [lwip-users] Queued segments not being sent
Date: Fri, 7 Mar 2008 17:17:29 -0500

Yeah, you’re right.

 

The good news is, I found the problem.  That tcp_poll routine sneaks in and was calling send_data (my version of it) and this threw off my one to one relationship of calling tcp_write and having tcp_sent be used to free the data.  I’m not sure what the purpose of tcp_poll is, but it was getting in my way.

 

Bill

 


From: address@hidden [mailto:address@hidden On Behalf Of Taranowski, Thomas (SWCOE)
Sent: Friday, March 07, 2008 3:44 PM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Queued segments not being sent

 

It’s always been my recommendation to leave early on a Friday, for precisely this reason.  Working hard on a Friday always causes problems.

 


From: address@hidden [mailto:address@hidden On Behalf Of Bill Auerbach
Sent: Friday, March 07, 2008 11:11 AM
To: 'Mailing list for lwIP users'
Subject: RE: [lwip-users] Queued segments not being sent

 

The problem appears to be the first segment in the big list.  It is being sent, and wireshark’s “Follow TCP stream” contains the following:

 

LINK

address@hidden@V......>address@hidden: 0

..drop: 0

..chkerr: 0

..lenerr: 0

..memerr: 0

..rterr: 0

..proterr: 0

..opterr: 0

..err: 0

..cachehit: 0

<snip>

 

LINK is correct and was the first segment sent by itself (not sure why that happens…)  The next segment were these lines:

 

  LWIP_PLATFORM_DIAG(("xmit: %"STAT_COUNTER_F"\n\t", proto->xmit));

  LWIP_PLATFORM_DIAG(("rexmit: %"STAT_COUNTER_F"\n\t", proto->rexmit));

  LWIP_PLATFORM_DIAG(("recv: %"STAT_COUNTER_F"\n\t", proto->recv));

 

Which is bad, and it picks up with fw: which is correct to the end.  The hex of the bad area is:

 

49 4e 4b 0a 09 00                          .LINK...

00 40 54 68 01 08 fb 10  03 67 00 00 40 56 18 01 address@hidden address@hidden

09 03 14 02 3e 00 00 00  40 57 c8 01 09 0b 18 01 ....>... @W......

15 00 00 66 77 3a 20 30  0a 09 00 64 72 6f 70 3a ...fw: 0 ...drop:

 

Nothing in the bad data makes any sense.  It’s not freeing early or reusing data because strings would appear or just the one word would be trashed.

 

The good news in all of this is that it’s Friday. J

 

Bill


reply via email to

[Prev in Thread] Current Thread [Next in Thread]