Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
> 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
I agree, but this is still better than crashing the machine... Aron -Original Message- From: Michael Renzmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 1:33 PM To: Aron Brand Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
