[plug] Wireless-N router for faster wireless....
daniel at rimspace.net
Tue Jan 20 15:10:34 WST 2009
> You use google just the same as I can ... or can you?
Sure. I did, in fact, before I wrote to you the first time, because
I wanted to make sure that, for example, there was no "wire" level
overhead to using WEP, and that TKIP was WEP encryption at heart.
As far as I can tell there is no particular problem with WEP causing
bandwidth loss in 802.11 protocols:
It doesn't have significant additional overhead in the media or MAC
layer, or any of the other "wire" levels.
WPA is a marketing name for using the TKIP protocol to change WEP keys
automatically; it doesn't include AES CCMP encryption.
WEP was introduced back in 1997.
I did find some record of problems with AES CCMP, part of WPA2, causing
performance issues with some wireless cards in the last few years, but
nothing about WEP, WPA or TKIP causing similar problems.
These were generally documented for older cards being falling back to
slow software implementations rather than the conventional hardware
based WEP support.
So, you have made some assertions about encryption causing bandwidth
problems, without giving any significant details.
I couldn't, for example, use what you have said so for to determine if
disabling encryption on a wireless like would help me: I can't judge if
it is all encryption, just WEP, WEP and TKIP, or just AES that you
believe has this effect.
I also grant you the assertion that WEP was released as a "known weak"
encryption protocol, despite your lack of supporting evidence, based on
the abilities of embedded chips in 1997.
You have not provided any support for the assertion that, today, WEP is
still an issue of power (or gate) consumption.
So, yes, I can use Google, but unlike you I can't find support for the
believe that using WPA encryption on an 80.11 network will cause
bandwidth to degrade.
Would you like to try and provide some actual *evidence* to support your
page 35, WEP adds 8 bytes of overhead to the frame; most wireless
networks carry up to 2348 byte frames, making this overhead
effectively zero when communicating with devices connected via 1500
 See the IEEE standards document, and also the definition in:
More information about the plug