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]

Date:	Mon, 2 Oct 2006 12:59:21 -0700
From:	Jean Tourrilhes <jt@....hp.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Andrew Morton <akpm@...l.org>,
	"John W. Linville" <linville@...driver.com>,
	Norbert Preining <preining@...ic.at>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	hostap@...oo.com, linux-kernel@...r.kernel.org,
	ipw3945-devel@...ts.sourceforge.net
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

On Mon, Oct 02, 2006 at 03:22:03PM -0400, Dan Williams wrote:
> 
> Right; we need to get this settled and we need to figure out a way with
> Wireless Extensions to allow exact SSIDs to be sent and retrieved from
> the card/driver.  How much cruft do we add to drivers and/or WE bits to
> bend over backwards and preserve compatibility with a lot of older bits?
> I can think of a few ways here to preserve backwards compat, but most
> involve adding bits to 3 places in each driver and a new flag to WE,
> which puts us right back in the same situation we're in right now;
> inconsistent drivers and poor semantics both inside and outside the
> kernel.

	There is no way old tools are going to set/process those extra
flags, so it does not work. And this won't fix out-of-tree drivers...

> Maybe the answer here _is_ to bend over backwards to preserve
> compatibility, restore null-termination-and-increment-length bits in
> drivers and WE, and kludge all the user-space tools.

	Let's not throw the baby with the bathwater.
	This is *not* the first time I've done such incompatible
change in WE (size in set, pointer in scan, remove pointer in
events). The other time, it went completely under the radar, you guys
did not noticed anything (apart Jouni).
	The difference is that this time I attempted to do it a bit
quicker than usual. Maybe I was too fast this time. But I've noticed
that some distro have become slower to pick up changes than in the
past, which is frustrating me.
	To me, the solution is just to let a bit more time for the
userspace to propagate to the distro. And to educate users to pay
attention to the incompatibility warnings displayed by the tools.

> Dan

	Have fun...

	Jean
-
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/