Skip to content
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

network: support conditionally binding active alt interface #1834

Merged
merged 9 commits into from
Oct 11, 2021

Conversation

goaway
Copy link
Contributor

@goaway goaway commented Sep 27, 2021

Description: Adds utility support for filtering for a viable WIFI or cellular interface to select as a potential alternate to the OS-supplied default, and an accessor for the platform-specific socket options to bind to it.
Risk Level: Low
Testing: Added unit test

Signed-off-by: Mike Schore mike.schore@gmail.com

@goaway goaway changed the title network: support conditionally selectin and binding active alt interface network: support conditionally binding active alt interface Sep 27, 2021
Base automatically changed from ms/interface-binding-2 to main September 28, 2021 08:46
@goaway goaway force-pushed the ms/interface-binding-3 branch 2 times, most recently from e3e1761 to 0d2add8 Compare October 4, 2021 10:20
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
library/common/network/configurator.h Outdated Show resolved Hide resolved
library/common/network/configurator.cc Show resolved Hide resolved
if (network == ENVOY_NET_WLAN) {
auto interfaces =
enumerateInterfaces(family, IFF_UP | IFF_MULTICAST, IFF_LOOPBACK | IFF_POINTOPOINT);
return interfaces.size() > 0 ? interfaces[0] : "";
Copy link
Member

Choose a reason for hiding this comment

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

does it matter if we send the first available interface? is there any heuristic for preference?

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
return interfaces.size() > 0 ? interfaces[0] : "";
return interfaces.size() > 0 ? interfaces.front() : "";

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's no documentation I'm aware that asserts any meaning with respect to order, and absent that, a slight bias towards whatever matches first seems reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't really have a strong opinion with respect to [0] vs front(), but the former seems perfectly clear to me, and subjectively, better indicates to me that I'm picking an element from a vector. May I ask your basis for preferring front()?

std::vector<std::string>
Configurator::enumerateInterfaces([[maybe_unused]] unsigned short family,
[[maybe_unused]] unsigned int select_flags,
[[maybe_unused]] unsigned int reject_flags) {
std::vector<std::string> names{};

#ifdef SUPPORTS_GETIFADDRS
Copy link
Member

Choose a reason for hiding this comment

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

note: I am adding full support for getifaddrs in Envoy here envoyproxy/envoy#18513. So we will be able to get rid of the ifdef.

Non-blocking of course! I can update this code once that lands :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, we can revisit. I actually think this still might be needed here though, but since this is non-blocking, let's discuss after.

TEST_F(ConfiguratorTest, EnumerateInterfacesFiltersByFlags) {
// Select loopback.
auto loopbacks = configurator_->enumerateInterfaces(AF_INET, IFF_LOOPBACK, 0);
EXPECT_EQ(loopbacks[0].rfind("lo", 0), 0);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
EXPECT_EQ(loopbacks[0].rfind("lo", 0), 0);
EXPECT_TRUE(absl::StrContains(loopbacks.front(), "lo"))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Again, I don't have a strong preference here, but I think the existing check is a little more specific. This suggestion would match an interface named "hello_world", for instance.

// Reject loopback.
auto nonloopbacks = configurator_->enumerateInterfaces(AF_INET, 0, IFF_LOOPBACK);
for (const auto& interface : nonloopbacks) {
EXPECT_NE(interface.rfind("lo", 0), 0);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
EXPECT_NE(interface.rfind("lo", 0), 0);
EXPECT_FALSE(absl::StrContains(interface, "lo"));

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replied above.

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Generally LGTM, thanks. Will take a further look once @junr03 comments are addressed.

Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
@goaway goaway merged commit 276b39a into main Oct 11, 2021
@goaway goaway deleted the ms/interface-binding-3 branch October 11, 2021 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants