Date: Sun, 7 Jan 2018 03:39:02 +0800 From: Julian Elischer <julian@freebsd.org> To: John Lyon <johnllyon@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eugene Grosbein <eugen@grosbein.net> Subject: Re: Need Netgraph Help [fixed] Message-ID: <c96502df-1ea3-555a-f773-1f402e753844@freebsd.org> In-Reply-To: <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> 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> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> <CAKfTJoUuxKKkZEo5%2Bnv98jqk3T2D77-CS-rdqvVUQE%2BczHpzrw@mail.gmail.com> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <CAKfTJoXdqm0Bj%2B85omHg6oiKhqDNkxfW5rs9nxsqH79qdCd9Gw@mail.gmail.com> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 all 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
hook)
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
will 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="eapout"
ethertype=0x888e }'
ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
>
> Thanks.
>
> Sent from my iPhone
>
> On Jan 5, 2018, at 11:16 PM, John Lyon <johnllyon@gmail.com
> <mailto:johnllyon@gmail.com>> 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. It 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="waneapout"
>> ethertype=0x888e }'
>>
>> 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 opposite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrows 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 first 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 "File 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 incoming traffic on the same interface? I tried to used two different ETF nodes, 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 probably 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
>> <julian@freebsd.org <mailto:julian@freebsd.org>> 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 hook 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 ETF and the ether nodes. Once this connect
>>> command was issued, the connection 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
>>> <https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>;
>>>
>>> On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer
>>> <julian@freebsd.org <mailto:julian@freebsd.org>> 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
>>> 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?)
>>>
>>>
>>> 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="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@freebsd.org <mailto:julian@freebsd.org>
>>> <mailto:julian@freebsd.org
>>> <mailto: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 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>;
>>> <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@omnilan.de
>>> <mailto:freebsd@omnilan.de>
>>> <mailto:freebsd@omnilan.de
>>> <mailto:freebsd@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@freebsd.org
>>> <mailto:freebsd-net@freebsd.org>
>>> <mailto:freebsd-net@freebsd.org
>>> <mailto:freebsd-net@freebsd.org>>
>>> mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> <https://lists.freebsd.org/mailman/listinfo/freebsd-net>;
>>> <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@freebsd.org
>>> <mailto:freebsd-net-unsubscribe@freebsd.org>
>>>
>>> <mailto:freebsd-net-unsubscribe@freebsd.org
>>> <mailto:freebsd-net-unsubscribe@freebsd.org>>"
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> freebsd-net@freebsd.org
>>> <mailto:freebsd-net@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@freebsd.org
>>> <mailto:freebsd-net-unsubscribe@freebsd.org>"
>>>
>>>
>>>
>>>
>>
>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c96502df-1ea3-555a-f773-1f402e753844>