All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
@ 2004-01-27  9:30 Aron Brand
  2004-01-27 11:32 ` Michael Renzmann
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Aron Brand @ 2004-01-27  9:30 UTC (permalink / raw)
  To: lartc

Hi Roy,

Strange. "kernel will resend then together with new ones" - this is
interesting, since the firewall DOES know how to drop locally generated
packets and the kernel doesn't attempt to retry them. I am not an expert
on this, but I think it might be interesting to check how the firewall
does this. Another option would be to trick the kernel that the packet
has been transmitted, to prevent the immediate retries, while actually
vanishing the packet.

Aron



--__--__--

Message: 8
From: "Roy" <roy@xxx.lt>
To: <rubens@etica.net>
Cc: <lartc@mailman.ds9a.nl>
Subject: Re: [LARTC] NEW imq driver
Date: Tue, 27 Jan 2004 06:42:29 +0200

Seems I was to fast to declare success,
my version is not much more stable than the original one,everything
depends
on dropped packets.
 This is even not imq fault afterall, can be prowed in other way also:

atempts to police outgoing trafic it will be ok until you dont touch
localy
generated packets
if you try to drop them you will be sorry, because kernel will resend
then
together with new ones
of cource policer will drop them too, but linux kernel keeps resending
then
thus increasing rate progresively.

I noticed that with my trafic counter. internal trafic grew to enormous
levels 10X more than it can be. In reality there was almost no output at
all.
so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on
100mb/s
it probably can kill computer (not tested).

Seems imq have similar problem  even if driver itself have no leaks
kernel
consumes all resousces on resnending droped packets so that computer
stops
responding


for now I dont have good idea how to fix it so I will try to avoid
localy
generated trafic
so it will me possible to shape ingress and forward, egress will be left
for
real device.
maybe later I will find how fix that



>
> It seems to capture ingress and egress traffic of all interfaces;
wouldn't
> this count packets twice ?

No, ingress is for local and egress for everything so everything should
be
ok (in theory)

> If the machine is doing SNAT or DNAT, what IP addresses would be seen
by
> the qdisc ?
>

I made driver see the final destination address because it is more
usefull


> Rubens
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
  2004-01-27  9:30 [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Aron Brand
@ 2004-01-27 11:32 ` Michael Renzmann
  2004-01-27 12:02 ` Aron Brand
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Michael Renzmann @ 2004-01-27 11:32 UTC (permalink / raw)
  To: lartc

Hi.

Aron Brand wrote:
> does this. Another option would be to trick the kernel that the packet
> has been transmitted, to prevent the immediate retries, while actually
> vanishing the packet.

I'm also no pro in this area, but I think this would be a bad idea. I 
guess this would have impact on the interface's statistics about sent, 
received and dropped packets, making it hard to look for network 
configuration errors and similar things.

Bye, Mike

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
  2004-01-27  9:30 [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Aron Brand
  2004-01-27 11:32 ` Michael Renzmann
@ 2004-01-27 12:02 ` Aron Brand
  2004-01-27 12:09 ` Michael Renzmann
  2004-01-28  4:57 ` Roy
  3 siblings, 0 replies; 5+ messages in thread
From: Aron Brand @ 2004-01-27 12:02 UTC (permalink / raw)
  To: lartc

I agree, but this is still better than crashing the machine...

Aron 

-----Original Message-----
From: Michael Renzmann [mailto:mrenzmann@otaku42.de] 
Sent: Tuesday, January 27, 2004 1:33 PM
To: Aron Brand
Cc: lartc@mailman.ds9a.nl; roy@xxx.lt
Subject: Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs

Hi.

Aron Brand wrote:
> does this. Another option would be to trick the kernel that the packet

> has been transmitted, to prevent the immediate retries, while actually

> vanishing the packet.

I'm also no pro in this area, but I think this would be a bad idea. I
guess this would have impact on the interface's statistics about sent,
received and dropped packets, making it hard to look for network
configuration errors and similar things.

Bye, Mike


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
  2004-01-27  9:30 [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Aron Brand
  2004-01-27 11:32 ` Michael Renzmann
  2004-01-27 12:02 ` Aron Brand
@ 2004-01-27 12:09 ` Michael Renzmann
  2004-01-28  4:57 ` Roy
  3 siblings, 0 replies; 5+ messages in thread
From: Michael Renzmann @ 2004-01-27 12:09 UTC (permalink / raw)
  To: lartc

Hi.

Aron Brand wrote:
> I agree, but this is still better than crashing the machine...

As was mentioned before: the netfilter framework itself is able to drop 
packets without negative side effects. So this should also be possible 
for IMQ (or any other network device driver).

Bye, Mike

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
  2004-01-27  9:30 [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Aron Brand
                   ` (2 preceding siblings ...)
  2004-01-27 12:09 ` Michael Renzmann
@ 2004-01-28  4:57 ` Roy
  3 siblings, 0 replies; 5+ messages in thread
From: Roy @ 2004-01-28  4:57 UTC (permalink / raw)
  To: lartc



> As was mentioned before: the netfilter framework itself is able to drop
> packets without negative side effects. So this should also be possible
> for IMQ (or any other network device driver).
>

Well, this needs to be tested. I will try nerfilter module which can drop
each n-th packet.
I wonder what will happen.
At least policer was not sucessfull for dropping packets.

Basicaly all this could be fixed if to find a way to tell kernel  that
device is busy and dont want more data.



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-01-28  4:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-27  9:30 [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Aron Brand
2004-01-27 11:32 ` Michael Renzmann
2004-01-27 12:02 ` Aron Brand
2004-01-27 12:09 ` Michael Renzmann
2004-01-28  4:57 ` Roy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.