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

Reply via email to