From owner-freebsd-net@freebsd.org Sat Jan 6 20:02:32 2018 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 78D3ADBB479 for ; Sat, 6 Jan 2018 20:02:32 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B52F97D3F5; Sat, 6 Jan 2018 20:02:31 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id i11so7853233wmf.4; Sat, 06 Jan 2018 12:02:31 -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=n0R9O7XCmKXC4QK+GhEZUdf2YTi0fHP++/6qczmXCcU=; b=RzW5WcGGeVtRu9gm12J+pXbWpvvsoUnBK6FFNWEAv9dEc06p0LcMCc3/BokxSfIZQy TLObmkUk24z1+3TXaZ7TvBRk+VY8yQ7pTjA4uDpAijK3ZhafB79XW1yy6aTzyPgRMSwC 0CGJxqkWiNE6sLsySJeE4YG0vZdV4J5ZvH8baMgVg5qmfUx2XxH6fEmfGs//A8A1maXR EOil78asDCfz43HtvKGO6OoVgx4cTTmqMp3oHgcPKQXGfGKVjrU2faS4oWBE+y5FfUtv ISGtHM6+QksNV3NDtoHqiccD5/hAzyXBv6QphAKhzZRRdlyu59RvGq+C346bh/qh+E6r Sb6A== 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=n0R9O7XCmKXC4QK+GhEZUdf2YTi0fHP++/6qczmXCcU=; b=mXfS2yvVlVm4+7VXhe2C8wHjZfkH1hBdmlVWUvwn60T4hzTjU2vzNXO/5Wx1BBFDG/ CA/Vag/aVWFZW4HgFu4ZMdMPTTitILocDM0+ByjnwTqy//jQydTgsiEOrFzRevUxAehY rjZgxXoPV/rj27oGFLTdGkPUjnTrHUhcan7sqyaNQxCd8hEf3DD8exqyXSbF9wmpLdMV P3VpD/zCFU0VCPVFaI7UQabKgWC2ppgckjnG7i/dtT6E2opvE+lHiHJQndyHewBgEigr 6i70FDu0RM8SeK7MSssBOjJAquKKitqtXJAsHJKc3UmGQmYKRDI6NLgV+Mx9wYKU5gna H0jg== X-Gm-Message-State: AKGB3mKzOxJBkG63wekd0bBxdJ9lQRj/1zY3zYTTuLzxspPH0CjqAy7w 3bIFpn+JjDC7RSK38ss14gHeWIUktdnF7vG5EXmFgFDc X-Google-Smtp-Source: ACJfBovUmT+3QrUB8QXhLePf8vCsOndF+//hqE3kDwNPBtYAfoq6OMXg9xr9EHKGb81tr3O7ztYDxQmnUmYyQAxLaq0= X-Received: by 10.80.161.167 with SMTP id 36mr9685505edk.38.1515268949244; Sat, 06 Jan 2018 12:02:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Sat, 6 Jan 2018 12:02:08 -0800 (PST) In-Reply-To: References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> From: John Lyon Date: Sat, 6 Jan 2018 15:02:08 -0500 Message-ID: Subject: Re: Need Netgraph Help [fixed] To: Julian Elischer 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: Sat, 06 Jan 2018 20:02:32 -0000 Thanks for the clarification and all the help. After Marko clarified that that edges/hooks are bidirectional, I was able to get it working WAN to LAN and LAN to WAN by using a pair of one2many and ETF nodes. The commands were (from memory): #Create Unfiltered WAN Path ngctl mkpeer igb0: one2many lower one ngctl name igb0:lower wanmux ngctl mkpeer wanmux: etf many0 downstream ngctl name wanmux:many0 wanfilter ngctl connect wanfilter: igb0: nomatch upper #Create Unfilter LAN Path ngctl mkpeer igb1: one2many lower one ngctl name igb1:lower lanmux ngctl mkpeer lanmux: etf many0 downstream ngctl name lanmux:many0 lanfilter ngctl connect lanfilter: igb1 nomatch upper #Cross Connect Two Paths ngctl connect wanfilter wanmux waneapout many1 ngctl connect lanfilter lanmux laneapout many1 #Filter Cross Connections ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" ethertype=3D0x888= e }' ngctl msg lanfilter: 'setfilter { matchhook=3D"laneapout" ethertype=3D0x888= e }' The graph looks like this: igb0] <----> [mux0] <---> [etf0] <----> [igb0 \ / X / \ igb1] <----> [mux1] <---> [etf1] <----> [igb1 It was conceptually easier for me to wrap my head around and it appears to work (somewhat). But if I can get it to work, I like Julian's approach better as it is simpler and uses fewer nodes. Thanks again for all the help! -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer wrote: > On 6/1/18 9:22 pm, John Lyon wrote: > > I just woke up with a follow-up question that may be my aha moment. Are > Netgraph edges between nodes always bidirectional? I have been treating a= ll > of the edges as unidirectional, requiring me to create two separate > Netgraphs. But if they are bidirectional, that would explain some things= . > > > yes edges are bidirectional > > see the following paragraph from the ng_etf man page: > ----- > Packets traveling in the other direction (towards the downstream hoo= k) > are also examined and filtered. If a packet has an ethertype that > matches one of the values configured into the node, it must have > arrived > in on the hook for which that value was configured, otherwise it wil= l > be > discarded. Ethertypes of values other than those configured by the > con- > trol messages must have arrived via the nomatch hook. > ----- > > here is the picture of what you need, > You will see this below in the old emails: > > so you need this: > > em0]lower---downstream[ETF0]nomatch---upper[em0... > eapout > | > | > eapout > em1]lower---downstream[ETF1]nomatch---upper[em1... > > ie. use an etf node on each interface. > > ngctl mkpeer igb0: etf lower downstream > ngctl name igb0:lower waneapfilter > ngctl connect waneapfilter: igb0: nomatch upper > > ngctl mkpeer igb1: etf lower downstream > ngctl name igb1:lower laneapfilter > ngctl connect laneapfilter: igb1: nomatch upper > > ngctl connect waneapfilter laneapfilter eapout eapout > > ngctl msg waneapfilter: 'setfilter { matchhook=3D"eapout" > ethertype=3D0x888e }' > ngctl msg laneapfilter: 'setfilter { matchhook=3D"eapout" > ethertype=3D0x888e }' > > > Thanks. > > Sent from my iPhone > > On Jan 5, 2018, at 11:16 PM, John Lyon wrote: > > Julian, > > So this didn't work when I tried to implement it on hardware in real life > and I can't figure out why. I am sure it's really basic, but the error > message is not very descriptive. > > I use the following script to create a graph that filters the EAP traffic > and forwards directly from the first Ethernet interface to the second. I= t > works perfectly. > > kldload ng_etf > ngctl mkpeer igb0: etf lower downstream > ngctl name igb0:lower waneapfilter > ngctl connect waneapfilter: igb0: nomatch upper > ngctl connect wanfilter: igb1: waneapout lower > ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" > ethertype=3D0x888e }' > > The end result is that EAPOL frames are forwarded directly from igb0 (WAN= ) > to igb1 (LAN). Graphically, it looks like (arrows indicating flow of > traffic): > > igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... > waneapout > | > |------>>lower[igb1.... > > However, I also need to do the reverse and forward EAPOL frames in the op= posite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrow= s indicating flow): > > igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... > laneapout > | > |------>>lower[igb0.... > > So I try a mirror image of my first script. However, when I type the fir= st line of: > > ngctl mkpeer igb1: etf lower downstream > > I get the following error message: > > ngctl: send msg: File exists. > > My guess (based on an earlier email in this thread) is that because I've = already connected my first NG_ETF node to the lower hook of igb1 (in order = to forward traffic out that interface), I am getting the error that the "Fi= le exists" when I try to connect a second ETF node to igb1 lower. If this = is the case, how can I write traffic out the interface, while filtering inc= oming traffic on the same interface? I tried to used two different ETF node= s, as suggested, but get an error message when I try. > > Thanks for any help. I feel like I am so close. At this point, I probab= ly should have just jumped ship and tried an alternate solution, but I just= can't allow the machine to win. :-) I have to get this working! > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer > wrote: > >> On 29/12/17 10:52 am, John Lyon wrote: >> >> It works!!! In virtual machine land at least, it works! It will be >> interesting to see what happens when the rubber meets the road and I >> actually test it "in the field." >> >> The issue was a missing single line that was not obvious from the man >> pages: >> >> sudo ngctl connect eapfilter: ix1: eapout lower >> >> your next issue will be that you can only attach em1:lower to a single >> peer at a time. So return packets can not DTRT. >> >> You will need to either put a multiplexing node in each interface, OR if >> I wrote it correctly, use the fact that packets fed into an etf match ho= ok >> will feed back out the input hook. >> >> so you need this: >> >> em0]lower---downstream[ETF0]nomatch---upper[em0... >> eapout >> | >> | >> eapout >> em1]lower---downstream[ETF1]nomatch---upper[em1... >> >> >> ie. use an etf node on each interface. >> >> >> >> >> >> >> >> Apparently, I had not created an alias for the connection between the ET= F >> and the ether nodes. Once this connect command was issued, the connecti= on >> to the lower hook of the ether node was ready to be connected to the ETF= . >> >> Thanks *so much* for your help. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer >> wrote: >> >>> On 28/12/17 9:59 pm, 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 hoo= k 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?) >>>> >>> >>> oops left out a line from the cut-n-paste... >>> >>>> >>>> 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 mkpeer ix0: etf lower downstream >>> >>>> $ 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=3D"eapout" >>>> ethertype=3D0x888e }' >>>> $ >>>> >>>> >>>> >>>>> 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 =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 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 wron= g? >>>>> >>>>> 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=C3=BCglich 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 downstre= am >>>>> ngctl name em0:lower lan_filter >>>>> ngctl connect em0: lan_filter: >>>>> upper nomatch >>>>> ngctl msg lan_filter: setfilter { >>>>> matchhook=3D"em1:lower" >>>>> ethertype=3D0x888e } >>>>> >>>>> 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=3Dmydrain' for th= e >>>>> '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 >>>>> " >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >>>> >>> >> >> > >