From owner-freebsd-net@freebsd.org Mon Dec 18 14:17:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B652E8DE9E for ; Mon, 18 Dec 2017 14:17:56 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFF117C676 for ; Mon, 18 Dec 2017 14:17:55 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id f9so29830042wmh.0 for ; Mon, 18 Dec 2017 06:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zOgyS6eJH17rbxaFx75wcbG6OGlfoExoutLs0WcLiI4=; b=dqIADQnhvN3bWBYex8xDyXtUQRpGQBVZgoC0y+abUxBMDt9oSa/lC1jJonUl1b793U ns0+ttFcNv5crc5J6PV4f1QGCP+Bbk3RrphYMGypmAmuNrFiiITw4WHS8Bqk2mOiu4ek y14vMF1O3FjJhODpl0EGV9VAKAcyo+uiBhPXLTwLAzXdRtpe01sk5zvUaAGGN2fDs6C+ 0mjoc0wFNGB3X5RDuPLsqSgkJQwvrLNP9tFUInnd7Tsx9OpGw6oA37tp47OR9i6n1VFJ nWTPtSDwupCkkRIK6d1ajbBMX3OWUFYIuGouhxvBV3T5VqofvPcMRxNvuE+vhyKpR3J5 aVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zOgyS6eJH17rbxaFx75wcbG6OGlfoExoutLs0WcLiI4=; b=lOGSCkI0OdKFJaQ7ppt3lUSg1RUnXaRHInylMB977tgETujL6l1R7gixOq2Rd+9Ui8 mGWZBoAWrWHe226nnzYq9TWCMxUVc2akeGEG3TVtAomHAcveddogxT6thRMZRJgY9k1Z 0Z3XYUUwJMy1C4Wm53loB6MUsX9bK0lK2MVHHJ2bXZH0Z2Knguaayg12ancf7TxxUgq+ WSKSnyVWSyz4t3sQGIg/Y8a8Xanl+9IuF070Nd0tjCRukoeelVvPO3W9FQZV/6f870E4 +1exgC23S5R0t1WneBGC6otNRGho9BoRuSly/nAPbk3CCYvbWeg52jZH5yHHi8ihzC8c 3FjQ== X-Gm-Message-State: AKGB3mKUbH44qpBASIxa0hiP3oaYKb6WFthlL7LSePizvmZWHA+GqXxf 58rImn32KglM2QAQbXdFDOcRLzLac0odlsextw0= X-Google-Smtp-Source: ACJfBovf6bD7MXwHdi2L8Emo5Z5jKwZ21shloC9G2mvTqVIAPlHaEc/rngbAlhUG9vlox73O+igsrUAdXCmI15wJ6dI= X-Received: by 10.80.241.19 with SMTP id w19mr13499edl.123.1513606674110; Mon, 18 Dec 2017 06:17:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Mon, 18 Dec 2017 06:17:33 -0800 (PST) In-Reply-To: <5A34E7CF.2000104@omnilan.de> References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <5A34E7CF.2000104@omnilan.de> From: John Lyon Date: Mon, 18 Dec 2017 09:17:33 -0500 Message-ID: Subject: Re: Need Netgraph Help To: Harry Schmalzbauer Cc: freebsd-net@freebsd.org, Eugene Grosbein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:17:56 -0000 Harry, Thanks for the help. I haven't had the chance to sit down and tinker over the weekend, but I hope I may get sometime in the next day or two. I will see what happens when I try to connect my filter as you suggested. My intention is essentially to use NetGraph in order to add some simple layer 2 firewalling capabilities to my PFSense router (FreeBSD + pf + pretty GUI for other functions) on my network. Unfortunately, pf on FreeBSD only appears to filter at layers 3 and 4. I need to also filter and redirect layer 2 traffic. I'm aware that IPFW can probably do what I want (filter and redirect based on MAC address and ethernet frame type). However, I prefer the pretty GUI of PFSense for convenience and time saving (I could duplicate all of the rules and functionality in the command line, but the GUI makes administration a lot easier). However, I don't want to hack together a solution that involves two firewalls running on the same box when I was hoping to use Netgraph to filter at layer 2 before passing other traffic up to pf for layer 3 and 4 filtering. However, this may be the route I have to go (PFSense does use both PF and IPFW when the "captive portal" functionality is enabled, so it is technically possible). Thanks for the link to the NetBSD presentation. I'm already aware of it, it was one of the first things I found when I googled about netgraph trying to sort through this whole mess. :-) -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Sat, Dec 16, 2017 at 4:30 AM, Harry Schmalzbauer wrote: > Bez=C3=BCglich John Lyon's Nachricht vom 15.12.2017 19:59 (localtime): > > Harry and Eugene (and others), > > > > I appreciate all of your help. It's been really insightful. Although = I > > feel like I'm getting much closer to the solution, I don't think my > problem > > has been diagnosed. I've outlined my thought process below. Can you > > please tell me if I am misunderstanding something? Admittedly, I am no= t > a > > kernel developer and my C language skills have atrophied the last few > > years. However, I've reviewed my script and I looked in the code for > > ng_etf.c and I don't think I am violating any of the requirements for > > linking a hook for no match. > > > > As Eugene stated: > > > >>> 1) referenced "matchook" exists and you should not use "indirect name= " > > here, > >>> only hook own name, or else you get error ENOENT (No such file or > > directory); > > > > This does not seem to be a problem as the upper and lower hooks for the > em1 > > already exist (I can confirm this). > > > >>> 2) referenced "matchook" is *not* downstream hook, or else you get > error > >>> EINVAL (Invalid argument); > > > > I read the ng_etf.c file in the source tree and found this little > snippet: > > > > /* and is not the downstream hook */ > > if (hook =3D=3D etfp->downstream_hook.hook) { > > error =3D EINVAL; > > break; > > } > > > > This appears to be an error check to make sure you are not creating a > cycle > > in the graph by referencing the ETF node's own downstream hook (i.e. > > filtering incoming traffic and circularly feeding non-matching frames > back > > into the ETF's own filter). I'm not doing this. I am feeding > non-matching > > packets into the *lower* hook of another ether node and not back into t= he > > *downstream* hook of the etf node I am creating. As a result, my > netgraph > > Ah, sorry, I was reading your setup too quickly and missed that em0|em1 > detail. > Since I'm no netgraph expert and also no kernel hacker due to C skills, > and on top I don't have any ng_etf experience, I'm out at this point > unfortunately. I just remembered the shell quoting issue I had once > myself and thougth this would be an easy one ;-) > > I _think_ it's not possible to redierct the packets that way with > ng_etf. You'd need at least to add the third hook to ng_etf. In the > manpage, it's a user land hook. > Have you tried if > ngctl connect em1: lan_filter: lower mydrain > works? > If so, your "setfilter" message might also work. > I think the missing third hook is the key to your solution =E2=80=93 whil= e I > don't know your intention, but I guess you want to get specific > type-tagged frames beeing transmitted on a dedicated interface. > > Pleas see > http://www.netbsd.org/gallery/presentations/ast/2012_ > AsiaBSDCon/Tutorial_NETGRAPH.pdf > on page 32+33. That example corresponds to the man page. > > Hope that helps, > > -harry >