radio header 802.11

Can i capture radio header 802.11 with promicuouos mode or only monitor
mode?
I would like to get signal strength, noise strength, etc.
Could i capture this information with libpcap and promiscuous mode?

Re: radio header 802.11

Radio level data is only available in monitor mode.

Sniffing an 80211 card in promisc mode has undefined results.  At best
it will act like sniffing a shared media network, you'll get 802.3
format ethernet frames of the data frames on the network.  At worst,
it'll be like sniffing a card not in promisc mode at all, you'll see
only your own data.

Many drivers/firmware don't appear to intelligently understand promisc
mode, so you're likely to get the worst-case most of the time.  In
either case, you can only see data from an associated network.  Rfmon is
required to see 802.11 layer headers, both management and 802.11 layer
data headers.

A quick grep through the new 80211 layer doesn't show any promisc
intelligence there, so it's likely that any cards which use it won't do
promisc properly unless they implement it locally outside of the 80211
common layer.  (this is a guess, I haven't sifted through the code
fully.)

-m

On Thu, Nov 03, 2005 at 12:16:47AM +0000, Luis Del Pino wrote:
> Can i capture radio header 802.11 with promicuouos mode or only monitor
> mode?
> I would like to get signal strength, noise strength, etc.
> Could i capture this information with libpcap and promiscuous mode?
> -
> This is the tcpdump-workers list.
> Visit https://lists.sandelman.ca/ to unsubscribe.

Re: radio header 802.11

On Nov 2, 2005, at 4:16 PM, Luis Del Pino wrote:

> Can i capture radio header 802.11 with promicuouos mode or only  
> monitor
> mode?
> I would like to get signal strength, noise strength, etc.
> Could i capture this information with libpcap and promiscuous mode?

Not unless the driver supports that.  If, as I infer from when you  
asked this on the Ethereal list, you're doing this on Linux, I don't  
*think* any of the drivers support that - I think they supply only  
Ethernet headers except in monitor mode - but if you mention what  
wireless adapter and driver you're using, somebody might know whether  
that'd work.

Re: radio header 802.11

Mike Kershaw wrote:
> Radio level data is only available in monitor mode.

On Linux, at least.  From a quick look at the wi driver and 802.11 
framework in NetBSD, you should be able to get radio data and 802.11 
headers in non-promiscuous, promiscuous, and monitor mode; the 802.11 
headers should be available for any device whose driver that uses the 
802.11 framework, and at least some other drivers should also support 
radio data.  The other free-software BSDs probably work similarly.

See

	http://wiki.ethereal.com/CaptureSetup/WLAN

for what I was able to infer from looking at the free-software BSDs.

> Sniffing an 80211 card in promisc mode has undefined results.  At best
> it will act like sniffing a shared media network, you'll get 802.3
> format ethernet frames of the data frames on the network.  At worst,
> it'll be like sniffing a card not in promisc mode at all, you'll see
> only your own data.

Except on Windows, where, at worst, you might see only your own 
*received* data, and not even see the data you're sending.

> Many drivers/firmware don't appear to intelligently understand promisc
> mode, so you're likely to get the worst-case most of the time.

What are the drivers and cards that have problems with promiscuous mode?

Re: radio header 802.11

On Thu, Nov 03, 2005 at 12:30:51AM -0800, Guy Harris wrote:
> Mike Kershaw wrote:
> >Radio level data is only available in monitor mode.
> 
> On Linux, at least.  From a quick look at the wi driver and 802.11 
> framework in NetBSD, you should be able to get radio data and 802.11 
> headers in non-promiscuous, promiscuous, and monitor mode; the 802.11 
> headers should be available for any device whose driver that uses the 
> 802.11 framework, and at least some other drivers should also support 
> radio data.  The other free-software BSDs probably work similarly.

In NetBSD, I know for certain that ath, atw, rtw, and wi provide radio
headers in all modes.  I believe atu, ipw, iwi, and ral do, too.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Re: radio header 802.11

> >Many drivers/firmware don't appear to intelligently understand promisc
> >mode, so you're likely to get the worst-case most of the time.
> 
> What are the drivers and cards that have problems with promiscuous mode?

If I recall, centrino definitely, I'll have to go through my logs and
see what others people have complained about and test them directly.

> >A quick grep through the new 80211 layer
> 
> Is that for Linux or BSD?  If it's for Linux, where's the new layer?

Linux.  Partially in kernel, partially in netdev chain, and 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 <dragorn <at> kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

<>!*''#                 Waka waka bang splat tick tick hash
^ <at> `$$-                  Caret at back-tick dollar dollar dash,
!*'$_                   Bang splat tick dollar under-score,
%*<>#4                  Percent splat waka waka number four,

[PATCH] DCCP - print all ACKs

Hi there folks,

Andrea Bittau picked up we weren't displaying ACKs for close packets
and provided a preliminary patch.

I've gone through the spec and reworked the patch slightly and it now
prints for all relevant packets.

This patch is against latest weekly CVS of tcpdump - 2005.10.03

Can this please be added to tcpdump?

Regards,

Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand

Hi there folks,

Andrea Bittau picked up we weren't displaying ACKs for close packets
and provided a preliminary patch.

I've gone through the spec and reworked the patch slightly and it now

Re: [PATCH] DCCP - print all ACKs

On 04/11/05, Hannes Gredler <hannes <at> juniper.net> wrote:
> checked into HEAD;
>
> who is going to receive credit/blame for this patch ?
>
> andrea, ian or both ?
>
Both

--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand

Re: [PATCH] DCCP - print all ACKs

checked into HEAD;

who is going to receive credit/blame for this patch ?

andrea, ian or both ?

tx, /hannes

Ian McDonald wrote:
> Hi there folks,
> 
> Andrea Bittau picked up we weren't displaying ACKs for close packets
> and provided a preliminary patch.
> 
> I've gone through the spec and reworked the patch slightly and it now
> prints for all relevant packets.
> 
> This patch is against latest weekly CVS of tcpdump - 2005.10.03
> 
> Can this please be added to tcpdump?
> 
> Regards,
> 
> Ian
> --
> Ian McDonald
> http://wand.net.nz/~iam4
> WAND Network Research Group
> University of Waikato
> New Zealand

Re: [PATCH] DCCP - print all ACKs

Ian is already on the blamelist (aka CREDITS) - so i just have added Andrea;

tx again for your submission;

/hannes

Ian McDonald wrote:
> On 04/11/05, Hannes Gredler <hannes <at> juniper.net> wrote:
> 
>>checked into HEAD;
>>
>>who is going to receive credit/blame for this patch ?
>>
>>andrea, ian or both ?
>>
> 
> Both
> 
> --
> Ian McDonald
> http://wand.net.nz/~iam4
> WAND Network Research Group
> University of Waikato
> New Zealand