Bug 379 - TLS, TTLS LEAP /NoWep doesn't work
: TLS, TTLS LEAP /NoWep doesn't work
Status: VERIFIED FIXED
: IPW2200
802.1x
: 0.13
: All All
: P1 major
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-11-15 08:24 by
Modified: 2005-10-03 15:00 (History)


Attachments
Debug information and ttls configuration (4.60 KB, application/x-gzip-compressed)
2004-11-15 08:27, Rafal Marszewski
Details
Logs from xsupplicant -d (17.13 KB, application/octet-stream)
2004-12-01 04:28, Rafal Marszewski
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-11-15 08:24:21
Steps to reproduce: 
Install Driver
Execute xsupplicant and verify using sniffer that Eapol-Start is sent by driver 
to Mcast EAP Port Access Entity (01:80:C2:00:00:03)
I have tested only with TLS, TTLS and LEAP.
------- Comment #1 From 2004-11-15 08:27:46 -------
Created an attachment (id=89) [details]
Debug information and ttls configuration

In attach. there are kernel debug, ttls_nowep script, xsupplicant log and debug
information from sniffer.
------- Comment #2 From 2004-11-15 08:58:19 -------
This situation happens just after inserting the wireless card, copy firmare to 
hotplug directory and load the driver. After restarting, the behaviour is 
different, but still .1x doesn't work. Now during or after exchanging the EAP-
frame driver is sending the disassociation to AP and the proccess .1x start 
again.
------- Comment #3 From 2004-11-18 05:59:04 -------
It doesn't work only when nowep is set on ap. Tested on Dlink an Cisco AP.
------- Comment #4 From 2004-11-29 07:21:16 -------
additional note: Rafal mentioned that the problem exists in WEP too.
------- Comment #5 From 2004-11-29 07:37:58 -------
Note from Rafal: I was this with xsupplicant version 1.0.
------- Comment #6 From 2004-11-29 07:40:02 -------
Note from scrub: Please execute at -d 8.

Log: 

logics	can you run it w/ xsupplicant at d 8?
logics	i see in the script you attached that you comment running at -d 8, but 
then execute at -d 4
logics	also, what version of xsupplicant, and does the same configuration 
work with the 2100?
logics	(i have some thoughts on what might be the cause, but want to rule out 
a couple other potentials as well)
cis	ok
cis	I will do with -d 8
cis	I was testing this with version from web (1.0)
logics	i know w/ xsupplicant tip (and possibly 1.0.1) i had to set the 
eapol_version explicitly in the .conf or my AP would fail the authentication, 
and the supplicant would then cut it down
cis	the same configuration works fine in ipw2100
cis	I only have problem when I use as forst_auth_command=dhclient ethx
logics	ok
cis	It just don't want to get IP address ;)
logics	-d 8 should provide the rest of the info needed to track it down then
------- Comment #7 From 2004-12-01 04:28:47 -------
Created an attachment (id=118) [details]
Logs from xsupplicant -d
------- Comment #8 From 2004-12-01 04:29:40 -------
The problem exists on driver 0.15 only with no wep. In attachm I have put the 
logs frm xsupplicant. I think that when I execute command iwconfig eth1 encr 
off, the destination mac address is changed to null (00:..:00). I have tested 
with the same steps in ipw2100 driver and problem doesn't appear. 
Steps to repro:
1. load driver and configure AP to EAP authentication without encryption
2 Execute command
  ifconfig ethx down
  iwconfig ethx essid Linux encryption off
  ifconfig ethx x.x.x.x netmask y.y.y.y up
3 execute xsupplicant
4 execute iwconfig ethx encr off
5. Verify that no IP address can be got after executing dhclient ethx
6. Verify in sniffer that some frames are sent with destination mac 00..00




 
------- Comment #9 From 2004-12-02 07:37:37 -------
09:37 < logics_sbux> ok... what appears to be happening is xsupplicant is
                     telling us to set the key at 0 length
09:37 < logics_sbux> the driver then disassociates because it thinks it is
                     being configured into Privacy mode (and its currently
                     associated w/out Privacy)
------- Comment #10 From 2005-01-12 10:42:42 -------
Upped to P1:Major so that we get it fixed so we support 802.1x for non-encrypted
authentication.
------- Comment #11 From 2005-01-15 13:50:32 -------
Modified behavior in 0.20 to match what ipw2100 does -- we will no longer force
a disassociation when we detect a change in security policy.

This has the side effect that if you are associated w/ a non-encrypted AP, and
configure encryption, it won't disassociate.  The user can either reload the
module, or temporarily change the ESSID to something else (to force a
disassociation)
------- Comment #12 From 2005-01-17 07:45:09 -------
I have retested this with 0.20 driver. Works ok, but after exchanging secuiruty 
data with Radius server, driver has null key. User must execute "iwconfig ethx 
encryption off".