Ethereal-dev: [ethereal-dev] ChangeLog? cvs2cl.pl works really nice...
If you've never used cvs2cl.pl, it uses the log information to
dynamically build a changelog from a CVS based project. For example,
below is the top few lines of the ChangeLog produced by the command:
./cvs2cl.pl --tags --branches --revisions --day-of-week
Might be nice to consider doing this as part of the commitinfo stuff for
ethereal, so that an actual changelog is maintained in the sources.
---cut---
1999-11-26 Friday 22:01 guy
* packet.c (1.57), packet-arp.c (1.23): ARP requests with a
hardware type of ARPHRD_ATM2225 are ATM ARP requests, as
described
in RFC 2225; they do *not* have the same format as regular ARP
requests, so dissect them differently.
Inverse ARP is also used on ATM, so add the Inverse ARP request
and
reply message types. (It's also used with other protocols, e.g.
Frame Relay.)
Handle zero-length addresses (meaning the address is absent).
They can have up to 6 different address fields, so make
"bytes_to_str()" have six static buffers in which it can return
strings.
1999-11-26 Friday 20:17 sharpe
* packet-smb.c (1.48): Fixed the problem of crashing when a
NetServerEnum2 with Level 0 is seen.
1999-11-26 Friday 20:14 guy
* packet-q2931.c (1.4): Minor bug fix.
1999-11-26 Friday 19:55 guy
* packet-atm.c (1.8), wiretap/snoop.c (1.16), wiretap/iptrace.c
(1.22): Move the "guess what type of ATM traffic this is" stuff
into the ATM dissector; I don't think it's guaranteed that even
a
Sniffer will tell you that (there may be situations where it
can't
figure it out, and where the user didn't tell it), we may need
it
for "atmsnoop" traffic and other types of ATM traffic as well,
we
will probably want to add to it the ability to let the user
specify
"virtual circuit X.Y is this kind of traffic", and we may also
have
Ethereal try to intuit it based on previous traffic in the
capture
(Q.2931 call setup, LANE traffic, etc.).
Use the field in "iptrace" headers that appears to be, in ATM
captures, a direction indicator - we may have the direction
backwards, but, as an STP packet was tagged as a DCE->DTE
packet,
and as the capturing machine, which also was presumably the
recipient of the packet, was an AIX box, not a switch or bridge
or
some piece of networking equipment such as that, it *probably*
wasn't sending the STP packet, it was probably receiving it.
1999-11-26 Friday 16:50 guy
* wiretap/netmon.c (1.17): It appears that the first frame in a
NetMon 2.0 capture file doesn't necessarily start at an offset
of
128 into the file; we have to read the first entry in the frame
....
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
