Need Netgraph Help [fixed]
Julian Elischer
julian at freebsd.org
Sat Jan 6 20:06:24 UTC 2018
On 7/1/18 4:02 am, John Lyon wrote:
> 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="waneapout"
> ethertype=0x888e }'
> ngctl msg lanfilter: 'setfilter { matchhook="laneapout"
> ethertype=0x888e }'
>
> 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.
etf includes a mux/demux.. the link is bidirectional.
>
> 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 <julian at freebsd.org
> <mailto:julian at freebsd.org>> 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 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 at gmail.com
>> <mailto:johnllyon at 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
>>> <https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>
>>>
>>> On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer
>>> <julian at freebsd.org <mailto:julian at 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 at freebsd.org <mailto:julian at 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 at freebsd.org
>>>> <mailto:julian at freebsd.org>
>>>> <mailto: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>
>>>> <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>
>>>> <mailto: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>
>>>> <mailto: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>
>>>> <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>
>>>>
>>>> <mailto:freebsd-net-unsubscribe at freebsd.org
>>>> <mailto:freebsd-net-unsubscribe at freebsd.org>>"
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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