All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Bandwidth monitoring
@ 2012-10-28 15:37 David H. Lynch Jr.
  2012-10-28 20:59 ` Christian Lamparter
  0 siblings, 1 reply; 29+ messages in thread
From: David H. Lynch Jr. @ 2012-10-28 15:37 UTC (permalink / raw)
  To: linux-wireless

>From: Christian Lamparter
>>># iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)
>> 
>> This is setting up to send on channel 1 HT40+ correct ?
>yes, I hope so.

Thanks

>> Wireshark appears to handle RadioTap - I am seeing lots of other
>flags
>> etc. but not BW40.
>It depends on the version. Here's a screenshot
>from wireshark 1.8.2: <http://imageshack.us/f/703/mcsinfo.png/>
Thanks

>> Googling Radiotap produces lots of comments that suggest that
>>Radiotap
>> headers - send and receive are not necescarily complete or accurate
>>from
>> device to device - is that a reasonable conclusion ?
>Most mac80211 driver should report rx'ed MCS information.
>At least ath9k, ath9k_htc, brcmsmac, carl9170, iwlagn, iwllegacy,
>mwl8k,
>rt2800*, rtl8192* do
Using carl9170 so that should be OK.

>What might not work is: injecting frames with MCS rates [no code
>in ieee80211_parse_tx_radiotap for that?]... So maybe the issue
>is indeed at the other end?

Assuming Carl9170/AR9170's at both ends 
But if I am am using iw to set monitor mode mode, channel, and
bandwidth, 
And using Raw sockets injection with a radiotap header that has no
frequency/channel/bandwidth information, 
I should then be able to receive that packet on another system with an
AR9170 and 1.8.2 Wireshark and the BW40 flag should be true ?

I need to do something that involves sending HT40 packets in a
completely different context. But I do not have a spectrum analyzer to
confirm that i am actually sending what I want.
So I have been using airmon, wireshark, ....
But i need to be able to send and verify an HT40 packet by some somewhat
normal means, to assure myself that my receiving end wireshark
hardware/driver/software combination can tell me what i need to know. 




--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: Bandwidth monitoring
@ 2012-10-29  0:44 David H. Lynch Jr.
  2012-10-29 11:46 ` Christian Lamparter
  0 siblings, 1 reply; 29+ messages in thread
From: David H. Lynch Jr. @ 2012-10-29  0:44 UTC (permalink / raw)
  To: linux-wireless

>From: Christian Lamparter <chunkeey@...>
>> But if I am am using iw to set monitor mode mode, channel, and
>> bandwidth, And using Raw sockets injection with a radiotap header
>> that has no frequency/channel/bandwidth information, 
>> I should then be able to receive that packet on another system
>> with an AR9170 and 1.8.2 Wireshark and the BW40 flag should be true?
>Ah now I see where the problem is.
>You see, the "40MHz bit" is part of the MCS rate meta info (aka flags).
>(See enum mac80211_rate_control_flags in include/net/mac80211.h)
RADIOTAP packet injection is not a manditory facet of my problem. 
I am only using it to inject a packet with know parameters so that I can
trace what is happening for the purposes of duplicating the behavior
either in firmware or in userspace. But before I can do so I need to see
the construction and environment changes needed to transmit an HT40
packet.

I would be happy with any other means of forcing the transmission of an
HT40 packet. RADIOTAP injection is just the only means I am aware of to
do so - and from what I am gathering not an effective one. 




>OffTopic:
>There is also a legacy duplicate flag IEEE80211_TX_RC_DUP_DATA that
>duplicates the 20MHz legacy packet in two 20MHz halves of a 40MHz
>channel. (The downside is that there's no dedicated RX_FLAG for
>that and this information is not available in the radiotap)
This might be sufficient - for the purposes of testing I do nto care
about the data in the packet. 






>The sending part is not. AFAICT you'll have to start by declaring
>and defining a new radiotap rate info element (IEEE80211_RADIOTAP_RATE
>can only handle the bit rate and that is not enough). Then you have
>to add a parser which translate the rate info in the radiotap header
>into mac80211 ieee80211_tx_rate and tell mac80211 to bypass rate_ctrl
>tx handler in this case so the info won't be overwritten again...
>And finally you'll have to add a header with this new rate info element
>into the radiotap header of all the frames you send through the raw
>monitor interface.

>A proof-of-concept should be easily doable within a day. But getting
>this
>new radiotap to be part of the spec will take longer ;)
with my level of Radiotap/mac80211/wifi knowledge this is much more than
a days work.

Any other ideas for forcing transmission of an HT40 packet ?
What If I omit radiotap and just send an ieee80211 raw packet ?

>> So I have been using airmon, wireshark, ....
>> But i need to be able to send and verify an HT40 packet by some
>>somewhat
>> normal means, to assure myself that my receiving end wireshark
>> hardware/driver/software combination can tell me what i need to
>know. 
>Well, you should be able to verify if your device picks up HT40 frames
>easily. All you need is any busy 11n network with a 11n AP and a 11n
>client. Just setup the receiver device (correct channel and HT40+/-
>setting) and start listening.
still not easy - no 80211n AP's just alot of AR9170's.
I guess I am going to be looking for a cheap 80211n AP. 



--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: Bandwidth monitoring
@ 2012-10-23 18:58 David H. Lynch Jr.
  2012-10-24  6:35 ` Christian Lamparter
  0 siblings, 1 reply; 29+ messages in thread
From: David H. Lynch Jr. @ 2012-10-23 18:58 UTC (permalink / raw)
  To: linux-wireless

>On Sunday, October 21, 2012 09:58:18 PM David H. Lynch Jr. wrote:
>> I am looking for an easy means to determine the characteristics of a
>> transmitted packet. 
>> Particularly whether it is HT20/HT40-/HT40+ I have used a variety of
>> sniffers, airodump, wireshark, ... and I can not seem to find
anything
>> that will tell me what I am after - or I do not know how to use them.
>differentiating between HT40+ and HT40- will be difficult to do with
>just one standard wifi device (should be possible with two though).

>If you use mac80211, have you setup your monitor channel by adding
>the HT20/HT40+/HT40- flag? 
># iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)


This is setting up to send on channel 1 HT40+ correct ?
I am already doing that I need to know if it is succeeding 
I am using Packettspammer to send with all the channel/frequency
radiotap headers removed.  an setting up using iw for what I want as
above.



>This might help.

>As for retrieving the information:
>If a HT20/HT40  frame was received, it should have a radiotap
>IEEE80211_RADIOTAP_MCS header element (on the monitor interface dump).
>In this element should provide the MCS and flags for 
> - BW40 (if false => HT20, if true => HT40+ or HT40- depending
>   on the channel configuration)
> - Short GI
> - Greenfield flag
> - (LDPC)

Wireshark appears to handle RadioTap - I am seeing lots of other flags
etc. but not BW40.

>But I don't know if any of this information is parsed by any of the
>current tools (depends on the version I guess). At least for wireshark
>you can always look at the raw hex dump of the package, so it should
>be there! The definitions of what RADIOTAP_MCS bit means what are in:
><include/net/ieee80211_radiotap.h>


Googling Radiotap produces lots of comments that suggest that Radiotap
headers - send and receive are not necescarily complete or accurate from
device to device - is that a reasonable conclusion ?



>Regards,
>	Chr

Thanks
--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 29+ messages in thread
* Bandwidth monitoring
@ 2012-10-21 19:58 David H. Lynch Jr.
  2012-10-22 10:43 ` Christian Lamparter
  0 siblings, 1 reply; 29+ messages in thread
From: David H. Lynch Jr. @ 2012-10-21 19:58 UTC (permalink / raw)
  To: linux-wireless

I am looking for an easy means to determine the characteristics of a
transmitted packet. 
Particularly whether it is HT20/HT40-/HT40+
I have used a variety of sniffers, airodump, wireshark, ...
and I can not seem to find anything that will tell me what I am after -
or I do not know how to use them.
I am transmitting packets in monitor mode with specified frequencies and
parameters and i am trying to verify that I have sent what I intended
without getting a spectrum analyser.  

thanks


^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: bandwidth monitoring
@ 2005-01-07  5:48 Patrich Björklund
  0 siblings, 0 replies; 29+ messages in thread
From: Patrich Björklund @ 2005-01-07  5:48 UTC (permalink / raw)
  To: netfilter

Hi, there. I dont really know if you just wanna know what ips gets
to/through your interfaces? I have a prog called tcpick. It show like
this:

root # tcpick -i eth0 -C
Starting tcpick 0.1.19
tcpick: listening on eth0
SYN-SENT       192.168.0.2:45190 > 217.215.148.17:pop3
SYN-RECEIVED   192.168.0.2:45190 > 217.215.148.17:pop3
ESTABLISHED    192.168.0.2:45190 > 217.215.148.17:pop3
FIN-WAIT-1     192.168.0.2:45190 > 217.215.148.17:pop3
FIN-WAIT-2     192.168.0.2:45190 > 217.215.148.17:pop3

>Hello
>
>Does somebody know a program for monitoring bandwidth by ip? I have
>one 
>internet interface and I must monitor many ips adresses on this
>interface. I 
>tried Ipac-ng and, I worked a lot to do this config but it seems not
>working 
>this way.
>
>thanx



------------------------------




^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: bandwidth monitoring
@ 2005-01-06 20:28 Daniel Chemko
  0 siblings, 0 replies; 29+ messages in thread
From: Daniel Chemko @ 2005-01-06 20:28 UTC (permalink / raw)
  To: J. Nerius, Michael Gale; +Cc: netfilter

J. Nerius wrote:
> How many hosts and how much traffic are you running through it? I've
> wanted to come up with a solution similar to the one you've described
> to replace my current bandwidthd setup but I'm thinking that my
> network may be too large with too much traffic to support something
> like that without building a monster box just to capture the stats.
> 

If you have a small static number of hosts in/out of your system, you
may want to use netfilter blank rule counters since the penalty of
passing each counter is very very low (entirely kernel side).

To put this in perspective, there've been a lot of performance issues
with people running 10000+ rule sites with adverse effects on their
network setup. Lower than that, and the impact is pretty low. Plus,
blank rules don't do anything but increment the counter, so the actual
CPU utilization of these rules are even lower. This is to give maxumum
accounting of an existing kernel. I'm sure there have been a few
in-kernel accounting packages made, but I can't recall any at the
moment. Maybe someone here can refresh our memory.

Of course the problem with this approach is that you have to know what
IP's that are generating traffic before setting this thing up since the
iptables rules are static. Its good if you want to monitor internal
user's traffic to the net and the amount of traffic a server is getting,
but to actually track the internet endpoints, you're better off using a
dynamic traffic tracking tools like ntop or bandwidthd.



^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: bandwidth monitoring
@ 2005-01-06 19:04 Daniel Chemko
  2005-01-06 19:39 ` Les Mikesell
  0 siblings, 1 reply; 29+ messages in thread
From: Daniel Chemko @ 2005-01-06 19:04 UTC (permalink / raw)
  To: J. Nerius, Les Mikesell; +Cc: netfilter

J. Nerius wrote:
> ntop is great for *short term* monitoring. Generally it will become
> unmanageable if run for too long. If you want to monitor and keep
> stats over a longer period of time, bandwidthd will probably work
> better for you.
> 
> J.N.
> 
> On Thu, 2005-01-06 at 11:42 -0600, Les Mikesell wrote:
>> On Thu, 2005-01-06 at 10:28, patrick.leduc@novipro.com wrote:
>> 
>>> Does somebody know a program for monitoring bandwidth by ip? I have
>>> one internet interface and I must monitor many ips adresses on this
>>> interface. I tried Ipac-ng and, I worked a lot to do this config
>>> but it seems not working this way.
>> 
>> Ntop might do what you need.  http://www.ntop.org.  It can summarize
>> and sort traffic by address/port/protocol, etc.  I don't use it
>> continuously but fire it up for a while if I think something is
>> hogging the network. 

I'll address this as well. Ntop is fantastic at giving you snapshot data
of a network, but it is inanely heavy at long term monitoring of
services. It got to the point that monitoring traffic from the firewall
filled memory and CPU usage if run long enough. It doesn't work for
continuous operations.

The one really good thing about iptables is that every rule has a
counter fo the number of hits that you run through it, so it  is
possible to create custom counters for your software. This is not a
'simple' process, but it'll give you accurate traffic flows with
filtering, etc. that a normal libcap based tool can't give you. PS:
/proc/net/dev data is incorrect when netfilter & NAT are enabled. I
believe its because NAT (return?) traffic bypass this counter, so any
management tool that uses this technique for monitoring bandwith will
also be flawed on a netfilter router.



^ permalink raw reply	[flat|nested] 29+ messages in thread
* bandwidth monitoring
@ 2005-01-06 16:28 patrick.leduc
  2005-01-06 17:09 ` J. Nerius
                   ` (5 more replies)
  0 siblings, 6 replies; 29+ messages in thread
From: patrick.leduc @ 2005-01-06 16:28 UTC (permalink / raw)
  To: netfilter

Hello

Does somebody know a program for monitoring bandwidth by ip? I have one 
internet interface and I must monitor many ips adresses on this interface. I 
tried Ipac-ng and, I worked a lot to do this config but it seems not working 
this way.

thanx


^ permalink raw reply	[flat|nested] 29+ messages in thread
[parent not found: <04a901c36e18$ad2d6650$2a0110ac@SAMHP>]

end of thread, other threads:[~2012-10-29 11:47 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-28 15:37 Bandwidth monitoring David H. Lynch Jr.
2012-10-28 20:59 ` Christian Lamparter
  -- strict thread matches above, loose matches on Subject: below --
2012-10-29  0:44 David H. Lynch Jr.
2012-10-29 11:46 ` Christian Lamparter
2012-10-23 18:58 David H. Lynch Jr.
2012-10-24  6:35 ` Christian Lamparter
2012-10-21 19:58 David H. Lynch Jr.
2012-10-22 10:43 ` Christian Lamparter
2005-01-07  5:48 bandwidth monitoring Patrich Björklund
2005-01-06 20:28 Daniel Chemko
2005-01-06 19:04 Daniel Chemko
2005-01-06 19:39 ` Les Mikesell
2005-01-06 16:28 patrick.leduc
2005-01-06 17:09 ` J. Nerius
2005-01-06 17:42 ` Les Mikesell
2005-01-06 17:56   ` J. Nerius
2005-01-06 20:09 ` Michael Gale
2005-01-06 20:19   ` J. Nerius
2005-01-06 21:28     ` Michael Gale
2005-01-06 21:54       ` J. Nerius
2005-01-06 23:30         ` Michael Gale
     [not found]   ` <41DDA135.5000205@cisco.com>
2005-01-06 21:24     ` Michael Gale
2005-01-07  1:54 ` Mark E. Donaldson
2005-01-10 13:45 ` Fabiano Reis
2005-01-26 18:33 ` Ranjeet Shetye
2005-01-26 20:00   ` Jose Maria Lopez
     [not found] <04a901c36e18$ad2d6650$2a0110ac@SAMHP>
2003-08-31  1:03 ` Bandwidth Monitoring Arnt Karlsen
2003-09-01  7:33 ` Ray Leach
2003-09-04  6:34   ` Dharmendra.T

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.