Frank v. Münchow-Pohl wrote:
when my understanding is correct, the requested feature
should be provided in packet.dll (when using winpcap as capture
interface), not in ethereal itself.
No, it should be in libpcap, so that it can be provided when WinPcap
*isn't* being used as a capture interface - WinPcap doesn't work very
well on my primary laptop, for example, except perhaps in a Virtual PC
for Mac window, and won't work on my other laptop except perhaps in
Windows-under-VMWare on a Linux or perhaps FreeBSD partition.
There'd probably still have to be some differences between the Win32 and
UN*X versions of the code, as the calls to manipulate serial ports would
be different, but a lot of the code (e.g., code to extract frames and
remove escapes) could be shared by the Win32 and UN*X versions.
I realized, that handling VJ- and PPP-compression
would be a lot of work, but I don't need them in my work now.
It seems to me, that these features are handled in ethereal
rather than in winpcap, but to make ethereal understand compressed
data through a pcap file, they have to be decoded (Or is there a way
to tell ethereal to decode these packets?).
As long as information as to which direction the packets were travelling
is available, Ethereal can decode that automatically, at least for VJ
compression, as there's a PPP protocol type for that, and Ethereal
recognizes it.
Unfortunately, the current libpcap format doesn't have that information.
You could try having your stand-alone program write the file in
pppdump format, which does have that information - and which contains
raw bytes from the serial line, so the code wouldn't have to extract
frames and remove escape sequences (although if it works in that fashion
it wouldn't fit into libpcap/WinPcap, which expect frames to be delivered).