On the old hosting on sourceforge , there are a small number of open issues. What is the status of those issues? Are they all resolved? Did they get transferred to github?
I looked for a few of them in the Github FreeRTOS issues and Github FreeRTOS-Plus-TCP Issues, such as “#183 FreeRTOS+TCP freezes in bad state if connection is reset during send” and “#181 xSTATIC_LIST_ITEM, xSTATIC_MINI_LIST_ITEM and StaticList_t wrong length”. They don’t seem to be in the new issues list.
Thank you.
On the old hosting on sourceforge, there are a small number of open issues. What is the status of those issues? Are they all resolved? Did they get transferred to github?
They got transferred to the new Freertos forum. I am not sure about each of the reported issues.
I looked for a few of them in the Github FreeRTOS issues and Github FreeRTOS-Plus-TCP Issues.
Looking at the issues reported on Github: yes, there is some work to do.
Of course, not all reported issues are real issues: some were solved quietly, some people reported back.
When an issue shows a possible vulnerability, it is treated with the highest possible priority.
“#183 FreeRTOS+TCP freezes in bad state if connection is reset during send”
That is strange: on 2018-12-10 I saw 10 posts, and 1 feature request. But I do not see the issue from Martin Bazley. Yes, the post still deserves an answer, and the function FreeRTOS_send() does need a change!
Did you encounter this problem yourself?
Anyway, thank you for pointing this out. I will report back here.
I wrote PR #561 with the title: “IPv4/Single: Let send() stop blocking after a connection reset”
It repairs the problem mentioned in the old issue #183 on SourceForge.
It never caused a problem in my own applications because I never use long timeouts like portMAX_DELAY.
Thank you for addressing that issue, Hein! I’ll keep watching the PR.
I did not encounter issue #183 myself, but I need to maintain a list of all possible errata for a project, so I’m following up on all the issues.
How about this issue #180 FreeRTOS-TCP arp reply length incorrect from sourceforge, ? It appears someone has written a patch, but I’m not able to test this fix at this time: I can see in the 2021112.00 release that it has not been patched yet, but the good news is it is only a one line change.
Here’s another issue I’m researching: It’s #169 FreeRTOS+TCP select bug. I don’t have a way to test this yet, as I’m still evaluating the FreeRTOS-Plus-TCP for a project, not building yet. It may be a legit error, but there was no follow-up to it at the time. I’ve searched through the present FreeRTOS forum and I can’t find any references to it. The submitter has supplied no patch, though they have a workaround. Any thoughts on this one?
Thank you.
All the open ones were moved to Forum. Please do not use SourceForge for new issues - use this forum or GitHub instead.
HI Guarav,
Thank you for getting back to me. I noticed that issues #181 and #169 are open in sourceforge, but I can not see where they have been moved into the FreeRTOS forum. Can anyone point me to them?
Thank you
I noticed that issues #181 and #169 are open in sourceforge, but I can not see where they have been moved into the FreeRTOS forum
Right, me neither. In my email client, I keep all FreeRTOS forum messages since 2008. On the day that #183 was published, I did not receive it by email. That day there were 10 posts, and 1 feature request. The same about #181 and #169.
But I am happy to check them and see if they still need action.
Thanks
#181 is not clear in description about what is meant by wrong length. I double checked the code and I do not think any action is needed there. @htibosch Would you please check if #169 needs any action?
I was just checking this month’s posts, and I saw this unresolved thread.
About the old issue #169 on SourceForge: I would definitely recommend to enable ipconfigTCP_HANG_PROTECTION, like @aggarg already concluded in issue #30.
It would be possible to change the code, but it might be risky and it would need a lot of difficult testing.