Errata

802.11 Wireless Networks: The Definitive Guide

Errata for 802.11 Wireless Networks: The Definitive Guide

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed
Page 75
"Frames to the AP" section, second paragraph

Incorrect: "Frames from the distribution system have the ToDS bit set, but the FromDS bit is 0." Should be: "Frames from the mobile station have the..."

Note from the Author or Editor:
This error is also present in the second edition, and an erratum for the second edition also exists.

Anonymous  Jan 28, 2010 
Printed
Page 104
Figure 4-50.

On figure 4-50 the bits of RSN Capabilities point to Authentication suite bytes.

Note from the Author or Editor:
Change the dotted lines to point to the RSN Capabilities field.

Anonymous  Sep 15, 2009 
Printed
Page p134
figure 7-14. and 7-15 ATIM window;(inside figure)

ATM window

NOW READS:
ATIM window

Anonymous    Nov 01, 2004
Printed
Page Index
entry for preauthentication

Preauthentication was not indexed. An entry HAS BEEN CREATED to refer to page 123.

Anonymous    Dec 01, 2003
Printed
Page throughout
Throughout book

802.1X is consistently referred to as "802.1x" throughout the book. When IEEE
specifications are standalone, the letter is capitalized, as in 802.1X. When a
specification is an addition that will eventually be rolled up into its parent, the
letter is lowercase. 802.11b modified clauses in 802.11, so its letter is lowercase.

Anonymous   
Printed
Page 8
Last paragraph

"The base 802.11 specification includes the 802.11 MAC and two physical layers: a
frequency-hopping spread-spectrum (FHSS) physical layer and a direct-sequence spread-
spectrum (DSSS) link layer."

NOW READS:
"The base 802.11 specification includes the 802.11 MAC and two physical layers: a
frequency-hopping spread-spectrum (FHSS) physical layer and a direct-sequence spread-
spectrum (DSSS) physical layer."

Anonymous    Dec 01, 2003
Printed
Page 11
Figure 2-4

On the "Infrastructure BSS" diagram in Figure 2-4, there is a dotted
line indicating a wireless connection between the two notebooks at the
bottom. While this would be accurate for a Independent BSS (ad-hoc BSS), it is
inacurate for the Infrastructure BSS, where all traffic
must pass first to the Access point (AP).

Note from the Author or Editor:
The figure was corrected in the second edition.

Anonymous   
Printed
Page 13
Last paragraph

The statement "In figure 2.5 the router uses a single MAC address to deliver frames
to a mobile station;...." is somewhat misleading, as it may be interpretted as
stating that when the router wishes to send a frame to any station in the ESS, the
router will always use the same MAC address.

More appropriate wording would be "The router in figure 2.5 addresses each station on
the local lan using that station's unique MAC address as the destination. All access
points within the ESS operate in concert to ensure only the access point that
currently owns the association with the addressed station, will send the frame to
that station over its wired to wireless bridge."

Note from the Author or Editor:
The sentence in question was altered in the second edition for clarity.

Anonymous   
Printed
Page 36
1st full paragraph

Mr. Gast says that in 802.11 MAC headers, the most signifigant bits are last.
However, when I look at source code for Kismet, Ethereal, and Orinoco driver, they
all treat the BYTE order as if it were Little Endian, but the bit order in within the
bytes is still most significant bits first. Also, looking at Ethereal's actual
parsing of a packet would also indicate that the packets are Little Endian byte
order. Please clarify this discrepancy for me. I suppose this could also be
considered a serious technical error if I am correct.

Anonymous   
Printed
Page 38
Table 3-1

The subtype name for subtype value 0111 in Table 3-1 should be CF-Ack+CF-Poll rather
than Data+CF-Ack+CF-Poll.

Note from the Author or Editor:
This error was fixed in the second edition of the book.

Anonymous   
Printed
Page 40
2nd paragraph

In figure 3-11, it shows that the ps-pool frame has bit 14 and 15 both set to 1, but
in the paragraph on page 40 describing the PS-Pool frame, it states that the bit is
set to 0.

Note from the Author or Editor:
The text was corrected in the second edition.

Anonymous   
Printed
Page 43
Under "Backoff with the DCF"

In 2nd line under this heading,
"congestion-based data"
should be
"contention-based data"

Anonymous   
Printed
Page 47
Figure 3-17

The NAV for the RTS in Figure 3-17: "RTS=3xSIFS + Data + ACK"
NOW READS: "RTS=3xSIFS + CTS + Data + ACK"

Anonymous    Nov 01, 2004
Printed
Page 62
First paragraph after heading, "Multirate Support"

The second sentence is missing some text:

"Speed nogotiation is particularly that are available to stations."

It should say:

"Speed negotiation is particularly important in wireless LANs because of
the plethora of modulations and data rates which are available to stations."

Anonymous   
Printed
Page 64
Figure 4-16

The last bar in figure 4-16, "Duration in RTS: 3xSIFS + ACK + frame time" should read
"Duration in RTS: 3xSIFS + CTS + ACK + frame time". The CTS term is missing.

Note from the Author or Editor:
This error was fixed in the second edition of the book.

Anonymous   
Printed
Page 76
Figure 4-33

The 2 Mbps data rate in the figure NOW READS "0010000".

Anonymous    Nov 01, 2004
Printed
Page 76
Figure 4-33

The Length field of the Supported Rates Information Element is labeled as 2 octets.
Like all other IEs it should only be one.
(fig 4-32)

I had several problems understanding this diagram at first.

The "7" over the Data Rate Label, really should be "0-7" as this is a variable length
field (only the data rates supported would be here).

And the zoom out is an example of two elements, inspite of the label which is
singular. You have to read the text to figure this out.

Also the Mandatory field is shown on the right, whereas the example codes it on the
left. The ordering probably doesn't matter, but the flipping causes some confusion.
Suggestion: Put the "Mandatory" rate field first, and the optionals last on the
frame. BTW: they are all rate labels.

And the positioning of the "Least <-> Most significant" label is also misleading.
The rates labels don't appear to have any order, and I'm guessing this is really
intended to talk about the label bit encoding, but it's on top of the label bytes.
It should be moved down to the expanded field view.

Note from the Author or Editor:
Other than the bit ordering, these changes were made in the second edition of the book.

Anonymous   
Printed
Page 77
Figure 4-36 was a duplicate of Figure 8-9. This HAS BEEN CORRECTED and a new Figure 4-36 inserted in the book.

Anonymous    Nov 01, 2004
Printed
Page 77
2nd sentence under "DS Parameter Set"

"High-rate, distribution ststem networks use the same channels..."
should be:
"High-rate, distribution ststem networks use the same channels..."

Anonymous   
Printed
Page 80
Figure 4-39

The Beacon frame does not show the Supported Rates information element, which is
required as per clause 7.2.3.1 of 802.11-1999.

Anonymous   
Printed
Page 81
Figure 4-41

The second information element in the Probe Response frame "Between Interval."

NOW READS:
"Beacon Interval."

Anonymous    Nov 01, 2004
Printed
Page 81
Figure 4-41

Same mistake as on page 80
Probe Response frame should also include the Supported Rates Information Element.

Anonymous   
Printed
Page 90
In section WEP Data Processing, instances of "IV" in the following

HAVE BEEN CHANGED to "ICV":

" RC4 takes the 64 input bits and generates a keystream equal to the length
of the frame body plus the IV. The keystream is then XORed with the frame
body and the IV to cipher it."

NOW READS:
" RC4 takes the 64 input bits and generates a keystream equal to the length
of the frame body plus the IVC. The keystream is then XORed with the frame
body and the IVC to cipher it."

Anonymous    Dec 01, 2003
Printed
Page 91
3rd paragraph

in the WEP key lengh sidebar talking about the 128-bit WEP, Gast says, "After
subtracting 104 bits for the shared secret component of the RC4 key, only 104 bits
are secret", when he means something like "after subtracting the 24 bit
Initialization Vector component of the RC4 key, only 104 bits are secret."

Note from the Author or Editor:
The suggested correction should be applied.

Anonymous   
Printed
Page 109
7. in ordered list

Minor typo:
The last part of the last sentence reads "put the port back into an authorized
station."
^^^^^^^
state.

Note from the Author or Editor:
This error was corrected in the second edition.

Anonymous   
Printed
Page 111
Section Keying

The book says that two WEP keys are used by 802.1X. That is correct, but the
description of how the keys are used is wrong. The book states that one key is used
for upstream transmissions, and one is used for downstream transmissions. The
correct implementation is that one key is used for unicast transmissions, and the
second key is used for broadcast transmissions.

Anonymous   
Printed
Page 118
1st paragraph

Minor typo:
The last part of the second sentence (first full sentence on the page) reads:

"...must wait for the congestion window to elapse before transmitting."

Elsewhere in the book, including in Figure 7-3 on the same page, this
is referred to as the "contention window" not "congestion window".

Note from the Author or Editor:
This error was corrected in the second edition.

Anonymous   
Printed
Page 122
Figure 7-5

In the "shared-key authentication exchange" diagram, the authentication algorithm in
the first frame is correctly listed as "1 (shared key)." But in the other 3 frames
the authentication algorithm was previously listed as "2 (shared key)."

The algorithm in all four frames NOW READS "1 (shared key)".

Anonymous    Nov 01, 2004
Printed
Page 123
Figure 7-6

The process is called preauthentication, but the text in the figure refers to
preauthorization. The figure should be changed to preauthentication to match the
surrounding text

{128+} Entire section;
Buffering is only performed on frames with the Order bit clear. Frames sent using
the StrictlyOrdered class are not allowed to be buffered at the access point. This
minor distinction does not appear in the text.

Anonymous   
Printed
Page 132
Figure 7-12

Station1 should assert a PS-Poll frame to AP at the second beacon interval as well as
the fifth beacon interval.

Note from the Author or Editor:
Station 1 does not need to send a PS-Poll frame in the second Beacon interval because PS-Poll frames are not used to retrieve buffered multicast frames. In the fifth Beacon interval, the second frame should be labeled as a unicast, not a multicast.

Anonymous   
Printed
Page 154
Middle of the page

Heading reads "TKI P data transmission". Should be "TKIP data transmission"

Anonymous   
Printed
Page 165
3rd paragraph / Figure 10-1

The third paragraph says that "In [figure 10-1], the hopping pattern is {2,8,4,7}".
The figure shows {2,8,4,6}.

Note from the Author or Editor:
This error was corrected in the second edition.

Anonymous   
Printed
Page 181
Figure 10-16

Figure 10-15 shows the first side lobe extending 11Mhz out from the center frequency.
This is correct I believe.

Figure 10-16 shows the first side lobe extending out what appears to be about 5Mhz.
If it were 11Mhz then it would extend to almost the halfway point between Channels 1
and 6. The scale of the lobe pattern appears to be skewed.

Note from the Author or Editor:
The figure was replaced in the second edition. See Figure 12-7 for the new figure.

Anonymous   
Printed
Page 186
5th paragraph

In the paragraph titled "Header" it says: "Five fields comprise the header:....".
It's wrong. It says twice the same field (Signal) so it should say "Four fields..."
and cite the Signal field only once.

Anonymous   
Printed
Page 191
Figure 10-26

The HR/DSSS PLCP framing diagram shows the length and CRC fields to be a mixture of 8
and 16 bits. Whereas the standard specifies them as all 16 bits.

AUTHOR: Yes, that is correct. Both the length and CRC fields should be 16 bits.
There are three changes necessary--I did get the CRC field length
right in the "short preamble" bar at the bottom of the figure, but the
length field is wrong. Both the CRC and length field are wrong in the
"long preamble" bar at the top.

Anonymous   
Printed
Page 209
Figure 11-12

I think that the unit is wrong. I think that it is not a MS (milli second) but a US
(micro second).

Note from the Author or Editor:
The comment is correct, and the figures were fixed in the second edition.

Anonymous   
Printed
Page 230
paragraph under Figure 12-24

The last sentence says that 'Peer-to-Peer networks are infrastructure networks.' I
believe 'Peer-to-Peer networks would be considered iBSS and NOT infrastructure
networks.

Note from the Author or Editor:
The comment is correct.

Anonymous   
Printed
Page 235
at the bottom of page

Equation at the bottom of the page must be

Path loss (dB) = 32.5 + 20 log F + 20 log d

instead of

Path loss (dB) = 32.5 + 20 log F + log d

Anonymous   
Printed
Page 252
2nd paragraph, kill command

A more elegant way to HUP a process is:

kill -1 `ps ax | grep "[c]ardmgr" | awk '{print $1}'`

You remove the u flag in ps aux since you don't care about the user running the
process. grep "[c]ardmgr" avoids having to use grep -v grep. We put the double quotes
in grep's argument to pass through the shell. Awk prints $1 since ps doesn't print
the user anymore.

Note from the Author or Editor:
This is a more elegant way to HUP a process. However, when the second edition was written, card services no longer needed as much hands-on management.

Anonymous   
Printed
Page 307
first paragraph

"read-dressing" should really be "re-addressing"

Note from the Author or Editor:
This error was fixed in the second edition.

Anonymous   
Printed
Page 333
First Paragraph

Ethereal now supports Lucent Orinoco under Linux, making
the statement "For data capture on Linux, only Intersil-based cards are supported."

See
http://www.ethereal.com/faq.html#q4.21

Note from the Author or Editor:
This erratum was fixed in the second edition (see page 556, third paragraph).

Anonymous   
Printed
Page 415
Lower Right, item "PMD"

PMD should be "... The lower component of the PHY, responsible for transmitting RF
signals ..." instead of "...... The lower component of the MAC ..."

Note from the Author or Editor:
This error was fixed in the second edition.

Anonymous