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: <20061003231648.GB26351@thunk.org>
Date:	Tue, 3 Oct 2006 19:16:48 -0400
From:	Theodore Tso <tytso@....edu>
To:	"John W. Linville" <linville@...driver.com>
Cc:	Jeff Garzik <jeff@...zik.org>, jt@....hp.com,
	Linus Torvalds <torvalds@...l.org>,
	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, johannes@...solutions.net
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

On Tue, Oct 03, 2006 at 05:40:44PM -0400, John W. Linville wrote:
> Unfortunately, I don't see any way to "fix" WE-21 without similarly
> breaking wireless-tools 29 and other "WE-21 aware" apps.  And since
> I'll bet that the various WE-aware apps have checks like "if WE >
> 20" for managing ESSID length settings, we may have painted ourselves
> into a korner (sic).

OK, I'm going to ask a stupid question.  Why is the kernel<->wireless
driver interface have to be tied to the userspace<->wireless
interface?  The first is internal to the kernel and is free to change,
and if it breaks out-of-tree drivers, I'll complain to Intel about why
the !@#@ the ipw3945 driver hasn't been merged, but we've never made
any guarantees about break out-of-tree drivers, so I wouldn't have the
right to complain to anyone else.

The second is an external userspace ABI, and that should remain
constant.  It sounds like right now one gets pushed straight out to
the other, but what if the wireless infrastructure layer in the kernel
provided "interface glue" so you can translate between multiple
interface versions --- and then force the userspace (or at least new
versions of the userspace) to declare to the kernel what version of
the interface they are expecting?  

That's what we do with the stat system call.  Userspace tells the
kernel whether they want the v1, v2, v3, v4, or v5 version of the stat
structure, and we have interface glue to support all of the old versions.  

Is there some reason why this would be too hard to do with the current
interface?  Or is the arguement that if you're going to invest that
much energy in fixing the userspace interface code, you would rather
go to d80211/nl80211?

Regards,

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