As Gerald Combs - Unicom Communications said:
>
> I want a program so good that whenever magazines like Network Computing
> and NetworkWorld review a commercial analyzer, hordes of people send in
> letters to the editor saying that the product is crap, and that if you
> _really_ want an analyzer, you should check out Ethereal. :)
That's a good goal. I think all of us have used commercial sniffers enough
to have a personal wishlist of features ... "if I were to write a sniffer,
I'd ..."
> - Gilbert and I had a discussion a while back, and we both agree
> that we need more functionality from libpcap than is currently
> available. LBL might accept patches for bug fixes, but they might
> not want mods to handle other file formats, network hardware, or
> extended filter directives.
Yes, I think we'll have to develop our own library. I thing libepcap or
whatever will need:
The same cross-platform portability as libpcap.
Fixes to Linux Token-Ring capturing (which I have to put in ethereal
because libpcap doesn't do it).
More information about the sniffing architecture and NIC should be in
the output file.
Live capture and file-reading, like libpcap. However, I want to read
uncompressed NAI sniffer output, LANAlyzer output files, snoop, and
others.
And from the on-line wishlist: compressed output files (like NAI),
reading from multiple NICs at once.
Also, the libepcap filter language should support network object
naming, even at the hardware address level.
More protocols should export variables/fields to the filter language.
The BPF filtering is very much oriented to TCP/IP testing.
Multi-thread safe? This would be useful in ethereal: one thread handles
GTK, one thread captures new data (libepcap), and another thread
dissect()s the newly captured data into the ethereal window.
The same encapsulation IDs across platforms. Gerald and I discovered
that the AIX libpcap uses different DLT_* values for PPP and Token-Ring
than non-AIX libpcaps.
Cross-platform data files. I want to sniff on a big-endian machine
and use etheral on a little-endian machine.
> - There isn't much validation or range checking in the packet dissection
> routines at the present time. This needs to be fixed, for reasons
> of security and stability.
this is definitely needed. Lots of my own code assumes that the packet is
good and complies to the appropriate RFC.
--gilbert
--
Gilbert Ramirez Voice: +1 210 358 4032
Technical Services Fax: +1 210 358 1122
University Health System San Antonio, Texas, USA
