The PC board I am using does not allow me to get to spare pins easily. I am using one UART for inter-processor comms, so can't use that for debug. Perhaps I can enlist one of the guys here with watchmaking skills... :-)
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of JM Sent: Thursday, August 27, 2009 12:35 PM To: Mailing list for lwIP users Subject: RE: [lwip-users] TCP not sending initial ACK Enable debugging to see what is going on. If you look at one of the Stellaris sample projects using lwIP, they are using uartstdio.c and ustdlib.c to feed debug text to the micro's UART. Also add this to your lwipopts.h: #define U8_F "c" #define S8_F "c" #define X8_F "x" #define U16_F "u" #define S16_F "d" #define X16_F "x" #define U32_F "u" #define S32_F "d" #define X32_F "x" #define LWIP_PLATFORM_DIAG(x) {UARTprintf x;} And add this somewhere to enable buffering, I put it in uartstdio.c because I'm lazy: #define UART_BUFFERED Set UART_TX_BUFFER_SIZE to something reasonable. Note also that they made a mistake in uartsdio.c by setting both Rx and Tx b buffers to UART_TX_BUFFER_SIZE (or vice versa). Be sure to define LWIP_DEBUG and any of the debug sections you want. I recommend starting with maybe TCP_INPUT_DEBUG, TCP_DEBUG, TCP_OUTPUT_DEBUG. Start up Hyperterminal in Windows and set it to 115.2K, 8N1, and set to the virtual COM the LMI driver placed there. For me, it's COM4. It's great for troubleshooting; I just wish I would have known about it earlier. --- 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, 11:33 AM 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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?5xUttxNdUSC-PtZNV4S03Jm5aD_OEuvkzaTbV 7Q9hMACdwvMa6MC90u8ypm0EK4Memzt4o2WoO8yEpaKKx8CcN6gea0aMd1ehBAr3LGSONsiI CjEg4ry3y8OoG1go0mMo3wCS4yMj32Mlr5bA18s7xcsChbm6xiXX8uY0Z10s3328ygcdEAgL tcfu0FmUj7fxnhJoiv6j0ol46jhOoazHzoIo0VBxQJs2078wend7d72atq18mYyUIPuQt0lU f4xgcI40i-Mh2lga5L8L0t4h9xx14g4z22ojfsc0eloj6zhPhoI62Pwlb21qE3R8L44h027D 16URW9w1O15ykM734goydxEAn3jhO-83ojyYa81wr3gebv9Ub0adkd7bUn45mn1F6H851Uc5 07K0YD4m5iRMNsQsEA4MKqeh1wd4x6psaPg0BYcxc1W3g5e0c91obc39o1FKyx42y8i1ao90 uXdgA2g9b1k6u6y8Me6iM76yEs60DEuGyUOpLsh5Gxew7Z0q5MGd1El-PE5e33zdi3wwa4Xy OEm2P0Om0qrEEh0s2x8JtwIhlgooQb8cfKC0_km078O3ZE13G35P1EVKly71cOXuAlA0RM1M ich2E5f1Hw7E1cMM9m5jt-LtdZ5VUQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEk DOUaxm163v00jrbOoWVJ5dZ5AQsLET76S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45f wxa14QgixasJfd40w90krDUvf0srpdLCQTSrLK8I6-VbQe9UW8msc> -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users <http://console.mxlogic.com/redir/?b3MWX3yrNJdZCXXzO9I07qIalf_BgY-F6lKnO fEizx8wOdwa0P9q8c0x02h81w650MqegSXxDh01pFxGtD2ZXxcQsx81CmgOl3Jp0yzJFaA08 0sKwPcK5pE0i-6gC0Z1E2D064wI5C1AI0QThgy1h490Bc4wftCEi184BwG3f3h4o739o3zhk e30jQflhspcTK8yRgDg3-wd2Ul6wQa_pQ2D1xNCF1Mg52tNpkb1pwpb0ddQk8we1gAmKMm8G Eccq5A67Tj0vGb03Ap1-Q0xR1yVwQsTaN3wCptLidk0RM1Mich2E5f1Hw7E1cMM9m5jt-Ltd Z5VUQsEK6XCPP4ByXtfzgKgGT2TQ03oGTZyLNeIjS7ByYEkDOUaxm163v00jrbOoWVJ5dZ5A QsLET76S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45fwxa14QgixasJfd40w90krDUvf 0srodLCQTSrLK8I6-VbQe9UW8msc> -----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 DOUaxm163v00jrbOoWVJ5dZ5AQsLET76S63ob6Azh0qmPP4ByXtfzgQKCy04ygmd44aPd45f wxa14QgixasJfd40w90krDUvf0srvdLCQTSrLK8I6-VbQe9UW8msc> start: 0000-00-00 end: 0000-00-00
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
