|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Darren Reed (avalon
coombs.anu.edu.au)Date: Sun Apr 07 2002 - 09:18:42 CDT
In some mail from Crist J. Clark, sie said:
>
> On Sun, Apr 07, 2002 at 06:09:48PM +1000, Darren Reed wrote:
> > In some mail from Crist J. Clark, sie said:
> > >
> > > It's in 5.0-CURRENT so it may make 5.0-RELEASE. ;) I do not plan to
> > > merge the code into 4.x-STABLE in its current form. I really am not
> > > happy with how it works in -CURRENT either, but to get it to work more
> > > cleanly and in a way darrenr suggested, I'd need to modify IPFilter
> > > code, which I have tried to avoid. So the -CURRENT code is
> > > experimental, but that's OK for -CURRENT. It's not OK for -STABLE.
> >
> > Ack. what was it that I suggested (that needed ipfilter code changed) ?
>
> A separate inetsw[] structure for the bridging. I don't see how you
> can do that without changing IPFilter code. Or am I missing something?
No, you're not.
> I _can_ do this, and it creates some really interesting possibilities
> (the obvious one being completely independent filter lists for the
> bridge and the IP stack). But I really do not want to create a
> divergent branch of IPFilter that isn't going to get merged back
> in.
Yes, I have been considering this too.
In some ways, it makes sense.
For example, you might have a box with both bridging interfaces and
routing interfaces.
Darren
To Unsubscribe: send mail to majordomo
FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]