ebtables-devel — Development questions, bugs, patches

[Ebtables-devel] Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log

[Harald W. <la...@ne...>]

On Tue, Oct 11, 2005 at 07:31:50PM +0000, Bart De Schuymer wrote:
> I seem to be unable to get Davem's current git tree.
> This fails miserably: 
> cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git

Try getting it via rsync, I never have successfully ran cg/git via http.

Also, a recent linus tree should be sufficient, even one of the latest
2.6.14-rc3/rc4 tarballs should be fine.

> Your patch won't apply to 2.6.13. At first I thought it was a problem
> with evolution or the kernel version, but looking at the source code of
> your mail, I see "=20" added here and there...

I've attached it to this mail again.  Since it isn't inline, saving it
as attachment should do fine.

-- 
- Harald Welte <la...@ne...>                 http://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

Re: [Ebtables-devel] Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log

[Bart De S. <bds...@pa...>]

Op di, 11-10-2005 te 12:55 -0700, schreef David S. Miller:
> From: Bart De Schuymer <bds...@pa...>
> Date: Tue, 11 Oct 2005 19:31:50 +0000
> 
> > I seem to be unable to get Davem's current git tree.
> > This fails miserably: 
> > cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> 
> I use an "alternates" file, so that Linus's tree's objects get used
> and only the truly local changes actually get stored in my tree.
> 
> Unfortunately that totally doesn't work with transports such
> as rsync.

OK, kernel now compiling without the patch. Harald, could you send it as
attachment?

The instructions at the top of http://www.kernel.org/git/ are somewhat
outdated.

cheers,
Bart

[Ebtables-devel] Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log

[David S. M. <da...@da...>]

From: Bart De Schuymer <bds...@pa...>
Date: Tue, 11 Oct 2005 19:31:50 +0000

> I seem to be unable to get Davem's current git tree.
> This fails miserably: 
> cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git

I use an "alternates" file, so that Linus's tree's objects get used
and only the truly local changes actually get stored in my tree.

Unfortunately that totally doesn't work with transports such
as rsync.

[Ebtables-devel] Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log

[Bart De S. <bds...@pa...>]

Op za, 08-10-2005 te 01:49 +0200, schreef Harald Welte:
> Hi Bart!
> 
> The patch below is totally untested (though it compiles), and updates
> ebtables to resemble the behaviour that we now have in ipv4 (and ipv6):
> {ip,ip6,eb}tables just tell the nf_log core that they want to log a
> packet, the mechanism (syslog, nfnetlink_log, ...) is actually decided
> by nf_log.
> 
> By default, everything will behave like before.
> 
> Please review, and test that ebt_log and ebt_ulog are still working as
> expected.  Thanks!
> 
> [NETFILTER] ebtables: Port ebt_[u]log.c to nf[netlink]_log
> 
> Since we now have a netfilter core logging API, we port the bridging log
> and ulog watchers to this new API.
> 
> This basically means that if you use the "ebt_log" watcher, it will by
> default log to the system console, but enables a userspace logging daemon
> binds itself to PF_BRIDGE, and take over all logging.
> 
> ebt_ulog also registers itself as logger with nf_log, but any packets
> explicitly send to ebt_ulog will always use the ulog mechanism and not
> handled via the generic logging handler.
> 
> This change resembles the situation that is now present in ipv4.

I seem to be unable to get Davem's current git tree.
This fails miserably: 
cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git

Your patch won't apply to 2.6.13. At first I thought it was a problem
with evolution or the kernel version, but looking at the source code of
your mail, I see "=20" added here and there...

Any ideas?

cheers,
Bart

Re: [Ebtables-devel] Simulating Communications Links

[Stephen H. <she...@os...>]

On Sun, 09 Oct 2005 15:40:25 +0000
"Ian Wright" <ian...@ho...> wrote:

> I'm wondering if anyone can give me a little advice. I'm fairly new to 
> network programming, and completely new to linux, yet it looks like I'm 
> going to have to use both for my final year project at university.
> 
> The requirement that I've been given is basically to delay and drop packets 
> randomly to simulate a communications link. The probability of dropping or 
> delaying a packet will depend on certain variables set by a user (in a GUI 
> if possible) indicating the length of the physical link and the % of network 
> load to network capacity. My project supervisor wants these delayed and 
> dropped packets to occur at the MAC level, and someone suggested using 
> ebtables which I'd never heard of before.
> 
> I'm just wondering how difficult it is to start using ebtables, and how 
> difficult would it be to modify it to create random drops/delays?
> 
> Hopefully what this will allow, is a user to experience the effects of 
> different multiple access schemes, different network loads and different 
> link lengths (eg satellite) via a streamed video.
> 
> Thanks for any help everyone
> 
> Ian W
> 
> 

You don't need ebtables for this, use netem
	see http://linux-net.osdl.org/index.php/Netem

-- 
Stephen Hemminger <she...@os...>
OSDL http://developer.osdl.org/~shemminger

Re: [Ebtables-devel] Simulating Communications Links

[Bart De S. <bds...@pa...>]

Op zo, 09-10-2005 te 15:40 +0000, schreef Ian Wright:
> I'm wondering if anyone can give me a little advice. I'm fairly new to 
> network programming, and completely new to linux, yet it looks like I'm 
> going to have to use both for my final year project at university.
> 
> The requirement that I've been given is basically to delay and drop packets 
> randomly to simulate a communications link. The probability of dropping or 
> delaying a packet will depend on certain variables set by a user (in a GUI 
> if possible) indicating the length of the physical link and the % of network 
> load to network capacity. My project supervisor wants these delayed and 
> dropped packets to occur at the MAC level, and someone suggested using 
> ebtables which I'd never heard of before.
> 
> I'm just wondering how difficult it is to start using ebtables, and how 
> difficult would it be to modify it to create random drops/delays?

It's simple, you don't need much knowledge about the inner working, just
start from a module that is already written, any target module should
do. This could be helpful too:
http://ebtables.sourceforge.net/ebtables-hacking/ebtables-hacking-HOWTO.html


To use ebtables on a non-bridge, see
http://ebtables.sourceforge.net/examples.html#ex_nobridge

cheers,
Bart

[Ebtables-devel] Simulating Communications Links

[Ian W. <ian...@ho...>]

I'm wondering if anyone can give me a little advice. I'm fairly new to 
network programming, and completely new to linux, yet it looks like I'm 
going to have to use both for my final year project at university.

The requirement that I've been given is basically to delay and drop packets 
randomly to simulate a communications link. The probability of dropping or 
delaying a packet will depend on certain variables set by a user (in a GUI 
if possible) indicating the length of the physical link and the % of network 
load to network capacity. My project supervisor wants these delayed and 
dropped packets to occur at the MAC level, and someone suggested using 
ebtables which I'd never heard of before.

I'm just wondering how difficult it is to start using ebtables, and how 
difficult would it be to modify it to create random drops/delays?

Hopefully what this will allow, is a user to experience the effects of 
different multiple access schemes, different network loads and different 
link lengths (eg satellite) via a streamed video.

Thanks for any help everyone

Ian W

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters

[Ebtables-devel] [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log

[Harald W. <la...@ne...>]

Hi Bart!

The patch below is totally untested (though it compiles), and updates
ebtables to resemble the behaviour that we now have in ipv4 (and ipv6):
{ip,ip6,eb}tables just tell the nf_log core that they want to log a
packet, the mechanism (syslog, nfnetlink_log, ...) is actually decided
by nf_log.

By default, everything will behave like before.

Please review, and test that ebt_log and ebt_ulog are still working as
expected.  Thanks!

[NETFILTER] ebtables: Port ebt_[u]log.c to nf[netlink]_log

Since we now have a netfilter core logging API, we port the bridging log
and ulog watchers to this new API.

This basically means that if you use the "ebt_log" watcher, it will by
default log to the system console, but enables a userspace logging daemon
binds itself to PF_BRIDGE, and take over all logging.

ebt_ulog also registers itself as logger with nf_log, but any packets
explicitly send to ebt_ulog will always use the ulog mechanism and not
handled via the generic logging handler.

This change resembles the situation that is now present in ipv4.

Signed-off-by: Harald Welte <la...@ne...>

---
commit 0dc2bc0656b4b1c5ba3524dadc8fbf36881903b7
tree 0e43d4f7b10f022ff523ea4751546d76d53c57b7
parent 2e64e94fe8e7e4630c9d9e66c437f3ba81e99f78
author Harald Welte <la...@ne...> Sat, 08 Oct 2005 01:43:49 +0200
committer Harald Welte <la...@ne...> Sat, 08 Oct 2005 01:43:49 +0=
200

 net/bridge/netfilter/Kconfig    |    6 +++-
 net/bridge/netfilter/ebt_log.c  |   61 +++++++++++++++++++++++++++++++++--=
----
 net/bridge/netfilter/ebt_ulog.c |   48 +++++++++++++++++++++++++++++--
 3 files changed, 102 insertions(+), 13 deletions(-)

diff --git a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig
--- a/net/bridge/netfilter/Kconfig
+++ b/net/bridge/netfilter/Kconfig
@@ -196,9 +196,13 @@ config BRIDGE_EBT_LOG
 	  To compile it as a module, choose M here.  If unsure, say N.
=20
 config BRIDGE_EBT_ULOG
-	tristate "ebt: ulog support"
+	tristate "ebt: ulog support (OBSOLETE)"
 	depends on BRIDGE_NF_EBTABLES
 	help
+	  This option enables the old bridge-specific "ebt_ulog" implementation
+	  which has been obsoleted by the new "nfnetlink_log" code (see
+	  CONFIG_NETFILTER_NETLINK_LOG).
+
 	  This option adds the ulog watcher, that you can use in any rule
 	  in any ebtables table. The packet is passed to a userspace
 	  logging daemon using netlink multicast sockets. This differs
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -3,6 +3,7 @@
  *
  *	Authors:
  *	Bart De Schuymer <bds...@pa...>
+ *	Harald Welte <la...@ne...>
  *
  *  April, 2002
  *
@@ -10,6 +11,7 @@
=20
 #include <linux/netfilter_bridge/ebtables.h>
 #include <linux/netfilter_bridge/ebt_log.h>
+#include <linux/netfilter.h>
 #include <linux/module.h>
 #include <linux/ip.h>
 #include <linux/if_arp.h>
@@ -55,17 +57,19 @@ static void print_MAC(unsigned char *p)
 }
=20
 #define myNIPQUAD(a) a[0], a[1], a[2], a[3]
-static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
-   const struct net_device *in, const struct net_device *out,
-   const void *data, unsigned int datalen)
+static void
+ebt_log_packet(unsigned int pf, unsigned int hooknum,
+   const struct sk_buff *skb, const struct net_device *in,
+   const struct net_device *out, const struct nf_loginfo *loginfo,
+   const char *prefix)
 {
-	struct ebt_log_info *info =3D (struct ebt_log_info *)data;
 	char level_string[4] =3D "< >";
+	unsigned int bitmask;
=20
-	level_string[1] =3D '0' + info->loglevel;
+	level_string[1] =3D '0' + loginfo->u.log.level;
 	spin_lock_bh(&ebt_log_lock);
 	printk(level_string);
-	printk("%s IN=3D%s OUT=3D%s ", info->prefix, in ? in->name : "",
+	printk("%s IN=3D%s OUT=3D%s ", prefix, in ? in->name : "",
 	   out ? out->name : "");
=20
 	printk("MAC source =3D ");
@@ -75,7 +79,12 @@ static void ebt_log(const struct sk_buff
=20
 	printk("proto =3D 0x%04x", ntohs(eth_hdr(skb)->h_proto));
=20
-	if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto =3D=3D
+	if (loginfo->type =3D=3D NF_LOG_TYPE_LOG)
+		bitmask =3D loginfo->u.log.logflags;
+	else
+		bitmask =3D NF_LOG_MASK;
+
+	if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto =3D=3D
 	   htons(ETH_P_IP)){
 		struct iphdr _iph, *ih;
=20
@@ -104,7 +113,7 @@ static void ebt_log(const struct sk_buff
 		goto out;
 	}
=20
-	if ((info->bitmask & EBT_LOG_ARP) &&
+	if ((bitmask & EBT_LOG_ARP) &&
 	    ((eth_hdr(skb)->h_proto =3D=3D htons(ETH_P_ARP)) ||
 	     (eth_hdr(skb)->h_proto =3D=3D htons(ETH_P_RARP)))) {
 		struct arphdr _arph, *ah;
@@ -144,6 +153,21 @@ static void ebt_log(const struct sk_buff
 out:
 	printk("\n");
 	spin_unlock_bh(&ebt_log_lock);
+
+}
+
+static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
+   const struct net_device *in, const struct net_device *out,
+   const void *data, unsigned int datalen)
+{
+	struct ebt_log_info *info =3D (struct ebt_log_info *)data;
+	struct nf_loginfo li;
+
+	li.type =3D NF_LOG_TYPE_LOG;
+	li.u.log.level =3D info->loglevel;
+	li.u.log.logflags =3D info->bitmask;
+
+	nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
 }
=20
 static struct ebt_watcher log =3D
@@ -154,13 +178,32 @@ static struct ebt_watcher log =3D
 	.me		=3D THIS_MODULE,
 };
=20
+static struct nf_logger ebt_log_logger =3D {
+	.name 		=3D "ebt_log",
+	.logfn		=3D &ebt_log_packet,
+	.me		=3D THIS_MODULE,
+};
+
 static int __init init(void)
 {
-	return ebt_register_watcher(&log);
+	int ret;
+
+	ret =3D ebt_register_watcher(&log);
+	if (ret < 0)
+		return ret;
+	if (nf_log_register(PF_BRIDGE, &ebt_log_logger) < 0) {
+		printk(KERN_WARNING "ebt_log: not logging via system console "
+		       "since somebody else already registered for PF_INET\n");
+		/* wecannot make module load fail here, since otherwise=20
+		 * ebtables userspace would abort */
+	}
+
+	return 0;
 }
=20
 static void __exit fini(void)
 {
+	nf_log_unregister_logger(&ebt_log_logger);
 	ebt_unregister_watcher(&log);
 }
=20
diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulo=
g.c
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -3,6 +3,7 @@
  *
  *	Authors:
  *	Bart De Schuymer <bds...@pa...>
+ *	Harald Welte <la...@ne...>
  *
  *  November, 2004
  *
@@ -115,14 +116,13 @@ static struct sk_buff *ulog_alloc_skb(un
 	return skb;
 }
=20
-static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+static void ebt_ulog_packet(unsigned int hooknr, const struct sk_buff *skb,
    const struct net_device *in, const struct net_device *out,
-   const void *data, unsigned int datalen)
+   const struct ebt_ulog_info *uloginfo, const char *prefix)
 {
 	ebt_ulog_packet_msg_t *pm;
 	size_t size, copy_len;
 	struct nlmsghdr *nlh;
-	struct ebt_ulog_info *uloginfo =3D (struct ebt_ulog_info *)data;
 	unsigned int group =3D uloginfo->nlgroup;
 	ebt_ulog_buff_t *ub =3D &ulog_buffers[group];
 	spinlock_t *lock =3D &ub->lock;
@@ -216,6 +216,39 @@ alloc_failure:
 	goto unlock;
 }
=20
+/* this function is registered with the netfilter core */
+static void ebt_log_packet(unsigned int pf, unsigned int hooknum,
+   const struct sk_buff *skb, const struct net_device *in,
+   const struct net_device *out, const struct nf_loginfo *li,
+   const char *prefix)
+{
+	struct ebt_ulog_info loginfo;
+
+	if (!li || li->type !=3D NF_LOG_TYPE_ULOG) {
+		loginfo.nlgroup =3D EBT_ULOG_DEFAULT_NLGROUP;
+		loginfo.cprange =3D 0;
+		loginfo.qthreshold =3D EBT_ULOG_DEFAULT_QTHRESHOLD;
+		loginfo.prefix[0] =3D '\0';
+	} else {
+		loginfo.nlgroup =3D li->u.ulog.group;
+		loginfo.cprange =3D li->u.ulog.copy_len;
+		loginfo.qthreshold =3D li->u.ulog.qthreshold;
+		strlcpy(loginfo.prefix, prefix, sizeof(loginfo.prefix));
+	}
+
+	ebt_ulog_packet(hooknum, skb, in, out, &loginfo, prefix);
+}
+
+static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+   const struct net_device *in, const struct net_device *out,
+   const void *data, unsigned int datalen)
+{
+	struct ebt_ulog_info *uloginfo =3D (struct ebt_ulog_info *)data;
+
+	ebt_ulog_packet(hooknr, skb, in, out, uloginfo, NULL);
+}
+
+
 static int ebt_ulog_check(const char *tablename, unsigned int hookmask,
    const struct ebt_entry *e, void *data, unsigned int datalen)
 {
@@ -240,6 +273,12 @@ static struct ebt_watcher ulog =3D {
 	.me		=3D THIS_MODULE,
 };
=20
+static struct nf_logger ebt_ulog_logger =3D {
+	.name		=3D EBT_ULOG_WATCHER,
+	.logfn		=3D &ebt_log_packet,
+	.me		=3D THIS_MODULE,
+};
+
 static int __init init(void)
 {
 	int i, ret =3D 0;
@@ -265,6 +304,8 @@ static int __init init(void)
 	else if ((ret =3D ebt_register_watcher(&ulog)))
 		sock_release(ebtulognl->sk_socket);
=20
+	nf_log_register(PF_BRIDGE, &ebt_ulog_logger);
+
 	return ret;
 }
=20
@@ -273,6 +314,7 @@ static void __exit fini(void)
 	ebt_ulog_buff_t *ub;
 	int i;
=20
+	nf_log_unregister_logger(&ebt_ulog_logger);
 	ebt_unregister_watcher(&ulog);
 	for (i =3D 0; i < EBT_ULOG_MAXNLGROUPS; i++) {
 		ub =3D &ulog_buffers[i];
--=20
- Harald Welte <la...@ne...>                 http://netfilter.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
  "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

Re: [Ebtables-devel] 2.4.31 not compiling with ebtables-brnf-11

[Bart De S. <bds...@pa...>]

Op vr, 23-09-2005 te 13:06 +0300, schreef Adrian Buciuman:
> I've got the following error:
> 
> br_stp_bpdu.c: In function `br_stp_handle_bpdu':
> br_stp_bpdu.c:146: error: `br' undeclared (first use in this function)

A new patch was already posted on the sourceforge project page, but I
see I forgot to update the download section on the homepage... Fixed.

cheers,
Bart

[Ebtables-devel] 2.4.31 not compiling with ebtables-brnf-11

[Adrian B. <adi...@gm...>]

I've got the following error:

br_stp_bpdu.c: In function `br_stp_handle_bpdu':
br_stp_bpdu.c:146: error: `br' undeclared (first use in this function)

[Ebtables-devel] Re: [PATCH][BRIDGE-NF] Fix iptables redirect on bridge interface

[David S. M. <da...@da...>]

From: Bart De Schuymer <bds...@pa...>
Date: Wed, 14 Sep 2005 19:49:53 +0000

> Here's a slightly altered patch, originally from Mark Glines who
> diagnosed and fixed the problem.

Applied, thanks Bart.

If you think it warrants inclusion in 2.6.13.x, please pass it
along to st...@ke...

Thanks again.

[Ebtables-devel] [PATCH][BRIDGE-NF] Fix iptables redirect on bridge interface

[Bart De S. <bds...@pa...>]

Hi Dave,

Here's a slightly altered patch, originally from Mark Glines who
diagnosed and fixed the problem.

Please apply,
Bart

Signed-off-by: Bart De Schuymer <bds...@pa...>

--- linux-2.6.13/net/bridge/br_netfilter.c.old	2005-09-14 19:35:17.410164848 +0000
+++ linux-2.6.13/net/bridge/br_netfilter.c	2005-09-14 19:38:20.233371496 +0000
@@ -214,9 +214,11 @@ static int br_nf_pre_routing_finish(stru
 				     .tos = RT_TOS(iph->tos)} }, .proto = 0};
 
 			if (!ip_route_output_key(&rt, &fl)) {
-				/* Bridged-and-DNAT'ed traffic doesn't
-				 * require ip_forwarding. */
-				if (((struct dst_entry *)rt)->dev == dev) {
+				/* - Bridged-and-DNAT'ed traffic doesn't
+				 *   require ip_forwarding.
+				 * - Deal with redirected traffic. */
+				if (((struct dst_entry *)rt)->dev == dev ||
+				    rt->rt_type == RTN_LOCAL) {
 					skb->dst = (struct dst_entry *)rt;
 					goto bridged_dnat;
 				}

Re: [Ebtables-devel] Interface of ebtables

[Bart De S. <bds...@pa...>]

Op di, 13-09-2005 te 17:28 +0530, schreef som...@wi...:
> Hi all,
> 
> I am developing a user program (in Redhat Linux 9.0) which will filter
> packet for specific Ethernet protocol. Does Eatables provides any
> programmatic interface   to be used  for this purpose?
> 
> Please provide me this information .It will be a great help form me.

The ebtables code in the CVS (v2.0.7) is modular. The code used for
adding rules, etc., is located in libebtc.c and is a shared library.
ebtablesd is an example of a program that uses these shared libraries.

cheers,
Bart

[Ebtables-devel] Interface of ebtables

[<som...@wi...>]

Hi all,

I am developing a user program (in Redhat Linux 9.0) which will filter
packet for specific Ethernet protocol. Does Eatables provides any
programmatic interface   to be used  for this purpose?

Please provide me this information .It will be a great help form me.

=20

Thanks and regards,

Somenath=20

=20

=20

=20

[Ebtables-devel] bridge conntrack

[Feyd <fe...@se...>]

Hi,

I would like to be able to bridge over a wireless NIC in managed mode. For
that to work, a real MAC SNAT and thus connection tracking is neccessary.
Is there anybody interested or already working on that?

Feyd

[Ebtables-devel] Re: [Ebtables-user] Bridge hooks

[Stephen H. <she...@os...>]

On Mon, 5 Sep 2005 03:09:48 -0700
"Vanathi, Ravindran (IE10)" <Van...@ho...> wrote:

> Hi,
>     
>     I am new to the Linux ethernet bridge and I need some help to write my
> module
>  
>     I have a requirement to write a program in user space to access frames
> from the MAC layer using bridge hooks.
>  
>     Is it possible to register the bridge hook function from the user layer
> and if so how can this be done?
>  

You would be better off using either frame diverter,
AF_PACKET or Tun/tap device to do this. Bridge hooks are intended only
for use by bridge code in kernel space.

[Ebtables-devel] Bridge hooks

[Vanathi, R. (IE10) <Van...@ho...>]

Hi,
    
    I am new to the Linux ethernet bridge and I need some help to write my
module
 
    I have a requirement to write a program in user space to access frames
from the MAC layer using bridge hooks.
 
    Is it possible to register the bridge hook function from the user layer
and if so how can this be done?
 
Thanks & Regards,
Vanathi
 

Re: [Ebtables-devel] netfilter hook not work in 2.6 kernel

[Bart De S. <bds...@pa...>]

Op za, 03-09-2005 te 02:39 +0000, schreef cyl:
> Hi,
> 
> I used to write a kernel module that register a netfilter hook in 
> NF_BR_PRE_ROUTING and a network driver to which I can inject pcap file.My 
> network driver will simulate 2 network interfaces and I'll add them to a 
> bridge. Then every packet I inject will pass through the netfilter hook 
> function. That was done in kernel 2.4.
> Now I switch my program to kernel 2.6 and it does not work anymore. The data is 
> still injected to my network driver but it won't pass through the hook 
> function. I dump the data before calling netif_rx(skb) and the content is 
> correct. Is there any significant change on the behavior between kernel 2.4 and 
> 2.6?

The functionality provided by the bridge-nf patch for 2.4 is almost
identical to that in the 2.6 kernel.
Your problem is probably caused by changes in the networking stack,
which has probably changed considerably.

cheers,
Bart

[Ebtables-devel] netfilter hook not work in 2.6 kernel

[cyl <u85...@ya...>]

Hi,

I used to write a kernel module that register a netfilter hook in 
NF_BR_PRE_ROUTING and a network driver to which I can inject pcap file.My 
network driver will simulate 2 network interfaces and I'll add them to a 
bridge. Then every packet I inject will pass through the netfilter hook 
function. That was done in kernel 2.4.
Now I switch my program to kernel 2.6 and it does not work anymore. The data is 
still injected to my network driver but it won't pass through the hook 
function. I dump the data before calling netif_rx(skb) and the content is 
correct. Is there any significant change on the behavior between kernel 2.4 and 
2.6?
I'd glad to provide more info about my program if anyone needs. Thanks very 
much.

Re: [Ebtables-devel] Re: [Ebtables-user] bridge/ebtables interaction...

[Bart De S. <bds...@pa...>]

Op do, 01-09-2005 te 09:26 -0700, schreef Stephen Hemminger:
> > I don't think the broute table should see packets while in learning
> > state, and it certainly shouldn't be able to make them be routed.
> > Perhaps it's ok to let this traffic be seen on the PRE_ROUTING hook, but
> > that means that, e.g., iptables connection tracking will see these
> > (IPv4) packets. Also, letting the packets not be seen by the broute
> > table while letting them be seen on the PRE_ROUTING hook sounds like an
> > ugly hack...
> > Apart from that, some people would perhaps like the fact that they can
> > make rules to decide which packets can update the fdb. Of course,
> > ebtables targets like snat, dnat, redirect would not be allowed.
> 
> We could pass the state to should_route_hook and let it decide?

No need to postpone the decision to should_route_hook. This should do:
if (br_should_route_hook && p->state != BR_STATE_LEARNING)

Note that the brouting chain cannot decide to drop the packet, it
decides whether to bridge or route the packet.

Doing this will mean that those packets are seen on prerouting without
being seen on brouting. It'll confuse the users and it's not aestetic.
Furthermore it will make connection tracking do unnecessary work. I
don't know if it's really worth that...

cheers,
Bart

Re: [Ebtables-devel] Re: [Ebtables-user] bridge/ebtables interaction...

[Stephen H. <she...@os...>]

On Thu, 01 Sep 2005 06:59:37 +0000
Bart De Schuymer <bds...@pa...> wrote:

> Op wo, 31-08-2005 te 11:53 -0700, schreef Stephen Hemminger:
> > Wouldn't something like this work:
> > 
> > Index: bridge-2.6/net/bridge/br_input.c
> > ===================================================================
> > --- bridge-2.6.orig/net/bridge/br_input.c
> > +++ bridge-2.6/net/bridge/br_input.c
> > @@ -53,6 +53,11 @@ int br_handle_frame_finish(struct sk_buf
> >  	/* insert into forwarding database after filtering to avoid spoofing */
> >  	br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
> >  
> > +	if (p->state == BR_STATE_LEARNING) {
> > +		kfree_skb(skb);
> > +		goto out;
> > +	}
> > +
> >  	if (br->dev->flags & IFF_PROMISC) {
> >  		struct sk_buff *skb2;
> >  
> > @@ -107,9 +112,6 @@ int br_handle_frame(struct net_bridge_po
> >  	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
> >  		goto err;
> >  
> > -	if (p->state == BR_STATE_LEARNING)
> > -		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
> > -
> >  	if (p->br->stp_enabled &&
> >  	    !memcmp(dest, bridge_ula, 5) &&
> >  	    !(dest[5] & 0xF0)) {
> > @@ -118,9 +120,10 @@ int br_handle_frame(struct net_bridge_po
> >  				NULL, br_stp_handle_bpdu);
> >  			return 1;
> >  		}
> > +		goto err;
> >  	}
> >  
> > -	else if (p->state == BR_STATE_FORWARDING) {
> > +	if (p->state == BR_STATE_FORWARDING || p->state == BR_STATE_LEARNING) {
> >  		if (br_should_route_hook) {
> >  			if (br_should_route_hook(pskb)) 
> >  				return 0;
> 
> I don't think the broute table should see packets while in learning
> state, and it certainly shouldn't be able to make them be routed.
> Perhaps it's ok to let this traffic be seen on the PRE_ROUTING hook, but
> that means that, e.g., iptables connection tracking will see these
> (IPv4) packets. Also, letting the packets not be seen by the broute
> table while letting them be seen on the PRE_ROUTING hook sounds like an
> ugly hack...
> Apart from that, some people would perhaps like the fact that they can
> make rules to decide which packets can update the fdb. Of course,
> ebtables targets like snat, dnat, redirect would not be allowed.

We could pass the state to should_route_hook and let it decide?

RE: [Ebtables-devel] kernel option "Bridged IP/ARP packetsfiltering" degrades bridging performance

[Cho-Soon Y. <csy...@ya...>]

 
There were not rules in iptables.
I did not enable connection tracking.
I did not enable ebtables. I tested the br_nf features.

When I disabled this "Bridge ~" kernel option, I got about 200,000 pps
bidirection.
As I enabled this option, I got about 100,000pps bidirection.

Thanks,
Yimbo

> Op wo, 31-08-2005 te 16:07 +0900, schreef Cho-Soon Yim:
> > Hi,
> >  
> > I have tested the bridging performance of Linux.
> > Linux machine;
> > Xeon 3.06GHz * 2 CPU
> > 1 G Memory(DDR266 ECC)
> > intel e1000 NIC 2 port LC type * 1 driver version( 
> 64bit/133Mhz with 
> > riser card)
> >  
> > But when I enabled that option(I recompiled the kernel), I 
> got success 
> > rate 5%.
> > It was a half of prior result. 
> > I did not add any filter rules. I just enabled that option 
> because I 
> > wanted to use bridge firewalling.
> > 
> > I have tried to tune the kernel, network kernel 
> paramenters, and NIC 
> > drivers.
> > But anything could not compensate the performance degration 
> that was 
> > caused by bridging packet filter option.
> > Is there anyone who addressed this issue out there?
> > I'd like to know the experience of whom tested this kind of 
> bridging 
> > firewall.
> 
> Are there no rules in iptables either? Is connection tracking enabled?
> There are not much details about performance. See e.g.
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=2625911
> &forum_id=8573
> 
> cheers,
> Bart
> 
> 


	

	
		
________________________________________________________
¹«·á 1GB¿ë·®!, ´õ ÀÌ»ó ¿ë·® °í¹Î¾ø´Â - ¾ßÈÄ! ¸ÞÀÏ (http://mail.yahoo.co.kr) 
ÃֽŠÈÞ´ëÆù Á¤º¸, º§¼Ò¸®, ij¸¯ÅÍ, ¹®ÀÚ¸Þ¼¼Áö - ¾ßÈÄ! ¸ð¹ÙÀÏ (http://kr.mobile.yahoo.com) 
´ëÇѹα¹ ºí·Î±×°¡ ¸ðÀÎ °÷! - ¾ßÈÄ! ÇÇÇøµ(http://kr.ring.yahoo.com)

Re: [Ebtables-devel] Re: [Ebtables-user] bridge/ebtables interaction...

[Bart De S. <bds...@pa...>]

Op wo, 31-08-2005 te 11:53 -0700, schreef Stephen Hemminger:
> Wouldn't something like this work:
> 
> Index: bridge-2.6/net/bridge/br_input.c
> ===================================================================
> --- bridge-2.6.orig/net/bridge/br_input.c
> +++ bridge-2.6/net/bridge/br_input.c
> @@ -53,6 +53,11 @@ int br_handle_frame_finish(struct sk_buf
>  	/* insert into forwarding database after filtering to avoid spoofing */
>  	br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
>  
> +	if (p->state == BR_STATE_LEARNING) {
> +		kfree_skb(skb);
> +		goto out;
> +	}
> +
>  	if (br->dev->flags & IFF_PROMISC) {
>  		struct sk_buff *skb2;
>  
> @@ -107,9 +112,6 @@ int br_handle_frame(struct net_bridge_po
>  	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>  		goto err;
>  
> -	if (p->state == BR_STATE_LEARNING)
> -		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
> -
>  	if (p->br->stp_enabled &&
>  	    !memcmp(dest, bridge_ula, 5) &&
>  	    !(dest[5] & 0xF0)) {
> @@ -118,9 +120,10 @@ int br_handle_frame(struct net_bridge_po
>  				NULL, br_stp_handle_bpdu);
>  			return 1;
>  		}
> +		goto err;
>  	}
>  
> -	else if (p->state == BR_STATE_FORWARDING) {
> +	if (p->state == BR_STATE_FORWARDING || p->state == BR_STATE_LEARNING) {
>  		if (br_should_route_hook) {
>  			if (br_should_route_hook(pskb)) 
>  				return 0;

I don't think the broute table should see packets while in learning
state, and it certainly shouldn't be able to make them be routed.
Perhaps it's ok to let this traffic be seen on the PRE_ROUTING hook, but
that means that, e.g., iptables connection tracking will see these
(IPv4) packets. Also, letting the packets not be seen by the broute
table while letting them be seen on the PRE_ROUTING hook sounds like an
ugly hack...
Apart from that, some people would perhaps like the fact that they can
make rules to decide which packets can update the fdb. Of course,
ebtables targets like snat, dnat, redirect would not be allowed.

cheers,
Bart

Re: [Ebtables-devel] kernel option "Bridged IP/ARP packets filtering" degrades bridging performance

[Bart De S. <bds...@pa...>]

Op wo, 31-08-2005 te 16:07 +0900, schreef Cho-Soon Yim:
> Hi, 
>  
> I have tested the bridging performance of Linux.
> Linux machine;
> Xeon 3.06GHz * 2 CPU
> 1 G Memory(DDR266 ECC)
> intel e1000 NIC 2 port LC type * 1 driver version( 64bit/133Mhz with
> riser card)
>  
> But when I enabled that option(I recompiled the kernel), I got success
> rate 5%.
> It was a half of prior result. 
> I did not add any filter rules. I just enabled that option because I
> wanted to use bridge firewalling.
> 
> I have tried to tune the kernel, network kernel paramenters, and NIC
> drivers. 
> But anything could not compensate the performance degration that was
> caused by bridging packet filter option. 
> Is there anyone who addressed this issue out there?
> I'd like to know the experience of whom tested this kind of bridging
> firewall.

Are there no rules in iptables either? Is connection tracking enabled?
There are not much details about performance. See e.g.

http://sourceforge.net/mailarchive/forum.php?thread_id=2625911&forum_id=8573

cheers,
Bart

Re: [Ebtables-devel] Re: [Ebtables-user] bridge/ebtables interaction...

[Stephen H. <she...@os...>]

Wouldn't something like this work:

Index: bridge-2.6/net/bridge/br_input.c
===================================================================
--- bridge-2.6.orig/net/bridge/br_input.c
+++ bridge-2.6/net/bridge/br_input.c
@@ -53,6 +53,11 @@ int br_handle_frame_finish(struct sk_buf
 	/* insert into forwarding database after filtering to avoid spoofing */
 	br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
 
+	if (p->state == BR_STATE_LEARNING) {
+		kfree_skb(skb);
+		goto out;
+	}
+
 	if (br->dev->flags & IFF_PROMISC) {
 		struct sk_buff *skb2;
 
@@ -107,9 +112,6 @@ int br_handle_frame(struct net_bridge_po
 	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
 		goto err;
 
-	if (p->state == BR_STATE_LEARNING)
-		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
-
 	if (p->br->stp_enabled &&
 	    !memcmp(dest, bridge_ula, 5) &&
 	    !(dest[5] & 0xF0)) {
@@ -118,9 +120,10 @@ int br_handle_frame(struct net_bridge_po
 				NULL, br_stp_handle_bpdu);
 			return 1;
 		}
+		goto err;
 	}
 
-	else if (p->state == BR_STATE_FORWARDING) {
+	if (p->state == BR_STATE_FORWARDING || p->state == BR_STATE_LEARNING) {
 		if (br_should_route_hook) {
 			if (br_should_route_hook(pskb)) 
 				return 0;