I have a laptop running BT2, a Nokia n800 (runs busybox 1.4.1), and a Belkin WAP all sitting on my desk, about one meter from each other. I'm using the laptop to capture traffic between the n800 and the WAP, but I'm consistently getting information missing from the dumps, apparently due to aircap-ng's failure to decrypt all the WPA packets. There are some other WAPs (not mine) in the vicinity, but their signals are all very weak. I'm not aware of any other sources of interference. I bought a wi-spy but it seems to be DOA.
I'm also getting DHCP and netbios packets in the dumps which I can't explain, and this traffic is what started my inquiry in the first place.

The WAP is operating on channel 11. I boot BT2 and do this:
wlanconfig ath1 create wlandev wifi0 wlanmode monitor
iwconfig ath1 channel 11
airodump-ng -c 11 -w foo -d <my WAP's bssid> ath1
My WAP shows up, and I'm getting all the beacons. As expected, no clients show up and there are no data packets, because I have no wireless clients connected, and I'm sure nobody else does either because I'm the only one who knows the WPA password, and the password is strong. I have a machine running Windows Vista with a wired connection to the WAP and it has a DHCP lease but there's no reason why its traffic would be transmitted on the wireless network. Now I tell the n800 to connect to Belkin, and immediately lights begin blinking madly on the WAP, and airodump is logging about 30 data packets per second. This is without me telling the n800 to initiate any network activity besides just connecting (associate with the WAP and get a DHCP lease), and do a single short HTTP GET to Nokia's website which the n800 does every time it gets a connection, which just takes a couple seconds. After a half minute or so of continuous traffic, I tell the n800 to disconnect, and immediately all data packets stop. Total data packets reported for the WAP for this run: 947. Total reported for the n800 (the only client): 550.
Now it's time to read them:
airdecap-ng -p <WAP's WPA password> -e belkin foo-01.cap
Total number of packets read 1648
Total number of WEP data packets 0
Total number of WPA data packets 925
Number of plaintext data packets 0
Number of decrypted WEP packets 0
Number of decrypted WPA packets 478

Size of foo-01.cap is 610061 bytes. foo-01-dec.cap is 274149 bytes.

Why were only about half of the WPA packets decrypted?

On previous runs I was using aircrack-ng suite version 0.9.1, so I upgraded to 1.0 beta1, but I'm still having the same problem. I searched, and found a suggestion at tinyshell.be to change crc.c as follows:
< unsigned long crc;
< crc = calc_crc(buf, len);
> unsigned long crc = 0xFFFFFFFF;
> for ( ; len > 0; len--, buf++)
> crc = crc_tbl[(crc ^ *buf) & 0xFF] ^ ( crc >> 8 );
> crc = ~crc;
There's no crc.c in the 1.0 beta1 source, so I made the change in the 0.9.1 source, recompiled, and tried it, but as I expected, it didn't solve the problem, since the code change appears to just inline the function calc_crc but not make any functional change at all. (It makes the subsequent "buf+=len" superfluous but the logic remains the same.) Later in the thread on tinyshell.be is a link to ticket# 158 in the aircrack-ng bug tracking system, which claims that the bug was fixed last April.

(The post in question at tinyshell.be is in the aircrackng forum, topic 365, msg7720; allow me to insert here the customary gripe I frequently read on the remote-exploit.org forum about not being allowed to post links.)

Anyway, pressing on in the analysis, wireshark foo-01-dec.cap shows 478 packets (same number that airdecap decrypted).
First packet is EAPOL from Belkin to Nokia; info says "Key[Malformed Packet]". So right from the start there's obviously some traffic missing from the decrypted dump, because the Belkin wouldn't be sending a packet to the Nokia without the Nokia first initiating contact. Second packet is EAPOL from Nokia to Belkin; info says "Key". Third is DHCP discover from Nokia at 0.0.0.0 to 255.255.255.255, 4th is DHCP request from Nokia at 0.0.0.0 to 255.255.255.255, 5th is arp lookup from Nokia at 192.168.2.2 for default gateway, 6th is arp reply from Belkin at 192.168.2.1.
DHCP info from Belkin to Nokia is missing from the decrypted dump, but obviously must have occurred, because Nokia reveals its newly assigned IP address in packet #5.

Seventh packet is TCP SYN from Nokia to 217.77.202.40:80 as beginning of stream that results in Nokia sending
GET /tableteer/rss/promo/tableteerinfo.xml HTTP/1.1
Host: n800.tableteer.nokia.com
Accept: */*
and receiving a response that's 919 bytes. This occurs without any DNS lookup, but I don't know if that's because the lookup is missing from the decrypted dump, or if the Nokia has the ip address hardwired or cached from a previous lookup.

Beginning with packet #8, mixed in with the one brief TCP stream, and then continuing to the end of the dump and constituting the bulk of the dump, are hundreds of DHCP requests from 192.168.2.2 to 192.168.2.1, all with the same transaction ID, and no replies from the Belkin. They're bootstrap protocol packets with message type "boot request (1)". I have no idea why this is happening. Why would a Unix machine which is already booted send boot request packets?

Mixed in with that are four NBNS packets from 192.168.2.1 to 192.168.2.2 with info "name query NBSTAT" and four ICMP replies from 192.168.2.2 with info "destination unreachable (port unreachable)". Why would a WAP, which is probably running some form of embedded Unix, send netbios packets to a connected client? The Vista machine on the wired network would seem to be the obvious culprit, but the packets are originating from the WAP itself, not from the Vista machine.

The continuous flurry of unexpected traffic turns out to be a bunch of boot requests; now I have three questions, why are those boot requests there, why are those netbios packets there, and why does airdecap only decrypt half of the WPA packets?
Are there obvious answers or is this a mystery to everybody else too?