It appears that the first two bytes of "xxz" are, in fact, the actual
authorGuy Harris <guy@alum.mit.edu>
Tue, 7 Jan 2003 08:41:23 +0000 (08:41 -0000)
committerGuy Harris <guy@alum.mit.edu>
Tue, 7 Jan 2003 08:41:23 +0000 (08:41 -0000)
commit4ef5d246332d236538329c94514b441114e6ec54
tree6d69d935b2a964e4ce0d9118afad30c52b7bf8e9
parentf8a7dc5ad367a2e76d81ec09bee8af9b57caf885
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet.  The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).

Treat "ATM/", as an encapsulation string, as RFC 1483 ATM.  (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)

There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now.  (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that?  Or perhaps that's in the record
header?)

svn path=/trunk/; revision=6871
wiretap/radcom.c