Need Netgraph Help
Julian Elischer
julian at freebsd.org
Thu Dec 28 18:29:11 UTC 2017
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
> <julian at freebsd.org <mailto:julian at 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 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
>> <https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>
>>
>> On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer
>> <julian at freebsd.org <mailto:julian at freebsd.org>> 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
>>> <https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>
>>>
>>> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer
>>> <julian at freebsd.org <mailto:julian at 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 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
>>> <https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>
>>>
>>> On Fri, Dec 15, 2017 at 3:48 AM, Harry
>>> Schmalzbauer <freebsd at omnilan.de
>>> <mailto:freebsd at omnilan.de>>
>>> 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 at freebsd.org
>>> <mailto:freebsd-net at freebsd.org> mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> <https://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>> To unsubscribe, send any mail to
>>> "freebsd-net-unsubscribe at freebsd.org
>>> <mailto:freebsd-net-unsubscribe at freebsd.org>"
>>>
>>>
>>>
>>>
>>
>>
>
>
More information about the freebsd-net
mailing list