linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Dan Williams <dcbw@redhat.com>, Zhu Yi <yi.zhu@intel.com>,
	dragoran <drago01@gmail.com>,
	linux-wireless@vger.kernel.org,
	ipw3945-devel <ipw3945-devel@lists.sourceforge.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	Jean Tourrilhes <jt@hpl.hp.com>
Subject: Re: [ipw3945-devel] iwl3945/mac80211 cannot connect to dynamic wep network
Date: Sun, 28 Oct 2007 11:49:59 -0700	[thread overview]
Message-ID: <20071028184959.GN4936@jm.kir.nu> (raw)
In-Reply-To: <1193594085.5197.20.camel@johannes.berg>

On Sun, Oct 28, 2007 at 06:54:45PM +0100, Johannes Berg wrote:

> Hmm. Is there a good explanation of all these values? I still haven't
> understood what all the IW_AUTH_* means. I'm fairly sure though that
> this particular instance hasn't changed in terms of behaviour since the
> original devicescape code (not that this means it's bug-free, of course)

The only documentation for these that I'm aware of is linux/wireless.h.
The original code was not doing this right either (it was implemented
before WE-18, if I remember correctly). The odd part is that I'm sure
this used to work long time ago..

IW_AUTH_* values were designed to provide mechanism for notifying the
driver on number of parameters related to authentication (and
association, in practice). WPA_VERSION, CIPHER_PAIRWISE, CIPHER_GROUP,
KEY_MGMT, 80211_AUTH_ALG, WPA_ENABLED, PRIVACY_INVOKED are parameters
describing the enabled security configuration for associations. Number
of these parameters are bitfields and can include multiple enabled modes
(e.g., both TKIP and CCMP could be allowed as the group cipher). I would
assume most of these parameters be obvious from the field and bitfield
value names.

PRIVACY_INVOKED is describing whether any sort of encryption is to be
used (boolean). If mixed-cell mode (for which there does not seem to be
configuration options in WE) is enabled, any privacy flag combination is
allowed. If mixed-cell is disabled, the PRIVACY_INVOKED has to match
with the Privacy flag advertized in the Beacon/ProbeRsp frames.

TKIP_COUNTERMEASURES is used to notify the driver of a two Michael MIC
failures within 60 seconds to trigger TKIP countermeasures (i.e.,
disable all TKIP encryption/decryption and prevent new associations that
would use TKIP). For client mode, it is also possible that this is
implemented in the driver, so some drivers do not need this. Anyway, for
AP mode, the notification is needed since the driver would not get
notifications of MIC errors detected at clients (which are reported to
the AP in EAPOL-Key frames).

DROP_UNENCRYPTED is a flag for configuring whether any unencrypted
non-EAPOL data frames are allowed through. There is a MIB variable for
this for WEP, but this is of limited use nowadays. I would expect all
WPA configuration to prevent unencrypted data frames (apart from initial
EAPOL frames) anyway.

RX_UNENCRYPTED_EAPOL is used to configure whether unencrypted EAPOL
frames are to be received when pairwise keys are set. This is needed for
IEEE 802.1X (i.e., non-WPA) which never encrypted EAPOL frames. With
WPA, EAPOL frames are encrypted when pairwise keys are set and as such,
unencrypted EAPOL frames should be dropped after the pairwise keys are
configured.

ROAMING_CONTROL can be used to enable/disable roaming decision in the
driver/firmware. The original need for this came from the Prism2
firmware design that has a configuration option for indicating which
component is responsible for roaming (selecting a new BSS if the current
one is likely to end up getting out of range).

-- 
Jouni Malinen                                            PGP id EFC895FA

  reply	other threads:[~2007-10-28 18:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-23  7:54 iwl3945/mac80211 cannot connect to dynamic wep network dragoran
2007-10-23  8:14 ` [ipw3945-devel] " Zhu Yi
2007-10-23  8:56   ` dragoran
2007-10-23 14:07   ` Dan Williams
2007-10-23 17:37     ` Johannes Berg
2007-10-24 15:07       ` Dan Williams
2007-10-25 13:29         ` Johannes Berg
2007-10-25 13:49           ` Dan Williams
2007-10-25 13:57             ` Johannes Berg
2007-10-28  5:18               ` Dan Williams
2007-10-28 10:28                 ` Johannes Berg
2007-10-28 17:36                   ` Jouni Malinen
2007-10-28 17:54                     ` Johannes Berg
2007-10-28 18:49                       ` Jouni Malinen [this message]
2007-10-29 14:42                         ` Johannes Berg
2007-10-26 10:32           ` [PATCH] " dragoran
2007-10-26 10:43             ` Johannes Berg
2007-10-26 10:53               ` dragoran
2007-10-26 10:43           ` [PATCH] fix dynamic wep dragoran
2007-10-26 10:55             ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071028184959.GN4936@jm.kir.nu \
    --to=j@w1.fi \
    --cc=dcbw@redhat.com \
    --cc=drago01@gmail.com \
    --cc=ipw3945-devel@lists.sourceforge.net \
    --cc=johannes@sipsolutions.net \
    --cc=jt@hpl.hp.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=yi.zhu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).