file_read(buf, bsize, count, file) macro is compilant with fread
function and takes elements count+ size of each element, however to make
it compilant with gzread() it always returns number of bytes.
In wiretap file_read() this is not really used, file_read is called
either with bsize set to 1 or count to 1.
Attached patch remove bsize argument from macro.
svn path=/trunk/; revision=36491
wtap-int.h, and change the unions of pointers to those private data
structures into just void *'s.
Have the generic wtap close routine free up the private data, rather
than the type-specific close routine, just as the wtap_dumper close
routine does for its private data. Get rid of close routines that don't
do anything any more.
svn path=/trunk/; revision=32015
iSeries capture processor. Parse the start date into year/month/day at
the time we see it, rather than for every packet; that means we don't
need to allocate a buffer to hold the date as a string (a buffer which
we weren't ever freeing).
svn path=/trunk/; revision=31981
do *not* modify the string handed to them - they g_mallocate a new
string and return it.
Create routines that *do* ASCII-only case mapping in place, and use them
instead.
Clean up indentation.
svn path=/trunk/; revision=26131
argument, as
1) it doesn't modify the string that argument points to
and
2) it's a buffer of "char".
Use g_ascii_xdigit_value() and put the values of the two bytes together
ourselves; strtoul() is a bit of overkill for two-hex-digit pairs.
While we're at it, check for invalid hex digits, and for bytes where
only one hex digit is present.
svn path=/trunk/; revision=25392
since rev 17756, meant that attempts to read iSeries files would fail in the
"Make sure it [pkt_encap] is not WTAP_ENCAP_PER_PACKET" assertion in
wtap_read().
Also set file_encap to WTAP_ENCAP_ETHERNET (instead of WTAP_ENCAP_PER_PACKET)
since it seems that all the packets in iSeries files are Ethernet (or at least
this module currently only supports Ethernet).
svn path=/trunk/; revision=25388
Attached is a small patch that correct an issue with reading certain IBM
iSeries Comms traces.
Traces where data has been dropped for whatever reason now have the
packet number suffixed with an asterix "*", this causes the current
iSeries wiretap routine to report a "bad" header. The attached patch
simply scans the packet number field and removes any "* characters prior
to scanning, the fact that data may be missing is more than adequately
reported later by current wireshark packet processing.
Regards .. Martin
svn path=/trunk/; revision=23000
Check for a case where, conceivably, the on-the-wire packet length (from
the IP header) could be shorter than the captured data length (due to
Ethernet padding), and handle it by making sure the on-the-wire length
is always >= the captured data length.
svn path=/trunk/; revision=21490
The patch addresses issues with higher precision packet
timings on top end iSeries hardware and should enable the iseries wiretap to handle timings in both micro and nano seconds.
svn path=/trunk/; revision=19428
> I've attached a fix that cleans up this code, actually since my last
> update of this module the particular call in question was fairly
> redundant so I just went ahead and removed it and updated the constant
> that specifies the maximum possible line length instead.
>
> Thanks for bring this to my attention.
svn path=/trunk/; revision=17737
Following my last submitted patch I did some further investigation on the different types of iSeries Comms Traces, although the field formats are constant, things such as page throws and line spacing vary depending on the tool used to pull the trace form the iSeries spool.
This patch should better handle the different formats and more importantly exit in a graceful manner if an unknown format is encountered.
svn path=/trunk/; revision=17699
Guy Harris