kernel encryption error forwarding packets through hostapd

[Brandon Craig Rhodes]

After many hours of wrestling, my Linux box with a Netgear card
("Intersil Corporation Prism 2.5 Wavelan chipset" according to lspci)
is acting as a WPA-PSK access point, and my laptop with built-in card
("Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter") is
able to associate and remain associated for moderate periods of time.
(After leaving the laptop idle for too long, I have to reset its card
with "iwpriv eth1 reset 1" to let it re-associate.)

>From the laptop, I can successfully ping both the access point and
hosts out on the Internet, and can successfully ssh to the access
point itself.  But most (not all!) TCP connections to hosts out on the
Internet hang because the SYN+ACK packets are never broadcast to the
laptop.  Running "tshark -n -i wlan0" on the access point shows the
SYN getting sent and the SYN+ACK coming back:

3014.327052 192.168.2.2 -> 69.61.125.42 TCP 60088 > 22 [SYN] Seq=0 Len=0 MSS=1460 TSV=10962417 TSER=0 WS=4
3014.386751 69.61.125.42 -> 192.168.2.2 TCP 22 > 60088 [SYN, ACK] Seq=0 Ack=1 Win=1872 Len=0 MSS=480 TSV=2246692600 TSER=10962417 WS=4

but on the laptop itself, tshark only sees the first packet!  At the
very moment that the access point tries to transmit the SYN+ACK, its
kernel produces the messages:

Jan  9 12:54:25 asaph kernel: Invalid packet for Michael MIC add (tailroom=6 hdr_len=24 skb->len=92)
Jan  9 12:54:25 asaph kernel: wifi0_rename: TX - encryption failed

I cannot find any mention of this error anywhere on the Internet
except in the hostap source code itself!  What causes this message,
and how can I prevent this error?

The one complication is that the machine which I use as my access
point uses the Xen virtual monitor to host two virtual machines on
which I can more safely run Internet services like Postfix and Apache.
Let us call the physical box acting as my access point "p", the
virtual host that acts as my firewall "v", and the laptop "lt".
Packets coming from the Internet are processed by "v" and:

 - are sent out the "eth1" interface of "v";

 - thus appear on the "vif2.1" interface of "p";

 - travel across the kernel Ethernet bridge "bridge1" on "p";

 - arrive at interface "vif0.1" on "p";

 - thus appear to the "p" as though they are arriving at its normal
   "eth1" interface;

 - "p" determines (a) that the packet is addressed to a host on my
   wireless network, (b) that iptables says to "ALLOW" the packet, and
   (c) that "/proc/sys/net/ipv4/conf/eth1/forwarding" is set to "1";
   therefore, "p" decides it can act as a gateway for the packet.

 - "p" sends the packet out its "wlan0" interface;

 - and, as discussed above, for some packets this results in
   successful transmission that can be seen by "lt", but for others
   generates the "Invalid packet for Michael MIC" kernel error on "p"
   and I see no packet arriving at "lt".

Does the fact that the packet travels across a kernel Ethernet bridge
before reaching the INPUT/FORWARD logic on the access point "p" give
it a shape or features that the wireless code simply cannot accept?
The test that these packets seem to fail (and they do it reliably; the
problem is not intermittent) in the "ieee80211_michael_mic_add()"
function is:

    if (skb_tailroom(skb) < 8 || skb->len < hdr_len)

Both cards in question, by the way, have been running perfectly for
years with WEP being used between them, so issues like signal strength
should not be involved; it is because of recent unauthorized use of my
network by Georgia Tech students that I have spent several days
attempting this upgrade to WPA.

Some details:

The access point uses the "hostap" and "hostap_diag" drivers; the
laptop, "ipw2100".  All are on the most recent Debian "2.6.18-3-686"
kernels.  On the access point I am running hostapd, as root, like:

# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd/hostapd.conf

where the configuration file contains (omitting all of the "logger"
and "wme" parameters, which I left as in the default file):

interface=wlan0
debug=0
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=attic
max_num_sta=255
macaddr_acl=0
auth_algs=3
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=3
wpa_passphrase=<my passphrase>
wpa_key_mgmt=WPA-PSK

On the laptop, I am running "wpa_supplicant" like:

# /sbin/wpa_supplicant -dd -W -P /var/run/wpa_supplicant.eth1.pid -i eth1 -D wext -c /etc/wpa_supplicant/eth1.conf

where the config file says:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=dialout
network = {
 ssid="attic"
 key_mgmt=WPA-PSK
 psk="<my passphrase>"
}

Having discovered that the firmware version "0.8.4" was a disaster
from a stability point of view (30%-40% packet loss), my access point
firmware is currently burned (because using RAM-loaded firmware did
not seem to quite work; it kept disappearing when I ran "hostapd") at
versions:

# hostap_diag wlan0
Host AP driver diagnostics information for 'wlan0'

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.7.4 (station firmware)

Thanks for any help!

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon