> From darrenr@reed.wattle.id.au
> In some email I received from Jun Xie, sie wrote:
> [...]
> > A possible fix is to replace
> > 
> > 	m_freem(m);
> > 	ipstat.ips_noproto++;
> > 	ipstat.ips_delivered--;
> > 
> > with
> > 
> > 	if (inetsw[ip_protox[ip->ip_p]].pr_input != rip_input)
> > 		m_freem(m);
> > 	else {
> > 		icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PROTOCOL, 0, 0);
> > 		ipstat.ips_noproto++;
> > 	}
> > 	ipstat.ips_delivered--;
> 
> Hmm ?  Shouldn't it just be:
> 
> if (inetsw[ip_protox[ip->ip_p]].pr_input == rip_input) {
> 	icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PROTOCOL, 0, 0);
> 	ipstat.ips_delivered--;
> 	ipstat.ips_noproto++;
> } else
> 	m_freem(m);
>
> Really, what does "delivered" mean here ?  To me it means either the
> kernel has taken it and processed it (which satisfies it being
> increased for ICMP/IGMP) or an application has received it.  Generally,
> the former has to be true for the latter.

Here are some definitions for ips_delivered/ipInDelivers:
- "datagrams delivered to upper level" (ip_var.h)
- number of "packets for this host" (netstat)
- "#datagrams delivered to transport layer" (R. Stevens' TCP/IP Vol.2)
- "total number of input datagrams successfully delivered to IP user protocols"
  (W. Stallings' SNMP book)

"packets for this host" is vague. ICMP/IGMP are kind of "upper level" of IP
or "IP user protocols" but definitely not "transport layer".

I agree that ips_delivered should not be decremented here for ICMP/IGMP
packets, because those ICMP packets that are reflected but not delivered
(e.g., ICMP_ECHO) are counted in too.

Jun