Dirk Ziegelmeier | 26 Jun 22:38 2016
Picon

lwIP 2.0.0 documentation

Hello all,

the lwIP documentation on the web was finally updated to 2.0.0:

http://www.nongnu.org/lwip/

Ciao
Dirk

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Dirk Ziegelmeier | 25 Jun 20:19 2016
Picon

[patch #9034] Use stdint.h and inttypes.h in lwip/arch.h?

URL:
  <http://savannah.nongnu.org/patch/?9034>

                 Summary: Use stdint.h and inttypes.h in lwip/arch.h?
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dziegel
            Submitted on: Sat 25 Jun 2016 06:19:02 PM GMT
                Category: Platform ports
                Priority: 5 - Normal
                  Status: Need Info
                 Privacy: Public
             Assigned to: dziegel
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

How about adding the following to lwip/arch.h? Would it be OK to use c99
headers?

/* Define generic types used in lwIP */
#ifndef LWIP_NO_STDINT_H
#include <stdint.h>
typedef uint8_t   u8_t;
typedef int8_t    s8_t;
typedef uint16_t  u16_t;
typedef int16_t   s16_t;
typedef uint32_t  u32_t;
typedef int32_t   s32_t;
#endif

/* Define (sn)printf formatters for these lwIP types */
#ifndef LWIP_NO_INTTYPES_H
#include <inttypes.h>
#define X8_F  "02"PRIx8
#define U16_F PRIu16
#define S16_F PRId16
#define X16_F PRIx16
#define U32_F PRIu32
#define S32_F PRId32
#define X32_F PRIx32
#define SZT_F PRIuMAX
#endif

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Dirk Ziegelmeier | 24 Jun 21:27 2016
Picon

[bug #48308] Warnings in PPP van Jacobsen code when compiling with clang

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

                 Summary: Warnings in PPP van Jacobsen code when compiling
with clang
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dziegel
            Submitted on: Fri 24 Jun 2016 07:27:54 PM GMT
                Category: PPP
                Severity: 3 - Normal
              Item Group: Compiler Warning
                  Status: None
                 Privacy: Public
             Assigned to: gradator
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

clang -g -Wall -DLWIP_DEBUG -pedantic -Werror -Wparentheses -Wsequence-point
-Wswitch-default -Wextra -Wundef -Wshadow -Wpointer-arith -Wcast-qual
-Wc++-compat -Wwrite-strings -Wold-style-definition -Wcast-align
-Wmissing-prototypes -Wredundant-decls -Wnested-externs -Wno-address
-Wunreachable-code -Wuninitialized -Wno-format -I. -I../../../..
-I../../../../../lwip/src/include -I../../../../ports/unix/include -c
../../../../../lwip/src/netif/ppp/vj.c

../../../../../lwip/src/netif/ppp/vj.c:165:28: error: cast from 'struct ip_hdr
*' to 'u32_t *' (aka 'unsigned int *') increases required alignment from 1 to
4 [-Werror,-Wcast-align]
  th = (struct tcp_hdr *)&((u32_t*)ip)[ilen];
                           ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:203:11: error: cast from 'struct
tcp_hdr *' to 'u32_t *' (aka 'unsigned int *') increases required alignment
from 1 to 4 [-Werror,-Wcast-align]
      || *(u32_t*)th != ((u32_t*)&cs->cs_ip)[IPH_HL(&cs->cs_ip)]) {
          ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:203:26: error: cast from 'struct ip_hdr
*' to 'u32_t *' (aka 'unsigned int *') increases required alignment from 1 to
4 [-Werror,-Wcast-align]
      || *(u32_t*)th != ((u32_t*)&cs->cs_ip)[IPH_HL(&cs->cs_ip)]) {
                         ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:224:15: error: cast from 'struct
tcp_hdr *' to 'u32_t *' (aka 'unsigned int *') increases required alignment
from 1 to 4 [-Werror,-Wcast-align]
          && *(u32_t*)th == ((u32_t*)&cs->cs_ip)[IPH_HL(&cs->cs_ip)]) {
              ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:224:30: error: cast from 'struct ip_hdr
*' to 'u32_t *' (aka 'unsigned int *') increases required alignment from 1 to
4 [-Werror,-Wcast-align]
          && *(u32_t*)th == ((u32_t*)&cs->cs_ip)[IPH_HL(&cs->cs_ip)]) {
                             ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:254:29: error: cast from 'struct ip_hdr
*' to 'u32_t *' (aka 'unsigned int *') increases required alignment from 1 to
4 [-Werror,-Wcast-align]
  oth = (struct tcp_hdr *)&((u32_t*)&cs->cs_ip)[ilen];
                            ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:268:8: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
  if (((u16_t*)ip)[0] != ((u16_t*)&cs->cs_ip)[0]
       ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:268:27: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
  if (((u16_t*)ip)[0] != ((u16_t*)&cs->cs_ip)[0]
                          ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:269:11: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
      || ((u16_t*)ip)[3] != ((u16_t*)&cs->cs_ip)[3]
          ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:269:30: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
      || ((u16_t*)ip)[3] != ((u16_t*)&cs->cs_ip)[3]
                             ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:270:11: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
      || ((u16_t*)ip)[4] != ((u16_t*)&cs->cs_ip)[4]
          ^~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:270:30: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
      || ((u16_t*)ip)[4] != ((u16_t*)&cs->cs_ip)[4]
                             ^~~~~~~~~~~~~~~~~~
../../../../../lwip/src/netif/ppp/vj.c:591:8: error: cast from 'struct ip_hdr
*' to 'u16_t *' (aka 'unsigned short *') increases required alignment from 1
to 2 [-Werror,-Wcast-align]
  bp = (u16_t*) &cs->cs_ip;
       ^~~~~~~~~~~~~~~~~~~
13 errors generated.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
chrysn | 23 Jun 17:00 2016
Picon

[bug #48300] Private mempools allocate foreign memory

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

                 Summary: Private mempools allocate foreign memory
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: chrysn
            Submitted on: Thu 23 Jun 2016 03:00:05 PM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

The memory access to pools declared using LWIP_MEMPOOL_DECLARE can be flawed
when MEM_ALIGNMENT is used. This was observed on an ARM Cortex device on which
MEM_ALIGNMENT was set to 8 for reasons outside the architecture. Two pools are
allocated in parallel, and memset'ing what was obtained from one of the pools
wiped the tab of the other.

I suppose this is because memp_memory_*_base itself is an unaligned u8_t
array, but in memp_init_pool, the address of desc->base gets aligned and thus
potentially increased; fully accessing the last element would then go to an
area not reserved to the respective _base.

I'll see whether I can submit a viable patch.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Dirk Ziegelmeier | 22 Jun 12:44 2016
Picon

[task #14052] Update doxygen documentation

URL:
  <http://savannah.nongnu.org/task/?14052>

                 Summary: Update doxygen documentation
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dziegel
            Submitted on: Wed 22 Jun 2016 10:44:06 AM GMT
                Category: Documentation
         Should Start On: Wed 22 Jun 2016 12:00:00 AM GMT
   Should be Finished on: Wed 22 Jun 2016 12:00:00 AM GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

1) There are many places in the code where doxygen docs are only partly
added.

2) There should also be different docs for internal and external APIs.
Currently, all functions are documented regardless whether they are intended
to be used in user code or not. Does doxygen provide such a functionality?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Sergio R. Caprile | 18 Jun 18:50 2016
Picon

Re: 2.0.0 Beta2?

On 18/06/2016 01:00 p.m., lwip-devel-request <at> nongnu.org wrote:
> Oh: Dirk has done a good job at working on doxygen, so we will have an 
> up-to-date doc page for the release (http://www.nongnu.org/lwip/) :-))
> 
> ... and: we might have to work on the UPGRADING document to help users 
> upgrading from 1.4.x to 2.0.0 (I've added a bug for this).

I'm teaching a postgraduate course on networking in embedded systems,
and we use lwIP 1.4.1. I'll be glad to collaborate on the docs and with
examples for the RAW API. I've been contributing to the wiki, I can move
that (and ellaborate) to a separate doc or into the sources for doxygen
inclusion; as you prefer.
I will also move to 2.0.x for next year class, so I'll be also happy to
help with the UPGRADING docs and beta test them on my example code for
RAW API.
goldsimon@gmx.de | 17 Jun 22:06 2016
Picon
Picon

2.0.0 Beta2?

Hey all,

2.0.0 Beta1 is nearly 2 months old now and we should move on. 2 months 
are already too long, so the only thing I plan to add for an actual 
release is:
- make TCPIP_CORE_LOCKING the default (todo: implement mutexes for the 
win32 port)
- fix the timing issues (patches #7855, #8712, #8995), only I'm no yet 
sure how to fix this best
- work around the often found link-time issue of the fact that the file 
name 'timers.c' is used by FreeRTOS, too (anyone have a good idea?)

As both is timer-related, any input on this please to patch #8995:
https://savannah.nongnu.org/patch/?8995

I'm open for votes on what else to include into 2.0.0 final, but I'd 
rather throw out 2.0.1 soon instead of delaying 2.0.0 further...

Oh: Dirk has done a good job at working on doxygen, so we will have an 
up-to-date doc page for the release (http://www.nongnu.org/lwip/) :-))

... and: we might have to work on the UPGRADING document to help users 
upgrading from 1.4.x to 2.0.0 (I've added a bug for this).

Cheers,
Simon
Simon Goldschmidt | 17 Jun 22:05 2016
Picon

[bug #48259] UPGRADING is missing 2.0.0 info

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

                 Summary: UPGRADING is missing 2.0.0 info
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Fri 17 Jun 2016 08:05:30 PM GMT
                Category: Documentation
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Erik Ekman | 14 Jun 15:45 2016
Picon
Gravatar

Fuzzing the lwIP stack

Hi all

I have just commited a new app into lwip-contrib/ports/unix/fuzz that helps when testing
the code for handling of unexpected input.

It fits together with an advanced tool called afl or american fuzzy lop
(http://lcamtuf.coredump.cx/afl/) that uses instrumentation to randomize and change data
until as much of the code as possible is tested.

I have added a few valid input packets for it to start with, adding more is welcome. They just
need to have correct mac and IP address so they are accepted by the stack.

I have already found one bug with this tool, and I think it can be very helpful to us.

For more info, here is the README I added:
-------------------------------------------------------------------

Fuzzing the lwIP stack

This directory contains a small app that reads Ethernet frames from stdin and
processes them. It is used together with the 'american fuzzy lop' tool (found
at http://lcamtuf.coredump.cx/afl/) and the sample inputs to test how
unexpected inputs are handled. The afl tool will read the known inputs, and
try to modify them to exercise as many code paths as possible, by instrumenting
the code and keeping track of which code is executed.

Just running make will produce the test program.

Then run afl with:

afl-fuzz -i inputs/<INPUT> -i output ./lwip_fuzz

and it should start working. It will probably complain about CPU scheduler,
set AFL_SKIP_CPUFREQ=1 to ignore it.

The input is split into different subdirectories since they test different
parts of the code, and since you want to run one instance of afl-fuzz on each
core.

When afl finds a crash or a hang, the input that caused it will be placed in
the output directory. If you have hexdump and text2pcap tools installed,
running output_to_pcap.sh <outputdir> will create pcap files for each input
file to simplify viewing in wireshark.

The lwipopts.h file needs to have checksum checking off, otherwise almost every
packet will be discarded because of that. The other options can be tuned to
expose different parts of the code.

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

/Erik
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Simon Goldschmidt | 14 Jun 09:30 2016
Picon

[bug #48220] TCPIP_CORE_LOCKING should be the default

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

                 Summary: TCPIP_CORE_LOCKING should be the default
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Tue 14 Jun 2016 07:30:14 AM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 2.0.0 Beta2
            lwIP version: git head

    _______________________________________________________

Details:

LWIP_TCPIP_CORE_LOCKING should perform much better since grabbing a mutex
should be faster than 2 thread context switches on most platforms. Also,
thread priorites help to schedule which task is served first.

However, we should get people to implement a mutex to prevent priority
inversion.

To do this, we could raise an #error if LWIP_COMPAT_MUTEX is 1. (and we should
implement mutexes for our example ports :)

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Ivan Delamer | 13 Jun 18:28 2016

Re: Question about some bigger changes in LwIP

Hello Jan,

> 1) IPv6 address/prefix auto/configuration and routing is not 
> implemented
> according to RFC. I have investigate it little bit and also compare 
> the
> source with uIP in contiki... and they are doing it right! So please 
> don't
> tell me that we are "light weight", because much more "light weight" 
> stack
> is doing it right.
> Implementation in LwIP is not bad, but naive so it just works in many 
> cases.

You are correct in your analysis. When I put together the first version 
of IPv6 for LwIP, I thought it was better than Contiki (I was a 
contributor/committer there too), but they have definitely worked a lot 
more on it since.

Patches, suggestions, code, bug reports, feedback, are very welcome and 
necessary. The IPv6 code was meant to be a starting point that works in 
most cases, to be improved by the community.

Now I have more kids and less free time to work on this, so it's up to 
anyone who wants to volunteer their time and knowledge to improve it. I 
can give my opinion and commit some patches, but that's about what I can 
offer right now.

Cheers
Ivan

Gmane