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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 10:32 PM To: [email protected] Subject: lwip-users Digest, Vol 42, Issue 5 Send lwip-users mailing list submissions to [email protected] 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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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\)" <[EMAIL PROTECTED]> Subject: RE: [lwip-users] Re: curious large packets and transmit stuck To: "Mailing list for lwIP users" <[email protected]> Message-ID: <[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Puschmann Sent: Sunday, February 04, 2007 12:06 PM To: [email protected] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users ------------------------------ _______________________________________________ lwip-users mailing list [email protected] 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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
