Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Dec 2017 11:36:55 -0500
From:      John Lyon <johnllyon@gmail.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>
Subject:   Re: Need Netgraph Help
Message-ID:  <CAKfTJoX-r1Y7qy76bgV3tsAbdtiOdFQ4Am7MDkV3m-as4FuZEQ@mail.gmail.com>
In-Reply-To: <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org>
References:  <CAKfTJoUMxo7gsio7JJD8Vj_xPgFx5YEBH3_XViFhR0dt59==Dw@mail.gmail.com> <5A3225BF.6020205@omnilan.de> <CAKfTJoX78JhqsvB669Gxsr5UtZkbwuZrnVhOdU2UMacF7FmP1g@mail.gmail.com> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <CAKfTJoW5H82VLyBZ_5_sa9HU7Xbot7imeiP-ogVCNkHGe0_30Q@mail.gmail.com> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <CAKfTJoXe%2BZjDEMbF12-JcwBAs0uQoAFYAC3g1A_d0yM8by-z6g@mail.gmail.com> <ac0e236e-f27c-d4ed-8527-010dd025efff@freebsd.org> <CAKfTJoWE31p%2Brx2CUyb6p-D1m7iTJ3tNzzp%2BkqPxH0DSBdXnag@mail.gmail.com> <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <julian@freebsd.org>
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 <julian@freebsd.org>
> 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 <julian@freebsd.org>
>> 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 <freebsd@omnilan.d=
e
>>>> >
>>>> 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"
>>>>
>>>>
>>>>
>>>
>>
>>
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKfTJoX-r1Y7qy76bgV3tsAbdtiOdFQ4Am7MDkV3m-as4FuZEQ>