> > I'd say this was a byte order problem for sure, except that 942359487 isn't
> > anything with low-order zeros in base 16.
>
> It's not a byte order problem. Here is the fix:
Nope. That change would cause the Linux version of "libpcap" to be able
to read *ONLY* "tcpdump" files from systems with the broken version of
the library, and to be *incapable* of reading files from any *other*
version of "libpcap" - *even if the Linux system in question doesn't
have the broken version of "libpcap"*.
I.e., it'd have the same effect that Alexey's bogus patch has.
The fix is the one I sent out in my mail, and checked into the CVS tree
- it allows us to read normal, modified, and broken "libpcap" files.
(It still means we write normal files, rather than modified or broken
files, but to change that I'd have to change "Save" and "Save As" to
write stuff out using Wiretap, and to put a combo box to let you select
the format in which to save the file into the file selection box for
"Save" and "Save As", so you can choose whether to write normal or
modified files. I have some code to do the first part of that.)
