Christian Stalp wrote:
And one question more, how can I use monitore-mode for normal traffic?
I.e., you want to run in monitor mode while still using the adapter for
normal traffic?
Whether you can do that depends on the adapter and the driver; as I
understand it, some adapters can support
Christian Stålp wrote:
Argh, thats are very very sad news. That dumps all my ideas. My project
was to track the retry field and in case of a dramitical increase switch
over to the monitor mode, and see what wrong. Maybe you see some
pattern, some events? My idea was to obserse which station in
sagun shakya wrote:
I agree, I'll add this to the configure script of tcpdump. This would
also be applicable for wireshark then?
Yes, and probably Snort and other apps using libpcap.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
Note that this means that your filter expression "wlan[0:2] & 0xF1 !=
0" will be checking the first two octets of the destination MAC
address, as that's what the first two octets of the link-layer header
are. (Yes, you said "wlan", but "wlan" is just another name for
"lin
Guy Harris wrote:
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Why did you add a
AC_CHECK_HEADERS(sys/bufmod.h)
check to configure.in after the check for libdlpi? It's checked for
later in the case
Guy Harris wrote:
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+
hi,
is it just me or are all the 2008 snapshots (tcpdump, tcpslice
and libpcap) broken?
$ tar zxvf tcpdump-2008.02.16.tar.gz
gzip: stdin: unrecognized file format
tar: End of archive volume 1 reached
tar: Sorry, unable to dete
