ebtables-devel — Development questions, bugs, patches

[Ebtables-devel] kernel oops on 2.4.29 with ebtables-brnf-9 patch

[Arinjay J. <ari...@gm...>]

Hi,
I have applied the ebtables-brnf-9_vs_2.4.29.diff patch on kernel 2.4.29 an=
d
am getting OOPS in netif_receive_skb.
The 2.4.29 kernel I have is already patched with some skbuff headroom and
tailroom changes. I have pasted the diff.

--- linux-2.4.29/include/linux/skbuff.h 2004-08-07 23:26:06.000000000 +0000
+++ linux-2.4.29-new/include/linux/skbuff.h     2005-06-17 17:51:
12.000000000 +0000
@@ -39,6 +39,9 @@
 #define SKB_MAX_HEAD(X)                (SKB_MAX_ORDER((X),0))
 #define SKB_MAX_ALLOC          (SKB_MAX_ORDER(0,2))

+#define SKB_HEADER_EXTRA 64
+#define SKB_TAIL_EXTRA  16
+
 /* A. Checksumming of received packets by device.
  *
  *     NONE: device failed to checksum this packet.
@@ -1033,9 +1036,10 @@
 {
        struct sk_buff *skb;

-       skb =3D alloc_skb(length+16, gfp_mask);
-       if (skb)
-               skb_reserve(skb,16);
+       skb =3D alloc_skb(length+SKB_HEADER_EXTRA+SKB_TAIL_EXTRA, gfp_mask)=
;
+       if (skb) {
+               skb_reserve(skb,SKB_HEADER_EXTRA);
+       }
        return skb;
 }

@@ -1073,7 +1077,9 @@
 static inline int
 skb_cow(struct sk_buff *skb, unsigned int headroom)
 {
-       int delta =3D (headroom > 16 ? headroom : 16) - skb_headroom(skb);
+       int delta =3D (headroom > SKB_HEADER_EXTRA ?
+                headroom :
+                SKB_HEADER_EXTRA) - skb_headroom(skb);

        if (delta < 0)
                delta =3D 0;

Will this patch cause any problem with the ebtables-br-nf patch that I am
using.

Thanks,

Arinjay

[Ebtables-devel] IP Fragments, more

[Francois-Xavier Le B. <fx....@fr...>]

Thanks Bart,

I think the file ebt_log.c need the same sort of patch.

Cheers,
Francois-Xavier

Selon Bart De Schuymer <bds...@pa...>:
> You're right, this patch should fix it. Thanks.
>
> Dave, please apply. This is probably a candidate for -stable.
>
> cheers,
> Bart
>
>
> [EBTABLES] Don't match tcp/udp source/destination port for IP fragments
>
> Signed-off-by: Bart De Schuymer <bds...@pa...>
>
>
> --- linux-2.6.14.2/net/bridge/netfilter/ebt_ip.c.old	2006-01-10
> 19:54:08.000000000 +0100
> +++ linux-2.6.14.2/net/bridge/netfilter/ebt_ip.c	2006-01-10
> 19:59:18.000000000 +0100
> @@ -15,6 +15,7 @@
>  #include <linux/netfilter_bridge/ebtables.h>
>  #include <linux/netfilter_bridge/ebt_ip.h>
>  #include <linux/ip.h>
> +#include <net/ip.h>
>  #include <linux/in.h>
>  #include <linux/module.h>
>
> @@ -51,6 +52,8 @@ static int ebt_filter_ip(const struct sk
>  		if (!(info->bitmask & EBT_IP_DPORT) &&
>  		    !(info->bitmask & EBT_IP_SPORT))
>  			return EBT_MATCH;
> +		if (ntohs(ih->frag_off) & IP_OFFSET)
> +			return EBT_NOMATCH;
>  		pptr =3D skb_header_pointer(skb, ih->ihl*4,
>  					  sizeof(_ports), &_ports);
>  		if (pptr =3D=3D NULL)
>
>
>

Re: [Ebtables-devel] [PATCH] selective IP NATing on a bridge (like NETMAP)

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

Op za, 24-12-2005 te 11:10 +0000, schreef Bart De Schuymer:
> Op ma, 19-12-2005 te 04:55 +0100, schreef Carl-Daniel Hailfinger:
> > Please find two patches attached (to avoid whitespace mangling):
> > - lindent of the files I worked on
> > - functional changes only.
> > Patches are against 2.6.15-rc5 and are compile tested only.
> > 
> Did you try if this code works? I don't think it will. Unless something
> recently changed, you can't register 2 targets with the same name in
> arptables. Iptables solved this by introducing the versioning
> (revision). Doing this in arptables will imply rewriting some code in
> arp_tables.c, and I don't think it's worth it (as I said before). Unless
> someone finds the time to actually do those changes and test them of
> course. That's why I referred you to that mail (which got outdated
> w.r.t. the way to do it in iptables now). If you really want to be sure
> what approach to take, you should ask David Miller, as he's the kernel
> maintainer of arptables and your patch will have to be approved by him.

I forgot to note that the revision approach will mean rewriting some of
the arptables userspace code too...

Re: [Ebtables-devel] [PATCH] selective IP NATing on a bridge (like NETMAP)

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

Op ma, 19-12-2005 te 04:55 +0100, schreef Carl-Daniel Hailfinger:
> Please find two patches attached (to avoid whitespace mangling):
> - lindent of the files I worked on
> - functional changes only.
> Patches are against 2.6.15-rc5 and are compile tested only.
> 
> What do you think?

I don't like the lindenting:
- In the kernel code, structs almost always have their '{' on a new
line.
- Changes that only make the code 2 lines longer aren't good
- The one-space nitpicking isn't worth the diff overhead
- The alterations in struct arpt_target just make it look worse

Did you try if this code works? I don't think it will. Unless something
recently changed, you can't register 2 targets with the same name in
arptables. Iptables solved this by introducing the versioning
(revision). Doing this in arptables will imply rewriting some code in
arp_tables.c, and I don't think it's worth it (as I said before). Unless
someone finds the time to actually do those changes and test them of
course. That's why I referred you to that mail (which got outdated
w.r.t. the way to do it in iptables now). If you really want to be sure
what approach to take, you should ask David Miller, as he's the kernel
maintainer of arptables and your patch will have to be approved by him.

cheers,
Bart

[Ebtables-devel] Re: [PATCH] [BRIDGE-NF] Fix bridge-nf ipv6 length check

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

From: Bart De Schuymer <bds...@pa...>
Date: Mon, 19 Dec 2005 19:00:13 +0000

> A typo caused some bridged IPv6 packets to get dropped randomly,
> as reported by Sebastien Chaumontet. The patch below fixes this
> (using skb->nh.raw instead of raw) and also makes the jumbo packet
> length checking up-to-date with the code in
> net/ipv6/exthdrs.c::ipv6_hop_jumbo.
> This is probably a candidate for -stable.
> 
> Signed-off-by: Bart De Schuymer <bds...@pa...>

Applied, thanks.

I'll probably pass this on to -stable, but bridge-nf+ipv6 is
nearly as fringe usage as DecNET or NetBEUI to be honest :-)

[Ebtables-devel] [PATCH] [BRIDGE-NF] Fix bridge-nf ipv6 length check

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

Hi Dave,

A typo caused some bridged IPv6 packets to get dropped randomly,
as reported by Sebastien Chaumontet. The patch below fixes this
(using skb->nh.raw instead of raw) and also makes the jumbo packet
length checking up-to-date with the code in
net/ipv6/exthdrs.c::ipv6_hop_jumbo.
This is probably a candidate for -stable.

Please apply,
Bart

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

--- linux-2.6.14.2/net/bridge/br_netfilter.c.old	2005-12-19 17:53:31.000000000 +0000
+++ linux-2.6.14.2/net/bridge/br_netfilter.c	2005-12-19 18:37:32.000000000 +0000
@@ -295,7 +295,7 @@ static int check_hbh_len(struct sk_buff 
 	len -= 2;
 
 	while (len > 0) {
-		int optlen = raw[off+1]+2;
+		int optlen = skb->nh.raw[off+1]+2;
 
 		switch (skb->nh.raw[off]) {
 		case IPV6_TLV_PAD0:
@@ -308,18 +308,15 @@ static int check_hbh_len(struct sk_buff 
 		case IPV6_TLV_JUMBO:
 			if (skb->nh.raw[off+1] != 4 || (off&3) != 2)
 				goto bad;
-
 			pkt_len = ntohl(*(u32*)(skb->nh.raw+off+2));
-
+			if (pkt_len <= IPV6_MAXPLEN ||
+			    skb->nh.ipv6h->payload_len)
+				goto bad;
 			if (pkt_len > skb->len - sizeof(struct ipv6hdr))
 				goto bad;
-			if (pkt_len + sizeof(struct ipv6hdr) < skb->len) {
-				if (__pskb_trim(skb,
-				    pkt_len + sizeof(struct ipv6hdr)))
-					goto bad;
-				if (skb->ip_summed == CHECKSUM_HW)
-					skb->ip_summed = CHECKSUM_NONE;
-			}
+			if (pskb_trim_rcsum(skb,
+			    pkt_len+sizeof(struct ipv6hdr)))
+				goto bad;
 			break;
 		default:
 			if (optlen > len)

[Ebtables-devel] Re: Dynamic source MAC-NAT?

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

On Sun, 18 Dec 2005 15:20:19 +0000
Bart De Schuymer <bds...@pa...> wrote:

> Iptables conntrack uses skb->nf_conntrack to refer to the connection
> tracking info. If ebtables' conntracking is implemented similarly, we'd
> need something like that too. Suppose we don't keep this reference in
> the skb and we dnat mac address $a to $b in prerouting. From that point
> on there won't be an easy way to know if the mac destination address $b
> was modified or not. If the skb is dropped later on, we'll probably need
> to decrease the use count of the conntrack, so it can be destroyed if
> it's not used anymore. For iptables this is done with nf_conntrack_put
> (see skbuff.h) called from __kfree_skb (skbuff.c). We'll need something
> similar I think.

I see, the resistance to add anything to the sk_buff can be expected and
the way the nfct is currently used prevents multilayer connection tracking.
One way to avoid touching the sk_buff could be to separate the nf_conntrack
from the layer conntrack it currently masquerades and turn it into list of
pointers to the layer conntracks. This would however add a kmalloc/kfree
per new/destroyed conntrack, could this be noticeable performance hit?

struct nf_conntrack_layer {
        void (*destroy)(struct nf_conntrack *);
};

struct nf_conntrack {
        atomic_t l2_use;
        atomic_t l3_use;
        struct nf_conntrack_layer *l2_ct;
        struct nf_conntrack_layer *l3_ct;
};

static inline void nf_conntrack_put(struct nf_conntrack *nfct)
{
        if (nfct) {
                if(nfct->l2_ct && atomic_dec_and_test(&nfct->l2_use))
                        nfct->l2_ct->destroy(nfct);

                if(nfct->l3_ct && atomic_dec_and_test(&nfct->l3_use))
                        nfct->l3_ct->destroy(nfct);

                if(!atomic_read(&nfct->l2_use) && !atomic_read(&nfct->l3_use))
                        /* destroy self */
        }
}

Feyd

[Ebtables-devel] [PATCH] selective IP NATing on a bridge (like NETMAP)

[Carl-Daniel H. <c-d...@gm...>]

Bart De Schuymer schrieb:
> Op za, 26-03-2005 te 15:11 +0100, schreef Carl-Daniel Hailfinger:
> 
>>arptables -A FORWARD -i eth1 -o eth0 -s 192.168.101.0/24 \
>>  -d 192.168.101.0/24 -p Reply -j mangle \
>>  --mangle-ip-s 192.168.100.0/24 --mangle-ip-d 192.168.100.0/24
>>
>>However, it seems the mangle target doesn't like source or destination
>>to be a network address. The documentation doesn't mention this
>>possibility, either. Looking at the kernel code, it seems I can patch
>>it to fit my needs, but I'd have to change struct arpt_mangle.
> 
> Interesting idea. Does iptables allow something like this?

Yes, with the NETMAP target.


>>Proposed patch follows, please criticize it.
>> [...]
> 
> This change will need to be done so that backwards compatibility
> is maintained.
> I guess a versioning system like the one introduced in iptables
> could be used, but I don't thinks that's worth it, since we only
> have one target. I think the approach mentioned in
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017522.html
> is the one to take. The arpt_mangle struct has a flags field.

Yes, but the new flags I introduce take up all 8 bits of the flags
field (and may need more in the future), so I decided to check the
length. The patch is now modeled after the current version of
ipt_MARK.


>>I plan to extend the patch to also allow MAC masks for those who
>>might be crazy enough to need that.
> 
> Yes, it's better to provide all options in one patch.

Done.

Please find two patches attached (to avoid whitespace mangling):
- lindent of the files I worked on
- functional changes only.
Patches are against 2.6.15-rc5 and are compile tested only.

What do you think?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [Ebtables-devel] Re: Dynamic source MAC-NAT?

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

Op za, 17-12-2005 te 21:03 +0100, schreef fe...@se...:
> Bart De Schuymer wrote:
> > The problem with dynamic macnat is that the kernel sk_buff structure
> > will have to be altered, which is something the network maintainers
> > don't like. Apart from that there should be no big problems implementing
> > it.
> 
> Why is the modification neccessary? As I understand it you only need to
> keep a hash of tracked "connections" and mangle the *skb->data when the
> packet hits. Am I missing something?

Iptables conntrack uses skb->nf_conntrack to refer to the connection
tracking info. If ebtables' conntracking is implemented similarly, we'd
need something like that too. Suppose we don't keep this reference in
the skb and we dnat mac address $a to $b in prerouting. From that point
on there won't be an easy way to know if the mac destination address $b
was modified or not. If the skb is dropped later on, we'll probably need
to decrease the use count of the conntrack, so it can be destroyed if
it's not used anymore. For iptables this is done with nf_conntrack_put
(see skbuff.h) called from __kfree_skb (skbuff.c). We'll need something
similar I think.

cheers,
Bart

[Ebtables-devel] Re: Dynamic source MAC-NAT?

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

Bart De Schuymer wrote:
> The problem with dynamic macnat is that the kernel sk_buff structure
> will have to be altered, which is something the network maintainers
> don't like. Apart from that there should be no big problems implementing
> it.

Why is the modification neccessary? As I understand it you only need to
keep a hash of tracked "connections" and mangle the *skb->data when the
packet hits. Am I missing something?

> I currently lack the time for any serious development, though.

I have briefly looked at DHCP (RFC2131) so far, as I was worried that
MAC NAT would break it, and it seems viable, there are two fields in the
packet that make it possible to identify the "connection".

Feyd

Re: [Ebtables-devel] Dynamic source MAC-NAT?

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

Op za, 10-12-2005 te 15:10 -0500, schreef Respawned Fluff:
> Is anyone working on _dynamic_ source MAC-NAT, i.e. the MASQ target
> equivalent from iptables?
> 
> This feature is mighty useful for implementing bridges over 802.11
> links without using WDS.
> WDS is problematic due to vendor interoperability or downright
> unavailability issues.
> 
> Currently the Cisco/Linksys WET products implement this. Note: WET !=
> WRT, and WET series don't seem to use Linux as OS.
> 
> I think that Feyd was also asking for this in his unreplied "bridge
> conntrack" post. His question is somewhat unclear in that he implies
> the current MAC-NAT is not "real", when he probably means dynamic.
> 
> Please cc any answer, as I'm not subscribed to the mailing list.

The problem with dynamic macnat is that the kernel sk_buff structure
will have to be altered, which is something the network maintainers
don't like. Apart from that there should be no big problems implementing
it.
I currently lack the time for any serious development, though.

cheers,
Bart

[Ebtables-devel] Dynamic source MAC-NAT?

[Respawned F. <res...@gm...>]

Is anyone working on _dynamic_ source MAC-NAT, i.e. the MASQ target
equivalent from iptables?

This feature is mighty useful for implementing bridges over 802.11 links
without using WDS.
WDS is problematic due to vendor interoperability or downright
unavailability issues.

Currently the Cisco/Linksys WET products implement this. Note: WET !=3D WRT=
,
and WET series don't seem to use Linux as OS.

I think that Feyd was also asking for this in his unreplied "bridge
conntrack" post. His question is somewhat unclear in that he implies the
current MAC-NAT is not "real", when he probably means dynamic.

Please cc any answer, as I'm not subscribed to the mailing list.

[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, 15 Nov 2005 18:21:21 +0000

> [NETFILTER] ebtables: Support nf_log API from ebt_log and ebt_ulog
> 
> This makes ebt_log and ebt_ulog use the new nf_log api.  This enables
> the bridging packet filter to log packets e.g. via nfnetlink_log.
> 
> Signed-off-by: Bart De Schuymer <bds...@pa...>
> Signed-off-by: Harald Welte <la...@ne...>

I'm going to queue this up for 2.6.16, thanks.

Re: [Ebtables-devel] Fwd: Linux bridge on linksys WRT54GS running OpenWRT

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

Op vr, 18-11-2005 te 20:37 +0100, schreef Sebastien Chaumontet:
> Hi Bart,
> 
> Thanks for your attention to this subject.
> 
> Here is how to reproduce this problem:
> - two hosts on a LAN
> - on host A create a bridge
> - add the device to bridge
> - run on host A : "tcpdump -i br0 not ip"
> - run on host A : "tcpdump -i eth0 not ip"
> - on host you can use a very good tool like vlc to join a group :
> "vlc udp://@[ff1e::8888]:8888"
> 
> This should generate a MLD report (which should be catched by
> multicast router) but it is blocked by something in bridge.
> So you will be able to see it on eth0 and not br0.
> 
> If you need some more information we can discuss about this on IRC
> #etables (freenode).

Using the pcap file you sent me, it turns out that the version field in
the IPv6 header isn't filled in correctly. Your packet has value 0
there, while it should be value 6.

Removing the following two lines from
net/bridge/br_netfilter.c::br_nf_pre_routing_ipv6() should let those
packets through (please report back if that doesn't fix it):
if (hdr->version != 6)
	goto inhdr_error;

Alternatively, you can disable IPv6 filtering by the bridge by doing
# echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

cheers,
Bart

Re: [Ebtables-devel] Fwd: Linux bridge on linksys WRT54GS running OpenWRT

[Sebastien C. <seb...@ch...>]

Hi Bart,

Thanks for your attention to this subject.

Here is how to reproduce this problem:
- two hosts on a LAN
- on host A create a bridge
- add the device to bridge
- run on host A : "tcpdump -i br0 not ip"
- run on host A : "tcpdump -i eth0 not ip"
- on host you can use a very good tool like vlc to join a group :
"vlc udp://@[ff1e::8888]:8888"

This should generate a MLD report (which should be catched by
multicast router) but it is blocked by something in bridge.
So you will be able to see it on eth0 and not br0.

If you need some more information we can discuss about this on IRC
#etables (freenode).

Thanks
Seb

On 11/18/05, Bart De Schuymer <bds...@pa...> wrote:
> Op vr, 18-11-2005 te 01:51 +0100, schreef Sebastien Chaumontet:
> > Hi ebtables dev team,
> >
> > Has you can see bellow we reported a problem with bridging and MLD
> > reports using bridge to bridge mailing list, but it seems more related
> > to ebtables.
> >
> > Can you have a look to this issue?
> >
> > The problem can be easily reproduced. Do not hesitate if you need help =
to do it.
>
> I don't have an IPv6 network (the IPv6 specific bridge-nf code was
> tested by others). If you can tell me how to reproduce this, that would
> be great.
>
> cheers,
> Bart
>
>
>

Re: [Ebtables-devel] Fwd: Linux bridge on linksys WRT54GS running OpenWRT

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

Op vr, 18-11-2005 te 01:51 +0100, schreef Sebastien Chaumontet:
> Hi ebtables dev team,
> 
> Has you can see bellow we reported a problem with bridging and MLD
> reports using bridge to bridge mailing list, but it seems more related
> to ebtables.
> 
> Can you have a look to this issue?
> 
> The problem can be easily reproduced. Do not hesitate if you need help to do it.

I don't have an IPv6 network (the IPv6 specific bridge-nf code was
tested by others). If you can tell me how to reproduce this, that would
be great.

cheers,
Bart

[Ebtables-devel] Fwd: Linux bridge on linksys WRT54GS running OpenWRT

[Sebastien C. <seb...@ch...>]

Hi ebtables dev team,

Has you can see bellow we reported a problem with bridging and MLD
reports using bridge to bridge mailing list, but it seems more related
to ebtables.

Can you have a look to this issue?

The problem can be easily reproduced. Do not hesitate if you need help to d=
o it.

Thanks

Sebastien

---------- Forwarded message ----------
From: Stephen Hemminger <she...@os...>
Date: Nov 17, 2005 6:10 PM
Subject: Re: Linux bridge on linksys WRT54GS running OpenWRT
To: Sebastien Chaumontet <seb...@ch...>
Cc: br...@li..., Micka=EBl Hoerdt
<ho...@cl...>, Olaf Menzel
<ola...@fo...>


On Thu, 17 Nov 2005 12:01:47 +0100
Sebastien Chaumontet <seb...@ch...> wrote:

> Hi all,
>
> Following the this thread opened by Olaf
> (http://lists.osdl.org/mailman/htdig/bridge/2005-July/001026.html)
>
> We performed some more tests with and without wireless. Latest one was
> to remove CONFIG_BRIDGE_NETFILTER from kernel option at compilation
> time on a 2.6.14-rc4. This change solved the problem and the bridge
> was able to forward correctly MLD packets (IPv6 multicast subscription
> message).
>
> So the problem seems to be related to etables. Something related to
> IP/SABOTAGE in br_netfilter.c?

The netfilter interface is really the responsibility of the ebtables
project. I maintain the hooks for them, but what happens in the filters
is their doing.

> As specified on the bridge FAQ "The bridge knows nothing about
> protocols, it only sees Ethernet frames." it should not look at the
> content of the packet.
>
> Most of performed tests are described on
> http://dbeacon.innerghost.net/LinuxBridgingMulticast
>

If you want put a link on http://linux-net.osdl.org on the bridge page.



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

[Ebtables-devel] [PATCH] ebtables: port ebt*[u]log.c to nf[netlink]_log

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

Hi Dave,

Below is a patch from Harald, slightly altered by me to merge some
printk's.

Please apply,
Bart


[NETFILTER] ebtables: Support nf_log API from ebt_log and ebt_ulog

This makes ebt_log and ebt_ulog use the new nf_log api.  This enables
the bridging packet filter to log packets e.g. via nfnetlink_log.

Signed-off-by: Bart De Schuymer <bds...@pa...>
Signed-off-by: Harald Welte <la...@ne...>


--- linux-2.6.14.2/net/bridge/netfilter/Kconfig.old	2005-11-15 18:00:10.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/Kconfig	2005-11-15 18:00:24.891607224 +0000
@@ -196,9 +196,13 @@ config BRIDGE_EBT_LOG
 	  To compile it as a module, choose M here.  If unsure, say N.
 
 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
--- linux-2.6.14.2/net/bridge/netfilter/ebt_log.c.old	2005-11-15 18:00:04.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/ebt_log.c	2005-11-15 18:05:38.000000000 +0000
@@ -3,6 +3,7 @@
  *
  *	Authors:
  *	Bart De Schuymer <bds...@pa...>
+ *	Harald Welte <la...@ne...>
  *
  *  April, 2002
  *
@@ -10,6 +11,7 @@
 
 #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,27 +57,30 @@ static void print_MAC(unsigned char *p)
 }
 
 #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 = (struct ebt_log_info *)data;
-	char level_string[4] = "< >";
+	unsigned int bitmask;
 
-	level_string[1] = '0' + info->loglevel;
 	spin_lock_bh(&ebt_log_lock);
-	printk(level_string);
-	printk("%s IN=%s OUT=%s ", info->prefix, in ? in->name : "",
-	   out ? out->name : "");
+	printk("<%c>%s IN=%s OUT=%s MAC source = ", '0' + loginfo->u.log.level,
+	       prefix, in ? in->name : "", out ? out->name : "");
 
-	printk("MAC source = ");
 	print_MAC(eth_hdr(skb)->h_source);
 	printk("MAC dest = ");
 	print_MAC(eth_hdr(skb)->h_dest);
 
 	printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
 
-	if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
+	if (loginfo->type == NF_LOG_TYPE_LOG)
+		bitmask = loginfo->u.log.logflags;
+	else
+		bitmask = NF_LOG_MASK;
+
+	if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
 	   htons(ETH_P_IP)){
 		struct iphdr _iph, *ih;
 
@@ -84,10 +89,9 @@ static void ebt_log(const struct sk_buff
 			printk(" INCOMPLETE IP header");
 			goto out;
 		}
-		printk(" IP SRC=%u.%u.%u.%u IP DST=%u.%u.%u.%u,",
-		   NIPQUAD(ih->saddr), NIPQUAD(ih->daddr));
-		printk(" IP tos=0x%02X, IP proto=%d", ih->tos,
-		       ih->protocol);
+		printk(" IP SRC=%u.%u.%u.%u IP DST=%u.%u.%u.%u, IP "
+		       "tos=0x%02X, IP proto=%d", NIPQUAD(ih->saddr),
+		       NIPQUAD(ih->daddr), ih->tos, ih->protocol);
 		if (ih->protocol == IPPROTO_TCP ||
 		    ih->protocol == IPPROTO_UDP) {
 			struct tcpudphdr _ports, *pptr;
@@ -104,7 +108,7 @@ static void ebt_log(const struct sk_buff
 		goto out;
 	}
 
-	if ((info->bitmask & EBT_LOG_ARP) &&
+	if ((bitmask & EBT_LOG_ARP) &&
 	    ((eth_hdr(skb)->h_proto == htons(ETH_P_ARP)) ||
 	     (eth_hdr(skb)->h_proto == htons(ETH_P_RARP)))) {
 		struct arphdr _arph, *ah;
@@ -144,6 +148,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 = (struct ebt_log_info *)data;
+	struct nf_loginfo li;
+
+	li.type = NF_LOG_TYPE_LOG;
+	li.u.log.level = info->loglevel;
+	li.u.log.logflags = info->bitmask;
+
+	nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
 }
 
 static struct ebt_watcher log =
@@ -154,13 +173,32 @@ static struct ebt_watcher log =
 	.me		= THIS_MODULE,
 };
 
+static struct nf_logger ebt_log_logger = {
+	.name 		= "ebt_log",
+	.logfn		= &ebt_log_packet,
+	.me		= THIS_MODULE,
+};
+
 static int __init init(void)
 {
-	return ebt_register_watcher(&log);
+	int ret;
+
+	ret = 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");
+		/* we cannot make module load fail here, since otherwise 
+		 * ebtables userspace would abort */
+	}
+
+	return 0;
 }
 
 static void __exit fini(void)
 {
+	nf_log_unregister_logger(&ebt_log_logger);
 	ebt_unregister_watcher(&log);
 }
 
--- linux-2.6.14.2/net/bridge/netfilter/ebt_ulog.c.old	2005-11-15 18:00:02.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/ebt_ulog.c	2005-11-15 18:00:24.000000000 +0000
@@ -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;
 }
 
-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 = (struct ebt_ulog_info *)data;
 	unsigned int group = uloginfo->nlgroup;
 	ebt_ulog_buff_t *ub = &ulog_buffers[group];
 	spinlock_t *lock = &ub->lock;
@@ -216,6 +216,39 @@ alloc_failure:
 	goto unlock;
 }
 
+/* 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 != NF_LOG_TYPE_ULOG) {
+		loginfo.nlgroup = EBT_ULOG_DEFAULT_NLGROUP;
+		loginfo.cprange = 0;
+		loginfo.qthreshold = EBT_ULOG_DEFAULT_QTHRESHOLD;
+		loginfo.prefix[0] = '\0';
+	} else {
+		loginfo.nlgroup = li->u.ulog.group;
+		loginfo.cprange = li->u.ulog.copy_len;
+		loginfo.qthreshold = 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 = (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 = {
 	.me		= THIS_MODULE,
 };
 
+static struct nf_logger ebt_ulog_logger = {
+	.name		= EBT_ULOG_WATCHER,
+	.logfn		= &ebt_log_packet,
+	.me		= THIS_MODULE,
+};
+
 static int __init init(void)
 {
 	int i, ret = 0;
@@ -265,6 +304,13 @@ static int __init init(void)
 	else if ((ret = ebt_register_watcher(&ulog)))
 		sock_release(ebtulognl->sk_socket);
 
+	if (nf_log_register(PF_BRIDGE, &ebt_ulog_logger) < 0) {
+		printk(KERN_WARNING "ebt_ulog: not logging via ulog "
+		       "since somebody else already registered for PF_BRIDGE\n");
+		/* we cannot make module load fail here, since otherwise
+		 * ebtables userspace would abort */
+	}
+
 	return ret;
 }
 
@@ -273,6 +319,7 @@ static void __exit fini(void)
 	ebt_ulog_buff_t *ub;
 	int i;
 
+	nf_log_unregister_logger(&ebt_ulog_logger);
 	ebt_unregister_watcher(&ulog);
 	for (i = 0; i < EBT_ULOG_MAXNLGROUPS; i++) {
 		ub = &ulog_buffers[i];

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

[Ingo O. <ne...@ax...>]

Hi Harald,

would you mind merging the prink()s ...

Harald Welte wrote:
> 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
> @@ -55,17 +57,19 @@ static void print_MAC(unsigned char *p)
>  }
>  
>  #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 = (struct ebt_log_info *)data;
>  	char level_string[4] = "< >";
> +	unsigned int bitmask;
>  
> -	level_string[1] = '0' + info->loglevel;
> +	level_string[1] = '0' + loginfo->u.log.level;
>  	spin_lock_bh(&ebt_log_lock);
>  	printk(level_string);
> -	printk("%s IN=%s OUT=%s ", info->prefix, in ? in->name : "",
> +	printk("%s IN=%s OUT=%s ", prefix, in ? in->name : "",
>  	   out ? out->name : "");
>  
>  	printk("MAC source = ");

... here ...

> @@ -75,7 +79,12 @@ static void ebt_log(const struct sk_buff
>  
>  	printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
>  

... and here?

> -	if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
> +	if (loginfo->type == NF_LOG_TYPE_LOG)
> +		bitmask = loginfo->u.log.logflags;
> +	else
> +		bitmask = NF_LOG_MASK;
> +
> +	if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
>  	   htons(ETH_P_IP)){
>  		struct iphdr _iph, *ih;
>  

I prefer evil printk()s over multiple ones :-)


Regards

Ingo Oeser

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

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

Sorry for this extremely delayed follow-up, but I just noticed that this
is the only patch in my 'master' branch that is not yet merged mainline.

On Tue, Oct 18, 2005 at 03:12:17PM +0000, Bart De Schuymer wrote:
> OK, but please fix the typo then. Shouldn't a similar comment be in
> ebt_ulog?

I've addressed both of your concerns (typo and similar comment/message
in ebt_ulog).

If you deem the attached patch fine, please submit it to davem.


[NETFILTER] ebtables: Support nf_log API from ebt_log and ebt_ulog

This makes ebt_log and ebt_ulog use the new nf_log api.  This enables the
bridging packet filter to log packets e.g. via nfnetlink_log.

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

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");
+		/* we cannot 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,13 @@ static int __init init(void)
 	else if ((ret =3D ebt_register_watcher(&ulog)))
 		sock_release(ebtulognl->sk_socket);
=20
+	if (nf_log_register(PF_BRIDGE, &ebt_ulog_logger) < 0) {
+		printk(KERN_WARNING "ebt_ulog: not logging via ulog "
+		       "since somebody else already registered for PF_BRIDGE\n");
+		/* we cannot make module load fail here, since otherwise
+		 * ebtables userspace would abort */
+	}
+
 	return ret;
 }
=20
@@ -273,6 +319,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...@gn...>          	        http://gnumonks.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
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[Ebtables-devel] Problem with ebtables and kernel 2.4.26

[<luc...@al...>]

Hello,
I'm new in bridging but I've tried to use ebtables on Linux Slackware, kernel 
2.4.26.
After patching kernel, I've installed ebtables package, re-compiling kernel 
with Bridge option. Then I use ebtables to set TOS field, but when I type 
brctl addbr br0, there is this error: add bridge failed: Package not installed. 
It is strange because I recompile kernel and I set Bridge option. Could 
anyone help me? Thanks!

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

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

Op di, 18-10-2005 te 10:58 +0200, schreef Harald Welte:
> On Mon, Oct 17, 2005 at 05:59:59PM +0000, Bart De Schuymer wrote:
> > 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!
> > 
> > Sorry for the late reply, some hardware problems got in the way.
> 
> no problem, I probably hold the record of delayed responses, so I can
> understand that completely ;)
> 
> > Apart from the comments below, the patch is fine by me (I tested both).
> 
> great.
> 
> > > +	nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
> > 
> > Should be ebt_log_packet
> 
> why is that?  nf_log_packet() is a function provided by the netfilter
> core in net/netfilter/.  Do you want an ebt_log_packet() wrapper function that just calls
> nf_log_packet() ?

I see it works with nf_log_packet() too. I just tried to mimic what
you're doing for ebt_ulog... Anyway, I'll accept your judgement on this.

> > >  {
> > > -	return ebt_register_watcher(&log);
> > > +	int ret;
> > > +
> > > +	ret = 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 
> > > +		 * ebtables userspace would abort */
> > > +	}
> > 
> > Since we're using PF_BRIDGE instead of PF_INET now, this if construct
> > can be replaced by a simple call to nf_log_register.
> 
> No, I think we only fix the comment (state PF_BRIDGE in the comment) but
> leave it like it is.

OK, but please fix the typo then. Shouldn't a similar comment be in
ebt_ulog?

cheers,
Bart

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

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

On Mon, Oct 17, 2005 at 05:59:59PM +0000, Bart De Schuymer wrote:
> Op za, 08-10-2005 te 01:49 +0200, schreef Harald Welte:
> > Hi Bart!
> >=20
> > 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.
> >=20
> > By default, everything will behave like before.
> >=20
> > Please review, and test that ebt_log and ebt_ulog are still working as
> > expected.  Thanks!
>=20
> Sorry for the late reply, some hardware problems got in the way.

no problem, I probably hold the record of delayed responses, so I can
understand that completely ;)

> Apart from the comments below, the patch is fine by me (I tested both).

great.

> > +	nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
>=20
> Should be ebt_log_packet

why is that?  nf_log_packet() is a function provided by the netfilter
core in net/netfilter/.  Do you want an ebt_log_packet() wrapper function t=
hat just calls
nf_log_packet() ?

> >  {
> > -	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 */
> > +	}
>=20
> Since we're using PF_BRIDGE instead of PF_INET now, this if construct
> can be replaced by a simple call to nf_log_register.

No, I think we only fix the comment (state PF_BRIDGE in the comment) but
leave it like it is.

The issues is, when (in chronological order)

1) someone starts their logging daemon (e.g. ulogd2)
2) the daemon is configured to nf_log_register() for PF_BRIDGE
3) then the ruleset is loaded, which automatically modprobe's ebt_log.ko
4) ebt_log wants to nf_log_register() for PF_BRIDGE

I think we should print some message to syslog to tell the use (once)
that logging will not be done via the system console, even though he
uses the "log" watcher (which traditionally always logged via syslog).

Comments?

--=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

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

Sorry for the late reply, some hardware problems got in the way.
Apart from the comments below, the patch is fine by me (I tested both).

Thanks a lot,
Bart

> @@ -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 = (struct ebt_log_info *)data;
> +	struct nf_loginfo li;
> +
> +	li.type = NF_LOG_TYPE_LOG;
> +	li.u.log.level = info->loglevel;
> +	li.u.log.logflags = info->bitmask;
> +
> +	nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);

Should be ebt_log_packet

>  }
>  
>  static struct ebt_watcher log =
> @@ -154,13 +178,32 @@ static struct ebt_watcher log =
>  	.me		= THIS_MODULE,
>  };
>  
> +static struct nf_logger ebt_log_logger = {
> +	.name 		= "ebt_log",
> +	.logfn		= &ebt_log_packet,
> +	.me		= THIS_MODULE,
> +};
> +
>  static int __init init(void)
>  {
> -	return ebt_register_watcher(&log);
> +	int ret;
> +
> +	ret = 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 
> +		 * ebtables userspace would abort */
> +	}

Since we're using PF_BRIDGE instead of PF_INET now, this if construct
can be replaced by a simple call to nf_log_register.

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

[Ian M. <im...@gm...>]

On 12/10/05, Harald Welte <la...@ne...> wrote:
> 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.g=
it
>
> Try getting it via rsync, I never have successfully ran cg/git via http.
>
If you want to keep using a git tree have a look at a page I put together:
http://wlug.org.nz/KernelDevelopmentWithGit

Ian