From owner-freebsd-net@freebsd.org Sat Dec 16 09:31:01 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 335F9EA261B for ; Sat, 16 Dec 2017 09:31:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC48F7E242 for ; Sat, 16 Dec 2017 09:31:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vBG9UtET069531; Sat, 16 Dec 2017 10:30:55 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A0D61AE1; Sat, 16 Dec 2017 10:30:55 +0100 (CET) Message-ID: <5A34E7CF.2000104@omnilan.de> Date: Sat, 16 Dec 2017 10:30:55 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Lyon CC: freebsd-net@freebsd.org, Eugene Grosbein Subject: Re: Need Netgraph Help References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sat, 16 Dec 2017 10:30:57 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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: Sat, 16 Dec 2017 09:31:01 -0000 Bezüglich 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 not 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 == etfp->downstream_hook.hook) { > error = 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 the > *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 – while 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