On Tue, Jun 28, 2011 at 3:52 PM, Michael Richardson <mcr@sandelman.ca> wrote:
> I'm not aware of a new file.
The email i responded to had 4 attachments sent by Evangelos.
Those were supposed to replace the files with those exact names.
> Please send github tree, ideally.
You mentioned github to me last time and offered to get me to
learn it in 5 minutes;-> I havent had time and the old school stuff i do
still works.
How about i send you patch #1 to delete the old files (as attached)
and another to re-add with new ones.
Alternatively: I could send one that overrides the existing ones.
cheers,
jamal
> --
> ] He who is tired of Weird Al is tired of life! | firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
> ] mcr@sandelman.ottawa.on.cahttp://www.sandelman.ottawa.on.ca/ |device driver[
> Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> then sign the petition.
>
commit d93443f24bfb5fd982ff33deb66979bae811db57
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue Jun 28 16:15:49 2011 -0400
[PATCH] Remove test files using old ForCES ports
Signed-off-by: Jamal Hadi Salim <hadi@mojatatu.com>
I was rudely surprised to find that "tcpdump -h" wasn't printing a usage
message, and I'm the person who *added* the "-h" option. Make it "-H",
and add an explicit "-h" option to print a usage message, so nobody else
makes the same mistake. Also, don't clear opterr, so that if you give
an illegal command-line option, you get an explanatory error message.
Instead of printing the result of icmp6_cksum() if it's non-zero, print
the checksum field value and the value it should have had. That means
that what we print is the same regardless of whether we're running on a
big-endian or little-endian machine.
Instead of printing the result of udp_cksum() if it's non-zero, print
the checksum field value and the value it should have had. That means
that what we print is the same regardless of whether we're running on a
big-endian or little-endian machine.
Also, just as we did with TCP:
Check -v and -K, and the fragmented flag, up front; then check the IP
version etc.. Don't check for IPv6 if we already know it's IPv4. Fetch
the checksum field only once.
Update some test files for the new output format.
Check -v and -K, and the fragmented flag, up front; then check the IP
version etc.. Don't check for IPv6 if we already know it's IPv4. Fetch
the checksum field only once.
The Wireshark routine is based on the BSD in-kernel portable checksum
routine (thus BSD-licensed); it takes a vector of pointers and lengths
and checksums the concatenation of the buffers in question (just as the
BSD in-kernel routine checksums a chain of mbufs).
This simplifies the "with a pseudo-header" checksums; hopefully it'll
fix up the problems being seen on some big-endian platforms, which might
be due to hand-calculating some or all of the checksum and doing so
incorrectly. It also gets rid of some code that might be dereferencing
unaligned pointers.
Get rid of some no-longer-necessary uudecodes (Git can store binary
files such as pcap files, so we no longer need to uuencode them, and the
uuencoded files are no longer around), and handle the "-X" and "-XX"
flag tests (where we had to rename the "should be" output files to avoid
collisions on case-insensitive file systems such as the default local
file system on the desktop UN*X with the biggest market share).
The "overlay" definition in print-sflow.c is correct, but the actual
extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
which leads to an incorrect report for speed.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
Use it in netdissect.h, where it's defined; otherwise, we get a bunch of
warnings when compiling modules that include interface.h but don't yet
include netdissect.h.
To: tcpdump-workers@lists.tcpdump.org
Date: Sat, 09 Apr 2011 12:51:14 +1000
Subject: [tcpdump-workers] Printing PPI packets
Printing PPI packets with tcpdump does not turn out
to be that hard.
My simple tests have produced the output as below.
It would be worthwhile having some changes made into
the tcpdump code base that were similar to the attached
that print them out.
From Kaladhar Musunuru <kaladharm@sourceforge.net>:
Added support for DCB Exchange protocol (DCBX) version 1.01.
http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf
DCBX protocol exchanges control state machine and generic feature state
machine parameters as Organizationally specific TLVs. The OUI used for
the DCBX TLV 1.01 is 0x001B21. Following TLVs are decoded:
- Control state
- Priority Groups (PG)
- Priority-based Flow Control (PFC)
- Application Protocol (APP)
From me:
Add a bunch of additional error checking, and sort the main switch
statement by TLV code (and thus by the order in the specification).
Also update/add indications of what standards document what items.
Use the same heuristic Wireshark uses, i.e. assume that FreeBSD only
reports MCS indices between 0 and 15, and that any other values with the
0x80 bit set are rate values. (Yes, those do exist.)
Also note, as I did in Wireshark, that it might be possible to extract
from the XChannel and Flags field the additional information to convert
an MCS index from the Rate field into a rate. (Whether that's possible
depends on what platforms using the FreeBSD convention do with the
channel width and guard interval information.)
Based on patches from an anonymous donor, support the radiotap RX flags and
MCS fields, and the vendor namespace, and, if Channel and XChannel are
both present, use XChannel, not Channel.
Do not try to look up a rate for an MCS value from the Rate field; you
cannot map an MCS value to a rate without also knowing the channel width
and guard interval length.
Thanks to some traces sent my way by Gavin McCullagh, and a comparison
against the output of inMon's sflowtool, I can confidently say "Yes
Virginia, there is an enterprise other than zero." Which means lest we
start trying to decode something as what it is not, we best actually
look at the enterprise field and make sure it is one we recognize.
around and created a bunch of smaller routines to more easily support
printing of both expanded and non-expanded counter and flow samples.
I've done simple testing of non-expanded counter and flow, and expanded
counter, but I don't have expanded flow at present with which to test.
So, that part of the change is only compile/eyeball tested.
Reviewed-and-tweaked-by: Guy Harris <guy@alum.mit.edu>
Fetch the element length early in the process, rather than fetching it
each time we need it - even after we've advanced the pointer we are
using to fetch it (doing the latter means we fetch the wrong value when
we subtract it from the remaining length).
If we were able to get the flags, we should process them, so we know
whether there's Atheros padding after the 802.11 header or if there's an
FCS at the end of the packet, and properly process them; if we weren't
able to get the flags, they're 0, so we're not doing anything
differently, and that's the best we can do.
When dissecting a sample, or a flow or counter within the sample, make
sure we don't run past the length in the sample/flow/counter header.
This also means we count the sample length down as we process the
contents of the sample, so we only add what, if anything, remains of the
sample to the pointer into the packet, and subtract that from the
remaining data length in the packet, which means we properly handle
packets with multiple samples.
Now that we're setting V_INCLS correctly, we don't need to include
"tcpdump-stdinc.h" - including <tcpdump-stdinc.h> works.
This also picks up configure changes from the previous configure.in
change.
pcap/bluetooth.h and pcap/usb.h require those types, so we check for
those types before checking those headers, and we include
"tcpdump-stdinc.h" in the tests, so the appropriate headers to define
those types get pulled in.
That way, uudecode will write the decoded output there, rather than to a
file named "empty" that gets left around. That also means we don't need
to redirect the output of uudecode to /dev/null, so don't do that.
Doing it at make time means you don't have to re-run the configure
script if you add uudecode to your system, and doing it by uudecoding a
uuencoded empty file means we don't depend on uudecode supporting
"--help".
Instead, check for uudecode in the configure script, and set the
CHECK_UUDECODE configuration variable to "true" if we find it and to a
command that prints an error message and exits with 1 if we don't find
it, and substitute that variable into the Makefile as the first command
for "make check".
The old ports for SCTP TML ports were replaced at RFC editor
publication time. Caught by folks preparing for an Interop
tommorow.
While we could add a backward compat support it seems meaningless
if those ports will never ever be used in production.
I will send new test/pcaps at a later point and remove the existing
ones once this patch goes in.
cheers,
jamal
commit 40ecad0e866e7567716e6e57158c5274c0786a21
Author: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Thu Feb 3 22:00:23 2011 -0500
Conform to new IANA assignment of ForCES SCTP TML
Signed-off-by: Jamal Hadi Salim <hadi@mojatatu.com>
