> > How does libpcap 0.5 fit into this?
>
> libpcap should be the library Ntop uses to capture and filter packets.
> WinPcap is the better porting of libpcap on Win32; it has all
> the original
> system calls plus some more.
Since I've got all unix (Linux) machines, WinPcap doesn't really apply in
this case.
> > <shrug> Even if it's missing packets, it ought to miss
> them at random,
> > right? Therefore at least the percentages for relative
> amount of protocol
> > usage would be correct. The raw bandwidth numbers I can
> get from the
> > routers themselves via SNMP.
> >
> > As long as it doesn't *crash* it'll probably work... once the packet
> > dissectors are fixed.
>
> I guess so.
> The relative percentage should be correct; however you suold
> not be able to
> determine the link load.
> I mean, you should be able to know that IPX traffix = 30% IP,
> but you should
> to be able to know that IP traffic = 80% of the link bandwidth.
Except that some of the decoders/dissectors don't interpret the packets
properly.
Examples: We are using the Ethernet II frame type for IPX. However, ntop
incorrectly calls those "Other IP". Bay Networks Autotopology frames and
Spanning Tree BPDUs are interpreted as "AppleTalk".
That sort of thing.
I'll be putting the 1GHz ntop box into play today anyway, just to see if it
can hack the load (regardless of the accuracy of the information). That box
also has ethereal 0.8.14 installed on it for actual packet capturing. If
there are any interesting results I'll let you know.
--J