netdev - Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Jun 2010 18:28:08 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	netdev@...r.kernel.org, Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is
 not successful

Le mercredi 02 juin 2010 à 11:12 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, Eric Dumazet wrote:
> 
> > Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
> >
> > > Yes but they are not increment any counter. If packets are dropped because
> > > of the rp_filter setting interfering f.e. then the packets vanish without
> > > any accounting.
> > >
> >
> > But packets are vanishing either way.
> 
> Its important to know why drops occur (any drops for that matter, drops
> mean retransmit which means latency). The symptom here was that
> multicast traffic on secondary interfaces was not being forwarded to the application.
> The rp_filter just dropped them and there was no way to easily track down
> the issue for the people experiencing the problem.
> 

I just dont follow you.

Your patch has nothing to do with dropped packets because of rp_filter. 

You inserted a counter increment in a path that is not taken at all by
packet delivery.

Maybe I missed something really obvious with your patch ?

It should only matters for the admin doing following command :

ip route get 1.2.3.4 from 192.168.0.1 iif eth0

That is a probe, not a 'packet delivery', this is why I said
incrementing an official MIB counter was probably wrong.

> In 2.6.31 the rp_filter was fixed to work properly with multicast and now
> it considers multicast traffic to secondary interfaces to have the wrong
> reverse path even though the multicast subscription occurred on the
> secondary interface. So it drops multicast traffic. The rp_filter has to
> be switched off when using multiple NICs for multicast load balancing.
> 

Have you considered CONFIG_NET_DROP_MONITOR ?
This one catches all possible cases, a developper doesnt have to patch
his kernel to add SNMP counters everywhere...

config NET_DROP_MONITOR
        boolean "Network packet drop alerting service"
        depends on INET && EXPERIMENTAL && TRACEPOINTS
        ---help---
        This feature provides an alerting service to userspace in the
        event that packets are discarded in the network stack.  Alerts
        are broadcast via netlink socket to any listening user space
        process.  If you don't need network drop alerts, or if you are ok
        just checking the various proc files and other utilities for
        drop statistics, say N here.


> > > LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> > > counters that allow us to diagnose and distinguish all the different
> > > causes of packet loss? We would love to have that.
> > >
> >
> > For an example, you could take a look at commit 907cdda5205b
> > (tcp: Add SNMP counter for DEFER_ACCEPT)
> 
> Well these are all TCP counters. I would add IP and UDP counters?

Why not ?

But as David said, it should be motivated by real use case ;)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html