eclipse-threadx / netxduo

Eclipse ThreadX - NetXDuo is an advanced, industrial-grade TCP/IP network stack designed specifically for deeply embedded real-time and IoT applications
https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/netx-duo/index.md
MIT License
230 stars 131 forks source link

_nx_ip_interface_status_check blocks undefinitely #184

Closed mapellil closed 7 months ago

mapellil commented 1 year ago

Describe the bug Calling the nx_ip_interface_status_check(,,, needed_status, timeout) with timeout>0 in case the needed_status condition is not meet the API block indefinitely. The same apply for nx_ip_status_check() API. The issue seems to come from the tx_mutex_get(&(ip_ptr -> nx_ip_protection), TX_WAIT_FOREVER); called within the above APIs.

To Reproduce eg. in case of wifi interface after having entered a wrong password the call to nx_ip_status_check(&IpInstance, NX_IP_INITIALIZE_DONE | NX_IP_LINK_ENABLED | NX_IP_INTERFACE_LINK_ENABLED, &actual_status, NX_IP_PERIODIC_RATE*5); will block undefinitely.

Expected behavior the nx_ip_status_check(), when called with timeout>0, should return if timeout expire

TiejunMS commented 1 year ago

What platform did you use? One solution is to move WIFI connect from network driver to the application.

mapellil commented 1 year ago

Thanks for the suggestion, however i do not expect to find a blocking call tx_mutex_get(&(ip_ptr -> nx_ip_protection), TX_WAIT_FOREVER) within a timed API nx_ip_status_check() because, if for any reason the API internal mutex is not released the API also become blocking regardless of the timer specified in the args. My platform is https://www.st.com/en/evaluation-tools/steval-stwinbx1.html. Regards

TiejunMS commented 7 months ago

In Azure RTOS, cost on the mutex waiting is not part of timeout. So it is not likely to change the logic here.