I don't trust Packet Builder's ability to convert time stamps between
Capsa format and pcap.
Change-Id: I0ac2e14216e37127d81d5bf1c6d48a2c20841a8e
Reviewed-on: https://code.wireshark.org/review/4721
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Clean up the code to read the block according to that description.
Change-Id: Icb332e293c4b41d91989aa17a7546f298068e908
Reviewed-on: https://code.wireshark.org/review/4716
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The time stamps aren't known to be right, so don't provide them - that
way, instead of users reading Capsa files and getting the wrong idea
about the time stamps, they'll get no time stamps and have to ask for
our help, at which point we can ask them for *their* help in seeing what
Capsa thinks the time stamps are. (The joys of reverse-engineering.)
Change-Id: I77e12c09f2bc74b50a1b2b226fa6da3e8c0fedf9
Reviewed-on: https://code.wireshark.org/review/4685
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(So why can't GCC or Clang be taught to warn about *all* implicit
shortenings, as MSVC does, not just 64-bit-to-32-bit shortenings?)
Change-Id: I88c0b0aa2f1b306f58952589ff8bcae17bc29768
Reviewed-on: https://code.wireshark.org/review/4676
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Yes, we should, on platforms with a 32-bit time_t, check to make sure
the time stamp fits and do something if it doesn't. Or we should make
the seconds part of an nstime_t be 64-bit and handle overly-large values
when converting them to year/month/day/hour/minute/second.)
Change-Id: If219534985dce29d00754ff151f6c4b5893080d8
Reviewed-on: https://code.wireshark.org/review/4675
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The time stamp origin is not correct. Capsa's absolute time stamp for
the sample captures from their Web site would be helpful.
Change-Id: I365daf7b42240e33f54df76939254f41ed57a9b2
Reviewed-on: https://code.wireshark.org/review/4671
Reviewed-by: Guy Harris <guy@alum.mit.edu>