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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 04 Jun 2007 21:41:47 +0900
From:	MOKUNO Masakazu <>
To:	Dan Williams <>
Cc:, Geoff Levand <>,
	Geert Uytterhoeven <>
Subject: Re: [PATCH 2/2] ps3: add wireless LAN support


Thank you for your comments!

It seems to be pretty preferable we make the driver wpa_supplicant
compatible, I'll plan to rework and resubmit the patch (to

On Fri, 01 Jun 2007 12:35:49 -0400
Dan Williams <> wrote:
> There are a few basic
> issues, rehashed here:
> 1) Need endian annotations and conversions.

OK, I'll fix. 

> 2) How much WPA does the device really support?  If it only supports
> WPA[2]-PSK, I guess that's OK, but the driver _MUST_ return the WPA and
> RSN information elements from each BSS that provides them using the
> IWEVGENIE tag from the get scan handler.  A hack might be to construct a
> suitable synthetic IE depending on the contents of the 'security' field
> the firmware passes back.  But userspace needs to know that a particular
> BSS supports WPA in a standard manner.

It supports WEP and WPA[2]-PSKs(TKIP and AES) only. 

I'll consider incorporating wpa_supplicant stuff, ie to support IWEVGENIE

> 3) Should remove the WPA passphrase bits from the encode functions,
> these functions should operate only on raw key material.  Userspace
> tools do the hashing.

The hypervisor (firmware) has functionality of hashing WPA passphrase. 
So the driver code just passes it to hypervisor.  With that feature, end
users can easily set their passphase.  I thought it was convenient.
Anyway I can remove it to delegate to user space.

> 4) I'd like an explanation of the scanning behavior too, looks fishy.

Well, it basically start to scan as requested.  But since scanning is
time consuming job and it seems to block normal messages, rate control
code you mentioned was inserted.
Background scan is performed for roaming as you thought.

> 5) Should be using a list of scanned BSSs, should be aging and culling
> them, instead of a static array.


> 6) The private ioctl needs to die.

These private ioctls were made so that we can setup the driver simply
with wireless-tools, like the answer to 3) above.
Anyway I'll try to incorporate wpa_supplicant support.

> 7) Does the device work with wpa_supplicant's 'wext' driver?

I don't think it works with wext of wpa_supplicant, although I didn't test
it with wpa_supplicant well.

Masakazu MOKUNO

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists