Skip to content

Fix status sequence and reporting for LWIP stack #8381

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Oct 18, 2018
Merged

Fix status sequence and reporting for LWIP stack #8381

merged 1 commit into from
Oct 18, 2018

Conversation

michalpasztamobica
Copy link
Contributor

@michalpasztamobica michalpasztamobica commented Oct 11, 2018 •
edited
Loading

Description

Connection status in LWIP Interfeace is being reported according to documentation, which can be found here: https://github.com/ARMmbed/mbed-os-5-docs/blob/a96abc0a89af7c0e02d0535c940aa68a989ff1e9/docs/api/networkinterfaces/networkinterface.md

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

@cmonr
Copy link
Contributor

cmonr commented Oct 11, 2018

@michalpasztamobica Could you be a bit more clear/explicit/verbose on the description of the PR? Which status? Which documentation?

@cmonr cmonr requested review from a team and kjbracey October 11, 2018 15:25
@SeppoTakalo
Copy link
Contributor

Documentation: ARMmbed/mbed-os-5-docs#744

This PR fixes the EthernetInterface events to match the submitted documentation.

SeppoTakalo
SeppoTakalo suggested changes Oct 11, 2018
View reviewed changes
Copy link
Contributor

@SeppoTakalo SeppoTakalo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verify the scenario I described and also check if that extra whitespace is correct.

Other that those, this looks OK.

features/lwipstack/LWIPInterface.cpp Outdated
if (interface->has_addr_state & HAS_ANY_ADDR) {
interface->connected = NSAPI_STATUS_GLOBAL_UP;
}
} else {
} else if (!netif_is_up(&interface->netif) && netif_is_link_up(&interface->netif)) {
// disconnect() was called, because netif_is_link_up is returning true even though netif is down.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing about this, I'm still wondering that there should be one more test.
What happens if you disconnect the ethernet cable, and then call interface->disconnect()

I would assume that in that case both functions are returning false in which case the generated event is probably not correct.
@michalpasztamobica Can you verify?

Copy link
Contributor Author

@michalpasztamobica michalpasztamobica Oct 12, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent point, you are right - if I call interface->disconnect() after I unplugged the cable there is no status change (it should change to DISCONNECTED).
I will try to improve the condition, but I am afraid we need to entangle the connection status and create kind of a simple state machine, which considers previous state in its logic.

@michalpasztamobica
Copy link
Contributor Author

Thank you for the remarks. I had to modify the logic quite a bit to get the events working as per documentation, but now I tested all possible scenarios:

  1. Connecting on startup
  2. Connecting after the initial connection failed due to unplugged cable
  3. Unplugging the cable after connection was established
  4. Calling disconnect after connection was established
  5. Unplugging the cable after disconnect was called
  6. Opposite of (6) - calling disconnect after cable was unplugged.
    Then I also tested all of those repeating the manual steps twice in a row.
    Finally I made sure that recovery is successful after every of these scenarios.
    I checked that TESTS and UNITTESTS are still passing all the changes.
    If necessary I can provide a sample application which I used.

@SeppoTakalo
Copy link
Contributor

@0xc0170 Please start the tests.

@cmonr
Copy link
Contributor

cmonr commented Oct 17, 2018

/morph build

@cmonr
Copy link
Contributor

cmonr commented Oct 17, 2018

@kjbracey-arm In case you still wanted to review this.

@mbed-ci
Copy link

mbed-ci commented Oct 17, 2018

Build : SUCCESS

Build number : 3386
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8381/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Oct 17, 2018

Exporter Build : SUCCESS

Build number : 3018
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8381/

@mbed-ci
Copy link

mbed-ci commented Oct 17, 2018

Test : SUCCESS

Build number : 3188
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8381/3188

@SeppoTakalo
Copy link
Contributor

@cmonr You can remove the "needs: review" label.
I have reviewed this and it is fine.

@cmonr cmonr merged commit 116a743 into ARMmbed:master Oct 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cmonr cmonr cmonr approved these changes

@SeppoTakalo SeppoTakalo SeppoTakalo approved these changes

@kjbracey kjbracey Awaiting requested review from kjbracey

Assignees
No one assigned
Labels
release-version: 5.10.2
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@michalpasztamobica @cmonr @SeppoTakalo @mbed-ci