-
It's still a pain, but that's nothing we can fix. At least I got a damn e-mail when I added this; hopefully it didn't just do so because I'm the one who submitted it....
("Rejected" indeed. Why does SourceForge make angry ticks fire out of my nipples? :-))
2009-12-31 02:25:06 UTC by guy_harris
-
*NOTHING* about it is convenient.
(This is a test, to see whether I've finally managed to figure out how to get it to send me e-mail, directly, when a new tracker item is added. Wish me luck....)
2009-12-31 02:22:46 UTC by guy_harris
-
I sometimes run tcpdump in scripts from a crontab. The way tcpdump 4.0 works today it by default will send some information to stderr. I'd like to be able to suppress this with a command line switch, but there doesn't appear to be this option. I created a sample patch that will permit this behavior by using two 'q' options. So for example, if you run 'tcpdump -nnqc1', you'd get something...
2009-12-11 03:37:53 UTC by johnkristoff
-
The top-of-Git-tree Makefile.in does create bindir.
2009-11-22 06:54:12 UTC by guy_harris
-
Makefile.in has tests for includedir and libdir directories, but not bindir.
2009-11-16 23:11:18 UTC by anthony11
-
This patch changes the program so that when its given a compressed file it can still read it. It just figures out which program it needs to unzip the file, runs that, and reads the input from there. Its like doing `zcat in.pcap | tcpdump -r -`, except now all you have to do is `tcpdump -r in.pcap. Its a nice feature when you are working with a lot of zipped pcap files.
2009-11-14 20:23:02 UTC by jonathansteel
-
Thanks for looking into this, Guy. This was on an OLPC XO-1, with its delightfully quirky setup. It's a Marvell 88W8388 and a linux kernel; which version, I'm not sure, but I can find out.
That said, I'm pretty sure I had the same problem with a capture done on a Toshiba tablet with a Prism card of some kind. I can verify (or unverify) that, if it would be helpful.
2009-11-05 00:16:16 UTC by horsepunchkid
-
I've checked in a change to save the first, rather than the last, IE of a given type (except for zero-length rates IEs, which are ignored - some devices seem to put a zero-length rates IE into frames, followed by the right rates IE). That should address this problem (the frames are still bad, so they're reported as such, with [|802.11]).
2009-11-04 22:59:50 UTC by guy_harris
-
At the end of frame 8's data, there are 5 bytes: 00 0c 12 18 60. That frame has a radiotap header, but the flags field does *NOT* have the "FCS present at end" bit set, so neither tcpdump nor Wireshark believe the frame has the FCS in the last 4 bytes. Furthermore, the frame is claimed to have been 474 bytes long on the network, with only the first 94 bytes of the frame captured.
The 00...
2009-11-04 00:37:32 UTC by guy_harris
-
Nope, *NOT* the same root cause.
The root cause of 2543416 was that the printer wasn't stopping before the FCS, and was parsing the FCS as if it were part of the payload.
The root cause of this is that the packets are cut short by a snapshot length, and the printer isn't stopping at the snapshot length.
2009-11-04 00:28:33 UTC by guy_harris
