-
Notifications
You must be signed in to change notification settings - Fork 498
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
Fix ifconfig parse logic failing on some tunnels #2635
base: main
Are you sure you want to change the base?
Fix ifconfig parse logic failing on some tunnels #2635
Conversation
Can one of the admins verify this patch? |
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.
Thanks @Woellchen! In the first commit that demonstrates the failure, can you mark the failing test(s) as pending
? And then remove the pending
in the second commit. This is important so that each commit passes if we later need to git bisect
.
Or you can keep the commits as-is and I can squash them when merging. Let me know which sounds better.
4c6519c
to
a83e1f9
Compare
Hey @joshcooper, thanks for getting back to me! |
Closing and reopening to trigger the right set of checks |
a83e1f9
to
8260822
Compare
Hey @joshcooper! To avoid further confusion and delays I have just merged the two commits into one and skipped the failing tests commit that was meant to demonstrate the failure. I have also rebased the branch once again. I hope that this way we can conclude this PR for good :) |
Tunnel interfaces that have a line similar to
"tunnel inet 192.0.2.1 --> 192.0.2.2" would fail the network resolver
because IPs were extracted through two separate IP + mask patterns.
However, in the example above, there is no such thing as a netmask.
This fix merges the patterns and extracts the IPs and netmasks
together so that no mismatches can occur. It might also fix some
cases where only the netmask would be nil and therefore produce an
invalid binding that could in turn resolve to the wrong (outer) IP of
the tunnel instead of the inner IP.