New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request to add more return values for 'esp_netif_receive'. (IDFGH-9398) #10770
Comments
Hi @Zmmfly Thank you for this feature request, it makes perfect sense (we might even consider it a bugfix, since we should report problems to upper layers, especially when it's not restricted by lwIP types/API, but fully under IDF control). Unrelated to the request, but an idea to explore maybe, since you linked some PPPoS issues with memory. You can also check if this change helps a bit? #10719 (comment) One more note, it might be possible to work around the err_t my_esp_netif_receive(esp_netif_t *esp_netif, void *buffer, size_t len, void *eb)
{
auto *netif_internal = (struct esp_netif_obj*)esp_netif;
auto *related = (struct lwip_peer2peer_ctx*)netif_internal->related_data;
return pppos_input_tcpip(related->ppp, (u8_t *)buffer, len);
} (not recommended, as directly interfacing lwip and hijacking internal structs of |
Hi @david-cermak Regarding the Issue you mentioned (#10719 (comment)), in the current project, which uses PPPoS and can ensure sufficient memory, the same problem still occurs; Yes, I did a similar job, modifying a version of my own: adding return values, multiple retries in the upper level calls after receiving failures, and still failing after reaching the specified number of retries before finally dropping the packet. Finally, in PPPoS high-rate applications, puts uart interrupts into IRAM can only be a workaround in the absence of hardware flow control, the most secure or use hardware flow control. |
Is your feature request related to a problem?
In PPPoS application, if baudrate >= 921600, the data processing speed is less than the data arrival speed; sometimes, 'esp_netif_receive' will return ESP_OK, but actually the reception is not successful, which will cause the PPP link to be lost.
Describe the solution you'd like.
'esp_netif_receive' returns ESP_FAIL or other values for error handling when receiving fails, which will improve stability when hardware flow control pins are not connected and no software flow control.
Describe alternatives you've considered.
pppos_example: Modem Disconnect from PPP Server (IDFGH-8640) #10085 (comment)
Additional context.
The text was updated successfully, but these errors were encountered: