From owner-freebsd-net@freebsd.org Thu Dec 28 18:29:11 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 D5DE0EAD160 for ; Thu, 28 Dec 2017 18:29:11 +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 AA58564EB8 for ; Thu, 28 Dec 2017 18:29:11 +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 vBSISufh004892 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 10:29:06 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> From: Julian Elischer Message-ID: <4d9c2d9d-b3b3-e3bd-a4ae-11a1d27f7d71@freebsd.org> Date: Fri, 29 Dec 2017 02:28:50 +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-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 28 Dec 2017 18:29:11 -0000 On 29/12/17 12:36 am, John Lyon wrote: > The netgraph bridge would probably forward the 802.1x frames, but > the man page says that firewalling on the netgraph bridge is not > supported.  I need to process with the firewall all of the other > traffic that is not EAPOL frames. ok > > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 11:10 AM, Julian Elischer > > wrote: > > On 28/12/17 11:58 pm, John Lyon wrote: >> Julian, >> >> That looks exactly like what I want!  It also looks like what I >> thought I was doing.  I have no idea why it worked for you and >> not for me.  :-( >> >> I will copy and paste tonight after work (making changes for >> em0 and em1 on my own test system) and see if I can get it to >> work.  If it works, I will figure out what I was doing wrong >> and let the world know in case anyone wants to Google it in the >> future. If it doesn't work -- I'll be back. :-) >> >> To answer your other questions: >> >> (1) EAP (or more accurately in this case EAPOL) is the >> extensible authentication protocol over LAN and is used for >> 802.1X port authentication.  The authentication frames are >> marked with the ethertype 0x888e to distinguish them from other >> Ethernet frames. They are also assigned the broadcast MAC >> address of 01:80:c2:00:00:03. Because 802.1D states that a >> standard compliant switch or bridge cannot forward frames with >> a MAC address inthe range of 01:80:c2:00:00:00 to >> 01:80:c2:00:00:0f, you can't just create a bridge in FreeBSD >> between the two interfaces since the FreeBSD bridge code is >> standard compliant.  So I have to process and forward the >> frames another way and it looks like Netgraph will let me do >> it.  Otherwise, I'm going to have to patch the bridge code in >> the kernel to include a sysctl variable that enables or >> disables this compliance. > or use the netgraph bridge. ng_bridge. it doesn't care as far as > I know. it's job it to produce "bump in the wire" devices. > see /usr/share/examples/netgraph. > > >> >> (2) You are correct that there are return frames (not packets >> as this all occurs at layer 2).  However, the graph to handle >> the return frames is going to just be a mirror of the the graph >> for processing the outgoing frames.  So if I can get it working >> in one direction, it's trivial to create a mirror image graph >> for the reverse direction. >> >> Thanks! >> >> >> >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> >> On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer >> > wrote: >> >> On 28/12/17 1:37 am, John Lyon wrote: >>> Julian, >>> >>> Unfortunately, this issue remains unresolved.  I would >>> like to think that this is just a PEBKAC issue, but I have >>> tried every permutation of escape characters in case it's >>> an issue with my syntax and I get the same set of errors.  >>> No matter what I do, I can't connect the no match hook of >>> an ETF node to the upper hook of an ng_ether node.  Do you >>> have any insights into why this might be occurring? >>> >>> By the way, thanks for reaching out to me!  I was going to >>> email you directly after the holidays since your name and >>> email address are at the bottom of the relevant Netgraph >>> man pages.  I figured that must mean if you didn't know >>> the answer, no one does. :-) >> >> what is EAP? >> what about return EAP packets? (are there any?) >> >> I think this is what you want: >> $ sudo ngctl list >> There are 7 total nodes: >>   Name: igb0            Type: ether           ID: >> 00000001   Num hooks: 0 >>   Name: igb1            Type: ether           ID: >> 00000002   Num hooks: 0 >>   Name: ix0             Type: ether           ID: >> 00000003   Num hooks: 0 >>   Name: ix1             Type: ether           ID: >> 00000004   Num hooks: 0 >>   Name: tap0            Type: ether           ID: >> 00000005   Num hooks: 0 >>   Name: bridge3         Type: ether           ID: >> 00000006   Num hooks: 0 >>   Name: ngctl7372       Type: socket          ID: >> 00000007   Num hooks: 0 >> $ sudo kldload ng_etf >> $ sudo ngctl name ix0:lower eapfilter >> $ sudo ngctl connect eapfilter: ix0: nomatch upper >> $ sudo ngctl connect eapfilter: ix1: eapout lower >> $ sudo ngctl show eapfilter: >>   Name: eapfilter       Type: etf             ID: >> 00000021   Num hooks: 3 >>   Local hook      Peer name Peer type    Peer ID         >> Peer hook >>   ----------      --------- ---------    -------         >> --------- >>   eapout          ix1 ether        00000004        lower >>   nomatch         ix0 ether        00000003        upper >>   downstream      ix0 ether        00000003        lower >> $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" >> ethertype=0x888e }' >> $ >> >> >> >>> >>> Thanks. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> >>> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >>> > wrote: >>> >>> 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 >>> " >>> >>> >>> >>> >> >> > >