Nabble - nongnu - lwip

[bug #28106] duplicate acknowledge for fast retransmit could have not null length

2009-11-27T08:37:34Z

Follow-up Comment #3, bug #28106 (project lwip):

Linux has:

#define FLAG_NOT_DUP (FLAG_DATA|FLAG_WIN_UPDATE|FLAG_ACKED)

i.e. if the packet has data, updates the window, or acks new data, it is not
a duplicate. The first of these is the point in question. Looks like other
stacks all consider a packet with data in as not a duplicate, so the change
brings us in line with everyone else.

You are quite right that if packets carrying data get interleaved with the
duplicate ACKs it will fail to do fast retransmission due to the dup ack count
being reset, but for most network stacks that would be an unusual case because
received packets would normal be processed in batches. That might not be the
case for users of lwIP, particularly where there are small windows and so not
many packets in flight, but it's better that we're compatible with other
stacks than with older versions of lwIP.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28106] duplicate acknowledge for fast retransmit could have not null length

2009-11-27T07:46:45Z

Follow-up Comment #2, bug #28106 (project lwip):

It is bad, that current implementation of lwip is not compatible with old
one :(

Kieran, I don't understand how fast retransmit works if dup ACK should have 0
length.

suppose host A send packets:
seqno 1 ack 100
seqno 2 ack 101
seqno 3 ack 102 - X this packet lost
seqno 4 ack 103
seqno 5 ack 104

host B send packets
seqno 105 ack 1 len 1
seqno 106 ack 2 len 1
seqno 107 ack 3 len 1
seqno 108 ack 3 len 0 (send dup ack)
seqno 108 ack 3 len 1 (send own data)
seqno 109 ack 3 len 0
seqno 109 ack 3 len 1
seqno 110 ack 3 len 0
seqno 110 ack 3 len 1

Host A receives (ack 3 len 0) - variable dupack incremented
(ack 3 len 1) - dupack reseted
(ack 3 len 0) - dupack incremented
(ack 3 len 1) - dupack reseted
and so on

Without length testing it seems to work.

Stevens in TCP/IP Illustrated use 4.4BSD-Lite sources.
It is interesting what say about duplicate ACKs standard
and how it is implemented e.g. in Linux?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Fredrik Hederstierna is out of the office.

2009-11-27T07:23:22Z

I will be out of the office starting 2009-11-27 and will not return until
2009-12-07.

I will respond to your message when I return.
Try contact Erik Ekman or Stefan Svensson for technical issues.
I'm also partly available from phone +46 768 506799.

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28106] duplicate acknowledge for fast retransmit could have not null length

2009-11-27T06:59:53Z

Update of bug #28106 (project lwip):

Planned Release: => 1.3.2

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28106] duplicate acknowledge for fast retransmit could have not null length

2009-11-27T06:57:18Z

Follow-up Comment #1, bug #28106 (project lwip):

Yes, that's an interesting case, and I agree with your deduction. It's not
just necessary because of the change to our stack, many other stacks will have
this requirement for an ACK to be seen as a duplicate.

We currently have no function to send a pure ACK with no data, but it is
necessary in this case.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28064] pbuf_alloc(PBUF_POOL) is not thread-safe

2009-11-27T06:50:30Z

Follow-up Comment #4, bug #28064 (project lwip):

I think that's a good approach for the short term and we can leave this bug
open to come up with something better, if necessary, for 1.4.0

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28064>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28106] duplicate acknowledge for fast retransmit could have not null length

2009-11-27T06:47:32Z

URL:
<http://savannah.nongnu.org/bugs/?28106>

Summary: duplicate acknowledge for fast retransmit could
have not null length
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: olegreen
Submitted on: Fri 27 Nov 2009 02:47:31 PM GMT
Category: TCP
Severity: 3 - Normal
Item Group: Faulty Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: CVS Head

_______________________________________________________

Details:

Last post I have done was for bug with status fixed,
title was not completely correct too.
So I submit new bug.

In new implementation of fast retransmit we have following rules:
/* (From Stevens TCP/IP Illustrated Vol II, p970.) Its only a
* duplicate ack if:
* 1) It doesn't ACK new data
* 2) length of received packet is zero (i.e. no payload)
* 3) the advertised window hasn't changed
* 4) There is outstanding unacknowledged data (retransmission timer
running)
* 5) The ACK is == biggest ACK sequence number so far seen (snd_una)
*/

We check clause 2
"length of received packet is zero (i.e. no payload)"

It means that we should ourself generate zero length ACK for each new segment
in out of sequence queue.
But now we call tcp_ack_now(pcb).
If unsent queue has something, we send non zero length ACK packet.

Actually in RFCs I didn't found mentioning about zero length ACK,
only Stevens.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Re: pbuf pool size / mss size in low memory environment and routing to slow link

2009-11-27T06:05:21Z

Hi Kieran,

the 36 pbufs with 256 bytes each and 1200 byte MSS did not work ;-)

Is there a recommendation of the relation between pbuf size and MSS? I did not find anything about this is the documentation ...

Marco

Kieran Mansley schrieb:

On Thu, 2009-11-19 at 13:15 -0800, fepgmbh wrote:

First of all, 6 pbufs seems not to be very much, and as i understood
they
can be chained together, i changed this to 36 pbufs with 256 bytes
each -
noticing that now the TCP connections won't work with the 1200 byte
MSS.


I wonder if your driver can handle that case correctly?  It has to know
to split the received packet across pbufs.  A naive driver might ignore
pbuf chains (on send as well as receive).

Kieran



_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

[task #7930] Create automatic test cases

2009-11-27T00:05:57Z

Follow-up Comment #7, task #7930 (project lwip):

First unit tests added, mainly for testing tcp ooseq processing.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/task/?7930>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28054] Two segments with FIN flag on the out-of-sequence queue

2009-11-27T00:05:25Z

Follow-up Comment #16, bug #28054 (project lwip):

The unit tests I just checked in seem to confirm the patch works (although
not all clauses of the code addin ooseq segments are covered, yet).

I would convert the new function to static though, to give the compiler room
for improvements.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28054>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Re: memp_malloc system protection

2009-11-26T22:56:35Z

Mike Kleshov wrote:

> 2009/11/27 goldsimon@... <goldsimon@...>:
>
>> Yes, you should. That's what's SYS_LIGHTWEIGHT_PROT is meant to be for.
>>
>> Simon
>>
>
> Surely it depends on the application. I'm using lwip raw API with no
> OS. I'm not using any concurrent access protection whatsoever. My
> interrupt service routines are small and simple, and they are not
> related to lwip in any way. Hence, no need for any protection.

I didn't think anyone having thought this through like you did would ask
such a question, so basically the answer is still "yes, the memp pools
need protection"! If you know you are running in a system where there is
no need for protection, the question wouldn't have arised...

Simon

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

Re: memp_malloc system protection

2009-11-26T22:48:46Z

2009/11/27 goldsimon@... <goldsimon@...>:
> Yes, you should. That's what's SYS_LIGHTWEIGHT_PROT is meant to be for.
>
> Simon

Surely it depends on the application. I'm using lwip raw API with no
OS. I'm not using any concurrent access protection whatsoever. My
interrupt service routines are small and simple, and they are not
related to lwip in any way. Hence, no need for any protection.

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

[bug #28064] pbuf_alloc(PBUF_POOL) is not thread-safe

2009-11-26T22:24:53Z

Follow-up Comment #3, bug #28064 (project lwip):

The code in question has been added on jan 28th, 2009 after a discussion on
lwip-users (without a bugtracker entry): Jonathan came up with a calculation
of how long it takes to free ooseq pbufs.

Having that calculation in mind, the most simple solution probably is to call
tcpip_callback (non-blocking) to free the ooseq pbufs in the correct thread
context. Of course, that doesn't work when allocating from an ISR with
NO_SYS=1.

The downside is of course that we still loose some packets until the
ooseq-freeing code runs in tcpip_thread, but that's the best I can currently
think of.

Any comments on this before I make the canges?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28064>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Re: memp_malloc system protection

2009-11-26T22:15:43Z

Francois Bouchard wrote:
> I'm running lwIP in stand alone mode and I'm wondering if I
> should mask interrupts routines during buffer allocation? memp_malloc()
Yes, you should. That's what's SYS_LIGHTWEIGHT_PROT is meant to be for.

Simon

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

memp_malloc system protection

2009-11-26T10:59:38Z

I'm running lwIP in stand alone mode and I'm wondering if I should mask interrupts routines during buffer allocation? memp_malloc()

THx

Francois

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

[bug #28064] pbuf_alloc(PBUF_POOL) is not thread-safe

2009-11-26T08:59:12Z

Update of bug #28064 (project lwip):

Severity: 3 - Normal => 5 - Blocker
Status: None => In Progress
Assigned to: None => goldsimon
Summary: pbuf_alloc(PBUF_POOL) cannot be used from ISR any
more => pbuf_alloc(PBUF_POOL) is not thread-safe

_______________________________________________________

Follow-up Comment #2:

Updated summary and status:

This is a blocker: if the pbuf-pool is empty, pbuf_alloc_pool iterates the
tcp_active_pcbs list from every thread. This has been introduced with 1.3.1.

As nice as this feature (reclaiming ooseq pbufs) is, it doesn't work as it
is.

If we still want this, we have to implement it in another way so that the
ooseq-freeing code runs in the tcpip-thread.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28064>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28098] Nagle can prevent fast retransmit from sending segment

2009-11-26T08:44:27Z

Update of bug #28098 (project lwip):

Status: None => Fixed
Assigned to: None => goldsimon
Open/Closed: Open => Closed

_______________________________________________________

Follow-up Comment #2:

The fix was rather simple: tcp_do_output_nagle() must return TRUE if
pcb->flags has TF_INFR set.

Fixed, thanks for reporting.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28098>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28099] API required to disable Nagle algorithm at PCB level

2009-11-26T07:19:48Z

Update of bug #28099 (project lwip):

Status: None => Fixed
Assigned to: None => goldsimon
Open/Closed: Open => Closed

_______________________________________________________

Follow-up Comment #1:

Good idea. Added tcp_nagle_*() function-like macros.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28099>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28098] Nagle can prevent fast retransmit from sending segment

2009-11-26T07:07:20Z

Follow-up Comment #1, bug #28098 (project lwip):

Hmm, this is indeed a problem that should be fixed for 1.3.2 as the nagle on
pcb-level is quite new...

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28098>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28087] accept() timeout but errno not set to ETIMEOUT

2009-11-26T07:06:22Z

Update of bug #28087 (project lwip):

Planned Release: => 1.4.0

_______________________________________________________

Follow-up Comment #1:

To implement this satisfactingly, the netconn API has to be changed:
netconn_accept() has to return an err_t instead of the connection pointer.

Together with bug #27709 (conn->err race condition on netconn_recv()
timeout), this will have to wait until 1.4.0.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28087>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28099] API required to disable Nagle algorithm at PCB level

2009-11-26T03:45:37Z

URL:
<http://savannah.nongnu.org/bugs/?28099>

Summary: API required to disable Nagle algorithm at PCB
level
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: hbryson
Submitted on: Thu 26 Nov 2009 11:45:36 GMT
Category: TCP
Severity: 3 - Normal
Item Group: Feature Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: 1.3.1

_______________________________________________________

Details:

Instead of using "tpcb->flags |= TF_NODELAY", it would be good if there was
an API to disable Nagle algorithm for applications using the tcp_*() APIs such
as tcp_connect()

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28099>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28098] Nagle can prevent fast retransmit from sending segment

2009-11-26T03:37:55Z

URL:
<http://savannah.nongnu.org/bugs/?28098>

Summary: Nagle can prevent fast retransmit from sending
segment
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: hbryson
Submitted on: Thu 26 Nov 2009 11:37:54 GMT
Category: TCP
Severity: 3 - Normal
Item Group: Faulty Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: 1.3.1

_______________________________________________________

Details:

If fast retransmit (tcp_rexmit() from tcp_receive()) attempts to output a
segment, the segment can be blocked by Nagle algorithm (if it matches the
appropriate criteria). It should not be.

If a slow retransmission occurs after the above event(tcp_rexmit_rto()), the
previous "stuck" segment is queued behind all its subsequent segments in the
unsent queue. When the unsent queue is output, the "stuck" segment will again
be prevented by Nagle from getting transmitted.

If no sunsequent data is enqueued to TCP (e.g. TCP PCB is "full"), the above
condition is persistent and the connection will stall and eventually fail.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28098>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #27445] PCB hangs in Fast Retransmit due to unchanging cwnd

2009-11-25T10:13:18Z

Follow-up Comment #14, bug #27445 (project lwip):

Ok, now we have Clause 2
"length of received packet is zero (i.e. no payload)"

It means that we should our self generate _zero length_ ACK for each new
segment in out of sequence queue.
But now we call tcp_ack_now(pcb).
If unsent queue has something, we send non zero length ACK.

Actually in RFCs I didn't found mentioning about zero length ACK,
only Stevens.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?27445>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[patch #6969] PPP: missing PAP authentication UNTIMEOUT

2009-11-25T01:34:29Z

Follow-up Comment #1, patch #6969 (project lwip):

Yesterday I sent a mail to one of the pppd developers
(paulus@...) about this patch. This is his response:

"Your proposed fix looks reasonable, although I would probably put the
UNTIMEOUT() just before the assignment to
u->us_clientstate."

This is not submitted yet to the pppd bugtracker.
I think this is the solution of:

http://ppp.samba.org/cgi-bin/ppp-bugs/incoming?id=1163;user=guest
https://savannah.nongnu.org/bugs/?13315

As Paul suggested, I propose to add
UNTIMEOUT(upap_timeout, u); /* Cancel timeout */
just before u->us_clientstate = UPAPCS_OPEN;

I think this should go into lwip 1.3.2. Any objections?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6969>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #21680] PPP upap_rauthnak() drops legal NAK packets

2009-11-25T01:23:30Z

Follow-up Comment #4, bug #21680 (project lwip):

I compared the the current lwip ppp implementation
with ucip (which seems to be dead) and pppd 2.4.5
(which is just 2 weeks old).

The latest release (ucip1-0-3.zip) that can be
downloaded from http://sourceforge.net/projects/ucip/
is much different when compared with the sources I got
via cvs. The conclusion is that there is nothing
to port from ucip, but it was very helpful to
look at it because I understood better what Marc did.
Thanks, Simon.

There are some fixes in pppd 2.4.5 that I wish to
backport here. Unfortunately the function/struct/var/const
definitions in pppd appear in different order.
The order in lwip is better, but I reverted it because
the comparison is much harder.

The new files are attached. I'll be glad if someone
can test them. I may have mistaken some #if 0 or #endif.

PS: please take a look at
https://savannah.nongnu.org/patch/?6969 !

(file #19129, file #19130, file #19131, file #19132)
_______________________________________________________

Additional Item Attachment:

File name: fsm.c Size:23 KB
File name: ipcp.c Size:43 KB
File name: lcp.c Size:57 KB
File name: pap.c Size:15 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?21680>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28087] accept() timeout but errno not set to ETIMEOUT

2009-11-24T22:24:47Z

URL:
<http://savannah.nongnu.org/bugs/?28087>

Summary: accept() timeout but errno not set to ETIMEOUT
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: hanhui03
Submitted on: Wed Nov 25 06:24:45 2009
Category: sockets
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: CVS Head

_______________________________________________________

Details:

In accept() function, when netconn_accept() return NULL, if sock->conn->err
is ERR_OK, errno should be ETIMEOUT.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28087>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28054] Two segments with FIN flag on the out-of-sequence queue

2009-11-23T09:40:46Z

Follow-up Comment #15, bug #28054 (project lwip):

Patch again corrected.
It was error in processing last segment.

if (next->next == NULL &&
TCP_SEQ_GT(seqno, next->tcphdr->seqno)) {
+ if (TCPH_FLAGS(next->tcphdr) & TCP_FIN) {
+ /* segment "next" already contains all data */
+ break;
+ }

(file #19118)
_______________________________________________________

Additional Item Attachment:

File name: oos_fin.patch Size:6 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28054>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28054] Two segments with FIN flag on the out-of-sequence queue

2009-11-23T07:11:15Z

Follow-up Comment #14, bug #28054 (project lwip):

I'll take a look at the patch, and if I think it's safe I'll try and get it
in to 1.3.2

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28054>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28054] Two segments with FIN flag on the out-of-sequence queue

2009-11-23T07:08:03Z

Follow-up Comment #13, bug #28054 (project lwip):

The patch looks good to me. I also like the separation into smaller
functions, it would do the rest of the code good, too, since it gets more
readable. And at least MSVC and gcc seem to inline static functions quite
well, which means that code size isn't an argument here.

However, I'm not in a position to test it and a "should work" might not be
enough at this stage of release, so we might want to delay this until after
the 1.3.2 release...?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28054>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

[bug #28054] Two segments with FIN flag on the out-of-sequence queue

2009-11-23T05:48:04Z

Follow-up Comment #12, bug #28054 (project lwip):

In this patch common part for insertion packet into
oos queue is moved into separate function.

I have tested this patch with FIN packets.
With other packets it should work too.

(file #19117)
_______________________________________________________

Additional Item Attachment:

File name: oos_fin.patch Size:5 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28054>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Last call for bugs for 1.3.2

2009-11-23T01:42:51Z

Thanks to some great work by Simon over the weekend, there are now no
bugs blocking the release of lwIP 1.3.2. If you know of a problem but
haven't yet reported it, please do so as soon as possible. If there
aren't any more problems I'll be making the final release in the next
couple of days.

Thanks

Kieran

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

Last call for bugs for 1.3.2

2009-11-23T01:42:51Z

Thanks to some great work by Simon over the weekend, there are now no
bugs blocking the release of lwIP 1.3.2. If you know of a problem but
haven't yet reported it, please do so as soon as possible. If there
aren't any more problems I'll be making the final release in the next
couple of days.

Thanks

Kieran

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel

Re: pbuf pool size / mss size in low memory environment and routing to slow link

2009-11-22T23:01:31Z

> > First of all, 6 pbufs seems not to be very much, and as i understood
they
> > can be chained together, i changed this to 36 pbufs with 256 bytes each
> > noticing that now the TCP connections won't work with the 1200 byte
> > MSS.

> I wonder if your driver can handle that case correctly? It has to know
> to split the received packet across pbufs. A naive driver might ignore
> pbuf chains (on send as well as receive).
> Kieran

Correct, I wrote my own driver for the ARM7 LPC23XX/24XX. I wrote the
driver so that it could handle PBUFs of different size than the EMAC DMA
buffers: equal, bigger, or smaller. Unless your driver is specifically
written to handle all of this data reorganization between the PBUFs and the
DMA bufs, it's best to assume they need to be the exact same size.

I was curious to know how much difference in speed there would be with
various buffer sizes, and equal or not equal. I tested with a 4MB stream of
TCP data. The data rate is currently around 2.2MB/sec. I tested with BUF
sizes down to 128 bytes, and up to 1536. But in each case the total RAM was
the same, about 12K.

There wasn't much difference in speed, maybe +/- 10%. I expected a larger
penalty when the buffer sizes were not equal, and/or when they were smaller,
but it really didn't affect it significantly. Very little speed difference.
Not much difference either with a large number of 24/256 size buffers, or a
small number of 4/1536 buffers. I could see no significant speed penalty by
chaining buffers either. The chaining appears very efficient.

With all that in mind, the most flexible combination is to use a larger
number of smaller buffers. 256 bytes seems about optimal and provides more
resources for higher frequency small packet traffic. Several of the other
TCP stacks I have used employed dual small/big buffers as a solution to this
problem. However, I have to give lwIP credit here, the PBUF chaining
approach gives all this small/big buffer size flexibility with virtually no
speed penalty.

My experience also suggests that lwIP [RAW] is about the fastest, smallest,
and most capable TCP stack solution for embedded systems with minimal RAM
resources. I am using this with FreeRTOS and my profiling shows only about
75% CPU utilization during the saturated TX/RX transfer. I think even more
speed is still possible with further optimizations and tuning, which is what
I am working on now. memcpy and chksum routines are very important, as well
as many other somewhat obscure areas. I am curious to see if I can
increase the speed further.

Chris.

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

Re: new data callback with pbuf pointer of zero

2009-11-22T12:23:30Z

Oops, somehow I missed that statement in that file! (I have looked at it several times previously)

--- On Sun, 11/22/09, goldsimon@... <goldsimon@...> wrote:

From: goldsimon@... <goldsimon@...>
Subject: Re: [lwip-users] new data callback with pbuf pointer of zero
To: "Mailing list for lwIP users" <lwip-users@...>
Date: Sunday, November 22, 2009, 1:54 PM

JM wrote:
> I'm a bit confused by this one. It took me a while to track down the cause of my crashes, but I finally discovered that the callback specified by tcp_recv was being passed a a pointer of zero for the pbuf. The callback function never checked for this and cause the processor to throw an exception because of the invalid pbuf pointer. Anyway, I have the callback return if the passed pbuf is zero and now it's fine. The passed error code is zero.
> What would cause it to be passed zero for the pbuf? By definition, isn't this callback used when there is data to provide? I'm using 1.3.0 in raw mode.
>
>
Excerpt from doc/rawapi.txt
The callback function will be passed a NULL pbuf to indicate that the remote host has closed the connection.

Does that make it clear enough? :-)

Simon

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

From forum: lwip-users

[bug #25882] TCP hangs on MSS > pcb->snd_wnd

2009-11-22T11:14:09Z

Follow-up Comment #8, bug #25882 (project lwip):

> for example keeping track of the largest window the other side has
advertised

That would mean taking this value as an upper limit for segment sizes in
tcp_enqueue? That would solve the problem where the server never announced a
window >= MSS. Plus it's an easy chance that doesn't have a big influence on
performance.

But couldn't a (badly implemented) remote TCP get into a state where the
window once was larger but now doesn't grow? Could this case be solved by
including code in the persist timer to send more than one byte (i.e. send as
much as the window allows)?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?25882>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

From forum: lwip-devel