Here is a patch that:
- Replaces the arrow labels by the beginning of the COLINFO column if available (usually containing message names/types).
- Change the comment area to be "protocol: colinfo_content"
From Anders
Added ID tag
Camel
Use col_set_str to remove TCAP info in col_info
svn path=/trunk/; revision=16975
tethereal internally converted the stdout capture filename "-" into "" which doesn't make any real sense and only complicated things.
To make things even more confusing, wiretap expected "" for dump output and "-" for offline reading ...
svn path=/trunk/; revision=16962
non-human-readable and non-machine-readable garbage from that
combination.
Use an exit code of 1 for command-line argument syntax errors in some
more cases.
svn path=/trunk/; revision=16961
I fixed fBACnetPropertyValue in the BACnet packet-bacapp.c dissector
where an optional decoding for Priority wasn't being optional. A valid
packet with a confirmedEventNotification that did not have the optional
priority made this bug evident by indicating Malformed Packet.
Me:
Fixed some signedness warnings, #if 0'ed out unused functions.
svn path=/trunk/; revision=16957
I've captured a Direct Cable Connection on a WinXP machine (see
http://wiki.ethereal.com/SampleCaptures?action=AttachFile&do=get&target=PPP-config.cap).
The thing is that the capture lib(?) creates fake Ethernet headers for
the PPP LCP and NCP packets. These contain " SEND#" or " RECV#" as both
source and destination address, where "#" seems to be a session number
based on modem control signals(?).
Anyway, to make more sense of the direction these PPP frames are going
I've added them to the address resolution file, as per attached patch.
svn path=/trunk/; revision=16949
>From the Debian bug database this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342588
The rates information element with zero tag length leads to uninitialised
memory access, presenting bogus data for the element. The attached patch
takes care of that.
Me:
One space in the map listing is enough.
svn path=/trunk/; revision=16947
pipe"; there's not much point in writing to the standard output if
you're *not* writing to a pipe, but....
"-b" doesn't necessarily imply a ring buffer - you can just request that
Tethereal keep switching files forever.
Standardize on an exit status of 1 for all those errors (there's a
sort-of convention, adhered to by many apps, that an exit status of 1
means a command-line argument error (as in "illegal flag" or "you
combined two flags that don't make sense together") and an exit status
of 2 is for other "run-time" errors.
svn path=/trunk/; revision=16942
Browsing through the wishlist I came across this old one by Steve Brown:
------8<------
The GTK1 UI wordwraps assembled TCP streams, the GTK2 UI doesn't, but
should also. Not wrapping makes reading any protocol that lacks linebreaks
virtually impossible (XML, etc.) as it all ends up on one line. I'm tired
of having to install the GTK1 UI :P
------8<------
It seems like a simple request. The oneliner patch implements this wish.
Maybe someone feels the need to make it a preference or selectable.
svn path=/trunk/; revision=16939
Ethereal does not take into account the protocol field of the IP header
when reassembling fragmented packets as specified in RFC791. This can
lead to incorrect reassembly of packets with an identical src address,
dst address, and identification number, but with differing protocols.
The attached patch includes the protocol in the generation of the id
used to index into the reassembly table.
svn path=/trunk/; revision=16937
I keep finding finding traces that show new problems with this code. This patch fixes 2 problems:
- I've seen RTCP frames containing a SR and RR with identical source info and the lsr matching the current MSW/LSW timestamp of the SR. Don't want to do calculation without real roundtrip info
- calculating the gap between the 2 frames was still wrong (sigh)
svn path=/trunk/; revision=16934
Over the last year or so there have been several developments in the 3GPP2 specifications. One of the areas that saw significant changes was A11 interface between PDSN and PCF. With the introduction of QoS support on this interface, the specification includes a lot of new information elements in this protocol
svn path=/trunk/; revision=16933
Gerald Combs