Thanks Kieran review the configuration.
It is GPRS environement, could only catpure sever log. It may not helpful.
I aslo find some low level device driver problem these days. I need to solve
that problem first.
On Thu, Oct 22, 2009 at 3:54 PM, Kieran Mansley wrote:
> On Thu, 2009-10-22 at 09:
Kieran Mansley wrote:
On Thu, 2009-10-22 at 11:18 +1300, David Empson wrote:
Kieran Mansley wrote:
> I was a bit wrong there. I've taken another look at the code and this
> change in behaviour is intentional. There were two changes in 1.3.1:
> - only send an explicit window update if the chang
Found the problem. Thanks to you and Kieran for the replies.
It's kind of a strange effect. So just in case anyone else runs into
a similar situation in the future, a quick description of what was
happening.
My driver is written so that when a new packet arrives or a
transmitted packet finishes
Jeff Barber wrote:
Now 256 happens to correlate to the size of the Tx and Rx ring buffers
in my driver so that was the obvious place to look. I notice that
sometimes my driver's linkoutput function is being called when its Tx
queue is full. I'm thinking that's the proximate cause of the
problem
On Thu, 2009-10-22 at 10:22 -0400, Jeff Barber wrote:
> problem. However, shouldn't the TCP_SND_QUEUELEN (32) and TCP_SND_BUF
> (8 * MSS) values be a limit to the maximum number of "outstanding"
> pbufs?
Yes. TCP_SND_BUF should cover all packets in flight from the
application until they are ac
(Apologies if you see this twice; I didn't see it show up in the list
archives so am trying again without the attachment)
I have an lwip-based FTP server built on a nearly stock 1.3.1 lwIP.
When I do a GET on a large file (resulting in a high-speed
unidirectional transfer), I'm seeing about every
On Thu, 2009-10-22 at 09:38 -0400, Pettinato, Jim wrote:
> Is anyone else having feelings of déjà vu with this thread??
>
> James M. Pettinato, Jr.
> FMC Technologies Measurement Solutions Inc.
>
> http://lists.nongnu.org/archive/html/lwip-devel/2008-04/msg00034.html
Almost - I think we're now
Is anyone else having feelings of déjà vu with this thread??
James M. Pettinato, Jr.
FMC Technologies Measurement Solutions Inc.
http://lists.nongnu.org/archive/html/lwip-devel/2008-04/msg00034.html
-Original Message-
From: lwip-users-bounces+jim.pettinato=fmcti@nongnu.org
[mailt
On Thu, 2009-10-22 at 12:33 +0200, Simon Goldschmidt wrote:
> Kieran Mansley wrote:
> > On Wed, 2009-10-21 at 17:04 +0200, goldsi...@gmx.de wrote:
> > > But is that really what we want (an bug free)? If so, we would really
> > > need a compile-time check that TCP_WND is at least 2*TCP_MSS (or only
Kieran Mansley wrote:
> On Wed, 2009-10-21 at 17:04 +0200, goldsi...@gmx.de wrote:
> > But is that really what we want (an bug free)? If so, we would really
> > need a compile-time check that TCP_WND is at least 2*TCP_MSS (or only
> > greater than TCP_MSS?) to prevent problems:
>
> I think a co
On 10/22/09, Kieran Mansley wrote:
> On Thu, 2009-10-22 at 14:35 +0700, Iwan Budi Kusnanto wrote:
> > Hi, i try to port lwip. I run the OS in qemu, and set lwip IP to
> 192.168.0.1
> > When i ping 192.168.0.1, i continuously get the following error, below.
> > Note : the qemu & tap0 setting wa
On Thu, 2009-10-22 at 14:35 +0700, Iwan Budi Kusnanto wrote:
> Hi, i try to port lwip. I run the OS in qemu, and set lwip IP to 192.168.0.1
> When i ping 192.168.0.1, i continuously get the following error, below.
> Note : the qemu & tap0 setting was fine. Previous lwip port can be
> ping-ed with t
On Thu, 2009-10-22 at 11:18 +1300, David Empson wrote:
> Kieran Mansley wrote:
> > I was a bit wrong there. I've taken another look at the code and this
> > change in behaviour is intentional. There were two changes in 1.3.1:
> > - only send an explicit window update if the change is greater than
On Thu, 2009-10-22 at 08:33 +0200, Simon Goldschmidt wrote:
> That's all true, but David's and Jan's recent problem was that the
> window was changed although tcp_recved() was called right away. This
> is not an RFC-violating problem but a problem in lwIP (when and how it
> calculates the window ch
On Wed, 2009-10-21 at 19:23 +0200, goldsi...@gmx.de wrote:
> David Shmelzer wrote:
> > I'm still confused as to why the the window size is decreasing in the
> > first place in 1.3.1 and not in 1.3.0. Isn't that causing the silly
> > window syndrome? The lwIP server is processing the packets immedia
On Thu, 2009-10-22 at 09:42 +0800, yueyue papa wrote:
> Hi All,
>
> I use lwIP+PPP in GPRS environment. I am still meet the response slow
> problem.
>
> The 80% time socket is used in this way
>
> connect --> send --(1xx bytes) ---> receive (1xx bytes)--->
> disconnect.
>
> What is suitable c
On Wed, 2009-10-21 at 17:04 +0200, goldsi...@gmx.de wrote:
> But is that really what we want (an bug free)? If so, we would really
> need a compile-time check that TCP_WND is at least 2*TCP_MSS (or only
> greater than TCP_MSS?) to prevent problems:
I think a compile time check would be a good id
Hi, i try to port lwip. I run the OS in qemu, and set lwip IP to 192.168.0.1
When i ping 192.168.0.1, i continuously get the following error, below.
Note : the qemu & tap0 setting was fine. Previous lwip port can be
ping-ed with this setting.
I also copy-paste my 'tcpdump -i tap0'.
Any idea ?
** e
18 matches
Mail list logo
