Ethernet bridge tables

Op vr, 25-02-2005 te 09:33 +0400, schreef Ramsurrun Visham:
> Hi,
> 
> I would like to know how does Ebtables interact directly with the
> networking stack. Applications like tcpdump have their packet flow
> separate from that of the normal packet flow. They simply tap in the
> normal flow and make a copy of the packets. What I would like to know
> is how to interact with that normal flow directly.
> 
> Bart, do you use the memcpy function to write into the ethernet frame?

Yes, see e.g.
net/bridge/netfilter/ebt_snat.c::ebt_target_snat()
You need to make sure the packet isn't shared (e.g. by tcpdump) before
altering the packet (see the code).

cheers,
Bart

Op wo, 23-02-2005 te 08:22 -0600, schreef Michael L Owen:
> 2) Add Squid as transparent Proxy (Accomplished, sort of).
> 
> With Squid in Transparent mode, all http requests are picked up by the 
> bridge device, and processed. All ebtables and iptables tables are in ACCEPT 
> mode (i.e. no rules in place yet). The problem at this point is that the 
> Squid responds to both sides of the bridge, and I need to limit all services 
> to the downstream side while allowing things like NetBIOS to be bridged. I 
> assume that this can be done with a combination of ebtable and iptable 
> rules, but I have been unable to find any viable examples so far. I'm 
> somewhat confused regarding the proper setup of the bridge for this as some 
> examples show a bridge(br0) with an IP assigned and two slave devices (eth0 
> and eth1) with no Ip's, while others show br0 with no IP and each slave 
> device with different two contiguous IP's assigned(like a 4-node subnet).

What exactly do you want? If you want to drop all IP traffic destined to
the bridge that arrived on a certain bridge port (say, eth0), just do
ebtables -A INPUT -i eth0 -j DROP

If you want the bridge to act as a router too, in such a way that one
side of the bridge has a different IP range than the other side of the
bridge, then it is best to implement a brouter because you can then
assign an IP address of the right range to both bridge ports, see the
examples page.
If you don't need 2 IP addresses for the bridge, then you don't need a
brouter.

cheers,
Bart

Op do, 24-02-2005 te 10:45 +0100, schreef Victor Garc=C3=ADa:
> I download ebtables using CVS, and when I do "make
> KERNEL_INCLUDES=3D/usr/src/linux/include/" in folder
> ebtables2/userspace/ebtables2 , the compilation return this error
>=20
> gcc -Wall -Wunused -DPROGVERSION=3D\"2.0.7\" -DPROGNAME=3D\"ebtables\"
> -DPROGDATE=3D\"January\ 2004\" -D_PATH_ETHERTYPES=3D\"/etc/ethertypes\"=
 -c
> ebtables-standalone.c ebtables.c -o ebtables-standalone.o
> -I/usr/src/linux/include/
> gcc: cannot specify -o with -c or -S and multiple compilations
> make: *** [ebtables-standalone.o] Error 1
>=20
> My gcc version is=20
>=20
> gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
>=20
> And I am working with kernel 2.6.8.1.
> Why does the compilation return this error?
>=20
> Thanks in advance

Hi, I've been searching the net but I haven't found a definite answer.
Please edit the Makefile so that
PROGDATE:=3DJanuary\ 2004
is changed into
PROGDATE:=3DJanuary2004

This deletes the space, which seems to be the most likely problem.
What happens now?

cheers,
Bart

Op di, 22-02-2005 te 10:31 +0400, schreef Ramsurrun Visham:
> Hi to all,
> 
> 
> I want to know if which part of the source code of ebtables is the code for modifying the mac address of ethernet frames is found. I know that such a thing is possible when we do SNAT & DNAT using ebtables rules.

Kernel part: ebt_snat.c and ebt_dnat.c in net/bridge/netfilter
Userspace part: extensions/ebt_nat.c

cheers,
Bart

Op vr, 18-02-2005 te 20:49 +0100, schreef Stefan Tauner:
> hi
> im using ebtables with only one interface in one bridge to filter for
> macs for traffic accounting.
> 
> everything works fine as long as i dont drop packets in the brouting
> chain (which shouldn't drop them but turn them over to the ip(filter)
> code), which i would like to use to avoid double queuing as described.
> 
> ebtables -t broute -A BROUTING -d mac:of:br0:and:eth0 -j DROP
> after that i dont get any response from that computer
> i tried different variations with -p arp or the redirect example from
> the hp (though br0 has the same mac as eth0)
> 
> any ideas?

How does your routing table look?

cheers,
Bart

On Fri, 18 Feb 2005 23:37:35 +0100, you wrote:

>How does your routing table look?

i knew you would ask that but forgot it anyway sry :)

Destination  Gateway      Genmask        Flags Metric Ref    Use Iface
192.168.0.0  0.0.0.0      255.255.255.0  U     0      0        0 br0
x.y.z.0      0.0.0.0      255.255.255.0  U     0      0        0 br0
0.0.0.0      x.y.z.1      0.0.0.0        UG    0      0        0 br0

Op za, 19-02-2005 te 07:08 +0100, schreef Stefan Tauner:
> On Fri, 18 Feb 2005 23:37:35 +0100, you wrote:
> 
> >How does your routing table look?
> 
> i knew you would ask that but forgot it anyway sry :)
> 
> Destination  Gateway      Genmask        Flags Metric Ref    Use Iface
> 192.168.0.0  0.0.0.0      255.255.255.0  U     0      0        0 br0
> x.y.z.0      0.0.0.0      255.255.255.0  U     0      0        0 br0
> 0.0.0.0      x.y.z.1      0.0.0.0        UG    0      0        0 br0

Try
ebtables -t broute -A BROUTING -p IPv4 -d mac:of:br0:and:eth0 -j DROP

See the "Speeding up traffic destinated to the bridge itself" on the
examples page.

cheers,
Bart

On Sat, 19 Feb 2005 19:09:07 +0100, you wrote:

>Try
>ebtables -t broute -A BROUTING -p IPv4 -d mac:of:br0:and:eth0 -j DROP
>
>See the "Speeding up traffic destinated to the bridge itself" on the
>examples page.

doesnt work either.

just to clarify: the difference between:
ebtables -t broute -A BROUTING -d mac:of:br0:and:eth0 -j DROP
and
ebtables -t broute -A BROUTING -p IPv4 -d mac:of:br0:and:eth0 -j DROP
is that the first cmd drops everything out of the link layer code into
the network layer code and the second does the same but only with
packets with 0x0800 in the ethernet type field.

so why should it work with with -p IPv4 when it doesnt work without?


i also forgot to mention that i use
"ifconfig eth0 hw ether mac:of:br0:and:eth0" as pre-up for eth0.
i need to do this because my isp does only allow 3 mac:ip pairs and
getting new nics registered with the support line is a pain :)
it worked perfectly even in windows so far but since ebtables sits
really deep in the network code i thought that could maybe be a
problem?

Op zo, 20-02-2005 te 10:37 +0100, schreef Stefan Tauner: 
> just to clarify: the difference between:
> ebtables -t broute -A BROUTING -d mac:of:br0:and:eth0 -j DROP
> and
> ebtables -t broute -A BROUTING -p IPv4 -d mac:of:br0:and:eth0 -j DROP
> is that the first cmd drops everything out of the link layer code into
> the network layer code and the second does the same but only with
> packets with 0x0800 in the ethernet type field.
> 
> so why should it work with with -p IPv4 when it doesnt work without?

That's because ARP requests and replies need to arrive on br0, because
the routing table uses br0.

> i also forgot to mention that i use
> "ifconfig eth0 hw ether mac:of:br0:and:eth0" as pre-up for eth0.
> i need to do this because my isp does only allow 3 mac:ip pairs and
> getting new nics registered with the support line is a pain :)
> it worked perfectly even in windows so far but since ebtables sits
> really deep in the network code i thought that could maybe be a
> problem?

Anything I try keeps working. The setup below, for example, works just
fine.

/etc/init.d/network stop
ifconfig eth0 hw ether 10:55:55:55:55:55
/etc/init.d/network start
# eth0 gets IP 192.168.0.131 via dhcp
brctl addbr br0
brctl addif br0 eth0
ifconfig eth0 0.0.0.0
ifconfig br0 192.168.0.131
ifconfig br0:1 192.167.0.131
route add default gw 192.168.0.1 dev br0
ebtables -t broute -A BROUTING -p IPv4 -d 10:55:55:55:55:55 -j DROP
arp -d 192.168.0.1
ping http://www.google.be

Routing table:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 br0
192.167.0.0     *               255.255.255.0   U     0      0        0 br0
default         192.168.0.1     0.0.0.0         UG    0      0        0 br0

ifconfig output:
br0       Link encap:Ethernet  HWaddr 10:50:50:50:50:50
          inet addr:192.168.0.131  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::1250:50ff:fe50:5050/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:904 (904.0 b)  TX bytes:4432 (4.3 KiB)

br0:1     Link encap:Ethernet  HWaddr 10:50:50:50:50:50
          inet addr:192.167.0.131  Bcast:192.167.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:904 (904.0 b)  TX bytes:4432 (4.3 KiB)

eth0      Link encap:Ethernet  HWaddr 10:50:50:50:50:50
          inet6 addr: fe80::1250:50ff:fe50:5050/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:123 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22416 (21.8 KiB)  TX bytes:17895 (17.4 KiB)
          Interrupt:11 Base address:0xc800

What are the big differences between my setup and yours?

cheers,
Bart

when i ping 192.168.0.255 i do get a reply from br0:0 (192.168.0.5)
when i ping x.y.z.255 i do get a reply from br0 (x.y.z.220) too
when i try unicast i dont get anything
when i ping from the brouter neither direct unicasts nor broadcasts
get replies altough the echo requests get out and the other network
devices reply (ethereal says so)

only difference (beside you're using ipv6 too) i noted is, that i dont
have traffic reports on my bridge alias
mine:
br0:0     Link encap:Ethernet  HWaddr 00:50:BA:11:FC:86 =20
          inet addr:192.168.0.5  Bcast:192.168.0.255
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

yours:
br0:1     Link encap:Ethernet  HWaddr 10:50:50:50:50:50
          inet addr:192.167.0.131  Bcast:192.167.0.255
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:904 (904.0 b)  TX bytes:4432 (4.3 KiB)

i also tried it now without everything set up in the interfaces but
typing the commands as you pasted them

Because of this
===============

iptables -t nat -A PREROUTING -i br0 -p tcp
--dport 80 -j REDIRECT --to-port 3128

===============

You could use the "physical interface" match extenstion in iptables to
specify that it is coming from the physical interface eth0


On Mon, 14 Feb 2005 20:53:37 -0800 (PST), tony vong
<tonyvong2002@...> wrote:
> Hi My linux box has two ports eth0 and eth1. I have
> already configured br0 and added eth0 and eth1 to br0.
> I want to redirec http traffic coming in from eth0 to
> the upper layer ip code. So I used the following two
> commands:
> 
> bash# ebtables -t broute -i eth0 -A BROUTING -p IPv4
> --ip-protocol 6 --ip-destination-port 80 -j redirect
> --redirect-target ACCEPT
> 
> bash# iptables -t nat -A PREROUTING -i br0 -p tcp
> --dport 80 -j REDIRECT --to-port 3128
> 
> However, I noticed that the http traffic coming in
> from eth1 also got redirected to upper layer IP code.
> 
> Is this a bug or what ?
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Ebtables-user mailing list
> Ebtables-user@...
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
> 


-- 
Mohamed Eldesoky
 http://www.eldesoky.net
RHCE

https://lists.netfilter.org/pipermail/netfilter-devel/2003-October/012884.html


From there, check their physdev match


On Thu, 17 Feb 2005 11:53:30 -0800 (PST), tony vong
<tonyvong2002@...> wrote:
> bash# ebtables -t broute -i eth0 -A BROUTING -p IPv4
> --ip-protocol 6 --ip-destination-port 80 -j redirect
> --redirect-target ACCEPT
> 
> bash# iptables -t nat -A PREROUTING -i br0 -p tcp
> --dport 80 -j REDIRECT --to-port 3128
> 
> If I am correct, the two statements above should only
> direct http traffic coming in from eth0 to IP layer.
> In other words, ip tables logging should not display
> http traffic coming in from eth1. But I am still
> seeing, in the iptables logging file, http traffic
> that arrives from from eth1!
> 
> Why is http traffic coming in from eth1 still being
> passed to iptables layer ???
> 
> 
> __________________________________
> Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
> http://promotions.yahoo.com/new_mail
> 


-- 
Mohamed Eldesoky
 http://www.eldesoky.net
RHCE

Op vr, 18-02-2005 te 15:23 +0400, schreef Ramsurrun Visham:
> can anyone tell me if it's posible to do load balancing with the br-nf code like we normally do with iptables.

The bridge-nf patch enables iptables to see bridged traffic, if that's
all that is needed for your purposes, then yes.

cheers,
Bart

Op do, 17-02-2005 te 11:52 -0800, schreef tony vong: 
> bash# ebtables -t broute -i eth0 -A BROUTING -p IPv4
> --ip-protocol 6 --ip-destination-port 80 -j redirect
> --redirect-target ACCEPT
> 
> bash# iptables -t nat -A PREROUTING -i br0 -p tcp
> --dport 80 -j REDIRECT --to-port 3128
> 
> If I am correct, the two statements above should only
> direct http traffic coming in from eth0 to IP layer.
> In other words, ip tables logging should not display
> http traffic coming in from eth1. But I am still
> seeing, in the iptables logging file, http traffic
> that arrives from from eth1!

What is your logging rule?
Your rules do not say anything about dropping packets.

What you probably want is something like this:

ebtables -t nat -A PREROUTING -i eth0 -p IPv4 --ip-destination-port 80 -j redurect --redirect-target ACCEPT
ebtables -t nat -A PREROUTING -p IPv4 -j DROP
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128

cheers,
Bart

PS: in the future, please direct these kind of questions only to the
ebtables-user mailing list.

Op di, 08-02-2005 te 15:07 +0100, schreef ebtables:
> Hello,
> 
> I'm trying to get the brouter config working
> My config:
> 
> eth0: 172.16.0.1
> eth1: 192.168.1.1
> Kernel: debian 2.6.8
> network cards: 3c900 & 3c905B
> 
> 
> Well, I'm doing
> 
> ifconfig eth0 0.0.0.0
> ifconfig eth1 0.0.0.0
> btcrl addbr br0
> brctl addif br0 eth0
> brctl addif br0 eth1
> ifconfig br0 0.0.0.0
> ifconfig eth0 172.16.0.1
> ifconfig eth1 192.168.1.1
> 
> Now... doing a ping (or anything else) to a host on one of the 2 networks does
> not work at all.
> 
> What is going wrong with my config??

The arp replies are entering your bridge on br0, while the arp requests
sent by your bridge box leave on ethx. You need to broute both ip and
arp messages in the BROUTING chain.

See "Making a brouter" at
http://ebtables.sourceforge.net/examples.html#easy

cheers,
Bart