On Wed, 2012-10-03 at 08:45 -0400, David Stevens wrote:

netdev-owner@vger.kernel.org wrote on 10/03/2012 03:28:48 AM:
 

quoted

BTW, it seems we dont properly increase UDP MIB counters when a
multicast message is not delivered to at least one socket.

If an interface is in promiscuous mode or there are false
positives in a multicast address filter, wouldn't this count as
"drops" packets that were never intended for this machine?

Yes, probably. So we drop them and its expected.

I think an otherwise valid multicast or broadcast packet that doesn't
have a local receiver is not an error and shouldn't be counted.

Hmmm

This counter is not an "error counter", just a "counter".

RFC definitions are exactly :

udpNoPorts OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The total number of received UDP datagrams for which
               there was no application at the destination port.

udpInErrors OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The number of received UDP datagrams that could not be
               delivered for reasons other than the lack of an
               application at the destination port.


So when a host receives an UDP datagram but there was no application
at the destination port we should increment udpNoPorts, and its not
an error but just a fact.

Now _if_ some reader interprets udpNoPorts increases as an indication
of errors, this reader is wrong.