-
Notifications
You must be signed in to change notification settings - Fork 3k
Increase DHCP timeout, and rework networking tests logic #4369
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
Conversation
@adbridge I tried to incorporate all of your feedback as best I could, if you see anything woefully amiss, please be sure to let me know! |
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
@studavekar Lots of timeouts for NUCLEO_F429ZI ?? |
Have replaced the board NUCLEO_F429ZI. |
/morph test-nightly |
@bridadan Because we use PR subject lines in our release notes, could you please add a comma after "timeout"? [Two independent clauses separated by a coordinating conjunction require a comma before the conjunction.] |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
NCS36510 failed again with the same error as some other PRs:
@studavekar do we have another problem board here? Either that or we have a genuine failure case |
Huh, it looks like it may be more issues with the NCS36510's 16-bit timer arithmetic, although I thought we clamped down the implementation over in #3779. @pan- has a pr coming in that lets us move the 16-bit timer arithmetic out of target code: #4094 Feel free to raise in issue to track this failure, but we should go ahead and adopt @pan-'s hal level implementation rather than continuing to debug target code. |
OK so this is the second failure with NCS36510. I left the comment in the issue we closed previously just like 2 hours ago. I however did not realize that there is that 64bit pull request. It is ready for the very last review, so hopefully will make it to 5.5. |
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor changes
eth.connect(); | ||
|
||
int err = eth.connect(); | ||
TEST_ASSERT_EQUAL(0, err); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have TEST_ASSERT_EQUAL(0, err) both before and after the if statement ?
err = sock.close(); | ||
TEST_ASSERT_EQUAL(0, err); | ||
if (err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this assert be after the setting of result ?
/** \brief Handshake with host and send setup data (timeout and host test name) | ||
* \details This function will send preamble to master. | ||
* After host test name is received master will invoke host test script | ||
* and add hos test's callback handlers to main event loop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
host
/** \brief Handshake with host and send setup data (timeout and host test name). Allows you to preserve sync UUID. | ||
* \details This function will send preamble to master. | ||
* After host test name is received master will invoke host test script | ||
* and add hos test's callback handlers to main event loop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
host
@bridadan seems like the same failures 2 times. Mind having a look? |
The dtls test already has the ability to retry upon a UDP failure. However the sockets are currently configured to be blocking and to wait forever. I added a timeout of 1.5 seconds in order the test to correctly timeout.
This adds some extra logs to the test for debugging purposes. Also allows the test to fail immediately if it fails to obtain an IP address.
The Greentea UUID can be used as a source of entropy/randomness during the test. This is useful for uniquely identifying a test run.
Before, the UDP test was very strict on the number of packets it would try to match before failing. Now it will keep trying for the whole test to get enough passing packets. It also includes the test's UUID so you can validate which packets are being received.
Making the test more forgiven for minor networking issues. Also adding more debug prints to make it easier to see which packets are coming from where.
This matches the timeout used in linux: https://linux.die.net/man/5/dhclient.conf This resolves several issues noticed during testing when we have a very large number of devices that try to get an IP address around the same time.
Avoids getting stuck in loop where the device always picks up the previous test's packets
This is a workaround for IAR's lack of flexibility with memory regions. Otherwise these tests would use very little heap and be mostly global allocations.
This creates a macro for the UUID length used by Greentea. This cuts down on the use of "magic numbers" in test cases that use the GREENTEA_SETUP_UUID function.
This file is moved to targets that support eth. It can't be common for any F4, as not all targets from this family support eth.
2523fc8
to
d0d7c6f
Compare
@bridadan I rebased ,and fix a regression from the previous CI (ethernet for F4), should be green ! |
/morph test-nightly |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Description
This PR attempts to fix a number of issues that have cropped up with the networking tests lately. It alters the behavior of the test to be more forgiving of certain types of network hiccups.
This is a continuation of #4240.
I have removed the random assignment of mac addresses from this PR since the issue is more complex and requires greater consensus.
Status
READY
Migrations
If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.
NO
Todos