* bridge+netfilter+libipq questions
[not found] <20030707222621.16976.2349.Mailman@kashyyyk>
@ 2003-07-08 14:35 ` Yong Li
2003-07-09 5:11 ` indev_name in bridge+iptables? Yong
1 sibling, 0 replies; 4+ messages in thread
From: Yong Li @ 2003-07-08 14:35 UTC (permalink / raw)
To: netfilter-devel
Hello All,
I have set up a bridge+Iptables on Linux. I use this rule:
iptables -A FORWARD ... -j QUEUE
I found the packet IN/OUT device are the same: our bridge port br0. I want
to recognize the IN and OUT packet in the userspace application using the
IN/OUT device in libipq, how to set the iptables rule?
Thank you!
^ permalink raw reply [flat|nested] 4+ messages in thread
* indev_name in bridge+iptables?
[not found] <20030707222621.16976.2349.Mailman@kashyyyk>
2003-07-08 14:35 ` bridge+netfilter+libipq questions Yong Li
@ 2003-07-09 5:11 ` Yong
2003-07-12 15:27 ` Scott MacKay
1 sibling, 1 reply; 4+ messages in thread
From: Yong @ 2003-07-09 5:11 UTC (permalink / raw)
To: netfilter-devel
Hello All,
I have a question about the ipq_packet_msg_t struct in bridge+iptables environment.
In the forward chain, the indev and outdev name are the same: br0(my bridge port).
In the mangle prerouting chain, the indev is br0, the outdev is null.
How to get the real in/out device(it is eth0 and eth1)?
Thanks in advance!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: indev_name in bridge+iptables?
2003-07-09 5:11 ` indev_name in bridge+iptables? Yong
@ 2003-07-12 15:27 ` Scott MacKay
2003-07-14 7:41 ` Harald Welte
0 siblings, 1 reply; 4+ messages in thread
From: Scott MacKay @ 2003-07-12 15:27 UTC (permalink / raw)
To: Yong, netfilter-devel
Hi, I had the exact same thing. The physical name is
not passed up in the message, sucks huh?
What I resorted to was to alter the kernel code for
the QUEUE messages. The low level structure has the
physical device names in it, but are not passed up. I
altered it so if there was a physical device name for
in & out, it copied those values over the existing
indev and outdev names (since 'br0' is pretty
useless). There is only 1 file to change, but can't
remember it off the top of my head. The 'real' method
would be to alter the _msg structure to include the
physdev names in it, but I was lazy :P
-Scott
--- Yong <sdssly@sina.com> wrote:
> Hello All,
>
> I have a question about the ipq_packet_msg_t struct
> in bridge+iptables environment.
>
> In the forward chain, the indev and outdev name are
> the same: br0(my bridge port).
>
> In the mangle prerouting chain, the indev is br0,
> the outdev is null.
>
> How to get the real in/out device(it is eth0 and
> eth1)?
>
> Thanks in advance!
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: indev_name in bridge+iptables?
2003-07-12 15:27 ` Scott MacKay
@ 2003-07-14 7:41 ` Harald Welte
0 siblings, 0 replies; 4+ messages in thread
From: Harald Welte @ 2003-07-14 7:41 UTC (permalink / raw)
To: Scott MacKay; +Cc: Yong, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
On Sat, Jul 12, 2003 at 08:27:59AM -0700, Scott MacKay wrote:
> Hi, I had the exact same thing. The physical name is
> not passed up in the message, sucks huh?
>
> What I resorted to was to alter the kernel code for
> the QUEUE messages. The low level structure has the
> physical device names in it, but are not passed up. I
> altered it so if there was a physical device name for
> in & out, it copied those values over the existing
> indev and outdev names (since 'br0' is pretty
> useless). There is only 1 file to change, but can't
> remember it off the top of my head. The 'real' method
> would be to alter the _msg structure to include the
> physdev names in it, but I was lazy :P
The reason for this dilemma is historical:
- ip_queue was in the kernel first (since pre 2.4.0)
- support for bridging firewalls was added later
- real support for physdev matching in iptables is only available
for kernel 2.5.x
- changing the ipq_msg structure would render all previous versions of
libipq (and existing ip_queue using applications) incompatible with
new kernels
Combined with the fact that bridging firewalls still seem very rare,
we'd rather stick with compatibility instead of adding that feature...
... however, a patch is always welcome and we'd put it into
patch-o-matic 'experimental' or something.
> -Scott
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-07-14 7:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20030707222621.16976.2349.Mailman@kashyyyk>
2003-07-08 14:35 ` bridge+netfilter+libipq questions Yong Li
2003-07-09 5:11 ` indev_name in bridge+iptables? Yong
2003-07-12 15:27 ` Scott MacKay
2003-07-14 7:41 ` Harald Welte
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.