[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] helpers trying (and failing) to setup routing, i
Re: [GNUnet-developers] helpers trying (and failing) to setup routing, iptables, sysctl and such
Mon, 18 Apr 2016 04:33:20 +0200
On Sun, Apr 17, 2016 at 10:37:26PM +0200, Christian Grothoff wrote:
> Hi Daniel,
> I think a command-line argument is fine, just don't introduce
> getopt()-style parsing into the SUID binaries ;-).
That's why I thought of a configure option to just not include
that functionality in the SUID binary in first place.
The diffstat to introduce that option at runtime also isn't as small
as I was hoping it would end up being...
As gnunet-helper-exit already got a parameter to specify the NAT
interface I reused that parameter and also skip sysctl for v4/v6
ip_forwarding if it isn't supplied.
For gnunet-helper-dns I needed to introduce a new parameter and pass
it from gnunet-service-dns which checks if the config option
SKIP_ROUTING_SETUP is set.
Find the patches for dns and exit attached, I'd be glad if you can
review them before I commit my changes.
> Happy hacking!
> On 04/17/2016 10:21 PM, Daniel Golle wrote:
> > Hi!
> > I'm currently working on improving IPvX-over-GNUnet on OpenWrt.
> > I believe that providing v4/v6/DNS exit service using an OpenWrt box
> > is a quite good idea.
> > On OpenWrt it doesn't make so much sense to mess around with routing,
> > sysctl and iptables rules in the helpers as networking and firewall are
> > managed by OpenWrt's services. The situation is also different from a
> > desktop system because on an embedded device (think e.g.:
> > IPvX-over-GNUnet router) the networking and firewall configuration
> > corresponds to a specific use (think: tunneling all traffic through
> > GNUnet) and do exactly that. To me it seems desirable to have an
> > additional parameter (or even a compile-time configure argument!) for
> > the dns- and exit-helpers to make them stay away from routing, sysctl
> > and firewall stuff and just assume that an external service will handle
> > all that once the interface comes up (because that's what netifd does
> > on OpenWrt).
> > Depending on your preference (additional cmdline parameter vs.
> > compile-time), I'd like to introduce that option, so EXIT will be more
> > useful to provide gateways to the ARPA internet in community mesh
> > networks -- that's the main application for most of them and GNUnet
> > could already offer a decentralized and more secure way to do that.
> > Cheers
> > Daniel
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnunet-developers
> GNUnet-developers mailing list
Description: Text Data
Description: Text Data