The history notes are a bit vague, with a jump from 2.0.0 to 2.2.1.
Can anyone confirm if there are known issues with DNS with version 2.0.7? The symptoms are random failures. I’m assuming its something to do with cached dns, because wireshark shows no attempts at DNS at all, and FreeRTOS_gethostbyname_a callback returns 0 for host ip.
History Notes say:
+ Made changes in DNS to make asynchronous lookup work.
@htibosch maybe?
Hello @friesen,
You might already know that earlier the +TCP source code was present as copies in two separate locations in amazon-freertos repository and freertos/freertos repository. That makes tracking the history a bit difficult. We have since rectified that and made a separate repository for the +TCP source.
I digress. After a bit of digging, I found the PR behind the line in history file. It is this one. If was fixing the timeout value.
Are you able to set a breakpoint in the code to check what happens exactly? Till then, I will try to replicate your issue. Can you point me from where did you get the +TCP version 2.0.7? I found this: FreeRTOS-Plus-TCP/source at amazon-freertos. Is it the correct one?
On this one, I’m doing remote debugging/logging on a problem location and guessing at what is happening. I upgraded the project to 2.4.0 and I’m going to test it on that version and see what happens. Any suggestions of what I could log to pinpoint failures? The failures were happening with good internet, the network IF was up, and with both FreeRTOS_gethostbyname_a and FreeRTOS_gethostbyname.
Its actually a bit difficult to pinpoint TCP versions even yet, it is confusing the way its done. My first attempts simply git cloned the freertos+tcp only to find the headers all say . So then I downloaded the supported version (b6eac0c ??), only to run into the dhcp bug fixed in bug report #414.
Is this by design that the main branch is the development branch? That seems a bit odd the way this is done,
If you are sure that the issue is happening with DNS, and all other things are proper, then I would suggest start by printing out the DNS cache when you call the gethostbyname function. See if there is some discrepancy there - if not, then you should figure out the control flow.
Apologies for your experience. But yes, currently it is by design that the main branch is always up to date with the latest changes and bug fixes. Periodically, we release versions of the library which have been tested to be performing properly. They can be found here: Releases · FreeRTOS/FreeRTOS-Plus-TCP · GitHub.
As you must already know, any code base is not perfect and without bugs - regardless of how well tested it is. There is always a room for improvement. And this ‘improvement’ is made incrementally on the main branch. If we deem a particular state of the repository stable, we tag it as a ‘release’ and update the version numbers.
If, in the current main branch you see in source code, you’ll see that it says to clarify it to the users that the branch is always incrementally worked on and updated.
If you would like a tested version, which again I would like to highlight that we don’t claim is perfect and without any bugs - it just meets the requirements set by our always improving set of tests, then you should follow the link above.
Yes, I suppose I could download that zip, its not really a nice git workflow though.
Why can’t the dev branch have version numbers?
@friesen : The git tags for each version contain the same version tags as the release zip files, so you might find those revisions best to use in production.
For example: GitHub - FreeRTOS/FreeRTOS-Plus-TCP at V3.0.0
Hello Erik, if I am not mistaken you refer to my PR #1415 from 3 years ago. My very first AWS/GIT contribution was 3.5 years ago.
In the old days there were few people working on the project. Sources were stored in ‘svn’ on ‘assembla.com’. No GIT yet.
You might remember that FreeRTOS+TCP started “In the Labs” about 8 years ago. We didn’t want to make too many promises and disappoint customers.
Only when FreeRTOS joined AWS, we started using github. In the beginning, it was hard to get an overview because it had become one big repo full of dependencies.
Aniruddha did a great job, splitting up the repos into submodules. And since about two years, things are pretty well streamlined, and documented.
Mentioned PR 1415 was one of my first PR’s. More programmers started working on FreeRTOS_DNS.c.
The asynchronous version, and LLMNR/NetBIOS were sometimes forgotten and got broken.
So please forgive me/us if it is difficult to reproduce the exact software status of 3 years ago. I will attach the History that I produced around that time.
History.tcp.hein.zip (1.4 KB)