bridge+netfilter+libipq questions

bridge+netfilter+libipq questions

[Yong Li]

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!

indev_name in bridge+iptables?

[Yong]

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!

Re: indev_name in bridge+iptables?

[Scott MacKay]

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

Re: indev_name in bridge+iptables?

[Harald Welte]

[-- 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 --]