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.
