On Oct 30, 2003, at 10:29 AM, Scott Emberley wrote:
Could you add the following files to the source tree.
Some issues:
1) It doesn't appear to be using "g_ntohl()", "g_ntohs()", any of the
"pntoh" or "pletoh" macros, or any other canonical-to-host-byte-order
conversion functions or macros - I suspect the fields in the file and
packet headers are in some standard byte order (given that it's an
application for x86-based PC's, that's *probably* little-endian byte
order), and that has to be converted to the byte order of the machine
running Ethereal, which isn't necessarily little-endian:
% uname -srp
Darwin 7.0.0 powerpc
2) It's using "guint64", which is supported by most of the platforms
on which Ethereal runs, but not all of them - unless we decide to stop
supporting those platforms (one I know of is some old form of SINIX),
we'd need to handle that in some other way, e.g. using floating point.
3) It has C++-style comments in C code; some C compilers don't accept
that.
4) In the current CVS version of Ethereal, for WTAP_ENCAP_ETHERNET the
pseudo-header's "eth.fcs_len" value has to be filled in with:
0, if the packet data doesn't contain the FCS for the Ethernet frame
(or, rather, wouldn't have even if the entire packet had been captured
- snapshot-length trimming doesn't count);
4, if it does contain the FCS (in which case phdr.len should include
the FCS);
-1, if it might or might not contain the FCS (Ethereal does a
heuristic to try to guess; this is required for some capture formats
such as libpcap format).
One question:
It says in "observer_read()" that it "neglect[s] frame marker" when it
subtracts 4 from packet_header.network_size and assigns the result to
wth->phdr.len - what's the frame marker? If it's an FCS, such as the
CRC-32 at the end of an Ethernet packet, it shouldn't be removed.