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

Interface wildcard support #69

Merged
merged 2 commits into from
Jun 7, 2017
Merged

Conversation

gromit1811
Copy link
Contributor

Not really a pull request yet, more a request for comments.

This implements interface wildcard support. With it, you can abbreviate network interface names using an iptables-style "+"-suffix that matches anything. For example, you could use "phyint eth+" to match eth0, eth1, eth2, ethfoo123 etc,. or you could use "mroute from tun+ group 239.0.0.0 to tun+" (and the latter is clever enough not to route from tunX to tunY when X==Y).

Wildcards may be used anywhere instead of fixed interface names, i.e. in the config file in "phyint", "mroute" and "mgroup" statements and also when specifying interface names on the command line.

I'm using this on a VPN server with lots of dynamic tunnel interfaces with hard to predict interface names.

This change is pretty intrusive but I tried to implement it in such a way that I don't have to restructure all of smcroute. So intead of performing simple interface lookups, functions using interface names now instatiate an iterator and iterate internally.

It's for an ancient version of smcroute (2.1.0). If you think interface wildcard support is useful and if you're happy with the way I implemented it, I'll try to make it work with latest smcroute and I'll update this pull request. But I wanted to ask first before wasting lots of time...

@troglobit
Copy link
Owner

Looks really interesting! I hadn't even thought about taking things in that direction, so I'm all in favor! 😃 👍

Just a couple of completely redundant comments, which would not stop me from merging, just style nitpicking. I'm not a fan of overly long struct names or _ in variable names, so if you would consider changing the following I'd be very happy:

  • struct iface_match_state *state to struct ifmatch *state, and
  • struct iface **iface_ret to struct iface **found

Cheers!

@troglobit
Copy link
Owner

troglobit commented May 21, 2017

Maybe we should synchronize the work on this and #71 ... it seems we need to go in a direction where we allocate and free VIFs at runtime.

I've scheduled that refactor for the v2.4 series, atm planned for end of summer. Will release v2.3 in the next couple of days, unless critical bugs are found.

@gromit1811
Copy link
Contributor Author

The original version or my patch for smcroute 2.1.0 added a "pending" flag to the interface struct originally intended to support dynamic allocation of VIFs. But I never got around to actually implement that and decided that an occasional SIGHUP is sufficient in my case. But in general, having dynamic allocation would be nice, right.

Regarding combining this pull request with #71: Typically, you'll want both features, but they're more or less independent of each other and both may be useful individually. So I'll update this pull request with my updated wildcard support soon. It's then up to you to decide whether to apply this right away (I guess it's too late for v2.3 as it's quite an invasive change) or wait until you do the refactoring.

Updated from old smcroute 2.1.0 changes. Using shortened structs/variables
to fit smcroute style.

Signed-off-by: Martin Buck <[email protected]>
@gromit1811
Copy link
Contributor Author

Pull request rebased on current master (close to a full rewrite...). Compiles without warnings and doesn't crash immediately, but I haven't tested it as extensively as my old version for smcroute 2.1.0 yet.

@troglobit troglobit self-requested a review May 22, 2017 17:35
Copy link
Owner

@troglobit troglobit left a comment

Choose a reason for hiding this comment

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

Looks good, great even! 👍

@troglobit
Copy link
Owner

Yup, this will have to go into v2.4.

Thank you for the feedback on my questions, above, I agree we need both.

@troglobit troglobit added this to the v2.4 milestone May 22, 2017
@troglobit troglobit self-assigned this May 22, 2017
@troglobit
Copy link
Owner

Hand merged ifvc.h using the web interface, for the first time.
I hope I didn't screw anything up ... here goes, merge! :)

@troglobit troglobit merged commit df32b67 into troglobit:master Jun 7, 2017
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.

2 participants