the capture; set it to that when writing the capture.
Support Token Ring and FDDI captures (as per the network type in the
file header appearing to be either the NDIS network type, or the NDIS
network type minus 1 - I forget whether Ethernet has an NDIS type of 0
or 1).
Don't write the file header twice, keeping a static copy of it around,
as Wiretap code isn't supposed to keep any static data around; instead,
write it only when we're done writing out all the records (as we do on
Network Monitor captures).
Compute the time stamps when writing the file.
Give Windows Sniffer 1.1-format a short name, so "editcap" doesn't dump
core or print "(null)" in its usage message.
WTAP_ENCAP_NULL isn't supported by NetMon; don't write it.
svn path=/trunk/; revision=1336
1) fix the check for the IE identifier to check all bits,
including the topmost bit;
2) print all fields in the Date IE as 2 digits.
svn path=/trunk/; revision=1335
Now should be decoding the names of lots more LanMan API request. These
were culled from Samba. Would be good to go through and give names to the
fields as well.
Will soon decode the response structures returned and then will look at
ways to specify that built-in routines should be called to decode an element.
I also need some captures with UNICODE in them. Anyone got any? Someone
sent in a patch for UNICODE handling, but I did not realize what it was and
now the code has diverged so far it is hard to apply the patch ...
Send captures to rsharpe@ns.aus.com./
svn path=/trunk/; revision=1334
instead of from DCE).
I can now open a RADCOM X.25 capture in ethereal, save it as sniffer, and
read it with a sniffer. The frame directions are correct. (BTW, the
snifconv.exe tool provided by RADCOM doesn't work with X.25 captures).
svn path=/trunk/; revision=1331
not have been supported in older versions of CMU SNMP. Instead, pick
our own names for the values, and define them appropriately for UCD and
CMU SNMP.
svn path=/trunk/; revision=1322
It's very basic, and doesn't write out the timestamps currently. It also
only handles WTAP_ENCAP_ETHERNET, although it can probably do the others,
but I don't have a good way to test them. This code has not yet been tested
against a Sniffer Pro, although wiretap can read the files just fine.
svn path=/trunk/; revision=1318
(but not in the string attached to the GUI proto_tree, because
proto_tree_add_item_format() was being used) was getting filled in with
the value of "prog" instead of "proc".
svn path=/trunk/; revision=1314
at all since the GtkText widget does not scroll horizontally (it says
so in the GTK+ docs and in the gtktext.c file in the GTK+ distribution).
Even if the Ethereal window is shrunk horizontally, the text widget will
line wrap (we could turn that off, but it just truncates the line, instead
of making the text widget horizontally-scrollable).
Also, change the packet list scrollbar policy to AUTOMATIC so that scroll
bars only appear when needed. This is how the protocol tree pane has
been configured already.
svn path=/trunk/; revision=1308
window is extended veritically, either up or down, the packet list
and hex dump pane sizes stay the same, and the protocol tree pane
is the one that grows. Hurrah! Of course you can still modify the
size of each pane with the little separator between each pane.
svn path=/trunk/; revision=1307
Update editcap to print out the type of capture file if -v specified and
add a -h flag. Also fix a few compiler warnings ...
svn path=/trunk/; revision=1302
- use a subtree for each facility
- decode the DTE address when appropriate
Address decoding in call setup and clearing packets :
- the A bit is the first bit of the general format identifier
- correct use of this A bit (toa parameter) in x25_ntoa
svn path=/trunk/; revision=1300
In packet_hex_print(), compute (bstart + blen) only once.
In time_secs_to_str(), return a meaningful string when time == 0, instead
of returing pointer to char buffer with old, inappropriate data in it.
svn path=/trunk/; revision=1297
from Guy, plus a few more of my own.
Also added in basic response decoding where we don't know what it is ...
Got more to do, as well as decoding returned data ... Thinking about that
now, and will have a data-drived approach.
I need some way to specify that an internal routine be called for some types
of data where we know what type it is, in the case of Server Types for
example ...
svn path=/trunk/; revision=1294
way, it checks that the type of the variable matches the type it's
claimed to have in the MIB (and indicates if it isn't), it can decode
enumerated types, and it may also use the DISPLAY-HINT string in the
MIB.
Handle unknown types better.
svn path=/trunk/; revision=1293
the "this is the first frame" flag, and the time stamp of the first
frame, used when writing Sniffer files, so that more than one could be
open at a time (Wiretap doesn't forbid that) and so that they're
initialized when you start writing a capture.
svn path=/trunk/; revision=1292
files (the former have a different per-packet header, and a different
magic number, from the standard "libpcap"; the latter have the same
per-packet header as "modified" "libpcap" files, but the same magic
number as standard "libpcap" files, sigh).
Support writing "libpcap" captures in all three formats (so that, for
example, people running Ethereal on RH 6.1 can write out captures that
the "tcpdump" that comes with RH 6.1 can read, although that's not the
default format we save in - there's no way to tell whether you're
running on RH 6.1, as far as I know; "uname()" just tells you, on Linux
systems, that the kernel is Linux 2.x, and what "x" is, it doesn't say
what the *rest* of the system is).
Fix the table in "file.c" to use Olivier's code for writing Sniffer
files.
svn path=/trunk/; revision=1288
Guy Harris