Bug 27283
| Summary: | netstat -i missing IPv4 input packet count for tun interface | ||
|---|---|---|---|
| Product: | Base System | Reporter: | bill <bill> |
| Component: | bin | Assignee: | Brian Somers <brian> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
bill
2001-05-12 14:20:01 UTC
State Changed From-To: open->feedback Ipkts seems to be incrementing ok on my -stable machine. Can the submitter confirm that the link was actually functional when the netstat -i was done ? Opkts seems very low.... Responsible Changed From-To: freebsd-bugs->brian I'll look after this Hmm, I think I know what the problem is. Recently, the network traffic counters were changed so that they count things on a per-ip basis. I'd guess that your tun interface changed IP number and therefore lost all of the old packet counts. WRT the other interfaces, I can't say for sure. Maybe Joe (cc'd) can comment on this - he did the changes :) Perhaps this is also due to an IP number change.... I've just done some quick tests here, and it looks as if just ifconfig'ing the interface with the same IP number that it currently has will reset the traffic counts. This doesn't sound good... Comments Joe ? > Yes, the link was definitely functional. And yes, now that you > mention it, the IPv4 opkts -- as well as almost all of the IPv4 > counts -- are too low. The only IPv4 count that could possibly be > accurate is sis1 opkts, but all of the link-layer counts look good. > > As an aside, all of my other systems, from 3.2-RELEASE through > 4.2-STABLE, have the same count for the link-layer and IPv4 rows > under each column. Starting with 4.3, the code appears to have > changed in terms of how packets are classified. I see the same thing > on one of my 5.0-CURRENT boxes. -- Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org> Don't _EVER_ lose your sense of humour ! No, the IP address has not changed on any of the interfaces.
And that wouldn't explain why ipkts is always zero for IPv4
on the tun interface.
The tun interface is used by pipsecd, by the way.
Bill
On 24-May-01 Brian Somers wrote:
> Hmm, I think I know what the problem is.
>
> Recently, the network traffic counters were changed so that they
> count things on a per-ip basis. I'd guess that your tun interface
> changed IP number and therefore lost all of the old packet counts.
>
> WRT the other interfaces, I can't say for sure. Maybe Joe (cc'd) can
> comment on this - he did the changes :) Perhaps this is also due to
> an IP number change.... I've just done some quick tests here, and it
> looks as if just ifconfig'ing the interface with the same IP number
> that it currently has will reset the traffic counts. This doesn't
> sound good...
>
> Comments Joe ?
>
>> Yes, the link was definitely functional. And yes, now that you
>> mention it, the IPv4 opkts -- as well as almost all of the IPv4
>> counts -- are too low. The only IPv4 count that could possibly be
>> accurate is sis1 opkts, but all of the link-layer counts look good.
>>
>> As an aside, all of my other systems, from 3.2-RELEASE through
>> 4.2-STABLE, have the same count for the link-layer and IPv4 rows
>> under each column. Starting with 4.3, the code appears to have
>> changed in terms of how packets are classified. I see the same thing
>> on one of my 5.0-CURRENT boxes.
>
> --
> Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
> Don't _EVER_ lose your sense of humour !
>
>
State Changed From-To: feedback->closed After testing the current behaviour, I conclude that the netstat -i output is correct, and corresponds exactly to ``show ipcp'' from the ppp prompt. I would observe that when you ``close; open'' from the ppp prompt, ppp doesn't clear the interface counters, however because it modifies the inteface addresses (even if it gets the same one again when the interface comes up), the kernel counters are reset. This behaviour was changed shortly before this bug was originally raised in 2001. |
