Page 2 of 3

Re: LWIP improvements  Topic is solved

Posted: Tue Dec 31, 2019 11:32 pm
by geebee
OK, attached are some changes:
- makefile allows users to pull in different LWIP filesets (first version, i.e. does not require any existing project to change)
- safety/clarity changes to static options
- my fixes for lwipthread + a subset of steved changes (I left out anything multicast, plus PPPOE which as it was gives a warning for PPPOE_SUPPORT not being defined)

These have no header/interface changes, and should all be drop in compatible with existing code.

Feel free to change and also to add comments as you see fit. Note that if you want to remove the default in lwip.mk (which I'm all for, just leave empty), you'll need to manually add in HTTPDFILES in projects that use it (such as some of the demos).

GB

Re: LWIP improvements

Posted: Sun Jan 12, 2020 9:05 am
by Giovanni
Hi,

I merged the patch in trunk, 19.1 and 18.2. The patch also fixed the old bug #1009.

I wish to merge also the latest lwIP 2.1.2, steved, is that just a drop-in replacements or there are fixes to be applied?

About a native IP stack, it is something I always wanted to do and it would go in the direction of completing the ChibiOS project offering, however I lack experience, it would start from the beginning...

Giovanni

Re: LWIP improvements

Posted: Mon Jan 13, 2020 9:35 am
by steved
Giovanni wrote:Hi,
I wish to merge also the latest lwIP 2.1.2, steved, is that just a drop-in replacements or there are fixes to be applied?

I've been using 2.1.2 for some time now; it just dropped in. There used to be a required mod to sockets.c to change the context of a semaphore-related call; this is no longer required.
Giovanni wrote:About a native IP stack, it is something I always wanted to do and it would go in the direction of completing the ChibiOS project offering, however I lack experience, it would start from the beginning...

20 years ago I had thoughts of writing my own IP stack, then read the estimate that it was two man-years work. Now we have IPv6......

That's why I'm interested in the FreeRTOS-written stack; it's the first open source free-to-use alternative to lwIp that I've seen.

Re: LWIP improvements

Posted: Fri Jan 17, 2020 2:18 am
by geebee
Here are the rest of the changes, which probably don't need to be merged in the stable releases. However, as long as the lwipthread_opts_t struct is memset to zero before initializing, any existing project will still work without any changes.

Let me know if you have any questions, and again feel free to change things/add comments.

I tried building the demos in trunk using LWIP. RT-STM32F107-OLIMEX_P107-LWIP builds, but heads up that the other two have some fatfs issue, where the conf file appears to be outdated.

I don't know much about alternative stacks to LWIP (or about LWIP for that matter), so I'm not of much help there, but I'll definitely help out testing whatever you end up with :)

GB

Re: LWIP improvements

Posted: Sun Apr 19, 2020 8:03 am
by Giovanni
geebee wrote:Here are the rest of the changes, which probably don't need to be merged in the stable releases. However, as long as the lwipthread_opts_t struct is memset to zero before initializing, any existing project will still work without any changes.

Let me know if you have any questions, and again feel free to change things/add comments.

I tried building the demos in trunk using LWIP. RT-STM32F107-OLIMEX_P107-LWIP builds, but heads up that the other two have some fatfs issue, where the conf file appears to be outdated.

I don't know much about alternative stacks to LWIP (or about LWIP for that matter), so I'm not of much help there, but I'll definitely help out testing whatever you end up with :)

GB


Hi,

Patch merged with minimal changes, back-ported to 20.3.x too.

Giovanni

Re: LWIP improvements

Posted: Fri May 29, 2020 4:56 pm
by mikenick42
Hi all,

I'm curious about what happened with #7 from geebee's driver. I'm trying to get a PTP driver working with multicast and when I add the NETIF_FLAG_IGMP flag to lwip_thread.c, everything seems to work. It looks like you may be working on a more flexible solution to the problem though, and I would be much happier just setting LWIP_IGMP to 1 in lwipopts rather than patching the source.

Thanks,
Mike

Re: LWIP improvements

Posted: Fri May 29, 2020 5:57 pm
by Giovanni
Probably it got lost in the noise, feel free to propose a patch over the -current- trunk code.

Giovanni

Re: LWIP improvements

Posted: Sat May 30, 2020 4:34 pm
by mikeprotts
I've not been able to move to 2.1.2 yet, but I plan to this week. Once it's working, it will test a heavy load on an http server using netconn api and mqtt client.

There are three changes for me.

First is that the mqtt_client structure has moved to mqtt_priv.h, which breaks my build unless I include that - but I'll see if I can work out a better way. I think this is an LWIP bug as mqtt_client_t is required for static allocation (that's assuming including the extra header is not good practice). The example code uses dynamic allocation.

Second is my system crashes unless I increase allocated stack to the tcpip and my application threads. I don't think it's a huge change, but as I've tuned my spare stack, it's causing a problem. It seems to be a surprisingly large increase, maybe 240 bytes for one thread, 40 for the others, but I've not fully checked yet.

The LWIP stats_display seems to be messed up, with pool allocations all showing as "hu", and that makes it tricky to tune the pools. I don't know if it's a bug in LWIP or my LWIP_PLATFORM_DIAG implementation, and I suspect the latter or otherwise it should have been spotted by others. It's something I use to tune the system, so I need to fix this. I know stats.c changed from using U32_F to MEM_SIZE_F so probably just needs a #define somewhere. I use the serial shell as the diagnostics area.

Mike

p.s. The reason I've used my own simple web server is a requirement for "chunked" encoding and not using any files as it's generated data. Longer term I hope to be able to change over.

Re: LWIP improvements

Posted: Sun May 31, 2020 10:16 am
by mikeprotts
Actually I think the stats problem is both ChibiiOS restriction & lwip bug.

The code in stats.c:
void
stats_display_mem(struct stats_mem *mem, const char *name)
{
LWIP_PLATFORM_DIAG(("\nMEM %s\n\t", name));
LWIP_PLATFORM_DIAG(("avail: %"MEM_SIZE_F"\n\t", mem->avail));
LWIP_PLATFORM_DIAG(("used: %"MEM_SIZE_F"\n\t", mem->used));
LWIP_PLATFORM_DIAG(("max: %"MEM_SIZE_F"\n\t", mem->max));
LWIP_PLATFORM_DIAG(("err: %"STAT_COUNTER_F"\n", mem->err));
}


should be using STAT_COUNTER_F for consistency (I'll report this to LWIP as a bug):
void
stats_display_mem(struct stats_mem *mem, const char *name)
{
LWIP_PLATFORM_DIAG(("\nMEM %s\n\t", name));
LWIP_PLATFORM_DIAG(("avail: %"STAT_COUNTER_F"\n\t", mem->avail));
LWIP_PLATFORM_DIAG(("used: %"STAT_COUNTER_F"\n\t", mem->used));
LWIP_PLATFORM_DIAG(("max: %"STAT_COUNTER_F"\n\t", mem->max));
LWIP_PLATFORM_DIAG(("err: %"STAT_COUNTER_F"\n", mem->err));
}


and then if I use:
#define LWIP_STATS_LARGE 1


it works fine. However, with:
#define LWIP_STATS_LARGE 0


all the stats become "hu". As I use the ChibiOS chsnprint function, I checked:
os/hal/lib/streams/chprintf.c

and h is not a supported length modifier (only l and L are). So we can either accept the limitation and require the LWIP_STATS_LARGE 1 setting, or implement a h (short int) modifier. I'll see if it's easy to add support, but I wouldn't consider this a bug as it's as designed in ChibiOS.

Mike

Re: LWIP improvements

Posted: Sun May 31, 2020 11:51 am
by mikeprotts
stats.c problem now lwip #58467
mqtt.h problem now lwip #58648

Mike