Hello Chuck, The lwIP device is the reciever in this connection, correct? It is implied but not stated, so I wanted to confirm. Could it be simply that the delayed ACK mechanism is the source of your difficulty? Have you verified your TCP timers are firing at least approximately as expected? Is the first packet a full TCP segment's worth of data, or smaller? If a full segment, are you perhaps not calling tcp_recvd() for the first packet received in the app's recv() callback? What do you have #defined for TCP_WND? I would think that the server should go ahead and send additional data in spite of not seeing an immediate ACK response to the first packet, it should not time out... unless of course the receive window would become zero after one packet. Hope this helps, - Jim __
James M. Pettinato, Jr. Software Engineer E: jim.pettinato <blocked::mailto:[email protected]> @fmcti.com <blocked::mailto:[email protected]> | P: 814 898 5250 FMC Technologies Measurement Solutions Inc. 1602 Wagner Avenue | Erie PA | 16510 USA Phone: 814 898 5000 | Fax: 814 899-3414 www.fmctechnologies.com <blocked::http://www.fmctechnologies.com/> ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Chuck Kuecker Sent: Thursday, August 27, 2009 11:34 AM To: Mailing list for lwIP users Subject: RE: [lwip-users] TCP not sending initial ACK I noticed the 1460 length coming up often. By changing TCP_MSS and TCP_WND, I get different behavior, but can't seem to reliably get that first packet to ACK. Some combinations of settings produce patterns of resent packets, some produce a clean transfer all the way to the end with no retransmits. None of them so far fixes the original problem. I suppose I could edit off the header from the resent packet, but that seems like a nasty hack, and risky if the HTTP header ever changes. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of JM Sent: Thursday, August 27, 2009 10:20 AM To: Mailing list for lwIP users Subject: RE: [lwip-users] TCP not sending initial ACK There isn't much out there that describes these settings in good detail. However, TCP_MSS is simply the maximum amount of data that lwIP will Rx/Tx per packet. This is data payload only, not including headers, etc. I believe anything over 1460 is not possible since this is the maximum allowed (if I'm wrong someone please correct this). I don't believe it has to be a power of 2. Often, on my streaming connection, I'll get some amount of data per packet that is about 700 bytes. --- On Thu, 8/27/09, Chuck Kuecker <[email protected]> wrote: From: Chuck Kuecker <[email protected]> Subject: RE: [lwip-users] TCP not sending initial ACK To: "Mailing list for lwIP users" <[email protected]> Date: Thursday, August 27, 2009, 10:46 AM I've been playing with the TCP options in lwipopts.h. Changing the value of TCP_MSS seems to have an effect on whether or not the initial packet I receive gets ACKed. Is there a tutorial somewhere about what these settings do? I originally had TCP_MSS set to 1500. Is this supposed to be a power of 2? ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of JM Sent: Thursday, August 27, 2009 6:07 AM To: Mailing list for lwIP users Subject: RE: [lwip-users] TCP not sending initial ACK I'd try a switch anyway, although it's unlikely to fix your problem, but it's easy enough to try. I have not yet tried switching my micro to half duplex, so I can't say if that fixes the hub issue. I will say however that while I was trying to determine what was wrong, the most random things would drastically change how well or bad it worked. Enabling certain sections of debug, changing pbuf sizes, and even what server I was connecting to. My assumption is it was very sensitive to timing. Then again, you said only one packet fails, then it's ok. In my case, things were ok then communications completely broke down. At any rate, I wish you luck. --- On Wed, 8/26/09, Chuck Kuecker <[email protected]> wrote: From: Chuck Kuecker <[email protected]> Subject: RE: [lwip-users] TCP not sending initial ACK To: "Mailing list for lwIP users" <[email protected]> Date: Wednesday, August 26, 2009, 4:02 PM Premature celebration. I changed the processor's settings to half duplex, and have the identical results. It reliably does not ACK the first packet of the download. I've been using the hub for months now, and this is the first time it's been suspect. There has to be something different about how I handle TCP reception in this part of my code as compared to the other section, where I do TCP reception flawlessly, always. I've just got to find it. Chuck ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of JM Sent: Wednesday, August 26, 2009 12:03 PM To: Mailing list for lwIP users Subject: RE: [lwip-users] TCP not sending initial ACK It only took me 3 -4 weeks to figure this out, but if you're on a hub, try a switch. Apparently if your micro is in full duplex mode, a hub is a no-go. I'm using the LM driver and it works great for receiving lots of data, anyway. Take a look at the "Identification" field in the IP header for all packets going one direction. They should be sequential and incrementing. If there's a gap in the sequence, that means Wireshark isn't displaying a packet that was sent, either because your hardware or OS discarded it. I haven't tried half-duplex yet with the hub again. I'm assuming this would also fix your problem. --- On Wed, 8/26/09, Chuck Kuecker <[email protected]> wrote: From: Chuck Kuecker <[email protected]> Subject: RE: [lwip-users] TCP not sending initial ACK To: "Mailing list for lwIP users" <[email protected]> Date: Wednesday, August 26, 2009, 11:54 AM No, the LWIP timers are called from the main timer tick, and there are no other threads. This is how LWIP is set up for the Luminary driver library I am using, and it has always worked before. Wireshark shows no defective packets. Chuck -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, August 26, 2009 10:34 AM To: Mailing list for lwIP users Subject: Re: [lwip-users] TCP not sending initial ACK Chuck Kuecker wrote: > > I've tried changing the frequency of LWIP interrupt handler calls, > both greatly slowing and speeding them up, with no apparent change in > behavior. > What exactly do you mean with "interrupt handler calls"? The timers? They should *not* be called from an interrupt level: the core code of lwIP may only be accessed from one context at a time! If you obeyed this rule and still have problems, have a look at wireshark packet traces and see if it reports errors in a packet. Also, have a look at the stats (turn them on in lwipopts.h if not already done) and find out whether there are packets dropped. Simon _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?m7xRS74TzqrXdTT7Ajo0eRokGv_axVZicHsLA vgB72h1Ar0k1CiQgo1204yg30ca1wQsxJNMI6WuWaz943BNtMY2E1xQqAa1VEVaQ760SEWRN 0G-d6b64OcLohs0w1DMI5yooK4QMG2Wx8My0MQalbdSZAMdA2VUVcr4ox9V4dub1cs-7nsKc xGdj6AkNKPxwc28QojaT2sA1NEVh0ZrBgM4NM3IxorQOCd0KoSUe3OG8s5zhObj8xd2rPEu8 5y052zMMS9e2UNgw2gad7dTmd3gYrlv0wJsnhKM6ITb2bb0I2OdAhE23hOy7Igb0cbi5XFT7 41GMoKllr2HM3Q6wnuxoCC19wsYcO0mdM76Tx01VRv6NKUj7nEm3G4ipEVc5lChLQg78RhpK dCzACM8WdLLzoAGU4OPQvcc8wcCI1gH02x8Km0U75LaMpC5BwOmA39wk70MqwYv4fy0JQgQ- 9s6g2osGqeg6p30craW8xCzV4bT54gGoKqeg8Y1jhOd1ACwd2Ul6wQk42E9spyOy6LyAyoQo g8b1AJ86j0Ee1wQbg4itQOrN1MIC-I95AMUr8zdOMIYqei8PWEs95HAm36E1o3KxNzQ1Ei61 4my0O091b2H9A4ICjt-LtdZ5VUQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEkDOU axm163v00jqoUsYedEFLEILecfK6S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45fwxa1 4QgixasJfd40w90krDUvf0srhdI6QTSrLK8I6YsZtOCc_> _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?b3MWX3yrNJdZCXXzO9I07qIalf_BgY-F6lKnO fEizx9Yf2sVxUcg2oM95MJc2go6m1yX84aLW72Eo6CP9kkQ4A0Oe0sQsANIg2nIzqJChaYJj 0syUhhud78VeUEG19ocxAq3dW8M0kdf8T0A1Ooqjts78ztnNnhgfGqeg81r5NxwDhAI5z3dV 35MQy-YzlNAyIqeg78EXuxEVs510MnJvlGcway6gC-W7Bho2wCOOdxaUm38w17zl70a41MS6 2rU99y4nh5AG0TLwc2m30UI-Gh2p1co1BOFwMCGyo9CzAfb82MQVs1Rh0MdBy0cC11EVaC4r Iz83KbnQwX0g5LayNzOrMuSdIy4xuq1wmGN8mYdj2trQpcuj4gauu41Lr1Uj7n0lWROMSdCz ACM8WdLLzoAGU4OPQvcc8wcCI1gH02x8Km0U75LaMpC5BwOmA39wk70MqwYv4fy0JQgQ-9s6 g2osGqeg6p30craW8xCzV4bT54gGoKqeg8Y1jhOd1ACwd2Ul6wQk42E9spyOy6LyAyoQog8b 1AJ86j0Ee1wQbg4itQOrN1MIC-I95AMUr8zdOMIYqei8PWEs95HAm36E1o3KxNzQ1si614my 0O091b2H9A4ICjt-LtdZ5VUQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEkDOUaxm 163v00jqoUsYedEFLEILecfK6S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45fwxa14Qg ixasJfd40w90krDUvf0srjdI6QTSrLK8I6YsZtOCc_> -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?2MYeKMUCYrjvpK-UYyr01SH2Bj_VkffGhBrBY zW4EUiv3MDeou340Cc2hsbj0A61BwoKOWcODUuGyUOpLuz0bC7xU72gycEz053x8QsA7Nw1j bwu1gH02x8Km0U75LaMpC5BwOmA39wk70MqwYv4fy0JQgQ-9s6g2osGqeg6p30craW8xCzV4 bT54gGoKqeg8Y1jhOd1ACwd2Ul6wQk42E9spyOy6LyAyoQog8b1AJ86j0Ee1wQbg4itQOrN1 MIC-I95AMUr8zdOMIYqei8PWEs95HAm36E1o3KxNzQ0Qi614my0O091b2H9A4ICjt-LtdZ5V UQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEkDOUaxm163v00jqoUsYedEFLEILec fK6S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45fwxa14QgixasJfd40w90krDUvf0srp dI6QTSrLK8I6YsZtOCc_> -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?b3MWX3yrNJdZCXXzO9I06vaAWt2I2c6-00U9G X33VkDa3JsfcimbJQ-d3t-LtdZ5VUQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEk DOUaxm163v00jqoUsYedEFLEILecfK6S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45fw xa14QgixasJfd40w90krDUvf0srodI6QTSrLK8I6YsZtOCc_>
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
