[EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
Sure, the idea was to mark the filter table obsolete as to make people
start using the mangle table to do their filtering for new setups. The
filter table would then still be available for legacy/special setups
Bill Davidsen wrote:
Bill Davidsen wrote:
If not, then shouldn't the filter table be obsoleted to avoid
confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with
Ilpo Järvinen wrote:
Willy Tarreau wrote:
I agree with this. The impression I got from the description of the two
patches I merged was that the problems they fix were quite annoying. But
maybe I should take that with a grain of salt.
No, it's not a grain of salt. I would say its utterly
Patrick McHardy wrote:
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Seems to work, I got your mail on netfilter-devel.
Looks like it works sometimes
Jan Engelhardt wrote:
On Oct 12 2007 00:31, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter-develm=117400063907706w=2
Patrick McHardy wrote:
Al Boldi wrote:
The problem is that people think they are safe with the filter table,
when in fact they need the prerouting chain to seal things. Right now
this is only possible in the mangle table.
Why do they need PREROUTING?
Well, for example to stop any
Patrick McHardy wrote:
Al Boldi wrote:
But can you see how forcing people into splitting
their rules across tables adds complexity. And without ipt_REJECT
patch, they can't even use REJECT in prerouting, which forces them to do
some strange hacks.
IMHO, we should make things
Patrick McHardy wrote:
Jan Engelhardt wrote:
On Oct 12 2007 16:30, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter
table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
If not, then shouldn't the filter table be obsoleted to avoid confusion?
Thanks!
--
Al
-
To
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT
Jeff Garzik wrote:
Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce fourth release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.
This
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
it does not give too much implementation detail (would be inapropriate
for conference proceedings,
Evgeniy Polyakov wrote:
Al Boldi ([EMAIL PROTECTED]) wrote:
Look at ZFS; it illegally violates layering by combining md/dm/lvm with
the fs, but it does this based on a realistic understanding of the
problems involved, which enables it to improve performance, flexibility,
and functionality
Jean-Baptiste Vignaud wrote:
Mmm, bad news, after 4 hours of intensive network stressing, one of the 2
3com card failed with the latest fedora kernel.
Aug 6 22:31:09 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
Aug 6 22:31:09 loki kernel: eth2: transmit timed out, tx_status 00
Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 select NF_CONNTRACK_ENABLED.
This exposes IPv4/6 connection tracking options for easier Kconfig setup.
Signed-off-by: Al Boldi [EMAIL PROTECTED]
Cc: Patrick McHardy [EMAIL PROTECTED]
Cc: David Miller [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL
Patrick McHardy wrote:
Al Boldi wrote:
Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 select
NF_CONNTRACK_ENABLED.
One thought that occured to me after the last of many false bugreports
that were actually caused by failure to configure the new options
properly. Most people know they want
Patrick McHardy wrote:
Sam Ravnborg wrote:
On Tue, Jul 24, 2007 at 08:36:33AM +0300, Al Boldi wrote:
Replaces NF_CONNTRACK_ENABLED with NF_CONNTRACK and selects it for
NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
This exposes IPv4/6 connection tracking options for easier Kconfig
setup
Patrick McHardy wrote:
Al Boldi wrote:
Patrick McHardy wrote:
But I vaguely recall having tried this myself and it broke somewhere,
maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
recall anymore. Al, if this also works without removal of
NF_CONNTRACK_ENABLED, please resend
Patrick McHardy wrote:
Al Boldi wrote:
Also, we could leave this as is, and select NF_CONNTRACK_ENABLED instead
of NF_CONNTRACK.
I guess so, and that would have to select NF_CONNTRACK.
Should I resend, or can you take care of it?
Thanks!
--
Al
-
To unsubscribe from this list: send
Zhao Xiaoming wrote:
The latest update:
It seems that Linux kernel memory management mechanisms including
buddy and slab algorisms are not very efficient under my test
conditions that tcp stack requires a lot of (hundreds of MB) packet
buffers and release them very frequently.
Here
The tulip driver is really great, but after suspending the device, the driver
does not restore the promisc bit when resuming from S1/S3/S4.
To work around this, an ifconfig eth0 up, on the already up device, restores
it.
Is there an easy way to fix this?
Thanks!
--
Al
-
To unsubscribe from
Ed L. Cashin wrote:
On Thu, Jan 26, 2006 at 01:04:37AM +0300, Al Boldi wrote:
Ed L. Cashin wrote:
This patch is a bugfix that follows and depends on the
eight aoe driver patches sent January 19th.
Will they also fix this?
Or is this an md bug?
No, this patch fixes a bug that would
Ed L. Cashin wrote:
This patch is a bugfix that follows and depends on the
eight aoe driver patches sent January 19th.
Will they also fix this?
Or is this an md bug?
It only happens with aoe.
Also, why is aoe slower than nbd?
md: bindetherd/e0.0
[ cut here ]
kernel BUG
Bernd Eckenfels wrote:
Al Boldi wrote:
The current ip / ifconfig configuration is arcane and inflexible. The
reason being, that they are based on design principles inherited from
the last century.
Yes I agree, however note that some of the asumptions are backed up and
required by RFCs
John W. Linville wrote:
Al Boldi wrote:
Here specifically, ip/ifconfig is implemented upside-down requiring a
link/dev to exist for an address to be defined, in effect containing
layer 3 inside layer 2, when an address should be allowed to be
defined w/o a link/dev much like an app
Ben Greear wrote:
Al Boldi wrote:
Here specifically, ip/ifconfig is implemented upside-down requiring a
link/dev to exist for an address to be defined, in effect containing
layer 3 inside layer 2, when an address should be allowed to be defined
w/o a link/dev much like an app is allowed
The current ip / ifconfig configuration is arcane and inflexible. The reason
being, that they are based on design principles inherited from the last
century.
In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
achieving new design-goals to enable a flexible non-redundant
27 matches
Mail list logo
