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
-----Inline Attachment Follows-----
_______________________________________________
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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
