unexpected behavior of ebtables' BROUTING target redirect

[k***@digmore.net]

Hello,

I have a bridge with a single ebtables rule to redirect all=20
IPv4-containing frames to layer 3 filtering:

# ebtables -t broute -A BROUTING -p IPV4 -j redirect --redirect-target=20
DROP --log-level notice --log-prefix "br_br_br: "

then, if I send a frame containing IPv4 from one host to another one=20
connected on another port of the bridge, I am supposed to get the=20
destination MAC address to be the one of the bridge port it entered the=
=20
bridge if I believe the documentation.

Or, logging packets with iptables, I see the source MAC address to=20
become the bridge port address, and the destination MAC address the one=
=20
of the host the message came from.

I am lost on this issue, it does not make sense to me and wonder where =
I=20
failed=E2=80=A6

Thanks a lot for any help, see below for details.

---- log on the bridge -----

Aug 28 11:15:08 spy kernel: [ 4952.682369] br_br_br: IN=3Deth0 OUT=3D=
MAC=20
source =3D 08:00:27:d5:24:36 MAC dest =3D 08:00:27:17:49:6d proto =3D 0=
x0800
Aug 28 11:15:08 spy kernel: [ 4952.682406] ip_raw_pre: IN=3Deth0 OUT=3D=
=20
MAC=3D08:00:27:df:b7:98:08:00:27:d5:24:36:08:00 SRC=3D192.168.142.103=20
DST=3D192.168.142.254 LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID=3D1 P=
ROTO=3DTCP=20
SPT=3D20 DPT=3D80 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0
Aug 28 11:15:08 spy kernel: [ 4952.682443] ip_man_pre: IN=3Deth0 OUT=3D=
=20
MAC=3D08:00:27:df:b7:98:08:00:27:d5:24:36:08:00 SRC=3D192.168.142.103=20
DST=3D192.168.142.254 LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID=3D1 P=
ROTO=3DTCP=20
SPT=3D20 DPT=3D80 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0
Aug 28 11:15:08 spy kernel: [ 4952.682464] ip_nat_pre: IN=3Deth0 OUT=3D=
=20
MAC=3D08:00:27:df:b7:98:08:00:27:d5:24:36:08:00 SRC=3D192.168.142.103=20
DST=3D192.168.142.254 LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID=3D1 P=
ROTO=3DTCP=20
SPT=3D20 DPT=3D80 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0

---- ip a on bridge ----

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast=20
master br0 state UP qlen 1000
link/ether 08:00:27:df:b7:98 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast=20
master br0 state UP qlen 1000
link/ether 08:00:27:d8:32:61 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state=20
UP
link/ether 08:00:27:d8:32:61 brd ff:ff:ff:ff:ff:ff
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Pascal Hambourg]

Hello,

Post by k***@digmore.net
=20
I have a bridge with a single ebtables rule to redirect all=20
=20
# ebtables -t broute -A BROUTING -p IPV4 -j redirect --redirect-targe=

t=20

Post by k***@digmore.net
DROP --log-level notice --log-prefix "br_br_br: "
=20
then, if I send a frame containing IPv4 from one host to another one=20
connected on another port of the bridge, I am supposed to get the=20
destination MAC address to be the one of the bridge port it entered t=

he=20

Post by k***@digmore.net
bridge if I believe the documentation.
=20
Or, logging packets with iptables, I see the source MAC address to=20
become the bridge port address, and the destination MAC address the o=

ne=20

Post by k***@digmore.net
of the host the message came from.
=20
---- log on the bridge -----
=20
Aug 28 11:15:08 spy kernel: [ 4952.682369] br_br_br: IN=3Deth0 OUT=3D=

MAC=20

Post by k***@digmore.net
source =3D 08:00:27:d5:24:36 MAC dest =3D 08:00:27:17:49:6d proto =3D=

0x0800

Post by k***@digmore.net
Aug 28 11:15:08 spy kernel: [ 4952.682406] ip_raw_pre: IN=3Deth0 OUT=3D=

=20

Post by k***@digmore.net
MAC=3D08:00:27:df:b7:98:08:00:27:d5:24:36:08:00 SRC=3D192.168.142.103=

=20

Post by k***@digmore.net
---- ip a on bridge ----
=20
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast=20
master br0 state UP qlen 1000
link/ether 08:00:27:df:b7:98 brd ff:ff:ff:ff:ff:ff

I see nothing wrong here. The value following MAC=3D is the Ethernet
header in network order, i.e. destination:source:protocol.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html