lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5220.1268430568@localhost>
Date:	Fri, 12 Mar 2010 16:49:28 -0500
From:	Valdis.Kletnieks@...edu
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: Weird wireless/wpa_supplicant screw-up.

On Fri, 12 Mar 2010 03:14:41 PST, Johannes Berg said:
> On Mon, 2010-03-08 at 17:22 -0500, Valdis.Kletnieks@...edu wrote:
> > (This could be user error/userspace bug, feel free to point me in the right
> > direction if you think so.  Hopefully somebody knows what I've broken this
> > time...)
> > 
> > Fedora Rawhide as of this morning, 2.6.33-mmotm0304 kernel, wpa_supplicant-0.6.8-8.fc13.x86_64
> > wireless-tools-29-5.1.fc12.x86_64.  Dell Latitude E6500, Intel 5100AGN card.
> > 
> > So I finally get a few spare cycles, and re-try getting WPA2 working on our
> > enterprise wireless network, and wpa_supplicant reports it completed
> > successfully and set the keys,
> 
> and does it work? The iwlist stuff could just be a reporting error...

OK, getting closer ;)

in net/wireless/wext-compat.c, we have this in cfg80211_wext_giwencode()
after I add some printk's:

printk(KERN_INFO "In giwencode idx=%d keys=%x cipher=%x\n", idx, wdev->wext.keys, wdev->wext.keys->params[idx].cipher);
        if (!wdev->wext.keys || !wdev->wext.keys->params[idx].cipher) {
printk(KERN_INFO "And we're going home...\n");
                erq->flags |= IW_ENCODE_DISABLED;
                erq->length = 0;
                return 0;
        }

which produces

[  151.401195] In giwencode idx=0 keys=1d023600 cipher=0
[  151.401198] And we're going home...

So the root cause has something to do with params[idx].cipher being unset.

I've become reasonably sure it's not pilot error on my part, as a co-worker's
laptop has the same issue - mine is a Dell Latitude E6500 with an Intel 5000agn
cardrunning Fedora Rawhide and a 2.6.34-rc1-mmotm kernel, and his is a Latitude
D830 with an Intel 3945, Ubuntu with a 2.6.32 kernel.

Looks like time to instrument more of wext-compat.c.  Oh joy.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ