Some drivers definitely change the format of the radiotap packets on the fly in
the same stream. As Guy says, you need to look at the bit field in the header
and parse the complex header. If all you care about is the dot11 header you can
just skip the header using the length field.
Also beware
The ieee 802.11 headers can vary in length depending on the packets types, qos,
etc.
The ieee standard is available for free, that should be your best reference.
--
Sent from mobile, brevity, accuracy and security disclaimers.
abhinav narain wrote:
hi,
I have seen tcpdump,wireshark both ju
abhinav narain wrote:
I wanted to know how much percentage of the original wireless traffic do I
lose when I am sniffing on monitor interfaces ?
pcap statistics show me no packet loss, but I wanted to know, if the
virtual interfaces( phy{0,1}) itself gave me all the traffic or not.
Ideal case wo
ireshark and graph by conversation.
Also check the site for Sharkfest and look at some of the presentations
from this year - I forget who gave it, but there was at least one about
identifying network problems via tcp analysis inside wireshark.
http://www.cacetech.com/sharkfest.09/
-m
--
Mike Ke
t doesn't take 100% cpu with mmap
disabled, obviously gutting mmap functionality isn't the end goal). Testing
with tcpdump for sake of simplicity:
drag...@drd1813 ~/src/libpcap $ tcpdump -V
tcpdump version 4.1-PRE-CVS_2009_06_22
libpcap version 1.1-PRE-CVS
Kernel 2.6.30, I can check con
nd to
rewriting my packet chain to handle it while preserving my other timing,
but it's not the real issue.
-m
--
Mike Kershaw/Dragorn
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"Yes, yes, LORD OF HUMANS! I will rule you ALL with an iron fist! YOU!
OBEY THE F
utral
padding-neutral log format to rewrite all the radio header data from the
other formats.
http://802.11ninja.net/lorcon/browser/trunk/lorcon_decode.c
is some basic code to strip various headers off dot11 packets.
-m
--
Mike Kershaw/Dragorn
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"You can't engineer away stupid."
pgpjU682PMnDt.pgp
Description: PGP signature
radiotap, and PPI off the top
of my head. Rtap and PPI are variable-length headers.
-m
--
Mike Kershaw/Dragorn
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Q. What does the toothfairy do with all my teeth?
A. She's building another You. Once she has all your teeth
the frames out to the OS before the
card buffer fills.
* Note - this was also in rfmon, not in normal operation mode. This
means my tests weren't waiting for ACK sequences to complete in the
firmware to rx data, etc.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 35
pass a C++ member function as a callback it must be static, or you
must have mechanisms to allow you to pass an instantiated object as
well.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"Yes, yes, L
efault capture size)?
A full RT header can be bigger than the 32 or 64 or whatever the default
# of bytes is for tcpdump to process.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Know the rules other people live by. Kno
partially
independent for the IEEE80211.sourceforge.net project which is run by
the IBM team doing the centrino drivers.
And theres a competing "complete" layer.
It's sort of a mess.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661
c.
> Could i capture this information with libpcap and promiscuous mode?
> -
> This is the tcpdump-workers list.
> Visit https://lists.sandelman.ca/ to unsubscribe.
>
>
> !DSPAM:4369640d189091249270289!
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint:
>
> Do you have any reason to believe that the official arphrd will have a
> value other than 803? If not, we might as well check it in now.
No, it's the next in line, and madwifi uses it as well for radiotap on
linux.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fin
u'd
rather wait before merging, let me know and I'll post it again once the
arphrd is officially ours.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Be different: conform.
--- pcap-linux.c2004
> While you're doing that, could you beat up on the driver teams to get
> them to adopt the same APIs for turning on monitor mode and setting the
> channel? There's a whole bunch of different commands (and presumably
> calls) with different drivers:
Oh, I know. :) I'm working on it.
> It app
> >Well, yes. :) I still have to get my patches accepted to the ieee80211
> >branch, merged into the kernel, and then all the driver patches done and
> >accepted. It's a step in the right direction tho.
>
> If you're working on the FreeBSD Aironet driver, you might want to look
> at the version
> >I've been working on bringing the radiotap headers to Linux so that
> >we'll finally have a kernel-level multi-platform consistent way to get
> >signal data on wireless cards.
>
> Well, it'd also need to be brought to the Aironet driver on the BSDs as
> well, to complete that process. (It's l
I've been working on bringing the radiotap headers to Linux so that
we'll finally have a kernel-level multi-platform consistent way to get
signal data on wireless cards.
Part of the argument which has arisen is about the 64byte static
container that the radiotap headers define to put the variabl
> > Ah, in my case, restarting the remote capture units is highly
> > undesirable/difficult/annoying to the users.
>
> Ok, but that depends on the application. I think it would be nice to
> support easy restarting of remote capture processes, especially if
> there are many of them.
IMHO thats cap
> If it was discussed on this list: my apoligies, I could not find a
> recent archive. Maybe you can send me a copy of the discussion.
It was, a while ago, I'm sorry though, I meant I'd been discussing it
with people on IRC just last night.
> I am a big fan of KISS, and my UDP based solution is a
> My proposal would be to introduce a magic string (like remote://1234),
> that makes libpcap listen on UDP port 1234. The remote capture
> application can "connect" and send the data in libpcap format. Because
> UDP is connectionless, I might add some special logic for the file
> header. As a resu
> ...although having it in libpcap does mean that applications might, in
> theory, be able to capture remotely without having to be changed.
Yeah, that would definitely be nice.
> However, if authentication is required for remote capture - which I
> suspect a lot of sites would want - that migh
> I want to add a feature where someone can connect and use a
> network-interface of a remote computer to capture data. As ronnie
> sahlberg has already pointed out in the ethereal list,
> authentication and athoriztion should be one of the topics there. For
> sure the will be several more issue
> Speaking of radio headers for 802.11 and link[M:N], I'm not sure a
> filter that tests those is necessarily useful - should the link[M:N]
> filters just test the 802.11 header and payload, and skip radio headers
> for the Prism, AVS, and radiotap headers? That way the same link[M:N]
> filter
PHY control frames are usually formatted very strangly. They don't
contain the standard 3 or 4 address set, they contain only the receiver
address.
You can't filter ACKs based on transmitting AP, it's not part of the
frame.
-m
> tcpdump do captures ACK subtype(one of the Control Frame) frames w
> On Tue, Feb 08, 2005 at 06:08:32PM +0530, shantha wrote:
> > tcpdump is displaying beacons and all the data packets but it is not
> > displaying the ACK frames which will be there for every data packet.
>
> There are not necessarily any "ACK frames" - if data is flowing both ways,
> ACKs can be
27 matches
Mail list logo
