Ok, it applied nicely. Thanks! But I have a weird feeling abount ebtables/bridge netfilter patch. I've been using bridge-nf in kernel 2.4.19 without problems but when trying ebtables/bridge netfilter patch against 2.4.20 I got this syslog entry on a transparent proxy/bridge (running squid):
br_netfilter: Argh!! br_nf_post_routing: bad mac.raw pointer.[eth1][br0] I don't know if it is serious, and it seems to be only eth1. The NIC is a Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet adapter which is integrated on the mainboard, hence pretty hard to replace. Wouldn't even think of heating up my soldering iron. ;-) I'll try to upgrage to kernel 2.4.22 and apply the latest patch. Bob. -----Original Message----- From: David Chambers [mailto:[EMAIL PROTECTED] Sent: 20. september 2003 00:08 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Bridge] Bridge firewalling with kernel 2.4.22 Try the ebtables/bridge netfilter patch versus 2.4.22 at http://sourceforge.net/project/showfiles.php?group_id=39571 (if the above URL does not work, go to the download section from ebtables.sourceforge.net) I have used this patch and AFAIR it applied nicely. - David On Fri, 19 Sep 2003, Robert Eliassen wrote: > > Hi! > > Trying to patch a 2.4.22 kernel with bridge-nf-0.0.7-against-2.4.19.diff > > According to the website (http://bridge.sourceforge.net/download.html) the > bridge-nf-0.0.7-against-2.4.19.diff patch (quote) "Should apply to most > recent kernels cleanly." (end of quote) > > Well, it didn't. Unpacked a fresh kernel and tried to patch but got the > following: > > # patch -p1 < bridge-nf-0.0.7-against-2.4.19.diff > patching file include/linux/netfilter.h > Hunk #1 succeeded at 118 (offset 1 line). > patching file include/linux/netfilter_ipv4.h > patching file include/linux/skbuff.h > Hunk #1 FAILED at 135. > 1 out of 1 hunk FAILED -- saving rejects to file include/linux/skbuff.h.rej > patching file net/bridge/br.c > Hunk #1 succeeded at 43 (offset 1 line). > Hunk #2 succeeded at 65 with fuzz 1 (offset -5 lines). > patching file net/bridge/br_forward.c > patching file net/bridge/br_input.c > patching file net/bridge/br_netfilter.c > patching file net/bridge/br_private.h > patching file net/bridge/Makefile > patching file net/Config.in > patching file net/core/netfilter.c > patching file net/core/skbuff.c > Hunk #1 FAILED at 231. > Hunk #2 FAILED at 364. > Hunk #3 FAILED at 421. > 3 out of 3 hunks FAILED -- saving rejects to file net/core/skbuff.c.rej > patching file net/ipv4/ip_output.c > Hunk #1 succeeded at 833 (offset 13 lines). > patching file net/ipv4/netfilter/ip_tables.c > patching file net/ipv4/netfilter/ipt_LOG.c > > > It all seems to get down to skbuff.h and skbuff.c which (IMHO) is pretty > much like the heart of Linux networking. I'm reluctant to run a patched > kernel with a messy skbuff-code. I'm not that prejudiced so I took a look at > the code... > > Now, looking at skbuff.h at line 135: > (This is the original, unpatched file) > > struct sock *sk; /* Socket we are owned by > */ > struct timeval stamp; /* Time we arrived > */ > struct net_device *dev; /* Device we arrived on/are > leaving by */ > struct net_device *real_dev; /* For support of point to > point protocols > (e.g. 802.3ad) over > bonding, we must save the > physical device that got > the packet before > replacing skb->dev with > the virtual device. */ > /* Transport layer header */ > union > > And then the according lines in the patch: > > @@ -135,6 +135,8 @@ > struct sock *sk; /* Socket we are owned by > */ > struct timeval stamp; /* Time we arrived > */ > struct net_device *dev; /* Device we arrived on/are > leaving by */ > + struct net_device *physindev; /* Physical device we > arrived on */ > + struct net_device *physoutdev; /* Physical device we will > leave by */ > > /* Transport layer header */ > union > > > It's obvious that the line "struct net_device *real_dev;" got in the > kernel source sometime after 2.4.19. and that it probably the reason the > patch don't apply cleanly. I'm not a kernel hacker although I work as a C > coder so I don't know what this real_dev pointer is. But to me it looks like > *real_dev and *physindev is pretty much the same song (with a different > artist?) > > Has anyone fixed this and made a clean patch on the 2.4.22 kernel? > > I guess I could make one myself, but then again I might be reinventing the > wheel. The quick and diry way would be to just adjust the 2.4.19-patch so it > applies cleanly, but the big question is: Has the Kernel guys done anything > smart so we need less patching in order to get bridge firewalling to work in > 2.4.22 ? I thought 2.4.22 was at feature freeze a long time ago... > > Regards > Bob. > > _______________________________________________ > Bridge mailing list > [EMAIL PROTECTED] > http://www.math.leidenuniv.nl/mailman/listinfo/bridge > -- ------------------------------------------ David Chambers Core Cytometry and Molecular Imaging The Salk Institute 10010 North Torrey Pines Road La Jolla, CA 92037-1099 Tel: (858) 453-4100 x1728 Fax: (858) 453-9681 Email: [EMAIL PROTECTED] Web: http://pingu.salk.edu/~davidc/ ------------------------------------------ _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
