>-Original Message-
>From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of goldsi...@gmx.de
>Sent: Tuesday, August 25, 2009 5:10 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] Re: IP Addr
Hello,
I've got another problem. I am receiving a large (~132 K) HTTP file via
TCP. The very first packet, which has the file length, is received, but
not ACKed. The server times out and resends this packet, which is
properly ACKed and all subsequent packets are handled properly.
I had thi
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: t
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: lwip-users-bounces+ckueck
Chuck Kuecker wrote:
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.
So lwIP is running in the main thread and the timers are called from
intterupt
Hi all,
Is lwip able to reassemble fragmented TCP packets? If yes, how?
In fact my stack is supposed to receive a HTTP POST request split
into 2 TCP fragments. At the TCP level, both fragments are set with
"Position fragment/Fragment offset" = 0 and "More fragment"=0. As a
result,
Hi all,
Is lwip able to reassemble fragmented TCP packets? If yes, how?
In fact my stack is supposed to receive a HTTP POST request split
into 2 TCP fragments. At the TCP level, both fragments are set with
"Position fragment/Fragment offset" = 0 and "More fragment"=0. As a
result,
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 fo
That's probably the cause. I am using a hub between my network and the
unit I am working on to allow Wireshark to get in and see packets.
Thanks!
Chuck
From: lwip-users-bounces+ckuecker=chaney-inst@nongnu.org
[mailto:lwip-users-bounces+ckuecker=chan
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 abo
Chuck Kuecker wrote
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.
You could post your code here if you want. If it's something obvious,
may
11 matches
Mail list logo
