-
-
Notifications
You must be signed in to change notification settings - Fork 64
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
Conversation
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
Cheers! |
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. |
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]>
af49f79
to
aa58929
Compare
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. |
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.
Looks good, great even! 👍
Yup, this will have to go into v2.4. Thank you for the feedback on my questions, above, I agree we need both. |
Hand merged |
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...