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-----
|