[Madwifi-users] Re: [corrected PATCH] madwifi+hostapd groupkey problematic]

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

With the help of the hostap mailing list and Sebastian's patch
(below), I now have a Windows XP client connecting using WPA.  I had
to add two parameters to the patch to get it to compile without
warnings.  Not sure if they are as intended.  These minimal changes
are here
  http://www.cybcon.com/~coert/tmp/Dmadwifi-hostapd-groupkey.patch
or in .pdf form:
  http://www.cybcon.com/~coert/tmp/Dmadwifi-hostapd-groupkey.pdf

/Coert Vonk

On Sun, 6 Feb 2005 18:55:55 -0800, Coert Vonk <coe...@gm...> wrote:
> This last patch works for me.  After sending the EAP-Request, it now
> receives an EAP-Response.
>=20
> To get it to compile, I added the two missing parameters in the call
> to  IEEE80211_DPRINTF() in net80211/ieee80211_output.c:301
>=20
> Just as with the earlier patch
>   http://sourceforge.net/mailarchive/message.php?msg_id=3D10728087
> I  get an "EAP-TLV: TLV Result - Failure - requested Failure" error
> during 802.1x EAP phase 2.  This might be a problem with WinXP SP2.
> See my cross posting on
>   http://lists.shmoo.com/pipermail/hostap/2005-February/009342.html
>=20
> Coert
>=20
> ---original-message--follows---
>=20
> From: Whoopie <whoopie79@gm...>
> Re: [corrected PATCH] madwifi+hostapd groupkey problematic]
> 2005-02-02 17:05
>=20
>  Sorry, but doesn=B4t work.
>=20
>  Kind Regards,
>  Whoopie
>=20
>  > -------- Original-Nachricht --------
>  > Betreff: [Madwifi-users] [corrected PATCH] madwifi+hostapd groupkey
>  > problematic
>  > Datum: Wed, 2 Feb 2005 18:01:01 +0100 (CET)
>  > Von: Sebastian Weitzel <togg@to...>
>  > An: madwifi-users@li...
>  >
>  >
>  >
>  >> This change is wrong.  The correct code is in FreeBSD.
>  >
>  > Thank you for that hint. I just found out yesterday that you develop
>  > mainly for the freebsd atheros driver and madwifi gets changes with mu=
ch
>  > delay.
>  > Since I want to bring madwifi to a much more stable and functional ver=
sion
>  > I am starting to port the most important things (wme for me) from bsd,
>  > which I would have started much earlier if I knew about existance of t=
hat
>  > ;)
>  >
>  > Please forget my old patch, I now adopted as much as I could from free=
bsd
>  > driver without changing to much around. Whoopie, can you please test i=
f
>  > this patch now works with Windows XP supplicant?
>  >
>  > If anyone else wants to port things from bsd to madwifi I think it wou=
ld
>  > be a good idea to mention it on the mailing list to prevent double wor=
k.
>  >
>  > Thanks and regards,
>  > Sebastian Weitzel
>  >
>  >
>=20
>  ------------------------------------------------------------------------=
--------
>=20
>  > diff -Nur madwifi.org/net80211/ieee80211_output.c
>  > madwifi/net80211/ieee80211_output.c
>  > --- madwifi.org/net80211/ieee80211_output.c 2005-02-01 09:55:38.000000=
000
>  > +0100
>  > +++ madwifi/net80211/ieee80211_output.c 2005-02-02 17:45:17.000000000
>  > +0100
>  > @@ -200,32 +200,37 @@
>  >  return skb;
>  > }
>  >
>  > +#define KEY_UNDEFINED(k)        ((k).wk_cipher =3D=3D &ieee80211_ciph=
er_none)
>  > /*
>  > - * Return the transmit key to use in sending a frame to
>  > - * the specified destination. Multicast traffic always
>  > - * uses the group key.  Otherwise if a unicast key is
>  > - * set we use that.  When no unicast key is set we fall
>  > - * back to the default transmit key.
>  > - */
>  > + * Return the transmit key to use in sending a unicast frame.
>  > + * If a unicast key is set we use that.  When no unicast key is set
>  > + * we fall back to the default transmit key.
>  > + */
>  > static inline struct ieee80211_key *
>  > -ieee80211_crypto_getkey(struct ieee80211com *ic,
>  > - const u_int8_t mac[IEEE80211_ADDR_LEN], struct ieee80211_node *ni)
>  > +ieee80211_crypto_getucastkey(struct ieee80211com *ic, struct
>  > ieee80211_node *ni)
>  > {
>  > -#define KEY_UNDEFINED(k) ((k).wk_cipher =3D=3D &ieee80211_cipher_none=
)
>  > - if (IEEE80211_IS_MULTICAST(mac) || KEY_UNDEFINED(ni->ni_ucastkey)) {
>  > - if (ic->ic_def_txkey =3D=3D IEEE80211_KEYIX_NONE ||
>  > -     KEY_UNDEFINED(ic->ic_nw_keys[ic->ic_def_txkey])) {
>  > - IEEE80211_DPRINTF(ic, IEEE80211_MSG_OUTPUT,
>  > -     ("%s: no transmit key, def_txkey %u\n",
>  > -     __func__, ic->ic_def_txkey));
>  > - /* XXX statistic */
>  > - return NULL;
>  > - }
>  > - return &ic->ic_nw_keys[ic->ic_def_txkey];
>  > - } else {
>  > - return &ni->ni_ucastkey;
>  > - }
>  > -#undef KEY_UNDEFINED
>  > +        if (KEY_UNDEFINED(ni->ni_ucastkey)) {
>  > +                if (ic->ic_def_txkey =3D=3D IEEE80211_KEYIX_NONE ||
>  > +                    KEY_UNDEFINED(ic->ic_nw_keys[ic->ic_def_txkey]))
>  > +                        return NULL;
>  > +                return &ic->ic_nw_keys[ic->ic_def_txkey];
>  > +        } else {
>  > +                return &ni->ni_ucastkey;
>  > +        }
>  > +}
>  > +
>  > +/*
>  > + * Return the transmit key to use in sending a multicast frame.
>  > + * Multicast traffic always uses the group key which is installed as
>  > + * the default tx key.
>  > + */
>  > +static inline struct ieee80211_key *
>  > +ieee80211_crypto_getmcastkey(struct ieee80211com *ic, struct
>  > ieee80211_node *ni)
>  > +{
>  > +        if (ic->ic_def_txkey =3D=3D IEEE80211_KEYIX_NONE ||
>  > +            KEY_UNDEFINED(ic->ic_nw_keys[ic->ic_def_txkey]))
>  > +                return NULL;
>  > +        return &ic->ic_nw_keys[ic->ic_def_txkey];
>  > }
>  >
>  > /*
>  > @@ -274,21 +279,32 @@
>  >  }
>  >  }
>  >
>  > - /*
>  > - * Insure space for additional headers.  First
>  > - * identify transmit key to use in calculating any
>  > - * buffer adjustments required.  This is also used
>  > - * below to do privacy encapsulation work.
>  > - *
>  > - * Note key may be NULL if we fall back to the default
>  > - * transmit key and that is not set.  In that case the
>  > - * buffer may not be expanded as needed by the cipher
>  > - * routines, but they will/should discard it.
>  > - */
>  > - if (ic->ic_flags & IEEE80211_F_PRIVACY)
>  > - key =3D ieee80211_crypto_getkey(ic, eh.ether_dhost, ni);
>  > - else
>  > - key =3D NULL;
>  > +        /*
>  > +         * Insure space for additional headers.  First identify
>  > +         * transmit key to use in calculating any buffer adjustments
>  > +         * required.  This is also used below to do privacy
>  > +         * encapsulation work.  Then calculate the 802.11 header
>  > +         * size and any padding required by the driver.
>  > +         *
>  > +         * Note key may be NULL if we fall back to the default
>  > +         * transmit key and that is not set.  In that case the
>  > +         * buffer may not be expanded as needed by the cipher
>  > +         * routines, but they will/should discard it.
>  > +         */
>  > +        if (ic->ic_flags & IEEE80211_F_PRIVACY) {
>  > +                if (ic->ic_opmode =3D=3D IEEE80211_M_STA ||
>  > +                    !IEEE80211_IS_MULTICAST(eh.ether_dhost))
>  > +                        key =3D ieee80211_crypto_getucastkey(ic, ni);
>  > +                else
>  > +                        key =3D ieee80211_crypto_getmcastkey(ic, ni);
>  > +                if (key =3D=3D NULL && eh.ether_type !=3D htons(ETHER=
TYPE_PAE))
>  > {
>  > +                        IEEE80211_DPRINTF(ic, IEEE80211_MSG_CRYPTO,
>  > +                            ("[%s] no default transmit key (%s) deftx=
key
>  > %u\n",
>  > +                            ether_sprintf(eh.ether_dhost)));
>  > +                        ic->ic_stats.is_tx_nodefkey++;
>  > +                }
>  > +        } else
>  > +                key =3D NULL;
>  >  skb =3D ieee80211_skbhdr_adjust(ic, key, skb);
>  >  if (skb =3D=3D NULL) {
>  >  /* NB: ieee80211_skbhdr_adjust handles msgs+statistics */
>  > @@ -333,24 +349,27 @@
>  >  case IEEE80211_M_MONITOR:
>  >  goto bad;
>  >  }
>  > - if (eh.ether_type !=3D __constant_htons(ETHERTYPE_PAE) ||
>  > -     (key !=3D NULL && (ic->ic_flags & IEEE80211_F_WPA))) {
>  > - /*
>  > - * IEEE 802.1X: send EAPOL frames always in the clear.
>  > - * WPA/WPA2: encrypt EAPOL keys when pairwise keys are set.
>  > - */
>  > - if (key !=3D NULL) {
>  > - wh->i_fc[1] |=3D IEEE80211_FC1_WEP;
>  > - /* XXX do fragmentation */
>  > - if (!ieee80211_crypto_enmic(ic, key, skb)) {
>  > - IEEE80211_DPRINTF(ic, IEEE80211_MSG_CRYPTO,
>  > -     ("[%s] enmic failed, discard frame\n",
>  > -     ether_sprintf(eh.ether_dhost)));
>  > - /* XXX statistic */
>  > - goto bad;
>  > - }
>  > - }
>  > - }
>  > +
>  > +        if (key !=3D NULL) {
>  > +                /*
>  > +                 * IEEE 802.1X: send EAPOL frames always in the clear=
.
>  > +                 * WPA/WPA2: encrypt EAPOL keys when pairwise keys ar=
e
>  > set.
>  > +                 */
>  > +                if (eh.ether_type !=3D __constant_htons(ETHERTYPE_PAE=
) ||
>  > +                    ((ic->ic_flags & IEEE80211_F_WPA) &&
>  > +                     !KEY_UNDEFINED(ni->ni_ucastkey))) {
>  > +                        wh->i_fc[1] |=3D IEEE80211_FC1_WEP;
>  > +                        /* XXX do fragmentation */
>  > +                        if (!ieee80211_crypto_enmic(ic, key, skb)) {
>  > +                                IEEE80211_DPRINTF(ic,
>  > IEEE80211_MSG_CRYPTO,
>  > +                                    ("[%s] enmic failed, discard
>  > frame\n",
>  > +                                    ether_sprintf(eh.ether_dhost)));
>  > +                                /* XXX statistic */
>  > +                                goto bad;
>  > +                        }
>  > +                }
>  > +        }
>  > +
>  >  if (eh.ether_type !=3D __constant_htons(ETHERTYPE_PAE)) {
>  >  /*
>  >  * Reset the inactivity timer only for non-PAE traffic
>  > Bin=E4rdateien madwifi.org/net80211/.ieee80211_output.c.swp and
>  > madwifi/net80211/.ieee80211_output.c.swp sind verschieden.
>  >
>=20
>       From: Sebastian Weitzel <togg@to...>
>       Re: [corrected PATCH] madwifi+hostapd groupkey problematic]
>       2005-02-03 00:32
>=20
>  > Sorry, but doesn=B4t work.
>=20
>  Hmm, strange. I retested with Windows XP SP2 + Centrino just now. The
>  WPA-EAP and WPA-PSK auth works perfectly.
>  I think there must be some issue on your side.
>=20
>  Regards,
>  Sebastian Weitzel
>