Guy Harris wrote:
>If so, and if (as I infer is the case from your statement that editcap
>couldn't recognize the file) Ethereal can't read your ATM traces
>(Ethereal and editcap use the same code to read and write capture files,
>so the sets of capture files they can read are the same), the only thing
>you can do with Ethereal would be to try to get Ethereal's code to read
>PrismLite files to work on your ATM captures, or send us some of the
>captures to see if we can get that code to handle those files. (Note
>that "we" doesn't mean "me" - Olivier Abad, for example, is more
>familiar with the Radcom file format than I am.)
Olivier Abad actually requested Radcom sample captures some months ago:
http://www.ethereal.com/lists/ethereal-users/200301/msg00157.html
Olivier Abad wrote:
<Currently, ethereal can read RADCOM captures from Ethernet, LAPB and ATM
<networks, but the heuristic we use to look for the network type doesn't
<work for all the files I have. In order to improve RADCOM file support,
<I need to have access to more capture files to be able to guess how the
<network type is really encoded.
<So I would like everybody who has RADCOM capture files (or has access to
<a RADCOM analyzer and can capture some data) to send it to me. Please
<don't forget to tell me from what kind of network the capture was taken,
<and if ethereal can't read the file, to send me an ASCII dissection of
<the capture (if possible).
... and Guy Harris added in the messsage
http://www.ethereal.com/lists/ethereal-users/200301/msg00158.html :
<...and we currently treat all frames in ATM captures as being
<LLC-encapsulated frames, but there might be information in the file to
<indicate the type of the frame (other than, say, the VPI/VCI and the
<first few bytes of the frame).
<So some ATM captures, especially if they have LANE, signalling, or ILMI
<traffic - or raw cells - would be useful as well.
