Ill take a look again to see if I can divine the DLT
type being reported.
Re: traffic stats -- yes as far as buckets: 1504-2500
3500-6500 and 6500+ would be good breaks for me --
though my application may not be the best to use as
the example. Anyone else have thoughts?
On another note related to my use of the tool -- I am
adding a custom non-IP protocol (the one generating
the jumbos) for tracking and stats. I think I have it
all hacked in but am failing miserably with graph.c --
I am getting complaints e.g.):
graph.c: In function 'hostTrafficDistrib':
graph.c:846: warning: declaration of `theHost' shadows
a parameter
graph.c:590: warning: shadow declaration is here
graph.c:946: warning: declaration of `dataSent'
shadows a parameter
graph.c:590: warning: shadow declaration is here
graph.c:846: warning: no previous prototype for
`hostFragmentDistrib'
graph.c:846: warning: declaration of
`hostFragmentDistrib' shadows a global declaration
etc. ad nauseum. Per my previous post my C is not so
good. I used stp as the sample non-IP proto to add in
support for my ether proto (0x63).
Any ideas what I am doing wrong?
Thanks!
-wP
--- Burton Strauss <[EMAIL PROTECTED]> wrote:
> The basic DLT message is INFO, so it should appear
> at -t 3 or higher:
>
> traceEvent(CONST_TRACE_INFO, "DLT: Device %d [%s]
> is %d, mtu %d, header
> %d",
> deviceId,
> myGlobals.device[deviceId].name,
> myGlobals.device[deviceId].datalink,
> myGlobals.device[deviceId].mtuSize,
>
> myGlobals.device[deviceId].headerSize);
>
> $ grep DLT: /var/log/ntopdevel
> Apr 8 11:39:46 tigger devel[3162]: DLT: Device 0
> [eth1] is 1, mtu 1514,
> header 14
> Apr 8 11:39:46 tigger devel[3162]: DLT: Device 1
> [eth2] is 1, mtu 1514,
> header 14
>
>
> The larger value won't hurt anything that I can see.
>
>
> Except for dns sniffing (and most servers won't be
> sending jumbos), ntop
> rarely goes in more than a handful of bytes, even in
> the deep packet
> inspection routines.
>
> The code in pbuf.c just reports it (if you have set
> the option) and then
> truncates the packet:
>
> (length > myGlobals.device[deviceId].mtuSize) )
> {
> /* Sanity check */
>
> if(myGlobals.runningPref.enableSuspiciousPacketDump)
> {
> traceEvent(CONST_TRACE_WARNING, "Packet # %u
> too long (len = %u)!",
> (unsigned
> int)myGlobals.device[deviceId].ethernetPkts.value,
> (unsigned int)length);
> dumpSuspiciousPacket(actualDeviceId);
> }
>
> /* Fix below courtesy of Andreas Pfaller
> <[EMAIL PROTECTED]> */
> length = myGlobals.device[deviceId].mtuSize;
>
>
incrementTrafficCounter(&myGlobals.device[actualDeviceId].rcvdPktStats.tooLo
> ng, 1);
> }
>
>
>
> Obviously part of the problem is we can't tell if
> the NIC we are using to
> monitor will accept jumbo frames. We could simply
> reset to 9K if we see one
> over 1500... (1504 for VLANs). Or is it 64K???
> That's one issue. Another
> is whether we can figure out from the interface what
> MTU for the device is -
> some skulking seems to show that the call SIOCGIFMTU
> isn't always
> available...
>
> And it might be nice to add a few more buckets to
> trafficStats.html to
> report on Jumbos. What would be good break points?
>
> -----Burton
>
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
