lwIP 1.3.2-rc1 released

[Kieran Mansley]

I've just made a release of lwIP-1.3.2-rc1 by tagging the CVS tree with
the STABLE-1_3_2-RC1 tag, and uploading zip snapshots to savannah.

It soon became clear after making the final release of 1.3.1 that a lot
of people had delayed upgrading (and so testing) until the final release
was made.  We therefore quickly discovered and fixed some important
bugs, and it was decided to make a 1.3.2 release to include these fixes.

The set of changes from 1.3.1 to 1.3.2 is much smaller than with
previous releases, and entirely bug fixes rather than any new features.
It should therefore be a very easy and safe upgrade.  The fixes made
vary in severity, but there are some pretty important ones, so I would
encourage everyone to make this step as soon as possible.  I don't
anticipate many changes between 1.3.2-rc1 and the final release, so
please test this release candidate rather than waiting.

I also don't expect there to be another "bug fix" release in the near
future: the next one will be 1.4.0 with all the new features and API
changes that are planned.  It's therefore doubly important that
1.3.2-rc1 gets thoroughly tested so that we can rely on 1.3.2 being
stable as it will be around for a while.

Thanks

Kieran



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

[Lou Cypher]

I'm pleased to see the updates, and the soon to be released 1.3.2; recompiling
with rc1 an application I have with 1.3.1 remembers me of a tiny issue, that I
faced even in previous releases (and kept being so tiny I always forgot to
report...).

I'm using
  #define  NO_SYS 1
  #define  SYS_LIGHTWEIGHT_PROT 1
and in sys.h I always get complaints from the compiler about sys_prot_t, as
unknown symbol.
Delving into sources it looks like line 78, sys.h:
  #include "arch/sys_arch.h"
should be included anyway, not just when NO_SYS is undefined; with that change
in fact, my code gets compiled silently.
Did I spot the right thing, or am I possibly running with unexpected #defines?

Lou

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium


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

[JamminJimP]

Lou,

This has been encountered before and there is a workaround: just define
the SYS_ARCH_PROTECT() and SYS_ARCH_UNPROTECT() macros in your
lwipopts.h. This avoids the sys_prot_t type being parsed altogether.

-------------------------------
#define NO_SYS 1

#include "ei_di_in.h"  // prototype for setintlvl() function

// using int masking (no mutexes, etc)
#define SYS_LIGHTWEIGHT_PROT 1  

#define SYS_ARCH_DECL_PROTECT(lev) int lev;
// Define SYS_ARCH_PROTECT to mask just ETH0 interrupts
#define SYS_ARCH_PROTECT(lev) lev = setintlvl(2);
#define SYS_ARCH_UNPROTECT(lev) setintlvl(lev);
----------------------------------

See this thread in the archives for more background:

http://lists.gnu.org/archive/html/lwip-devel/2009-03/msg00017.html
 
Hope this helps!

- Jim
__

James M. Pettinato, Jr.
Software Engineer
E: jim.pettinato@... | P: 814 898 5250

FMC Technologies Measurement Solutions Inc.
1602 Wagner Avenue | Erie PA | 16510 USA
Phone: [phone] | Fax: [phone]
www.fmctechnologies.com

 

-----Original Message-----
From: lwip-users-bounces+jim.pettinato=fmcti.com@...
[mailto:lwip-users-bounces+jim.pettinato=fmcti.com@...] On Behalf
Of Lou Cypher
Sent: Friday, October 30, 2009 10:52 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwIP 1.3.2-rc1 released

I'm pleased to see the updates, and the soon to be released 1.3.2;
recompiling with rc1 an application I have with 1.3.1 remembers me of a
tiny issue, that I faced even in previous releases (and kept being so
tiny I always forgot to report...).

I'm using
  #define  NO_SYS 1
  #define  SYS_LIGHTWEIGHT_PROT 1
and in sys.h I always get complaints from the compiler about sys_prot_t,
as unknown symbol.
Delving into sources it looks like line 78, sys.h:
  #include "arch/sys_arch.h"
should be included anyway, not just when NO_SYS is undefined; with that
change in fact, my code gets compiled silently.
Did I spot the right thing, or am I possibly running with unexpected
#defines?

Lou

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on
your desktop!
Check it out at http://www.inbox.com/marineaquarium


_______________________________________________
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

Shouldn't we add a news item for this on
http://savannah.nongnu.org/projects/lwip/ ?

Simon


Kieran Mansley wrote:

> I've just made a release of lwIP-1.3.2-rc1 by tagging the CVS tree with
> the STABLE-1_3_2-RC1 tag, and uploading zip snapshots to savannah.
>
> It soon became clear after making the final release of 1.3.1 that a lot
> of people had delayed upgrading (and so testing) until the final release
> was made.  We therefore quickly discovered and fixed some important
> bugs, and it was decided to make a 1.3.2 release to include these fixes.
>
> The set of changes from 1.3.1 to 1.3.2 is much smaller than with
> previous releases, and entirely bug fixes rather than any new features.
> It should therefore be a very easy and safe upgrade.  The fixes made
> vary in severity, but there are some pretty important ones, so I would
> encourage everyone to make this step as soon as possible.  I don't
> anticipate many changes between 1.3.2-rc1 and the final release, so
> please test this release candidate rather than waiting.
>
> I also don't expect there to be another "bug fix" release in the near
> future: the next one will be 1.4.0 with all the new features and API
> changes that are planned.  It's therefore doubly important that
> 1.3.2-rc1 gets thoroughly tested so that we can rely on 1.3.2 being
> stable as it will be around for a while.
>
> Thanks
>
> 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

[Lou Cypher]

Hi Jim,

> See this thread in the archives for more background:
>
> http://lists.gnu.org/archive/html/lwip-devel/2009-03/msg00017.html
>  
> Hope this helps!

Thanks, that helps yes, and avoids patching the lwIP sources, as I'm doing on
every new release I include in my project (...)

Though there's something needed on lwIP's side, or the conditionals on lines
151...195 of sys.h
------------------------------------
  #ifndef SYS_ARCH_PROTECT
  #if SYS_LIGHTWEIGHT_PROT
  ...
  #else
  ...
  #endif /* SYS_LIGHTWEIGHT_PROT */
  #endif /* SYS_ARCH_PROTECT */
------------------------------------
would be there for no use.


Lou

____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!


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

[Chris Strahm]

re: lwIP [RAW]

The TCP Push function and how it is used is not clear.  Let's say I am
transferring 1MB block of data.   There are hundreds of calls to TCP_WRITE.
Should I be using TCP_WRITE_FLAG_MORE on any of them?  What effect will it
have?

Thanks,  Chris.




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

[David Empson]

"Chris Strahm" <cstrahm@...> wrote:
> re: lwIP [RAW]
>
> The TCP Push function and how it is used is not clear.  Let's say I am
> transferring 1MB block of data.   There are hundreds of calls to
> TCP_WRITE.
> Should I be using TCP_WRITE_FLAG_MORE on any of them?  What effect will it
> have?

The purpose of the PSH mechanism is to tell the TCP/IP stack in the sending
and receiving stations not to wait for any more data and to deliver the data
as soon as possible.

By default, each call to tcp_write() will result in the last segment of data
written having the PSH flag set. This will appear in the corresponding
packet when it is transmitted.

If you set TCP_WRITE_FLAG_MORE, then LWIP will not set the PSH flag on any
segment generated by that call to tcp_write(). You would generally do this
if you are expecting to write more data almost immediately, e.g. if you are
making multiple tcp_write() calls which are gathering data from separate
buffers. By not setting TCP_WRITE_FLAG_MORE on the last call to tcp_write(),
the last segment will have the PSH flag.

If you never set TCP_WRITE_FLAG_MORE, all your tcp_write() calls will result
in a packet with the PSH flag set, though several short writes may be
combined into a single segment, if they are done quickly enough relative to
calls to tcp_output(). You can't assume there will be a one-to-one
relationship between tcp_write() calls and packets with the PSH flag.

If you always set TCP_WRITE_FLAG_MORE, no packets will have the PSH flag
set, and both the transmit and receive sides may delay delivery of data
while waiting for more (e.g. to completely fill a segment).

As far as I can see, LWIP pays no further attention to the PSH flag for
transmit - it is simply passed through to the receiver. This is arguably a
bug, as the absence of PSH in a non-full segment should make LWIP wait for
more data, and its presence should force the opposite behaviour.

Since LWIP transmission is managed by tcp_output(), an application using the
raw API has direct control over when transmission is initiated, so this is
probably not a significant issue. The PSH flag is mainly there for the
benefit of the receiver.

On the receive side, LWIP only pays attention to PSH in the sockets API. It
isn't significant for the raw API due to the manner in which LWIP delivers
receive data to the application. I'm not sure how netconn should deal with
it (if at all).

Summary: given the current LWIP implementation of PSH, the use of
TCP_WRITE_FLAG_MORE is only significant if the receiving station is likely
to pay attention to the PSH flag.



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

[Chris Strahm]

Thanks for your response David.  You sound like you know this stuff well.

The reason I asked was because I could not see any difference.  The tests I
am running right now are with my custom TCP protocol with send/rcve 4MB data
blocks.  I get about 2.2MB/sec transfer rates right now.  I've tried
tcp_write with and without PUSH on every call and could not see more than
about 1% difference in speed.  I also tried with and without tcp_output
after every tcp_write, and didn't see much difference either.   I guess if
everything just seems to keep working no matter what I set, I should be
happy.

Like you say, the other side is probably not treating the packets much
differently.  This is my Windows app and I am using blocking mode with
multiple threads.  Not sure there is any control over how Winsock handles
PUSH at the app level, but it sure looks like it doesn't really matter
anyway.  The data comes in and goes out just fine.

Thanks, Chris.




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

[Chris Strahm]

A specific question about tcp_write() failing:

The normal check for space before calling tcp_write() seems to be:  SendLen
< tcp_sndbuf(pcb)

Which I assume checks to see if there is space enough in the output tcp
queue.

If this passes, then how would tcp_write ever fail with an err_mem result?

Does this change if COPY(0) or COPY(1) is used for the apiflags?

In other words, could memory still be required for data copy that is not
checked by the tcp sndbuf queue space.

If so, is there a check to test for available mem to copy data?

Thanks,  Chris.




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

> In other words, could memory still be required for data copy that is not
> checked by the tcp sndbuf queue space.

Yes. That's because tcp_sndbuf() tests against a counter variable that can be configured to any size in lwipopts.h. However, the memory needed to enqueue a segment can be configured in lwipopts.h, too. If these values don't match, tcp_write() can return ERR_MEM although the sndbuf limit isn't reached yet.

> If so, is there a check to test for available mem to copy data?

That's hard: depending on whether you copy data or not, you need a PBUF_RAM or PBUF_ROM pbuf. In addition to that, you need one struct tcp_seg. These come from the corresponding memp pools, but there is no default way (aside from looking at the stats, maybe) to know if tcp_write will fail or not.

However, this is just the way lwIP is designed: your application code just has to cope with tcp_write failing, that's all :-)

Simon
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


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

[Bill Auerbach]

It's a bit wasteful, but could he pre-allocate what tcp_write would do when
copy is enabled, if it passes, free the memory and then call tcp_write.  If
the pre-allocate fails, it would have in tcp_write also.

Is there a way to allocate a pbuf with a mem_malloced payload that the stack
knows to mem_free when it's done?  If so, he could mem_malloc and copy
himself and let the stack free it up.

Bill

>-----Original Message-----
>From: lwip-users-bounces+bauerbach=arrayonline.com@...
>[mailto:lwip-users-bounces+bauerbach=arrayonline.com@...] On
>Behalf Of Simon Goldschmidt
>Sent: Monday, November 09, 2009 1:35 AM
>To: Chris Strahm; Mailing list for lwIP users
>Subject: Re: [lwip-users] TCP_WRITE [Raw]
>
>
>> In other words, could memory still be required for data copy that is
>not
>> checked by the tcp sndbuf queue space.
>
>Yes. That's because tcp_sndbuf() tests against a counter variable that
>can be configured to any size in lwipopts.h. However, the memory needed
>to enqueue a segment can be configured in lwipopts.h, too. If these
>values don't match, tcp_write() can return ERR_MEM although the sndbuf
>limit isn't reached yet.
>
>> If so, is there a check to test for available mem to copy data?
>
>That's hard: depending on whether you copy data or not, you need a
>PBUF_RAM or PBUF_ROM pbuf. In addition to that, you need one struct
>tcp_seg. These come from the corresponding memp pools, but there is no
>default way (aside from looking at the stats, maybe) to know if
>tcp_write will fail or not.
>
>However, this is just the way lwIP is designed: your application code
>just has to cope with tcp_write failing, that's all :-)
>
>Simon
>--
>GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
>
>_______________________________________________
>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

[Bill Auerbach]

David, this is another great write-up that I think would benefit all by
being in the Wiki!  This is a good explanation here of something that I
eventually needed to learn about when sending large data blocks.

Bill

>-----Original Message-----
>From: lwip-users-bounces+bauerbach=arrayonline.com@...
>[mailto:lwip-users-bounces+bauerbach=arrayonline.com@...] On
>Behalf Of David Empson
>Sent: Sunday, November 08, 2009 5:58 PM
>To: Chris Strahm; Mailing list for lwIP users
>Subject: Re: [lwip-users] TCP_WRITE_FLAG_MORE
>
>"Chris Strahm" <cstrahm@...> wrote:
>> re: lwIP [RAW]
>>
>> The TCP Push function and how it is used is not clear.  Let's say I am
>> transferring 1MB block of data.   There are hundreds of calls to
>> TCP_WRITE.
>> Should I be using TCP_WRITE_FLAG_MORE on any of them?  What effect
>will it
>> have?
>
>The purpose of the PSH mechanism is to tell the TCP/IP stack in the
>sending
>and receiving stations not to wait for any more data and to deliver the
>data
>as soon as possible.
>
>By default, each call to tcp_write() will result in the last segment of
>data
>written having the PSH flag set. This will appear in the corresponding
>packet when it is transmitted.
>
>If you set TCP_WRITE_FLAG_MORE, then LWIP will not set the PSH flag on
>any
>segment generated by that call to tcp_write(). You would generally do
>this
>if you are expecting to write more data almost immediately, e.g. if you
>are
>making multiple tcp_write() calls which are gathering data from separate
>buffers. By not setting TCP_WRITE_FLAG_MORE on the last call to
>tcp_write(),
>the last segment will have the PSH flag.
>
>If you never set TCP_WRITE_FLAG_MORE, all your tcp_write() calls will
>result
>in a packet with the PSH flag set, though several short writes may be
>combined into a single segment, if they are done quickly enough relative
>to
>calls to tcp_output(). You can't assume there will be a one-to-one
>relationship between tcp_write() calls and packets with the PSH flag.
>
>If you always set TCP_WRITE_FLAG_MORE, no packets will have the PSH flag
>set, and both the transmit and receive sides may delay delivery of data
>while waiting for more (e.g. to completely fill a segment).
>
>As far as I can see, LWIP pays no further attention to the PSH flag for
>transmit - it is simply passed through to the receiver. This is arguably
>a
>bug, as the absence of PSH in a non-full segment should make LWIP wait
>for
>more data, and its presence should force the opposite behaviour.
>
>Since LWIP transmission is managed by tcp_output(), an application using
>the
>raw API has direct control over when transmission is initiated, so this
>is
>probably not a significant issue. The PSH flag is mainly there for the
>benefit of the receiver.
>
>On the receive side, LWIP only pays attention to PSH in the sockets API.
>It
>isn't significant for the raw API due to the manner in which LWIP
>delivers
>receive data to the application. I'm not sure how netconn should deal
>with
>it (if at all).
>
>Summary: given the current LWIP implementation of PSH, the use of
>TCP_WRITE_FLAG_MORE is only significant if the receiving station is
>likely
>to pay attention to the PSH flag.
>
>
>
>_______________________________________________
>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

Bill Auerbach wrote:
> It's a bit wasteful, but could he pre-allocate what tcp_write would do when
> copy is enabled, if it passes, free the memory and then call tcp_write.  If
> the pre-allocate fails, it would have in tcp_write also.
>  
So why bother with trying? tcp_write failing will tell you the same.
> Is there a way to allocate a pbuf with a mem_malloced payload that the stack
> knows to mem_free when it's done?  If so, he could mem_malloc and copy
> himself and let the stack free it up.
>  
Enqueueing pre-allocated pbufs (which essentially is what you suggest)
is a thing I'd like to have in the future, but it's not supported right
now. Besides, it would not solve this problem as we might be running out
of other resources (e.g. struct tcp_seg) as well.


Simon


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

[Ben Hastings-2]

Simon Goldschmidt <goldsimon@...> wrote:


> In other words, could memory still be required for data copy that is not
> checked by the tcp sndbuf queue space.

Yes. That's because tcp_sndbuf() tests against a counter variable that can
be configured to any size in lwipopts.h. However, the memory needed to
enqueue a segment can be configured in lwipopts.h, too. If these values
don't match, tcp_write() can return ERR_MEM although the sndbuf limit
isn't reached yet.

> If so, is there a check to test for available mem to copy data?

That's hard: depending on whether you copy data or not, you need a
PBUF_RAM or PBUF_ROM pbuf. In addition to that, you need one struct
tcp_seg. These come from the corresponding memp pools, but there is no
default way (aside from looking at the stats, maybe) to know if tcp_write
will fail or not.

However, this is just the way lwIP is designed: your application code just
has to cope with tcp_write failing, that's all :-)

Simon
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


_______________________________________________
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

What's the time plan on 1.3.2 final? There haven't been any serious bug
reports since then, I think. On the other hand, I'm not sure how well it
has really been tested as we didn't have a news item or a ZIP to download...

Simon


Kieran Mansley wrote:

> I've just made a release of lwIP-1.3.2-rc1 by tagging the CVS tree with
> the STABLE-1_3_2-RC1 tag, and uploading zip snapshots to savannah.
>
> It soon became clear after making the final release of 1.3.1 that a lot
> of people had delayed upgrading (and so testing) until the final release
> was made.  We therefore quickly discovered and fixed some important
> bugs, and it was decided to make a 1.3.2 release to include these fixes.
>
> The set of changes from 1.3.1 to 1.3.2 is much smaller than with
> previous releases, and entirely bug fixes rather than any new features.
> It should therefore be a very easy and safe upgrade.  The fixes made
> vary in severity, but there are some pretty important ones, so I would
> encourage everyone to make this step as soon as possible.  I don't
> anticipate many changes between 1.3.2-rc1 and the final release, so
> please test this release candidate rather than waiting.
>
> I also don't expect there to be another "bug fix" release in the near
> future: the next one will be 1.4.0 with all the new features and API
> changes that are planned.  It's therefore doubly important that
> 1.3.2-rc1 gets thoroughly tested so that we can rely on 1.3.2 being
> stable as it will be around for a while.
>
> Thanks
>
> 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

[Kieran Mansley]

On Wed, 2009-11-11 at 17:45 +0100, goldsimon@... wrote:
> What's the time plan on 1.3.2 final? There haven't been any serious bug
> reports since then, I think.

Agreed, hopefully I'll get some time this week to sort things out.

> On the other hand, I'm not sure how well it
> has really been tested as we didn't have a news item

oops, forgot about that.

> or a ZIP to download...

Should be: there is for me at least when I follow the download link at
savannah.

Kieran



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

Kieran Mansley wrote:
> On Wed, 2009-11-11 at 17:45 +0100, goldsimon@... wrote:
>  
>> What's the time plan on 1.3.2 final? There haven't been any serious bug
>> reports since then, I think.
>>    
>
> Agreed, hopefully I'll get some time this week to sort things out.
>  
Great!

>> On the other hand, I'm not sure how well it
>> has really been tested as we didn't have a news item
>>    
>
> oops, forgot about that.
>
>  
>> or a ZIP to download...
>>    
>
> Should be: there is for me at least when I follow the download link at
> savannah.
>  

Hmm, indeed. I seem to have overlooked it, sorry.

Simon


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