Laczen commented on PR #15962: URL: https://github.com/apache/nuttx/pull/15962#issuecomment-2713301580
> > @Laczen: @tmedicci @cederom the first problem is caused by udp_input, it also appears when both network interfaces are up before starting the client but the server is not running. The problem is that udp_input tries to send a ICMP response that there is nothing listening on the udp port (ICMP is enabled for wlan0). The device cannot send a ICMP response (it is a ipv6 device). The logic in `udp_input.c` does not take into account this possibility. > > Hmm, so there is no initial handshake with the server to check if the communication can follow? Or the check is performed on one interface and error information is sent over another interface? Do I get this right? Two interfaces cannot be used at the same time? Is this a limitation of the ESP hardware/implementation or the espstack design limitation? What would be the best / working solution? Using different channels for different interfaces? Maybe @fdcavalcanti could help here? :-) There is a bug in `udp_input.c` that does not correctly support Kconfig options. UDP allows sending back a message that there is no one listening on the requested port and this is not handled correctly. The handling of icmp(v6) responses is not something I have been studying up to now since there are some remarks about icmpv6 for sixlowpan (the documentation states `The current ICMPv6 and neighbor- related logic only works with Ethernet MAC`) so I have just disabled it. Up to now I have found quite some unhandled situations in the network code when using more elaborate setups (e.g. wlan (net80211 network supporting ipv6 and ipv4) and espnow (ipv6 over sixlowpan, over wireless packet radio over espnow). These are bugs that are present in the network code and not related to this PR. In general I have the feeling that the current state of the code is overestimated (especially in the sixlowpan area) and that there is lots of room for improvement. Many parts are broken and people are happy that it works in their setup. IMO NuttX is great and the addition of espnow will allow setting up a network of nodes for e.g. plant monitoring, home automation, ... based on cheap and readily available hardware. However NuttX is far from perfect (e.g. coap support) and there will be limitations imposed by the hardware (e.g. the same wifi channel should be used when trying to make a node that has both wifi and espnow connectivity). Limiting the setup/usability can be done but I would rather not do this from the start. I have added a warning to the documentation about combined use of wifi and espnow. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
