oepnssl vs. matrixssl

[Assaf Harel]

Hi,

matrixssl claim to have the basic functionality of openssl with tiny
footprint.
did anyone successfully ported hostapd / wpa_supplicant to work with
matrixssl ?

Thanks,
Assaf 

-----Original Message-----
From: hostap-bounces+assafh=mtlk.com at shmoo.com
[mailto:hostap-bounces+assafh=mtlk.com at shmoo.com] On Behalf Of Assaf
Harel
Sent: Tuesday, October 23, 2007 10:00
To: Jouni Malinen; hostap at shmoo.com
Subject: RE: Adding WPS support for hostapd / wpa_supplicant


Hi Jouni,  list,

I'm aware of other implementations, and read the thread with an engineer
from Atheros offering their implementation the same way we did.

Both Atheros and our implementation is based on an original open source
code that came from Intel.
Intel provided this code with very slight support to not at all.
After reviewing their code, and running it for few weeks we understood
that there are few things missing there.
The main issue that is missing is the implementation of AP Proxy.

Let me roll back for a minute trying to explain WPS in a bit more
details:
WPS entities are "enrollee" (can be either AP or Station) and
"registrar" (can be either Station, AP or wired registrar (through upnp)
connected directly to the AP - currently only Microsoft Vista implements
this role).
If the station acts as an enrollee and the AP as a registrar we have a
very simple case of EAPOL transactions (of ~12 messages) of the new
EAPOL method EAP_WSC. At the end the station will know how to work with
the AP (i.e. SSID, WPA mode, keys, etc). This is straight forward.

The plot thickens when the Registrar is external, i.e. either Wired
(Vista) or Wireless (i.e. on another station, yes WPS allows this,
thinking of a case where you're registrar is on your laptop, handheld,
cell phone, or even wireless IPTV in the future). In this case the AP
has to act as proxy and to forward messages between enrollee and
registrar. The problem is that Intel never implemented this feature
seriously. They did some "quick and dirty" proxy by simply forwarding
messages from the wired interface to the wireless one and vise versa.
This doesn't take care of the case of a wireless registrar, or the case
of multiple registrars (the standard requires the support of more the
one registrar through the same AP).

This implementation is the main contribution Metalink has to add over
Intel's original patch to hostapd / wpa_supplicant. I believe that this
would be Atheros main contribution as well, and I believe they differ.
We can wait for our and their submission, before considering each one
(we don't mind adopting to Atheros solution if it is superior to ours,
but I fear that this may not be the case - we saw Atheros device in
action since it's a part of the WiFi WPS certification testbed).

Please instruct me how you would like to proceed.

Regards,
Assaf 

-----Original Message-----
From: hostap-bounces+assafh=mtlk.com at shmoo.com
[mailto:hostap-bounces+assafh=mtlk.com at shmoo.com] On Behalf Of Jouni
Malinen
Sent: Tuesday, October 23, 2007 04:31
To: hostap at shmoo.com
Subject: Re: Adding WPS support for hostapd / wpa_supplicant

On Mon, Oct 22, 2007 at 02:41:28PM +0200, Assaf Harel wrote:

> My team worked on WPS application over the past 3 months. We passed 
> WiFi certification recently, and would like to contribute this WPS 
> application, which is used internally and by customers.

> We had to modify Intel's sources a lot in order to pass WiFi 
> certification (both the hostapd / wpa_supplicant patch, and wsccmd 
> itself). We would like to contribute these sources to hostap project 
> (under the same dual-GPL/BSD license of course).
> 
> What should we take into consideration?

There are other WPS implementations for hostapd/wpa_supplicant and at
least one is currently in process of getting integrated into hostapd. It
would be useful to understand whether there are any larger differences
in the designs for these implementations and whether there are any
particular benefits in them to figure out what kind of combination would
be the best fit for hostapd/wpa_supplicant.

> Intel patches are based on version 0.4.8, and we upgraded it to 
> 0.4.10, would it be acceptable or should we port to 0.5.x / 0.6.x ?

No new features will be added to the 0.4.x branch and I would rather not
add any larger changes to 0.5.x either at least not before they have
been introduced and tested in the current development branch (0.6.x). I
would assume that seeing the changes based on older versions would be
useful from the view point of being able to review the design, but the
changes will need to be ported to 0.6.x before they can be included.

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
HostAP mailing list
HostAP at shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

-- Disclaimer: --
This e-mail is intended solely for the person to whom it is addressed
and may contain confidential or legally privileged information. Access
to this e-mail by anyone else is unauthorized. If an addressing or
transmission error has misdirected this e-mail, please notify the author
by replying to this e-mail and destroy this e-mail and any attachments. 
E-mail may be susceptible to data corruption, interception, unauthorized
amendment, viruses and delays or the consequences thereof. If you are
not the intended recipient, be advised that you have received this email
in error and that any use, dissemination, forwarding, printing or
copying of this email is strictly prohibited.
_______________________________________________
HostAP mailing list
HostAP at shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

-- Disclaimer: --
This e-mail is intended solely for the person to whom it is addressed and may contain confidential or legally privileged information. Access to this e-mail by anyone else is unauthorized. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and destroy this e-mail and any attachments. 
E-mail may be susceptible to data corruption, interception, unauthorized amendment, viruses and delays or the consequences thereof. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited.