[Bridge] bridge at start up
Kjetil Lund
kjetil.lund at tekblad.no
Fri Jan 28 10:53:47 PST 2005
Create a simple startup-script in init.d, as described here for example:
http://commmunity.linux.com/howtos/Bridge+Firewall+DSL-3.shtml
--
Regards
K. Lund
-----Original Message-----
From: Dominic Anyanna
To: bridge at lists.osdl.org
Sent: 28.01.2005 18:55
Subject: [Bridge] bridge at start up
hi i have gone through the achieves but still could not get my bridge to
suvive a reboot .
please can anyone help me am using fedora core 2
-----Original message-----
From: bridge-request at lists.osdl.org
Date: Fri, 28 Jan 2005 03:08:06 +0100
To: bridge at lists.osdl.org
Subject: Bridge Digest, Vol 17, Issue 25
> Send Bridge mailing list submissions to
> bridge at lists.osdl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osdl.org/mailman/listinfo/bridge
> or, via email, send a message with subject or body 'help' to
> bridge-request at lists.osdl.org
>
> You can reach the person managing the list at
> bridge-owner at lists.osdl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bridge digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Bart De Schuymer)
> 2. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Patrick McHardy)
> 3. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (David S. Miller)
> 4. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Patrick McHardy)
> 5. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (David S. Miller)
> 6. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Patrick McHardy)
> 7. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Rusty Russell)
> 8. Re: [PATCH/RFC] Reduce call chain length in netfilter
> (Rusty Russell)
>
>
>
----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 Jan 2005 22:16:04 +0100
> From: Bart De Schuymer <bdschuym at pandora.be>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: "David S. Miller" <davem at davemloft.net>
> Cc: netdev at oss.sgi.com, netfilter-devel at lists.netfilter.org,
> bridge at osdl.org, snort2004 at mail.ru,
gandalf at wlug.westbo.se,
> rusty at rustcorp.com.au, dwmw2 at infradead.org, ak at suse.de,
> shemminger at osdl.org
> Message-ID: <1106860564.3389.4.camel at localhost.localdomain>
> Content-Type: text/plain
>
> Op do, 27-01-2005 te 11:47 -0800, schreef David S. Miller:
> > On Thu, 27 Jan 2005 18:50:50 +0100
> > Patrick McHardy <kaber at trash.net> wrote:
> >
> > > From what I can see it doesn't generate tail-calls currently:
> >
> > Indeed... It even doesn't do this on Sparc64 either, even for
> > the okfn(skb) call which I was sure it would.
> >
> > It won't tail-call for function pointers for some strance reason
> > as exhibited by this simple test:
> >
> > struct sk_buff {
> > int foo;
> > };
> >
> > int invoke(struct sk_buff *skb, int (*okfn)(struct sk_buff *))
> > {
> > return okfn(skb);
> > }
> >
> > extern int test_func(struct sk_buff *);
> >
> > int invoke2(struct sk_buff *skb)
> > {
> > return test_func(skb);
> > }
> >
> > In the generated asm on sparc64, invoke2() gets a tail-call
> > whereas invoke() does not. Hmmm...
>
> Pasha (<snort2004 at mail.ru>) is currently using a bridge-nf patch vs
> 2.4.29 with the changes I sent to you. After two days he sent me
> (yesterday) a message that all is well. Without the patch he was
getting
> the stack overflow oopses.
>
> cheers,
> Bart
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 Jan 2005 23:48:04 +0100
> From: Patrick McHardy <kaber at trash.net>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: "David S. Miller" <davem at davemloft.net>
> Cc: netdev at oss.sgi.com, netfilter-devel at lists.netfilter.org,
> bdschuym at pandora.be, bridge at osdl.org, snort2004 at mail.ru,
> rusty at rustcorp.com.au, dwmw2 at infradead.org, ak at suse.de,
> shemminger at osdl.org, gandalf at wlug.westbo.se
> Message-ID: <41F96FA4.4000105 at trash.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> David S. Miller wrote:
>
> >In the generated asm on sparc64, invoke2() gets a tail-call
> >whereas invoke() does not. Hmmm...
> >
> >
> Apparently support for indirect tail-calls was added to gcc 3.4.
>
> gcc-3.3.5:
> 0x0000000000000000 <invoke+0>: sub $0x8,%rsp
> 0x0000000000000004 <invoke+4>: callq *%esi
> 0x0000000000000006 <invoke+6>: add $0x8,%rsp
> 0x000000000000000a <invoke+10>: retq
>
> gcc-3.4.4:
> 0x0000000000000000 <invoke+0>: mov %rsi,%r11
> 0x0000000000000003 <invoke+3>: jmpq *%r11d
>
> Regards
> Patrick
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 Jan 2005 15:24:50 -0800
> From: "David S. Miller" <davem at davemloft.net>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: Patrick McHardy <kaber at trash.net>
> Cc: netdev at oss.sgi.com, netfilter-devel at lists.netfilter.org,
> bdschuym at pandora.be, bridge at osdl.org, snort2004 at mail.ru,
> rusty at rustcorp.com.au, dwmw2 at infradead.org, ak at suse.de,
> shemminger at osdl.org, gandalf at wlug.westbo.se
> Message-ID: <20050127152450.6daba4fa.davem at davemloft.net>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 27 Jan 2005 23:48:04 +0100
> Patrick McHardy <kaber at trash.net> wrote:
>
> > David S. Miller wrote:
> >
> > >In the generated asm on sparc64, invoke2() gets a tail-call
> > >whereas invoke() does not. Hmmm...
> >
> > Apparently support for indirect tail-calls was added to gcc 3.4.
>
> Good data point.
>
> I've been trying to figure out ways to decrease the number of
> args that get sent to nf_hook_slow but this would require
> some API changes unfortunately.
>
> One idea goes like this, we create little descriptors of the form:
>
> struct nf_hook_desc {
> int (*okfn)(struct sk_buff *);
> int pf;
> int hook;
> };
>
> Then NF_HOOK*() callsites do something like this:
>
> static const struct nf_hook_desc nf_ip_local_out = {
> .okfn = dst_output,
> .pf = PF_INET,
> .hook = NF_IP_LOCAL_OUT,
> };
>
> ...
>
> /* Send it out. */
> return NF_HOOK(&nf_ip_local_out, skb, NULL, rt->u.dst.dev);
>
> This gets us down to 4 arguments from 6. I think we can kill
> one more.
>
> It is never the case that both indev and outdev are both
> set, so we can use some nf_hook_desc piece of state to
> indicate which (in or out) the passed device pointer is.
>
> Oh yes, we can nicely add the thresh thing in here too
> while we're at it.
>
> So the final nf_hook_desc might look something something like:
>
> struct nf_hook_desc {
> int (*okfn)(struct sk_buff *);
> int hook;
> int thresh;
> u8 pf; /* AF_MAX is 32 */
> u8 is_output;
> };
>
> Hook could possibly use a smaller type as well to condense
> the size of this thing even further. I don't know if there
> are any nice assumptions we can make about the hook numbers.
>
> Now, back to the compatability issue. We could create a
> new macro, NF_HOOK_DESC() and keep the existing ones around
> via some nf_hook_slow() that basically does:
>
> int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb,
> struct net_device *indev, struct net_device *outdev,
> int (*okfn)(struct sk_buff *), int thresh)
> {
> struct nf_hook_desc desc;
>
> desc.okfn = okfn;
> desc.hook = hook;
> desc.thresh = thresh;
> desc.pf = pf;
> desc.is_output = (outdev != NULL);
> return nf_hook_desc(&desc, skb, (outdev ? outdev : indev));
> }
>
> So the final new stuff looks something like:
>
> #ifdef CONFIG_NETFILTER
> struct nf_hook_desc {
> int (*okfn)(struct sk_buff *);
> int hook;
> int thresh;
> u8 pf; /* AF_MAX is 32 */
> u8 is_output;
> };
> #define NF_DESC_DECLARE(_name, _okfn, _hook, _thresh, _pf,
_is_output) \
> static const struct nf_hook_desc _name = { \
> .okfn = _okfn, \
> .hook = _hook, \
> .thresh = _thresh, \
> .pf = _pf, \
> .is_output = _is_output, \
> };
>
> extern int nf_hook_desc(struct nf_hook_desc *desc, struct sk_buff
*skb,
> struct net_device *dev);
>
> #define NF_HOOK_DESC(_desc, _skb, _dev) \
> nf_hook_desc(_desc, _skb, _dev)
> #endif
>
> Just throwing around ideas... comments?
>
> ------------------------------
>
> Message: 4
> Date: Fri, 28 Jan 2005 01:08:54 +0100
> From: Patrick McHardy <kaber at trash.net>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: "David S. Miller" <davem at davemloft.net>
> Cc: netdev at oss.sgi.com, netfilter-devel at lists.netfilter.org,
> bdschuym at pandora.be, bridge at osdl.org, snort2004 at mail.ru,
> rusty at rustcorp.com.au, dwmw2 at infradead.org, ak at suse.de,
> shemminger at osdl.org, gandalf at wlug.westbo.se
> Message-ID: <41F98296.9040804 at trash.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> David S. Miller wrote:
>
> >I've been trying to figure out ways to decrease the number of
> >args that get sent to nf_hook_slow but this would require
> >some API changes unfortunately.
> >
> >One idea goes like this, we create little descriptors of the form:
> >
> >struct nf_hook_desc {
> > int (*okfn)(struct sk_buff *);
> > int pf;
> > int hook;
> >};
> >
> >Then NF_HOOK*() callsites do something like this:
> >
> >static const struct nf_hook_desc nf_ip_local_out = {
> > .okfn = dst_output,
> > .pf = PF_INET,
> > .hook = NF_IP_LOCAL_OUT,
> >};
> >
> >...
> >
> > /* Send it out. */
> > return NF_HOOK(&nf_ip_local_out, skb, NULL, rt->u.dst.dev);
> >
> >This gets us down to 4 arguments from 6. I think we can kill
> >one more.
> >
> >It is never the case that both indev and outdev are both
> >set, so we can use some nf_hook_desc piece of state to
> >indicate which (in or out) the passed device pointer is.
> >
> >
> indev and outdev are both set in the forward hook.
>
> >Oh yes, we can nicely add the thresh thing in here too
> >while we're at it.
> >
> >So the final nf_hook_desc might look something something like:
> >
> >struct nf_hook_desc {
> > int (*okfn)(struct sk_buff *);
> > int hook;
> > int thresh;
> > u8 pf; /* AF_MAX is 32 */
> > u8 is_output;
> >};
> >
> >Hook could possibly use a smaller type as well to condense
> >the size of this thing even further. I don't know if there
> >are any nice assumptions we can make about the hook numbers.
> >
> >
> There are currently five hooks. I really hope we'll never reach
> 256, so u8 should be big enough.
>
> >Now, back to the compatability issue. We could create a
> >new macro, NF_HOOK_DESC() and keep the existing ones around
> >via some nf_hook_slow() that basically does:
> >
> >int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb,
> > struct net_device *indev, struct net_device *outdev,
> > int (*okfn)(struct sk_buff *), int thresh)
> >{
> > struct nf_hook_desc desc;
> >
> > desc.okfn = okfn;
> > desc.hook = hook;
> > desc.thresh = thresh;
> > desc.pf = pf;
> > desc.is_output = (outdev != NULL);
> > return nf_hook_desc(&desc, skb, (outdev ? outdev : indev));
> >}
> >
> >So the final new stuff looks something like:
> >
> >#ifdef CONFIG_NETFILTER
> >struct nf_hook_desc {
> > int (*okfn)(struct sk_buff *);
> > int hook;
> > int thresh;
> > u8 pf; /* AF_MAX is 32 */
> > u8 is_output;
> >};
> >#define NF_DESC_DECLARE(_name, _okfn, _hook, _thresh, _pf,
_is_output) \
> >static const struct nf_hook_desc _name = { \
> > .okfn = _okfn, \
> > .hook = _hook, \
> > .thresh = _thresh, \
> > .pf = _pf, \
> > .is_output = _is_output, \
> >};
> >
> >extern int nf_hook_desc(struct nf_hook_desc *desc, struct sk_buff
*skb,
> > struct net_device *dev);
> >
> >#define NF_HOOK_DESC(_desc, _skb, _dev) \
> > nf_hook_desc(_desc, _skb, _dev)
> >#endif
> >
> >Just throwing around ideas... comments?
> >
> >
> Sounds like a good idea to get rid of the static arguments to
> nf_hook_slow. Keeping both devices we are still down from 7 to
> 4 arguments with your suggestion.
>
> Regards
> Patrick
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 27 Jan 2005 17:10:23 -0800
> From: "David S. Miller" <davem at davemloft.net>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: Rusty Russell <rusty at rustcorp.com.au>
> Cc: netdev at oss.sgi.com, bdschuym at pandora.be, bridge at osdl.org,
> snort2004 at mail.ru, gandalf at wlug.westbo.se,
> netfilter-devel at lists.netfilter.org, dwmw2 at infradead.org,
ak at suse.de,
> shemminger at osdl.org
> Message-ID: <20050127171023.2e8547e1.davem at davemloft.net>
> Content-Type: text/plain; charset=US-ASCII
>
> On Fri, 28 Jan 2005 11:29:29 +1100
> Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> > No, let's just fix them all.
>
> In tree, yes. But leaving the NF_HOOK()/NF_HOOK_THRESH() compat
> macros in there for out-of-tree modules I feel is mandatory, it's
> a major API change.
>
> ------------------------------
>
> Message: 6
> Date: Fri, 28 Jan 2005 02:35:42 +0100
> From: Patrick McHardy <kaber at trash.net>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: Rusty Russell <rusty at rustcorp.com.au>
> Cc: netdev at oss.sgi.com, bdschuym at pandora.be, bridge at osdl.org,
> snort2004 at mail.ru, gandalf at wlug.westbo.se, Netfilter
development
> mailing list <netfilter-devel at lists.netfilter.org>,
> dwmw2 at infradead.org, ak at suse.de, shemminger at osdl.org, "David
S.
> Miller" <davem at davemloft.net>
> Message-ID: <41F996EE.2030409 at trash.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Rusty Russell wrote:
>
> >On Thu, 2005-01-27 at 17:10 -0800, David S. Miller wrote:
> >
> >>In tree, yes. But leaving the NF_HOOK()/NF_HOOK_THRESH() compat
> >>macros in there for out-of-tree modules I feel is mandatory, it's
> >>a major API change.
> >>
> >
> >I'm not so sure. The hook functions which are registered, sure (ie.
> >keep the calling convention the same). But do any external modules
use
> >NF_HOOK()? That implies they're writing their own network stack for
> >some protocol, which I would expect to be uncommon.
> >
> Freeswan comes to mind. But I guess one more #ifdef can't hurt :)
>
> Regards
> Patrick
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 28 Jan 2005 11:29:29 +1100
> From: Rusty Russell <rusty at rustcorp.com.au>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: "David S. Miller" <davem at davemloft.net>
> Cc: netdev at oss.sgi.com, bdschuym at pandora.be, bridge at osdl.org,
> snort2004 at mail.ru, gandalf at wlug.westbo.se, Netfilter
development
> mailing list <netfilter-devel at lists.netfilter.org>,
> dwmw2 at infradead.org, ak at suse.de, shemminger at osdl.org
> Message-ID: <1106872169.18360.6.camel at localhost.localdomain>
> Content-Type: text/plain
>
> On Thu, 2005-01-27 at 15:24 -0800, David S. Miller wrote:
> > It is never the case that both indev and outdev are both
> > set, so we can use some nf_hook_desc piece of state to
> > indicate which (in or out) the passed device pointer is.
>
> NF_IP_FORWARD... it's really *really* useful for filtering forwarded
> packets. However, is it ever the case that indev != skb->dev? If
not,
> we can simply drop that arg and use skb->dev.
>
> > Now, back to the compatability issue. We could create a
> > new macro, NF_HOOK_DESC() and keep the existing ones around
> > via some nf_hook_slow() that basically does:
>
> No, let's just fix them all. Also, gcc 3.4 will discard unused
static
> variables, so I prefer the kernel start just declaring structs as
> normal, and have them "used" in the !CONFIG case by an inline
function
> which allows gcc to realize that it can be eliminated, but suppresses
> unused warnings. This also means you get type checking etc without
the
> config option.
>
> BTW, someone should go through and start ripping out #ifdef
> CONFIG_PROC_FS around those structs, too...
>
> Cheers,
> Rusty.
> --
> A bad analogy is like a leaky screwdriver -- Richard Braakman
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 28 Jan 2005 12:32:25 +1100
> From: Rusty Russell <rusty at rustcorp.com.au>
> Subject: [Bridge] Re: [PATCH/RFC] Reduce call chain length in
> netfilter
> To: "David S. Miller" <davem at davemloft.net>
> Cc: netdev at oss.sgi.com, bdschuym at pandora.be, bridge at osdl.org,
> snort2004 at mail.ru, gandalf at wlug.westbo.se, Netfilter
development
> mailing list <netfilter-devel at lists.netfilter.org>,
> dwmw2 at infradead.org, ak at suse.de, shemminger at osdl.org
> Message-ID: <1106875946.18360.29.camel at localhost.localdomain>
> Content-Type: text/plain
>
> On Thu, 2005-01-27 at 17:10 -0800, David S. Miller wrote:
> > On Fri, 28 Jan 2005 11:29:29 +1100
> > Rusty Russell <rusty at rustcorp.com.au> wrote:
> >
> > > No, let's just fix them all.
> >
> > In tree, yes. But leaving the NF_HOOK()/NF_HOOK_THRESH() compat
> > macros in there for out-of-tree modules I feel is mandatory, it's
> > a major API change.
>
> I'm not so sure. The hook functions which are registered, sure (ie.
> keep the calling convention the same). But do any external modules
use
> NF_HOOK()? That implies they're writing their own network stack for
> some protocol, which I would expect to be uncommon.
>
> Rusty.
> --
> A bad analogy is like a leaky screwdriver -- Richard Braakman
>
>
> ------------------------------
>
> _______________________________________________
> Bridge mailing list
> Bridge at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/bridge
>
>
> End of Bridge Digest, Vol 17, Issue 25
> **************************************
>
AfriOne Mail - AfriOne Cares!!!
<<ATT01947.txt>>
More information about the Bridge
mailing list