Bruce M Simpson wrote:
>
> Hi,
>
> At this point I'm tempted to explicitly *not* roll support for IPFW1
> in XORP's ACL manager precisely because of its limitations; see below.
I'd say IPFW1 is dead. Just ignore it and require IPFW2 on 4.x.
> On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Opp
В вт, 14/12/2004 в 17:13 +0100, Andre Oppermann пишет:
> > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph
> > filtering has nothing common with host filtering.
>
> Nontheless you need to call it from somewhere?
Yes, If, for example, I do connection of two VPNs without
On Tue, Dec 14, 2004 at 03:23:02PM +0100, Andre Oppermann wrote:
...
> > the struct ifnet. All i meant to say is that we want a unique
> > key, possibly in a small namespace, to quickly locate the per-if
> > private firewall info. How the key is used is not a business of
> > the rest of the kernel.
В вт, 14/12/2004 в 17:56 +0100, Andre Oppermann пишет:
> > > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph
> > > > filtering has nothing common with host filtering.
> > >
> > > Nontheless you need to call it from somewhere?
> >
> > Yes, If, for example, I do connectio
>> As i also said before, i agree that when the number of interfaces
>> becomes large, managing ipfw lists can become difficult (though i
>> see no way your technique can help without the assistance of scripts
>> generating the actual lists for each interface making sure that the
>> 'common' checks
On Tue, Dec 14, 2004 at 04:32:51PM +0100, Andre Oppermann wrote:
> See below.
>
> > > Wouldn't it be even better to have per-interface and global rules
> > > after each other? This way your problem with the general rule
> > > synching can be solved.
> >
> > this is what gleb suggested later toda
On Tue, Dec 14, 2004 at 07:05:20AM -0800, Bruce M Simpson wrote:
...
> Are there any nicer ways of telling IPFW v1 and v2 apart both at compile
> time and run-time? Right now I do something like this:-
With very high accuracy, at compile time you can say that ipfw2 is
available from 4.7 and higher
As someone who is quite new to all of this, take my thoughts with a
grain of salt. That being said, this is my view on the matter.
On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Let's take a high level view of the issue at hand and the consider
> some alternative
On Tue, 14 Dec 2004 14:27:01 -0500, Josh Kayse <[EMAIL PROTECTED]> wrote:
> As someone who is quite new to all of this, take my thoughts with a
> grain of salt. That being said, this is my view on the matter.
>
> On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> > L
Andre Oppermann wrote:
Hence you need a ng_ipfw node to plug in between. Should be easy for
Gleb to write one.
One has existed for several years, bu tit hasn't been integrated for
various reasons (
and probably laziness on my part)
___
[EMAIL PROTE
On Tue, 14 Dec 2004, Heinz Knocke wrote:
Hi,
[sk(4) problems]
> Honestly said I don't know how to track it further, because
> the link layer (hardware or the driver) seems just to clip
> frames. If there's not enought info for the solution please
> tell me what tests can I do - I'll do it ASAP.
I just built a 5.3RELEASE machine out of a Gigabyte GA-8I915P Duo Pro,
which has two BCM5751 chips on board.
These interfaces come up at 1000BaseTX according to the link lights on
my switches, but drop back to 100BaseTX/full-duplex when the bge driver
loads.
ifconfig bge0 media 1000baseTX resu
Answering (maybe) my own question, it looks like the changes to miidevs
and brgphy didn't make the 5.3 cut, even though the changes to bge did.
Will advise.
Aleksandr Milewski wrote:
I just built a 5.3RELEASE machine out of a Gigabyte GA-8I915P Duo Pro,
which has two BCM5751 chips on board.
The
Hi,
I would like to establish a TCP/IP connection over USB between my
FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port.
I've read that udbp can be used for this purpose, but I have not found
enough information about it to be able to use it. Could someone explain
me how th
James,
On Tue, Dec 14, 2004 at 12:33:07AM -0500, James wrote:
J> I'm personally against modifying ipfw(4) for this purpose. It gets into the
J> complexity of syntax and simply violates the initial simple model of the
whole
J> ipfw packet filter itself. I agree in that freebsd systems acting as
Luigi,
On Mon, Dec 13, 2004 at 10:42:00AM -0800, Luigi Rizzo wrote:
L> I considered doing that when designing ipfw2 (implementing per-interface
L> lists in addition to the global one, for backward compatibility),
L> but then decided against it because 1) a simple initial switch based
L> on the i
On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote:
A> Different worlds. I wonder why everything has to "like Cisco". It's
A> not always the most clever way they solve a given problem.
By the way, Juniper has per-interface filters, too. Juniper's world
is not so far from ours, as Ci
On Mon, Dec 13, 2004 at 10:50:01PM +0100, Andre Oppermann wrote:
A> > (Now I speak only about ipfw. But other filters can be used in same
A> > manner with a very small changes.)
A> >
A> > We have list of rules defined in struct ip_fw_chain. At this moment
A> > we have only one instance of it - a g
On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
...
> > Implementationwise, the kernel side is evidently trivial as the
> > original code already supports the idea of multiple chains. All
> > you need is to extend the struct ifnet with a pointer to the chain,
> > or use some other
On 2004.12.14 06:13:07 -0800, Bruce M Simpson wrote:
> What I'm really missing in IPFW is the ability to maintain one or more
> 'shadow rulesets'. These rulesets may not be the active rulesets, but
> I can manipulate them as tables, independently of the active ruleset(s),
> push rules into them, f
Bruce M Simpson wrote:
>
> On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote:
> > Let's take a high level view of the issue at hand and the consider
> > some alternative approaches to the situation.
> [snip]
>
> I'm wrapping up in Berkeley for the holidays, but I wanted to drop my 2
Hi,
Could we also add ability to keep state between reseting of the rules?
For, example, if I use keepstates, after flushing and setting new rules that
could be different by two lines from an old one I kick my self from that
server with out any serious reason, I didn't change anything for ssh.
I
Hi,
At this point I'm tempted to explicitly *not* roll support for IPFW1
in XORP's ACL manager precisely because of its limitations; see below.
On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Oppermann wrote:
> IPFW2 does have this functionality. It's called "sets" of rules which
> you can atomi
Ð ÐÑ, 14/12/2004 Ð 16:02 +0100, Andre Oppermann ÐÐÑÐÑ:
> Vladimir Grebenschikov wrote:
> >
> > Ã ÃÃ, 14/12/2004 Ã 13:54 +0100, Andre Oppermann Ã:
> > > It's about HOW to implement it. I think the ways proposed so far are
> > > hackish, too complex and outside of our framework which was very w
Vladimir Grebenschikov wrote:
>
> ÷ ×Ô, 14/12/2004 × 17:13 +0100, Andre Oppermann ÐÉÛÅÔ:
>
> > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph
> > > filtering has nothing common with host filtering.
> >
> > Nontheless you need to call it from somewhere?
>
> Yes, If, fo
On Tue, Dec 14, 2004 at 06:20:10AM -0800, Luigi Rizzo wrote:
> They do exist, they are called 'set' and you can associate
> rules to a specific set, atomically enable/disable/swap/rename
> sets, etc. This was designed exactly for this purpose (atomic
> updates of firewall configuration with a singl
Vladimir Grebenschikov wrote:
>
> > It breaks the PFIL_HOOKS API.
>
> If I not mistaken Gleb claims that do not break:
>
> G> please don't take this hard. I'm not going to change pfil(4) API,
> G> since it has everything required.
But this is not correct. He changes the way PFIL_HOOKS are call
On Tue, Dec 14, 2004 at 04:20:31PM +0300, Gleb Smirnoff wrote:
>>> ipfw syntax will be 100% backward compatible. The following keywords would
>>> be added:
>>>
>>> ipfw chain list - list configured chains
>>> ipfw chain add | delete - delete, remove chain
>>> ipfw chain _nu
Aleksandr Milewski wrote:
Answering (maybe) my own question, it looks like the changes to miidevs
and brgphy didn't make the 5.3 cut, even though the changes to bge did.
Will advise.
That was it.
Pulled in miidevs, brgphy.c, brgphyreg.h from HEAD
bge0: gigabit link up
bge1: gigabit link up
And th
Pierre-Luc Drouin wrote:
Hi,
I would like to establish a TCP/IP connection over USB between my
FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port.
I've read that udbp can be used for this purpose, but I have not found
enough information about it to be able to use it. Could s
Hi!
Marvell's chip is not in supported nics section of 5_3 release notes, but in
man sk is , so I decided to write.
I've got some boxes with Marvell Gigabit NICs on-board (Gigabyte and ASUS).
Sadly, I can't be happy with it and freebsd 5.3 because of the following two
problems:
a) sk0 driver
31 matches
Mail list logo
