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/
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/
> 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/