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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of frank rizzo
Sent: Friday, April 08, 2005 12:39 PM
To: [email protected]
Subject: RE: [Ntop-dev] RE: [Ntop] Jumbo frame support question
Aye - quite ugly - but working. I dont see any DLT type reported when I
turned on -K and -t 4.
-wP
--- Burton Strauss <[EMAIL PROTECTED]> wrote:
> So the DLT messages are reporting this still as 10Base-T ( DLT: Device
> 1 [eth2] is 1, mtu 1514, header 14 )???
>
> That's ugly because there's then no way to tell them apart...
>
> -----Burton
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of frank rizzo
> Sent: Thursday, April 07, 2005 3:38 PM
> To: [email protected]
> Subject: [Ntop-dev] RE: [Ntop] Jumbo frame support question
>
> I changed the mtu for the EN10MB DLT type in globals-core.c table to
> 9000 as you described:
>
> _mtuSize[DLT_EN10MB] = 9000;
>
> Its a kludge but works for me (my C is weak sauce).
> Gig ints are now happily plugging away without too-large packet
> warnings.
>
> Thanks!
>
> -wP
>
>
> --- Burton Strauss <[EMAIL PROTECTED]> wrote:
> > The FAQ is in the source, and also available
> HTMLized through About |
> > Help.
> >
> > There is no explicit support. To the extent jumbo
> frames are just
> > large Ethernet frames, ntop will work.
> >
> > First, let's move this to ntop-dev...
> >
> > The code to handle "DLT" (Data Link Type) is
> largely in pbuf.c,
> > although the table is in globals-core.c.
> >
> >
> > The mtu table is set in initNtopGlobals(), look
> for
> > _mtu:
> >
> > { int ii;
> > for (ii=0; ii<MAX_DLT_ARRAY; ii++) {
> > _mtuSize[ii] = CONST_UNKNOWN_MTU;
> > _headerSize[ii] = 0;
> > }
> > }
> >
> > _mtuSize[DLT_NULL] = 8232
>
> > /* no
> > link-layer encapsulation */;
> > _headerSize[DLT_NULL] = CONST_NULL_HDRLEN;
> >
> > So we need to figure out the values.
> >
> > Run ntop w/ -t 4 (trace level 4) and grep out the
> > DLT: messages, e.g.:
> >
> > Apr 1 14:39:21 tigger ntop[2434]: DLT: Device 0
> > [eth1] is 1, mtu 1514,
> > header 14
> > Apr 1 14:39:21 tigger ntop[2434]: DLT: Device 1
> > [eth2] is 1, mtu 1514,
> > header 14
> >
> > That will show how ntop is seeing the frames. It may simply be a
> > matter of increasing the mtu upper value, or it may be
> another
> > ethertype, which will
> > require coding in pbuf.c
> >
> >
> > -----Burton
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of frank rizzo
> > Sent: Friday, April 01, 2005 4:39 PM
> > To: [email protected]
> > Subject: [Ntop] Jumbo frame support question
> >
> > I am relatively new to ntop and this list, so I apologize if this is
> > something that has been covered (the FAQ site is also down
> > apparently).
> >
> > I have a gig nic that I have enabled jumbo frames
> on
> > -- the specific application that I am working with consists primary
> > of jumbo-frame multicast data. The MTU shows as 1500 in the ntop
> > status -- my nic is set to 9000. I see no ability to change
> this
> > in the config of ntop.
> > Am I missing something? Can ntop deal with jumbo frames?
> >
> > Thanks,
> >
> > -wP
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Personals - Better first dates. More second dates.
> > http://personals.yahoo.com
> >
> > _______________________________________________
> > Ntop mailing list
> > [email protected]
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> >
> > _______________________________________________
> > Ntop mailing list
> > [email protected]
> > http://listgateway.unipi.it/mailman/listinfo/ntop
> >
>
>
>
> __________________________________
> Yahoo! Messenger
> Show us what our next emoticon should look like.
> Join the fun.
> http://www.advision.webevents.yahoo.com/emoticontest
> _______________________________________________
> Ntop-dev mailing list
> [email protected]
>
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>
> _______________________________________________
> Ntop-dev mailing list
> [email protected]
>
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
