From owner-freebsd-net@freebsd.org Thu Dec 28 16:37:18 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 782B1EA7F55 for ; Thu, 28 Dec 2017 16:37:18 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 0A3341BBF; Thu, 28 Dec 2017 16:37:18 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id g75so45024495wme.0; Thu, 28 Dec 2017 08:37:17 -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=PawD6w+4oeWXoclqh5zM8oL73czp9gFumHjqaySdNus=; b=Jb/QtmNOEkwwwh5ar/kb7+vKZ9EMnpNuF2Ox1GfSGwZdzdGNUrblpa7aBIyGr6ENMO z25NxPFWpQb6VC6JejqChM8NqNPyzaSxGWulWs3qqYxeXqn8qtIky1DU0aD2bIWmo5rI mGggErDHJHMb9anC1WSFGHc8eRQUYn1dlcBOEmWn+EB4Dbk+un8G/xScKVCzUF65FJRD O/iz0EXfsQaJ4tu+aIIAtbIhuJzGbFjO4qJHA74NdwGJKAPdq0ltH4HR97mxH6pIcXC7 E+AIdcH8JDvhKtFpnj3OT2oDOXEji0YADqLuJjfVt4qwkQl5m3MnOHvAWukEEwfLrtvx BlCg== 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=PawD6w+4oeWXoclqh5zM8oL73czp9gFumHjqaySdNus=; b=Wo4yU5XBECozD41L5hOaemVfEBlj1S/vOZJh2MmLXZa6blwIkE6cGqbP5BQCCfX0Cf F7/NtR7Ic+mwXwBz2x+4nnOaUl+15BrxTvGOhyCHWLLTbP+mMTZWzeiwqbKUl1UiymLu aae8i3m7BrZvo6YgaiTY+XlPt0+LnhJxOLT7bN0BLi9axFwu/SD1lDO044Ixcsv5A5xy lP+lEGrzz64exHLAdOmEmrAZ5hGDuwHkUitaXO0RLIEjUx2fpteyN8A6LluQEdcbNj6m 4/3NBId/DYrY9a8xzyV2BosYAjn7zhQAZyIYfA63rUtUUPvFujeyCXalfGphAr/D2LzW 69kg== X-Gm-Message-State: AKGB3mL5h1Sa1pOsm6vePP1g1vlMSeRwOJeLPjo0jzXf+KfsHP1Rz8Xk Znq1iCwNTlhR8RXOVIRvZgI4gojAO+ddadrWwc1DOMAM X-Google-Smtp-Source: ACJfBosyllFsiqv57mVbZCq7zoqpClBrFWeNoAbyR0uz/PsxmeGjFox3e12HLTdD37RkyzAc7yUVDVbPmrO0ohUVhRI= X-Received: by 10.80.230.3 with SMTP id y3mr41268558edm.211.1514479035760; Thu, 28 Dec 2017 08:37:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Thu, 28 Dec 2017 08:36:55 -0800 (PST) In-Reply-To: <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> 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: John Lyon Date: Thu, 28 Dec 2017 11:36:55 -0500 Message-ID: Subject: Re: Need Netgraph Help 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: Thu, 28 Dec 2017 16:37:18 -0000 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. -------------------------------- 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 in the 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 tha= t >> this is just a PEBKAC issue, but I have tried every permutation of escap= e >> characters in case it's an issue with my syntax and I get the same set o= f >> errors. No matter what I do, I can't connect the no match hook of an ET= F >> node to the upper hook of an ng_ether node. Do you have any insights in= to >> 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=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 th= e >>>> em1 >>>> already exist (I can confirm this). >>>> >>>> 2) referenced "matchook" is *not* downstream hook, or else you get err= or >>>>>> 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) tha= t >>>> 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=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (local= time): >>>>> >>>>>> 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 crypt= ic >>>>>>>>> >>>>>>>> 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 m= y >>>>>>>>> LAN >>>>>>>>> interface. Any ethernet frames that correspond to EAP traffic ne= ed >>>>>>>>> >>>>>>>> to be >>>>> >>>>>> immediately forwarded from the LAN interface to my WAN interface. A= ll >>>>>>>>> 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=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 nam= e" >>>>>> >>>>> 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 the 'msg' comm= and. >>>>> >>>>> 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" >>>> >>>> >>>> >>> >> >> > >