DAG cards

Jan Coppens Jan.Coppens at intec.rug.ac.be
Tue Mar 4 12:07:47 EST 2003


Hi Eddie,

Thx for the reply.

> Hi Jan,
> 
> > Does the element "FromDAGDump" support DAG capture-files with full packet
> > capture and variable record size, or is only the older fixed
> > record-size (64byte) supported ? Has someone already implemented an
> > element that captures traffic from a DAG card in Click? (Something like
> > "FromDevice", maybe "FromDAGDevice"?)
> 
> Only the older record size is supported; I didn't even know a variable
> record size existed. Do you have a reference close at hand?

Chapter 11 of the "DAG 4.2GE Installation Guide" defines the new data formats. It says:

In previous releases, records had a fixed length of 64 bytes. This release allows for variable length records of captured data. The DAG4.2GE uses the API Type 2 Ethernet Variable Length Record. Refer to the DAG Programming Guide for more information on the DAG API.
Here is an overview of the data format used: 

Generic Variable Length Record 

      8 byte timestamp 
     1 byte type 
     1 byte 

      flags 
     2 byterlen 
     2 byte lctr 
     2 byte wlen 
     (rlen - 12) bytes of record 
     


timestamp: The time of arrival of this cell (refer to the DAG Standard Timestamps manual for details). 

type: This field contains an enumeration of the frame subtype. If the type is zero, then this is a legacy format. 
0: TYPE_LEGACY 
1: TYPE_HDLC_POS: PoS w/HDLC framing 
2: TYPE_ETH: Ethernet 
3: TYPE_ATM: ATM Cell 

flags: This byte is divided into 2 parts, the interface identifier, and the capture offset. 
1-0: capture interface 0-3 
2: varying record lengths 
3: truncated record (insufficient buffer space) 
7-4: reserved 

rlen: record length: total length of the record transferred over the PCI bus to storage. 

lctr: loss counter A 16 bit counter, recording the number of packets lost between the DAG card and the memory hole due to overloading on the PCI bus. The counter starts at zero, and sticks at 0xffff. 

wlen: wire length: packet length including some protocol overhead. The exact interpretation of this quantity depends on the physical medium. 
Type 2 Ethernet Variable Length Record 

      8 byte timestamp 
     1 byte type: 2 
     1 byte 

      flags 
     2 byterlen 
     2 byte lctr 
     2 byte wlen 
     1 byte offset
     1 byte pad 
     (rlen - 18) bytes of packet 
     


offset: Number of bytes that was *not* captured from the start of the frame. This is typically used to skip link layer headers when they are not required in order to save bandwidth and space.

Important: Timestamps are in little-endian (Pentium native) byte order. All other fields are in big-endian (network) byte order. All payload data is captured as a byte stream, no byte re-ordering is applied. 

> 
> To my knowledge, no one has implemented a FromDAGDevice. I'd love to help
> someone do that, though. Hint hint hint

I'd like to implement the FromDAGDevice in the near future. Do you have any ideas how to begin with the implementation?

Jan

> 
> Eddie
> 
-------------- next part --------------
Hi Eddie,
Thx for the reply.
 
> Hi Jan,
>
> > Does the element "FromDAGDump" support DAG capture-files with full packet
> > capture and variable record size, or is only the older fixed
> > record-size (64byte) supported ? Has someone already implemented an
> > element that captures traffic from a DAG card in Click? (Something like
> > "FromDevice", maybe "FromDAGDevice"?)
>
> Only the older record size is supported; I didn't even know a variable
> record size existed. Do you have a reference close at hand?
Chapter 11 of the "DAG 4.2GE Installation Guide" defines the new data formats. It says:
In previous releases, records had a fixed length of 64 bytes. This release allows for variable length records of captured data. The DAG4.2GE uses the API Type 2 Ethernet Variable Length Record. Refer to the DAG Programming Guide for more information on the DAG API.
Here is an overview of the data format used:
Generic Variable Length Record
8 byte timestamp
1 byte type
1 byte
flags
2 byterlen
2 byte lctr
2 byte wlen
(rlen – 12) bytes of record
timestamp: The time of arrival of this cell (refer to the DAG Standard Timestamps manual for details).
 
type: This field contains an enumeration of the frame subtype. If the type is zero, then this is a legacy format.
0: TYPE_LEGACY
1: TYPE_HDLC_POS: PoS w/HDLC framing
2: TYPE_ETH: Ethernet
3: TYPE_ATM: ATM Cell
 
flags: This byte is divided into 2 parts, the interface identifier, and the capture offset.
1-0: capture interface 0-3
2: varying record lengths
3: truncated record (insufficient buffer space)
7-4: reserved
 
rlen: record length: total length of the record transferred over the PCI bus to storage.
 
lctr: loss counter A 16 bit counter, recording the number of packets lost between the DAG card and the memory hole due to overloading on the PCI bus. The counter starts at zero, and sticks at 0xffff.
 
wlen: wire length: packet length including some protocol overhead. The exact interpretation of this quantity depends on the physical medium.
Type 2 Ethernet Variable Length Record
8 byte timestamp
1 byte type: 2
1 byte
flags
2 byterlen
2 byte lctr
2 byte wlen
1 byte offset
1 byte pad
(rlen – 18) bytes of packet
 
offset: Number of bytes that was *not* captured from the start of the frame. This is typically used to skip link layer headers when they are not required in order to save bandwidth and space.
Important: Timestamps are in little-endian (Pentium native) byte order. All other fields are in big-endian (network) byte order. All payload data is captured as a byte stream, no byte re-ordering is applied.
>
> To my knowledge, no one has implemented a FromDAGDevice. I'd love to help
> someone do that, though. Hint hint hint
I'd like to implement the FromDAGDevice in the near future. Do you have any ideas how to begin with the implementation?
 
Jan
 
>
> Eddie
>


More information about the click mailing list