Hello. On Fri, 2007-01-26 at 23:57, Volker Braun wrote: > > Here is a patch against 0.6.4 to configure the most common phase2 > options. Almost all of it was written by Stefan Schmidt <stefan at > datenfreihafen.org>, i just fixed some remaining bugs: > > http://carrot.hep.upenn.edu/~vbraun/phase2.patch Great. Thanks a _lot_. That's why I love OSS. Somebody else jumps in and finished my work. :) Thanks again. I'll test this on monday. Our usual dynamic wep-key + EAP/TLS setup and the new WPA[1,2] + EAP/TLS setup. The second one should be the default setup for eduroam, so perhaphs other students or university memebers could be interested in it. http://www.eduroam.org/ > Now I know that adding another option to the WPA Enterprise dialog is > not going to yield any praises, but on the other hand side it makes it > useful for me (Dynamic WEP + phase2 PAP). I know that the whole > dialog has to become smarter, but some phase2 options ought to > stay. Dan, Robert, how are the chances to get this included into 0.6.5? I know aou don't like to add more stuff to the dialogs, but it would enable some more people to use nm instead of falling back to wpa_supplicant only for some special networks. Of course we need a better solution for 0.7. > ==== 1) WPA Enterprise passwords not saved to keyring ==== > > There are two "secrets" in the WPA Enterprise dialog: The password and > the passphrase for the private key. Only the latter is stored in the > gnome-keyring. > > Whats really broken is, of course, the dialog: you either have a > password or a private key. A dirty hack would be to at least store the > password in the gnome-keyring and disable the private key > passphrase (who uses that? %-) for now. I know setups where the certs and private keys are used. Anyway I think passphrase for key and password are mutal exclusive. Somebody knows a setup where both are used? But I see no reason why we are not able to store both in the keyring. > The "WPAx Enterprise" should allow for the EAP types that are included > in the wifi certification, they are bound to show up in actual > installations. So the "EAP Method" combobox should be > > EAP-TLS > EAP-TTLS/MSCHAPv2 > PEAPv0/EAP-MSCHAPv2 > PEAPv1/EAP-GTC > EAP-SIM > EAP-LEAP > > When choosing "EAP-TTLS/MSCHAPv2", for example, then automatically > phase2="auth=MSCHAPv2" is passed, and no extra phase2 box is > needed. Likewise, only the authentification that makes sense for the > given EAP type appears in the dialog. So if one selects "EAP-TLS" the > remaining dialog asks for the private certificate, whereas if one > selects "EAP-TTLS/MSCHAPv2" then the remaining dialog is > anon_identity, identity, password only. I like this idea. > The ca_cert and ca2_cert is automatically set to be the usual root > certificate (which ought to be already in the distro > somewhere, FC6: /etc/pki/tls/cert.pem). Distro packages depend on this > file (FC6: depends already on openssl which owns the cert.pem). I even like this one, but how we like to hanlde this? Add this to the distro backend or should distros care with own patches for it? regards Stefan Schmidt
Attachment:
signature.asc
Description: Digital signature