|
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@fmcti.com | 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
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:
address@hidden
[mailto:address@hidden 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 <address@hidden>
wrote:
From: Chuck Kuecker
<address@hidden>
Subject: RE: [lwip-users] TCP not
sending initial ACK
To: "Mailing list for lwIP users"
<address@hidden>
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:
address@hidden
[mailto:address@hidden 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
<address@hidden>
wrote:
From: Chuck Kuecker
<address@hidden>
Subject: RE: [lwip-users] TCP
not sending initial ACK
To: "Mailing list for lwIP users"
<address@hidden>
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:
address@hidden
[mailto:address@hidden
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 <address@hidden>
wrote:
From: Chuck Kuecker
<address@hidden>
Subject: RE: [lwip-users]
TCP not sending initial ACK
To: "Mailing list for lwIP
users" <address@hidden>
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:
address@hidden
[mailto:address@hidden
On
Behalf Of address@hidden
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users
mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users |
-----Inline Attachment
Follows-----
|
-----Inline Attachment
Follows-----
|
|