Appendix A: Directory of Suppliers

Merging Netstumbler Log Files

NetStumbler's .NS1 log files can be merged together very easily. The File|Merge option opens a file selection dialog, and the file that you select will be merged with the active file in NetStumbler. This can be useful if you want to gather the results of several trips into a single file covering a week's or a month's wardriving, or from several people canvassing a metropolitan area on a cooperative basis.

You can begin by creating a new, empty file with the File|New option, or the New button in the button bar. One caveat: Unless you've un-checked the 'New document starts scanning' option on the General tab of the Options dialog, you'll add your own access point to the new file if the AP is within range. Turning off scanning by clicking the Scanning button won't prevent this. Once you have a new file, you can add existing files to it by selecting each in turn from the File|Merge dialog. Once you've added everything that needs adding, you can save the new file out under an appropriate name.

Exporting to Text

To export to a text file, select File|Export and choose from the three options:

• Summary: Each stumbled station is one text record.

• Text: Each different signal strength reading on each station is a separate record. These are much larger files.

• Wi-Scan: Similar to the Text format, but saves files for the Wi-Scan utility written by Pete Shipley, who basically invented wardriving as we know it. This format omits certain items present in the other export formats.

In each case, give the file a name with a .txt extension. NetStumbler does not provide the .txt extension automatically.

The exported text records (each line being considered a record) are tab-delimited. Each field within a record is separated from the next field by a tab character.

The Text File Field Structure

For the most part, each text record corresponds to a line on the NetStumbler display, so this description repeats the description of the display to some extent. Here is a summary of the fields output by NetStumbler 0.3.30, in order from the left column:

1. Latitude of the GPS receiver when NetStumbler detected the station, in degrees.

2. Longitude of the GPS receiver when NetStumbler detected the station, in degrees.

3. SSID of the station, enclosed in parentheses.

4. Type: The mode in which the stumbled station was operating. 'BBS' = infrastructure mode. 'Ad-hoc' = ad hoc mode. The 'BBS' may be a bug; Marius may have intended to use 'BSS' here, as BSS is IEEE jargon for a station operating in infrastructure mode.

5. BSSID: The MAC address of the station, enclosed in parentheses. 'BSSID' is jargon for 'MAC address.'

6. The time that the station was logged, in GMT (Greenwich Mean Time).

7. The signal-noise ratio, signal reading, and noise reading, given as three numbers enclosed in square brackets.

8. Name: The AP's descriptive name, if it can be determined. This field is usually blank. NetStumbler cannot always determine an AP's name, even if the AP has one. (Most do not.)

9. The Flag bits. I'll discuss these bit fields later in this chapter.

10. The channel bits. This indicates the channel or channels on which the stumbled station was detected during the time it was in range of NetStumbler. It's a hexadecimal value, which I'll relate to channel numbers below.

11. The beacon interval at which the stumbled station is sending beacon frames, in milliseconds. I've never seen this with a nonzero value in an exported text file, even though it displays correctly on the main NetStumbler display. I can only assume that there's a bug in the export code.

The Name field exists to show an access point's descriptive name. Keep in mind that in an Extended Service Set (ESS) there may be several access points with the same SSID. The SSID is the name of the network, not the access point! (Since the vast majority of small office and home office networks have only a single AP, this can easily be misunderstood.) Most APs allow administrators to assign a descriptive name, which acts as a more-easily-remembered alias for the AP's MAC address. Curiously, the name of my Cisco Aironet 340 AP is not reported by NetStumbler, and I really don't know why.This is probably a chipset- or firmware-specific problem. If you have any insights, please let me know.

Note that you won't see the Signal+, Noise-, and SNR+ fields in the exported files. These fields exist only on the main NetStumbler display, and are calculated internally every second or so from the multiple signal strength readings taken on each stumbled AP while it remains in range. To duplicate the Signal+, Noise-, and SNR+ fields, you would have begin with the 'big' text file, and examine all the Signal, Noise, and SNR readings taken for a given AP. (Each reading has a separate exported text record, and if you spend any significant time within range of a single AP, there may be hundreds for that AP.) From these readings you would determine the highest signal reading, lowest noise reading, and best SNR for that AP.

If you're looking at an exported summary text file, the Signal, Noise, and SNR fields are the overall best reading taken while the AP was within range.

The Flag Bits

The Flag bits are a 16-bit block of information returned by the client card. Each bit in the lower 8 bits of the Flag bits has a distinct meaning, some of which are defined in the IEEE 802.11 specification, in section 7.3.1.4. The higher 8 bits are reserved for future use, and will always be seen as 0 in NetStumbler's log files. You'll see values like '0031' and '0011' a lot; other values much more rarely.

Interpreting the Flag bits requires a little knowledge of both hexadecimal and binary numbers. Alas, if you're completely clueless about hex and binary numbers I'll have to send you elsewhere, since I don't have the room to explain them here. I cover it thoroughly in my book Assembly Language Step By Step. ( John Wiley & Sons, 2000: ISBN 0-471-37523-3.) Hex numbers are in base 16, and use the letters A to F to indicate the values 10 to 15.

Let's look at an example. Figure 19.1 shows how the 8 significant flag bits are defined.

Figure 19.1: NetStumbler's Flag Bits.

Each bit in the Flag bits maps to a feature or condition inside the access point. A 1-bit means that the corresponding feature or condition is enabled, present, or true, however that makes sense in context. Each bit also has a binary value of 1, 2, 4, or 8. The 8 defined bits of the Flag bits field are divided into two four-bit hexadecimal digits. Within each of those digits, the binary values of any 1-bits are added together to yield a value for the hex digit.

In the example shown in Figure 19.1, three bits are set:

• Infrastructure mode

• WEP enabled

• PBCC

The binary value of the Infrastructure mode bit is 1, and it's the only bit set in the low digit. Thus, the low digit has a value of 1. In the high digit, WEP enabled and PBCC are both set. The WEP enabled bit has a binary value of 1. The PBCC bit has a binary value of 4. Adding 4 and 1 gives us the hexadecimal value of the high digit. The value you would see in a NetStumbler log file (recalling that the two initial digits are always zero) is 0051.

Pulling apart a value from the log file means going in reverse, in a sense: You have to look at a hexadecimal digit and find out which of the values 1, 2, 4, or 8 are 'inside' it. Table 19.1 shows what bits are present in all 16 possible values for a hexadecimal digit.

Table 19.1: Hexadecimal Values and Their Equivalents Bit Patterns.

Hexadecimal Value	Bit Pattern
0	0000
1	0001
2	0010
3	0011
4	0100
5	0101
6	0110
7	0111
8	1000
9	1001
A (10)	1010
B (11)	1011
C (12)	1100
D (13)	1101
E (14)	1110
F (15)	1111

The way to use Table 19.1 is to look down the left column for the digit you see in the Flag bits field in a NetStumbler log file, then go over to the right column to find the bits that it represents. Compare those bits to the named bit fields shown in Figure 19.1, to see which bit fields correspond to the 1-bits in the digit.

I suppose I should let you dope out the common ones for practice, but hexadecimal is not everybody's taste. (I'm an assembly language programmer and it's in my blood.) So Table 19.2 shows the commonest Flag bits values and their meanings.

Table 19.2: Common Flag Bits Values.

Value	Meaning
0001	AP is in infrastructure more; WEP is off
0002	AP is in ad-hoc mode; WEP is off
0011	AP is in infrastructure mode; WEP is on
0031	AP is in infrastructure mode; WEP is on; AP is using short preambles
0051	AP is in infrastructure mode; WEP is on; AP is using PBCC

That's how the encoding of the Flag bits works. Some of what the Flag bits do is pretty obvious. Most is obscure. This gets pretty technical, so I'll be brief.

• Channel Agility is an extension to the 802.11b format that allows a station to change channels automatically if it detects interference on the channel it's using. ShareWave's Whitecap technology, which represents an extended 802.11b system, uses channel agility. Cisco's Aironet line has something similar but not interoperable. Channel Agility is part of the larger 'quality of service' issue being addressed in the IEEE task group 802.11e, and when 802.11e is adopted, we will have a standard for channel agility. I rarely see this bit set; my guess it will be set for any access point that uses channel agility, probably through the Whitecap chipset.

• PBCC means Packet Binary Convolutional Code, which is an encoding scheme allowing higher bit rates in 802.11b transmissions. As best I know, PBCC is currently used only by access points incorporating the Texas Instruments chip set, which implements a proprietary extension to the 802.11b standard. This is called 802.11b+ and is used by a number of new products from several vendors, including D-Link's AirPlus product line. (I discuss this in greater detail in Chapter 4.) The DWL-900AP+ access point uses PBCC to boost its theoretical bit rate (when communicating with other 802.11b+ devices) to 22 MBps. (In 'real life' the DWL-900AP+ doesn't get anywhere close!) If you find a station with the PBCC bit set, you are most likely seeing an 802.11b+ access point. My tests show that the DWL-900AP+ does set this bit.

• The Short Preamble bit refers to a feature in the 802.11b physical layer. Each frame begins with a block of bits called the preamble. There is a long preamble format that all 802.11b compliant devices are required to support. A second, shorter form of the preamble is optional, and can be used to improve link throughput when the functionality of the long preamble isn't required. (Streaming video and voice over IP are two instances when a short preamble can be used to good effect.) Short preambles are the default condition on some access points, including the Cisco Aironet 340. Most of the APs I see with this bit set are Cisco units.

• When the WEP Enabled bit is set to 1, that means the station has enabled WEP.

• The CF-Poll Request and CF-Pollable bits are part of something called the coordination function (CF) that not all access points fully implement, though it is an element of the 802.11 standard. CF is about wireless Ethernet collision detection, and comes into play when a Wi-Fi client can hear its access point but not the other clients associated with that same access point. The client can request that its AP tell it when it's 'clear to send,' that is, when all the other clients are quiet and won't interfere. Explaining this fully here would be a handful, but I don't consider it especially useful knowledge for stumbling anyway. See section 7.3.1.4 of the IEEE 802.11 standards document for details. My guess is you'll see these bits set in business networks with lots of clients rather than home networks. I see them in about 2% of stumbled nodes.

• When the Ad Hoc Mode bit is set to 1, the station is operating in ad-hoc mode.

• When the Infrastructure Mode bit is set, the station is operating in infrastructure mode. The Ad-Hoc Mode and Infrastructure Mode bits are mutually exclusive and you will never see both set simultaneously on the same AP.

The Channel Bits

The channel bits are another 16-bit data block, in which each Wi-Fi channel has an associated bit. This might seem an odd way to express a channel number, but it allows NetStumbler to store multiple channels for a single access point. It's possible (though fairly rare) for a station to change its operating channel while it's in range of NetStumbler. (This may become much more common once the IEEE 802.11e task group is adopted, since 802.11e standardizes 'channel agility,' which is the ability of an access point to duck interference by moving on its own initiative to another channel.) If that happens, NetStumbler displays all channels on which it detected that station during the time it was in range. It stores multiple channels in the log file by raising the appropriate bit for each channel.

Table 19.3 summarizes the common values for the channel bits, when only one channel was detecting while the station was in range. Ninety-nine percent of the time, you'll see only these channel bits values in a log file.

Table 19.3: The Channel Bit Values.

Channel	Channel Bits Field Value
1	0002
2	0004
3	0008
4	0010
5	0020
6	0040
7	0080
8	0100
9	0200
10	0400
11	0800

Note from the table that the value 0001 is invalid and can never appear, as that bit corresponds to no channel. Any other value not in the table indicates multiple channels.

As an example of multiple channels, consider Figure 19.2. Let's posit that an access point jumps through the channels 1, 6, 8, and 11 while in range of NetStumbler. (Once 'channel agility' is made a part of the greater 802.11 standard, this will become a commonplace.) NetStumbler stores a bit in the channel bits field for each of those four channels. This is shown in the 'Example' line in the figure. Each group of four bits corresponds to one hexadecimal digit in the channel bits value.

Figure 19.2: The Channel Bits for Channels 1, 6, 8, and 11.

More to the point, each digit in a hex number is represented by four binary bits. A 16-bit quantity like the channel bits, therefore, can be represented in four hex digits. Figure 19.2 separates the 16 bits of the channel bits field into four groups of four bits. Each bit in its group stands for a value of 1, 2, 4, or 8. Within each groups, the values of any 'set' bits (bits with a 1 value) are added together to give you the value for the associated hex digit.

The bit for channel 8 has a value of 1. The bit for channel 11 has a value of 8. Adding 8 and 1 gives you 9, the value of the hex digit for that group of channel bits. If channel 9's bit were also set, you'd have to add 1 + 2 + 8, for a total of 11-which is the hex digit B.

That's how channel bits are formed. You can 'reverse engineer' a given channel bits value by separating it into its four hex digits, and then looking for the values 1, 2, 4, or 8 within each hex digit. A 3 digit would contain 1 and 2; a 6 digit would contain 2 and 4. Work upward in the figure to find the channel bits associated with each value of 1, 2, 4, or 8 you find inside a hex digit.

Note that the first hex digit is always 0, or something is wrong. No channels correspond to bits 12 to 15.