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: <20061003233138.GA2095@bougret.hpl.hp.com>
Date:	Tue, 3 Oct 2006 16:31:38 -0700
From:	Jean Tourrilhes <jt@....hp.com>
To:	Theodore Tso <tytso@....edu>,
	"John W. Linville" <linville@...driver.com>,
	Jeff Garzik <jeff@...zik.org>,
	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 07:16:48PM -0400, Theodore Tso wrote:
> 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?

	They are not tied since WE-13. But you need a certain amount
of consistency, otherwise it's pure madness. If the driver does X
(no-NUL), but the userspace sees Y (mandatory NUL), then both driver
writer and application writer will go insane. You really want the API
to be as transparent as possible.

	But that's not the issue. The issue is that the userspace API
change was decided at the wireless summit last spring, and this was
something that most wireless people were very strongly advocating for,
including userspace people (Dan, Jouni). And most of it has already
been implemented.
	I think we can trust both Dan and Jouni to have a pretty good
idea of the impact of such changes. They are the one having to
implement it and dealing with the angry users.
	I've done many incompatible changes to the WE API over the
years, and it all went fine and dandy (anybody did notice those
changes ?). They key is to get userspace in place when you do the
kernel change.
	As I said, I was against that change, and I'm the one being
flamed.

> Is there some reason why this would be too hard to do with the current
> interface?

	It's already done with the current interface, you can access
the API with either ioctls or RtNetlink.

> 						- Ted

	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/