implement new address filter based on default route availability #179
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
November 17, 2021 16:48
instead of using a plain sockaddr, use the mptcpd_addr_info structure, so that we can more easily include additional metadata. Additionally change the mptcpd_addr_info layout so that this don't break existing interface->addrs users. This make address management more efficent and will simplify the next patch.
This only adds the configuration-related bits, the actual check implementation is in the next patch.
Contributor
Author
|
the failure is cause by too old libell version. the gitlab workflows install ubuntu-latest defeault, which is v 0.27, while this changeset uses some functions introduces in libell 0.29. I have no idea how to tell the gitlab workflow to use/install a more recent version. |
pabeni
force-pushed
the
route_lookup
branch
6 times, most recently
from
3a6fad7 to
d6429af
Compare
Pull Request Test Coverage Report for Build 1515662526
💛 - Coveralls |
Member
ossama-othman
left a comment
ossama-othman
left a comment
There was a problem hiding this comment.
@pabeni I still have to go through the changes in detail, but I did make a quick pass and left some comments about minor issues.
ossama-othman
added
bug
ossama-othman
requested changes
Nov 24, 2021
if the relevant flag is enabled, do a route lookup for a default route at address creation time and notify the new address only if such route is found. In case of failure re-schedule the check with a small timeout and exponential backoff up to 3 times. That is intended to cope with e.g. DHCP clients configuring the address and the relevant route in order. Note that route lookup is async, an racing address removal can try to delete the relevant address object before the route lookup completes. Implement a simple refcount mechanism on the mptcp address object to avoid such issue. In a similar manner, route lookup can race with interface deletion. Instead of adding another ref-count, just lookup again the interface via the known ifindex in the async operation. Finally default route lookup for ipv4 does not really work on the Linux kernel: 'ip route get 0.0.0.0 ...' always returns a loopback route. To fetch the default route, lookup for a test-only address: as no host/network should use it, it should be reachable only via the default route. The gitlab workflows is update accordingly, explicitly building and installing the minimal required libell version
ossama-othman
approved these changes
Nov 29, 2021
This was referenced Nov 29, 2021
ossama-othman
pushed a commit
that referenced
this pull request
Dec 2, 2021
The new default route availability based address filter introduced in PR #179 requires features in ELL >= 0.30. Adjust the ELL version check and documentation accordingly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this change-set implement the functionality discussed in recent public meetings.
Depending on a newly introduced configuration flag, new address are used/notified only if a default route is available for such address/interface.
There are a few quirks due to ipv4 route resolution and libell async notification, see the 3rd patch for the details.
This should close issue #170