--Ayym4vmyMU9P4uDb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 23, 2006 at 11:01:42AM -0700, Sam Leffler wrote:
> Jonathan A. Kollasch wrote:
> > Hi,
> >=20
> >  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`
> >=20
> > 01:54:25.094909 DA:33:33:ff:ed:8f:e6 BSSID:00:13:46:0a:39:82 SA:00:b0:d=
0: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:d=
a:79:8f:ae LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03, IP 172.27.72.=
11.22 > 172.27.72.40.64735: P 320:480(160) ack 1 win 33580 <nop,nop,timesta=
mp 5868 5516>
> >=20
> > It appears to me that whatever is supposed to be decrypting
> > the packets addressed to 33:33:ff:ed:8f:e6 isn't.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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).
> >=20
> > 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.
> >=20
> > 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).
>=20
> You don't provide any details of your network/wireless config.  CCMP

D-Link DI-524 being used as access point. The relevant addresses are
all in the same broadcast domain (i.e. the AP should be
bridging all frames).  3.99.21 kernel, userland a week or two old.
Router is a sparc64 3.0 box with wired interfaces.
A few Fast Ethernet switches, Cat5 cable, etc..
The client card is an older WG511T.

wpa_supplicant.conf:
ctrl_interface=3D/var/run/wpa_supplicant
ctrl_interface_group=3Dwheel
network=3D{
	ssid=3D"tluafed"
	key_mgmt=3DWPA-EAP
        eap=3DTTLS
	phase2=3D"auth=3DPAP"
}

the "identity" and "password" are entered through wpa_cli.

> 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
> issue).


Also, I've been told that many (40% in one test of 10), even
enterprise-grade, access points do not properly handle multicast
(while in WPA mode).  As I don't have another available AP, I may
try a hostapd-based thing with my ral or ath PCI card.  Also, I
should probably try with WPA[12]-PSK as well.  I've already
tested WPA1-Enterprise and had similar dysfunctional results.

	Jonathan Kollasch

--Ayym4vmyMU9P4uDb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFEnMGUOjx1ye3hmokRAsvyAJ9u2FXjsCKylFUWkcIPepLCXPgv9ACdEd3P
k9kAS2Fl15hIAsYehSgUZRg=
=k41k
-----END PGP SIGNATURE-----

--Ayym4vmyMU9P4uDb--