[lwip-users] RE: lwip-users Digest, Vol 42, Issue 5

[Tanweer_Noor]

Hi all I downloaded lwip...can anyone suggest me how to run it using a
client server program bypassing the kernel
Regards
Tanweer Noor

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of address@hidden
Sent: Tuesday, February 06, 2007 10:32 PM
To: address@hidden
Subject: lwip-users Digest, Vol 42, Issue 5

Send lwip-users mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.nongnu.org/mailman/listinfo/lwip-users
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-users digest..."


Today's Topics:

   1. RE: Re: curious large packets and transmit stuck
      (Taranowski, Thomas (SWCOE))


----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Feb 2007 20:11:15 -0600
From: "Taranowski, Thomas \(SWCOE\)" <address@hidden>
Subject: RE: [lwip-users] Re: curious large packets and transmit stuck
To: "Mailing list for lwIP users" <address@hidden>
Message-ID:
        
<address@hidden
com>
        
Content-Type: text/plain;       charset="US-ASCII"

I didn't see any details on what driver/hardware/os you're using, so I'm
making an educated guess...

The problem you describe could potentially be a problem within the
driver.  I could see a scenario where the driver fails to send/transmit
any data because, say, there are no transmit buffers available.  In this
case the driver would fail to send, but be unable to notify that data
was sent, depending on the implementation of the low level driver/stack
interface.  In this case, the stack could be caught in some undefined
state.  The receipt of the ping triggers a transmit, and an interrupt,
and perhaps some other events, depending on the implementation, that
could cause operation to resume, but you'd probably see that some
packets were lost.  

I'd make sure that the driver send call never returns an error
condition.  As a simple test, try increasing the size of the transmit
queue, or whatever you use, for the driver.

You could also increase the size of the PBUF_POOL_BUFSIZE option, so
that the depth of the buffer chain sent to the driver is shorter.  This
could result in fewer transmit buffers being used, depending on your
implementation of course.

-Thomas

-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of Andre Puschmann
Sent: Sunday, February 04, 2007 12:06 PM
To: address@hidden
Subject: [lwip-users] Re: curious large packets and transmit stuck

hey guys,
another thing that maybe brings a bit more light is the following. once
the stack is as slow i can burst the things up for another ~300 packets
with a single ping.
after that burst transmission is slow again. but i can do this "trick"
again and again.
i already checked the timer function but they are called frequently.
what can a single ping packet activate in the stack (or its helper
functions)??
any hints??


best regards,

andre


Andre Puschmann wrote:
> hi kieran,
> here are my lwip opts.h and one trace using the netconn-api and
another
> one using the raw api ..
> if you have a look at the first trace (netconn) you can see that the
> packets slowly dropping out/in .. it seems that lwip "forgets" acks
the
> other end send. you can't see the large packets directly, i mean there
> is one large and another small one, but before the stuck all packets
> were 1000bytes long. so it seems that it has something to do with
that.
> if i use the raw api there are no "large" packets .. since as long as
> lwip has something to send it sends packet with max size (1456byte).
but
> nevertheless, after a while the whole system shows the same behavior.
> 
> do you think it has something to do with my timer/semaphore/mbox
> implementation?
> 
> 
> many thanks
> 
> andre
> 
> 
> 
> 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap
> 2: http://www.puschmann.net/public/large_and_small_packet.cap
> 3: http://www.puschmann.net/public/opt.h
> 
> 
> Kieran Mansley wrote:
>> On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote:
>>> i am aware of this fact. the curious thing IMO is the correlation
>>> between the occurrences of this "larger packets" and the stuck of
the
>>> whole stack.
>> Sounds like you may either have a locking problem (the usual cause of
>> deadlock) or possibly a resource allocation issue.  Is lwIP sending
or
>> receiving the large packet?  Could you get a packet trace using
>> something like ethereal?  Your lwipopts.h configuration might throw
some
>> light on the problem too.
>>
>> Kieran



_______________________________________________
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

End of lwip-users Digest, Vol 42, Issue 5
*****************************************



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.