Yep..<br>Sorry Peter, Anish.<br><br>So, as far as the current patch is concerned, this patch should be tested WITHOUT thinking about the WPA-Enterprise Networks scenario.<br><br><br><br>That should bring us back on the track (for this particular patch) :P<br>
<br><br>Regards,<br>Ajay<br><br><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 8:31 PM, Anish Mangal <span dir="ltr"><<a href="mailto:anish@activitycentral.com" target="_blank">anish@activitycentral.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not to take the discussion in a different direction, but IMO, would be<br>
great if Enterprise network support made it to upstream sugar. :-)<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jun 25, 2012 at 8:22 PM, Ajay Garg <<a href="mailto:ajay@activitycentral.com">ajay@activitycentral.com</a>> wrote:<br>
> Peter,<br>
><br>
> Is WPA-Enterprise Networks supported in Sugar 0.96, yet? (I don't think it<br>
> is).<br>
> As a result, the current patch has not been tested with WPA Enterprise<br>
> Networks.<br>
><br>
> There is a patch for WPA-Enterprise Networks (fully integrated in dextrose3)<br>
> available at<br>
> <a href="http://patchwork.sugarlabs.org/patch/1096/" target="_blank">http://patchwork.sugarlabs.org/patch/1096/</a><br>
><br>
> with specs at<br>
> <a href="http://wiki.sugarlabs.org/go/Features/WPA-WPA2-Enterprise-Network-Connections" target="_blank">http://wiki.sugarlabs.org/go/Features/WPA-WPA2-Enterprise-Network-Connections</a><br>
><br>
> Would upstream be interested :P :P (I would be more than willing to port<br>
> it).<br>
><br>
><br>
><br>
> Adding Anish in the loop.<br>
><br>
><br>
> Regards,<br>
> Ajay<br>
><br>
><br>
><br>
><br>
> On Mon, Jun 25, 2012 at 8:07 PM, Peter Robinson <<a href="mailto:pbrobinson@gmail.com">pbrobinson@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Sun, Jun 24, 2012 at 12:00 PM, Ajay Garg <<a href="mailto:ajay@activitycentral.com">ajay@activitycentral.com</a>><br>
>> wrote:<br>
>> ><br>
>> > NM may request the secrets in the following cases ::<br>
>> ><br>
>> > a)<br>
>> > Wifi connection is lost.<br>
>> ><br>
>> > b)<br>
>> > After being lost, the wifi connection is again within the range.<br>
>> ><br>
>> > c)<br>
>> > When the credentials for the wifi network change.<br>
>> ><br>
>> ><br>
>> > In every case, secrets were being requested via the popup dialog.<br>
>> ><br>
>> > However, case c) is rare (and when it does happens, usually the<br>
>> > system-administrator, or the like,<br>
>> > has the responsibility for issuing the changes publically).<br>
>> ><br>
>> > Thus, due to case c) (which is rare), cases a) and b) were suffering<br>
>> > (these cases are generally<br>
>> > very plausible cases in everyday life).<br>
>> ><br>
>> ><br>
>> > So now, the intended solution is :::<br>
>> ><br>
>> ><br>
>> > 1.<br>
>> > Always return the cached secrets (present in 'settings' themselves).<br>
>> > This would make the irritating dialog-box go away, for cases a) and b).<br>
>> ><br>
>> ><br>
>> > 2.<br>
>> > For case c), the user would ::<br>
>> ><br>
>> >    (i)   "Discard Network History".<br>
>> >    (ii)  Click on the wifi icon (in the neighborhood-view).<br>
>> >    (iii) Enter the new (publically broadcasted) credentials.<br>
>><br>
>> This biggest time for C is when it's WPA-Enterprise and the enterprise<br>
>> user authenication has a lifetime on the password. Our corp wifi is AD<br>
>> authenticated and the password expires every 60 days.<br>
>><br>
>> Peter<br>
><br>
><br>
</div></div></blockquote></div><br>