From owner-freebsd-net@freebsd.org Thu Dec 28 16:10:58 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 DF78EEA6C20 for ; Thu, 28 Dec 2017 16:10:58 +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 BED1080CEF for ; Thu, 28 Dec 2017 16:10:58 +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 vBSGAljW004481 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 08:10:52 -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> From: Julian Elischer Message-ID: <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> Date: Fri, 29 Dec 2017 00:10:41 +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 16:10:59 -0000 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 >> " >> >> >> >> > >