[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using libpcap for gnunet-dns- and gnunet-exit-helpers?

From: Schanzenbach, Martin
Subject: Re: Using libpcap for gnunet-dns- and gnunet-exit-helpers?
Date: Wed, 27 Nov 2019 12:37:09 +0100


my take would be that limiting this functionality to Linux for now is
perfectly fine as there are other options (e.g. local DNS server configuration).


> On 27. Nov 2019, at 12:15, ng0 <address@hidden> wrote:
> You are right, libpcap does not allow what we require.
> I'm still reading into it, but can we add a packet filter neutral
> (or not using any packet filters at all) version to the requirements
> of a stable GNUnet? What I describe below doesn't scale very good.
> The two helpers right now require iptables.
> pf implementations on *BSD differ by syntax.
> Other systems most likely use a different packet filter.
> iptables could change / be on its way out in the future (see eBPF in Linux
> and its recent development directions).
> Even for iptables this means we have to keep up with changes.
> Right now, every porter would have to add a block for the packet filter
> of their operating system.
> As someone more knowledged about this wrote yesterday "hoping for 
> compatibility
> between firewalls seems like a plan doomed to fail".
> Do I follow this course for now (adding system specific firewalls), or
> do we have another option in the near/far future for these helpers?
> it's really unpleasant for adding and maintaining systems support beyond
> Linux for this part. and even Linux will change at some point,
> so we need to move to whatever firewall has replaced iptables again
> (a new nftables? idk). OpenBSD's pf syntax changes slowly, but sometimes
> it changes. Other pf syntaxes change as well. I'm not sure about other
> firewalls and how they developed over time, but it is unlikely they
> didn't change.

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

[Prev in Thread] Current Thread [Next in Thread]