Mr. Strauss, Thank you for taking the time for responding to my original post.
On Fri, Jun 06, 2003 at 12:19:34PM -0500, Burton M. Strauss III wrote: > 1. http://www.gmane.org - it's in the docs/FAQ for ntop. Couldn't find a link to the FAQ under the above URL, so I grabbed it from the tarball. Thank you for reminding me to read it--please forgive me for not doing so before posting here to begin with. > 2. 'Cooked' sockets are unique to Linux. They're not quite raw, but they're > not quite a real protocol level socket library, they're something in > between. Don't let the terminology scare you. > > It doesn't sound like an ntop problem, it's sounds like a problem with the > underlying packet capture library (libpcap) that doesn't support the > arptype. But since you've cut & pasted only part of the log message, it's > hard to tell. So while libpcap may be unable to decipher the HDLC headers, it can still make a pretty accurate guess about what the layer-3 protocol headers contain. While sniffers which rely on the libpcap library report the same error as Ntop does, these sniffers do correctly (?) perform inspection on what is happening on the TCP/IP level. What is meaningful to me is the ability to determine src/dst for IP and TCP/UDP. The ability to report traffic usage would also be needed. If this can all be done, using Ntop, then further discussions about ARP Type support and HDLC headers may not be necessary. Would you agree? > If you google for arptype "not supported by libpcap" -- you'll see some > entries referring to using an old libpcap. So updating might help. > > If you want to pursue this further, use the ntop problem report form - you > should be able to get ntop up long enough to generate the skeleton if you > don't point ntop at the problem interface. > > However - > > There's no support in ntop right now for HDLC. And you need to understand > how you're using 'HDLC'. HDLC covers a lot of ground. HDLC operates at the > same network layer as TCP/IP, it's a complete layer 2 communications > protocol. > > See, for example, http://www2.rad.com/networks/1994/hdlc/hdlc.htm and > http://members.tripod.com/~vkalra/hdlc.html > > While it's conceptually feasible to extend ntop to support another layer 2 > and higher protocol, it would be very difficult to coerce into ntop's > Ethernet/TCPIP model of MAC and IP addresses. Difficult, but not > impossible. Precisely what reports and such would be available would have > to be determined. > > HDLC can also be used to encapsulate IP traffic for point to point links. > If that's the situation, then (assuming you can update to a libpcap that > supports the interface), we could train ntop to ignore the HDLC headers and > just process the IP portion (like we do today with PPP and PPPoE). I think my previous response was strongly influenced by this comment of yours. Ntop just needs to know that the first few bytes of frames should be ignored (it seems that tethereal and tcpdump may do this already). > HDLC is a dying protocol - so if you're not willing to sponsor development, > I doubt anyone else will. I'll warn you, that either way, this will entail > a fair amount of work, just to get to the point of giving you a cost > quotation. If you're interested in sponsoring the development, contact me > off list. While I'm not against sponsoring development, I need to make sure we really need such ability. If it is possible to obtain the information I require using Ntop (exporting a flow from one unit to be analyzed on another dedicated machine), then Ntop would be the answer. My difficulty getting this to work may be due to a SIGSEGV received from running 'ntop -f' with a traffic dump from running 'tcpdump -w' on a HDLC interface of another machine. Running 'tcpdump -r' allows me to inspect packets. If what I am attempting to do isn't too outrageous, then I will start another thread with the results of a GDB backtrace. Better yet, I will learn how to use Ntop's "probe" functionality and direct it towards Ntop running on a dedicated "display" machine. I have a lot to learn and test. Thank you for allocating your time addressing my comments. Sincerely, hank _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
