Thank you very much. I don't remember at what stage the .tgz was but I'm sure I have improved the scripts meanwhile. Since I see you're interrested, I'm going to fuddle my current files together into a new tgz.
The current implementation is thought in this way: when the (virtual) interface is brought up, then try to establish the tunnel until the interface is brought down. If no "real" path to the OpenVPN server is available, it will try again until there is one. This way I didn't require a dependency for a real interface up to now. For multiple internet interfaces, the default route or - if set - specific multiwan rules are applied. Binding to a specific interface is still possible in the openvpn config file, but only to the real interface name. Binding it to a uci network name would require additional coding in the start script - and additionally the dependency to the bound interface being up. I'm planning on publishing my files to svn, but was away for a while and didn't find the time. Great that it is useful for you, I'm looking forward for your feedback. Cheers Joachim Am 14.12.2012 14:22, schrieb Brian J. Murrell: > Nice work on netifdizing OpenVPN! I'm really looking forward to > patching all of your scripts from > http://pariah-angels.de/openwrt/openvpn-interface.tgz into my AA-rc1 > installation I have here. Any chance you might want to publish an AA > ipk for it? :-) > > I wonder what your thoughts are on the applicability of your existing > work to a router with > 1 "external" (i.e. Internet) interfaces (and > therefore more than one external IP address). In such a case, (AFAIU, > anyway) one typically chooses one of the interfaces and tells OpenVPN to > bind to it. > > Also, being totally new to this netifd stuff, I am just trying to figure > out the facilities available to "proto" scripts, so I could totally be > missing it here, but does your proto script have a dependency on an > Internet interface being up? That is, will "ifup" for an OpenVPN > interface only succeed if a "real" interface, providing connectivity > upstream, is already plumbed? > > In a message thread on the -users lists where I was trying to get an HE > IPv6 tunnel up, Jow showed me where the 6in4 proto fails unless there is > a route to 0.0.0.0 present using: > > ( proto_add_host_dependency "$cfg" 0.0.0.0 ) > > I wonder if that is applicable here. But more importantly, for > 1 > external interface systems, having a dependency on interface OpenVPN > intends to bind to would be even more important. > > Looking forward to your thoughts. > > Cheers, > b. > > > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
