From: Patrick McHardy <kaber@trash.net>
To: "Eliot, Wireless and Server Administrator,
Great Lakes Internet" <support8@greatlakes.net>
Cc: lartc@mailman.ds9a.nl,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
Date: Thu, 08 Jun 2006 07:41:59 +0000 [thread overview]
Message-ID: <4487D4C7.9060604@trash.net> (raw)
In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255436@xavier.staff.greatlakes.net>
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> Eh. What a pain. If I disable this, then ebtables will not call iptables
> after the ebtables are finished running. I figured out that I could use
> ebtables to match the destination MAC address like I needed for the
> other problem I posted (See "Bi-directional packet classification with
> ACK prioritization" thread for details). However, in order for that to
> work, I have to have bridge-nf-call-iptables enabled. Essentially, I can
> use the ebtables to flag the packets going to a destination MAC address
> and then inside the iptables POSTROUTING mangle chain, I can pick up
> that flag and reflag packets based on their Layer 3 and 4 information.
> But, then I run right back into the problem of this thread in that the
> packets are going through the TC qdiscs and classes before they hit the
> POSTROUTING mangle chain.
>
> Now, what confuses me is that I have this nice big printout of the order
> that the packets traverse ebtables, iptables, and tc which was made by
> Josh over at ImageStream (see
> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image)
> which clearly shows that it should go through ebtables POSTROUTING nat,
> then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC
> qdisc classification, then TC qdisc deque. Also, after reading
> http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty
> clear that the image depiction should be correct. But, since this is not
> happening, either the code has changed or both those sources are just
> wrong.
I guess both are wrong.
> Do you happen to have any idea how I can get this straightened out? Do
> we need to rewrite part of the code to make this work correctly? If that
> is what it takes, I would be more than happy to look into doing that.
Fixing this is one of my short-term TODO items, most likely before
2.6.18.
> Maybe we can write a --destination-mac option for the iptables MAC
> matching module? Is that information available to iptables in the
> POSTROUTING mangle or nat chains? If not, would it be at all possible to
> make it available? That would solve this problem very nicely.
No, iptables can't reliably get at this information (it might need
to be resolved first).
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: "Eliot, Wireless and Server Administrator,
Great Lakes Internet" <support8@greatlakes.net>
Cc: lartc@mailman.ds9a.nl,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
Date: Thu, 08 Jun 2006 09:41:59 +0200 [thread overview]
Message-ID: <4487D4C7.9060604@trash.net> (raw)
In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255436@xavier.staff.greatlakes.net>
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> Eh. What a pain. If I disable this, then ebtables will not call iptables
> after the ebtables are finished running. I figured out that I could use
> ebtables to match the destination MAC address like I needed for the
> other problem I posted (See "Bi-directional packet classification with
> ACK prioritization" thread for details). However, in order for that to
> work, I have to have bridge-nf-call-iptables enabled. Essentially, I can
> use the ebtables to flag the packets going to a destination MAC address
> and then inside the iptables POSTROUTING mangle chain, I can pick up
> that flag and reflag packets based on their Layer 3 and 4 information.
> But, then I run right back into the problem of this thread in that the
> packets are going through the TC qdiscs and classes before they hit the
> POSTROUTING mangle chain.
>
> Now, what confuses me is that I have this nice big printout of the order
> that the packets traverse ebtables, iptables, and tc which was made by
> Josh over at ImageStream (see
> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image)
> which clearly shows that it should go through ebtables POSTROUTING nat,
> then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC
> qdisc classification, then TC qdisc deque. Also, after reading
> http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty
> clear that the image depiction should be correct. But, since this is not
> happening, either the code has changed or both those sources are just
> wrong.
I guess both are wrong.
> Do you happen to have any idea how I can get this straightened out? Do
> we need to rewrite part of the code to make this work correctly? If that
> is what it takes, I would be more than happy to look into doing that.
Fixing this is one of my short-term TODO items, most likely before
2.6.18.
> Maybe we can write a --destination-mac option for the iptables MAC
> matching module? Is that information available to iptables in the
> POSTROUTING mangle or nat chains? If not, would it be at all possible to
> make it available? That would solve this problem very nicely.
No, iptables can't reliably get at this information (it might need
to be resolved first).
next prev parent reply other threads:[~2006-06-08 7:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-03 16:43 [LARTC] iptables CLASSIFY and MARK not working? Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-08 7:41 ` Patrick McHardy [this message]
2006-06-08 7:41 ` Patrick McHardy
-- strict thread matches above, loose matches on Subject: below --
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-19 17:31 ` Andreas Unterkircher
2006-05-19 19:26 ` Jody Shumaker
2006-05-22 21:56 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-23 4:32 ` Jody Shumaker
2006-05-30 19:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 19:49 ` Jason Boxman
2006-05-30 20:12 ` Luciano Ruete
2006-05-30 20:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 20:19 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 20:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 18:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 18:22 ` Patrick McHardy
2006-06-01 18:49 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 19:09 ` Patrick McHardy
2006-06-01 19:09 ` Patrick McHardy
2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 19:44 ` Patrick McHardy
2006-06-01 19:58 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 20:01 ` Patrick McHardy
2006-06-01 20:01 ` Patrick McHardy
2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 20:10 ` Patrick McHardy
2006-06-01 20:10 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4487D4C7.9060604@trash.net \
--to=kaber@trash.net \
--cc=lartc@mailman.ds9a.nl \
--cc=netfilter-devel@lists.netfilter.org \
--cc=support8@greatlakes.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.