This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Identifying 802.11 Over-Crowded Bandwidth with Wireshark and Aircap.

2

Hi all and thanks for reading my post.

I have been using Wireshark and AirPcap (USB adapter) on and off, over the last 1-2 weeks, so excuse any ‘apparent’ questions I might ask.

I will start by saying that my knowledge of the IEEE 802.11 standard is ‘starter-intermediate’, but I do have access to it and I am more than willing to understand it fully. I am ‘fresh’ out of university (Electrical & Electronic Engineering) with some basic knowledge (/modules) on my back, on Electromagnetics, Communication systems, HF and RF engineering and Communication protocols (tcp/ip, udp).

Over the last week or so, I have been reading the book ‘802.11 Wireless Networks: The Definitive Guide’ by Matthew S. Gast. At the same time I have been ‘following up’, what I have been reading using Wireshark and AirPcap to identify (/verify) how the 802.11 protocol works in ‘real-time’ (i.e. I have been looking at the 802.11 control, management and data frames, etc…).

I have designed a PCB with a microcontroller connected to a Lantronix Matchport 802.11 b/g transceiver. I am trying to wirelessly transmit 640kbps from the 802.11 transceiver module to an access point (and ultimately a PC). Also the combined onbarod memory of the microcontroller and 802.11 transceiver, used to buffer data waiting to be transmistted is at 14kB (or 112kb).

http://www.lantronix.com/device-networking/embedded-device-servers/matchport.html

What I am seeing is that the wireless transmission does not really go as I would have hoped. It has become apparent to me that it is IMPOSSIBLE to guarantee that this operation goes smoothly over at least a 10 minute period (i.e Continuous transmission of 640kbps over 10 min), unless some large onboard memory is available.

It seems the myth of non-overlapping channels had me completely ‘blinded’. The moment another 802.11 device starts operating, the likely hood of a buffer over run is increased many orders of magnitude.

What I am here to ask is this: Is it possible to guarantee a long term (more that 5 min) 802.11 transmission operation of 1Mbps and if yes, what buffers sizes should be used? Is there some ‘rule of thumb’ here with regards to transmission speed and onboard memory?

For a given wireless environment, how can I use Wireshark and the AirPcap adapter to measure (/predict) what kind of onboard memory I require for a given transmission speed, assuming that the wireless environment remains constant?

With regards to the above question, I (think I) have been plotting the data length of the retransmitted packets using wireshark filter (wlan.sa== xx:xx:xx:xx:xx:xx && wlan.fc.retry == 1 && data.len). This filter, I think is a ‘satisfactory’ (/initial) indicator of the degradation of the wireless transmission, due to adjacent channel interference. I should point out here, that I am also using a spectrum analyzer (Wispy 2.4x – Chanalyzer) to visualize the 2.4GHz spectrum and that I am causing (/initiating) at will, the adjacent channel interference. But is there a better wireshark filter that will indicate beyond doubt transmission degradation and maybe give me some sort of clue as to what maximum transmission speed I can sustain with a given onboard memory size?

One quite general question would be what kind of onbarod memories do 802.11 chips have in commercial products (802.11 adapters, laptop, etc…)? I am unaware of the 802.11 chips driver operation. Are they able to ‘steal’ RAM (from the PC) when required?

My last question would be relatively simple. Can a technology designed (/amended) to transmit at 27Mbps sustain a 1Mbps transmission over a period of time?

The obvious is answer will likely be, it depends on the wireless environment. My next question of course, will be give me some ‘metrics’ or specs as to ‘what’, ‘when’, ‘how’.

I am aware of the overcrowded principle of all wireless technologies. How do I measure this and quantify how throughtput degrades with increase usage?

I realize some of my questions are broad, but I will appreciate any comment big or small. I am also in the process of going through the IEEE literature on 802.11 (adjacent channel interference, etc…), but this will take time.

Thanks and regards

Alex

asked 25 Feb '11, 11:57

almost_linear's gravatar image

almost_linear
31459
accept rate: 0%

edited 27 Feb '11, 10:42

1

To be sure to get your question correct: You wanna have 640 kbits / second but the problem is that your memory (with 112.000 bits) is not enough to buffer frames to be send over the wireless network ? For the buffer to fill, that would mean that the device cannot send data for a few seconds at all, am I right with that or did I get something wrong ?

Did you have Retry Bits set when there is only the transciever module and no other wlan client active?

What does "the other" device do, when becoming active and bringing your transciever connection down (buffer overrun) -> what were you transmitting etc.

(28 Feb '11, 08:03) Landi

2 Answers:

0

Hi Landy and thanks for your reply.

For the buffer to fill, that would mean that the device cannot send data for a few seconds at all, am I right with that or did I get something wrong?

Yes you are right, but the magnitude is not seconds, but milli-seconds. Specifically 175ms. I have enough memory to buffer for 175ms worth of data.

Did you have Retry Bits set when there is only the transceiver module and no other wlan client active?

The university environment, in which I work, might or might not have a client working at any single time. Even when testing late at night (10pm) I still get a few retransmitted packets (retry bit set). During these late night tests, Airpcap-Wireshark did not show any data frames being transmitted (from other MACs) and the 2.4Ghz spectrum (monitored using Wispy-Chanalyzer) was ‘quite’, apart from the channel I was transmitting on. I should point out, a number of university access points in the vicinity of my ‘testing area’ will ALWAYS transmit beacon frames.

What does "the other" device do, when becoming active and bringing your transceiver connection down (buffer overrun) -> what were you transmitting etc.

I use my laptop connected to the university network (which is on a non overlapping channel) and download a large file. This will generally create a buffer overrun. My laptop is situated about 5 meters away from the matchport WLAN transceiver.

Hope my answers might help you, provide me with some insight into my ‘problems’.

Thanks and regards

Alex

answered 28 Feb '11, 08:33

almost_linear's gravatar image

almost_linear
31459
accept rate: 0%

edited 01 Mar '11, 08:09

0

Hi all,

I am trying to narrow down some of my questions, so I can possibly get some help from the members of this forum.

An extract from ‘802.11 Wireless Networks: The Definitive Guide’ by Matthew S. Gast., on page196 says: “… Stations are responsible for maintaining sufficient memory to buffer frames, but the buffer size must be traded off against the use of that memory for other purposes. The standard allows a station in an independent network to discard frames that have been buffered for an "excessive" amount of time, but the algorithm used to make that determination is beyond the scope of the standard. The only requirement placed on any buffer management function is that it retain frames for at least one beacon period.

(also confirmed from page 136 of the ANSI/IEEE Std 802.11, 1999 Edition (R2003))

The beacon interval in my Netgear access point is set, to the default value, of 102.4msec (As far as I can tell this value is standard across many access points).

Given the 802.11 Matchport transceiver I am using has a maximum data transmission speed of 921,6kbps, I would except the onboard memory to be at least 92,160b (or 11,520kB). Lantronix, the manufacturer of the 802.11 transceiver only provides (6kB).

Is Lantronix providing too little onbarod memory, or is the trail of my thought wrong?

Thanks

Alex

answered 02 Mar '11, 13:09

almost_linear's gravatar image

almost_linear
31459
accept rate: 0%

edited 02 Mar '11, 13:52

1

I'm not the hardware guy - but as far as my thoughts were going when reading your post, I think it should be standard for a NIC to obtain some (maybe even kernel) memory to use as a buffer... But absolutely not sure 'bout that...

(03 Mar '11, 02:13) Landi