linux-kernel - Re: wpa supplicant/ipw3945, ESSID last char missing

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: <20061003180543.GD23912@tuxdriver.com>
Date:	Tue, 3 Oct 2006 14:05:50 -0400
From:	"John W. Linville" <linville@...driver.com>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Lee Revell <rlrevell@...-job.com>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Norbert Preining <preining@...ic.at>, hostap@...oo.com,
	ipw3945-devel@...ts.sourceforge.net, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	johannes@...solutions.net, jt@....hp.com
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

On Tue, Oct 03, 2006 at 09:27:34AM -0700, Linus Torvalds wrote:

> We don't do this version skew dance. If we need to break something, it had 
> better be some damn substantial reasons, and even then we're generally 
> better off supporting _both_ interfaces for a while (perhaps using a 
> version code), and then marking the old one deprecated.

FWIW, this clean-up is not intended to break older binaries.
It is intended to standardize driver implementations of the WE API.
Breakage is (merely!) a side-effect...

The overall purpose of the WE-21 patch was to continue disambiguating
how drivers implement the WE API.  This is intended to (hopefully)
avoid strange, hidden bugs lurking out there in driver/tool
interaction, especially for tools other than wireless-tools
(e.g. NetworkManager, wpa_supplicant, etc).  In this case, it looks
like maybe some older versions of these tools were effectively
exploting the strange, hidden bugs... :-(

It seems there were a few genuine bugs which crept into the WE-21
implementation.  Jean has posted fixes for those today.  It looks
like those patches get things working again when combined with
updated tools.

Today's news seems to indicate that at least the major distros are
already shipping the updated tools, or on the verge of shipping them.
The window of breakage for most users looks like it will be fairly
small, no matter what action taken.

The more we can clean-up the WE API, the easier it will be to implement
the cfg80211 WE compatibility layer intended for wireless-dev.
I think WE-21 makes things better in that respect.

Finally, I already scaled-back Jean's original WE-21 patch.  I only
anticipate minor bug fixes for WE from now on, with nl80211/cfg80211
as the heir-apparent.

With all that said, I'd prefer to keep the existing WE-21 patches and
add Jean's fixes ASAP.  Is this acceptable?  If not, I'll submit the
reversions to Jeff ASAP.

Suggestions?

John
-- 
John W. Linville
linville@...driver.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/