Subject: Re: multicast WPA-encrypted frames being dropped?
To: Jonathan A. Kollasch <>
From: Sam Leffler <>
List: tech-net
Date: 06/23/2006 11:01:42
Jonathan A. Kollasch wrote:
> Hi,
>  So, I've been using WPA-Enterprise (complete with Kerberos
> authentication, no thanks to the FreeRADIUS from pkgsrc, but
> that's another issue) and am trying to get IPv6 connectivity,
> which was working fine with WEP on 3.0.  Anyway AFAICT
> frames to my 33:33:ff:... address are not being decrypted,
> here's a snipit of `tcpdump -s0 -eni ath0 -y IEEE802_11`
> 01:54:25.094909 DA:33:33:ff:ed:8f:e6 BSSID:00:13:46:0a:39:82 SA:00:b0:d0:c8:58:9c Data IV:fbe8 Pad 20 KeyID 1
> 01:54:25.834352 DA:00:09:5b:ed:8f:e6 BSSID:00:13:46:0a:39:82 SA:00:50:da:79:8f:ae LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03, IP > P 320:480(160) ack 1 win 33580 <nop,nop,timestamp 5868 5516>
> It appears to me that whatever is supposed to be decrypting
> the packets addressed to 33:33:ff:ed:8f:e6 isn't.
> The symptoms include being unable to receive a
> router advertisement, and being unable to
> ping this wireless client's link-local address
> from the wired side of the LAN.
> Pinging ff02::1%ath0 from the client returns
> only a subset of the link-local addresses on
> the broadcast domain.  Directing a ping6 or two
> at a specific LL address seems to add it to the
> subset.
> Also the "rx seq# violation (CCMP)" number in ifconfig -v
> is increasing faster than I'd like (rate seems to depend
> on this problematic traffic).
> I'm not really sure where the problem lies, be it the
> cheap "router" AP or NetBSD and/or wpa_supplicant.
> I suppose at the very least I'd like to know if
> this has happened to anyone else.
> Anyway the Wireless Router doesn't let me set a
> default route out the LAN side, so I can't put
> the RADIUS server in a different broadcast domain.
> This happens to prevent what I was wanting to do
> (see my IPsec and altq post a few weeks ago).

You don't provide any details of your network/wireless config.  CCMP
seq# violations should not occur and probably indicate the mcast ipv6
frames are not being recognized as mcast and decoded with the group key.
 This happens in the kernel (i.e. it's unlikely to be a wpa_supplicant