From owner-freebsd-net@freebsd.org Wed Dec 27 15:32:30 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 B642AE9603B for ; Wed, 27 Dec 2017 15:32:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99D5D69BED for ; Wed, 27 Dec 2017 15:32:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBRFWMsM002215 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Dec 2017 07:32:27 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon , Harry Schmalzbauer Cc: freebsd-net@freebsd.org, Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> From: Julian Elischer Message-ID: <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> Date: Wed, 27 Dec 2017 23:32:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Wed, 27 Dec 2017 15:32:30 -0000 John did you get a resolution to this issue? On 16/12/17 2:59 am, John Lyon wrote: > 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 > should not be triggering this error condition. > >>> 3) it was not already configured, or else you get error EEXIST (File > exists). > > I am not getting this error, so it appears not to be an issue in my case. > > What am I missing here? The man page states that "*any other *hook" can be > used for the non-matching packets. So the man page says this should work, > and there's no explicit error condition that I see (caveat, I have not > written in C for at least 10 years - PEBKAC is entirely possible) that > would be triggered in the ng_etf code. So what is going wrong? > > Thanks for all of your help, patience, and understanding. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer > wrote: > >> Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localtime): >>> 15.12.2017 4:27, John Lyon wrote: >>> >>>>>> I'm a new Netgraph user, but am having some problems with a simple >>>>>> Netgraph >>>>>> script I have written. Unfortunately, the error message is cryptic >> and I >>>>>> can't tell what I am doing wrong since my script closely follows the >>>>>> example provided in the ng_etf man page. >>>>>> >>>>>> For some context, I'm trying to filter EAP traffic coming in on my LAN >>>>>> interface. Any ethernet frames that correspond to EAP traffic need >> to be >>>>>> immediately forwarded from the LAN interface to my WAN interface. All >>>>>> other ethernet frames coming in on my LAN interface need to be >> handled by >>>>>> the kernel's network stack. A (horrid) ASCII art representation of my >>>>>> desired netgraph would look like this: >>>>>> >>>>>> lower -> em0 -> downstream -> ETF -> no match -> upper em0 >>>>>> -> match -> >>>>>> lower em1 >>>>>> >>>>>> The script I have written is this: >>>>>> >>>>>> #! /bin/sh >>>>>> ngctl mkpeer em0: etf lower downstream >>>>>> ngctl name em0:lower lan_filter >>>>>> ngctl connect em0: lan_filter: upper nomatch >>>>>> ngctl msg lan_filter: setfilter { matchhook="em1:lower" >>>>>> ethertype=0x888e } >>>>>> >>>>>> Unfortunately, the last line of my script generates the following >> error >>>>>> message: >>>>>> >>>>>> ngctl: send msg: Invalid Argument >>> For "setfilter" command to work, ng_etf requires that: >>> >>> 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); >>> 2) referenced "matchook" is *not* downstream hook, or else you get error >>> EINVAL (Invalid argument); >>> 3) it was not already configured, or else you get error EEXIST (File >> exists). >> >> Eugene kindly looked into the code and found that the error is due to >> wrong matchhook definition. >> I've never had any contact with ng_etf yet, but according to the man >> page, you need to set the (additional) filter hook by 'nghook -a >> lan_filter: mydrain' and use 'matchhook=mydrain' for the 'msg' command. >> >> Do idea about the intention, so for the rest you have to tweak as needed. >> >> -harry >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >