DHCP address in lwip

[danielinux]

Hello,

I am preparing a demo for an MQTT library with SSL support, and I was thinking about setting up the IP address automatically at startup using DHCP. I set my lwip configuration accordingly and lwip is capable of getting a valid IP configuration. However, I don't see an official mechanism for an application to retrieve its new configuration, and the netif object is static inside the lwip wrapper.

What would be the best way to poll/read the IP address at the end of the DHCP handshake, from an application that can then properly setup socket communication afterwards? Binding to '0.0.0.0' before the interface is configured does not seem to work well.

Thanks in advance,

Daniele

[Giovanni]

Hi,

I am not very into lwIP, waiting for suggestions

Giovanni

[danielinux]

A possible way could be that lwipInit returns a pointer to the netif being initialized by the thread, so other threads can retrieve information about the network interface. This would work for the case, but it still implies that lwip is bound to a single interface at startup.

A more generic and elegant way would be to initialize the network interface after the generic lwIP initialization, but it would move some of the complexity of IP configuration to the application code, which is now hidden inside the lwipthread.c wrapper.

(On a separate note: I am not at all into lwIP either, at the point that I started coding a replacement many years ago, which eventually did quite well. Have you ever considered providing an option for alternative embedded TCP/IP stacks?)

[Giovanni]

Let's wait for ideas, other people are very involved in lwIP.

Giovanni

[danielinux]

No suggestions yet?

I think it would make sense to have a complete support for dynamic address configuration on ChibiOS IoT clients. If I get some input on how the API should look like, I'd be happy to implement and propose a patch.

[Giovanni]

Hi,

I think it could follow the pattern of the other things in ChibiOS HAL, a configuration structure passed to an initialization function. Could you encode all options in a structure?

Giovanni

[faisal]

(On a separate note: I am not at all into lwIP either, at the point that I started coding a replacement many years ago, which eventually did quite well. Have you ever considered providing an option for alternative embedded TCP/IP stacks?)

What alternative tcp-ip stacks would you recommend?

[danielinux]

Hi,

I think it could follow the pattern of the other things in ChibiOS HAL, a configuration structure passed to an initialization function. Could you encode all options in a structure?

Giovanni

This is how it already works. My issue is that there is no way from the application to tell when/wheather the initialization of the DHCP has been successful to start using sockets, and according to my experiments, lwIP is not smart enough to keep listening sockets across netif config changes.

My proposal is (see a few messages above) that we change the return value from void to a netif pointer in lwIP initialization. This will imply that our TCP/IP support is one-interface only, but it would allow to keep the same code in the apps, except when you need to check for the status of the interface after initiating a DHCP handshake.

If I have a go from you/community, I'll prepare a patch in that direction.

[danielinux]

What alternative tcp-ip stacks would you recommend?

I think that picoTCP would be a good fit. It has several real advantages over lwIP in terms of adherence to protocol standards. Socket API is more complete and the interface is much clearer in general.

I've integrated it into different RTOS's, and I think it would be easy to have it in /ext as alternative to the current stack, with no impact on the existing application software.

[Giovanni]

Interesting, lwip is not exactly easy to use. Do you have use cases with WolfSSL using it?

Giovanni