Lakshminath,
The devil is in the details.
As I see it EAP doesn't provide a way for an 802.11 supplicant to
know it's authenticator's ID.
I'd like to be proven wrong, but I am skeptical of claims based on assumptions.
Dave.
On 10/4/2006 07:36 PM, Lakshminath Dondeti wrote:
Hi Dave
I haven't had time to join this discussion prior to this, but
I'll just pick this response out of the stream and make a comment or two:
On 11/21/2006 11:50 AM, Madjid Nakhjiri wrote:
Hi Yoshi,
I don't quite agree with this. Defining the full functionality of a new EAP
method (including how it s
I'm sorry, I haven't responded earlier either, but I would like to pile on with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale.
Encoding the "REQ=" and "RESP=" int
Earlier, I felt like asking if there were any independently developed implementations of EAP-FAST, now I see one.
And we see what gets discovered when you attempt interoperabilty testing with real running code.Dave.Feb 11, 2009 05:13:19 PM, j...@w1.fi wrote:
On Wed, Feb 11, 2009 at 01:29:34PM -08
On Aug 14, 2009, Alan DeKok wrote:
...
> I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but
> possible.
In many ways that's what PANA is about, but that's not what spurred me to
respond.
> The main limitation on bulk data transfer is that most EAP to
> RADIUS gateways (
On 8/16/2009 04:30 AM, Alan DeKok wrote:
David Mitton wrote:
>> The main limitation on bulk data transfer is that most EAP to
>> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50
>> packets.
>
> This kind of thing drives me crazy. Why are their
Over the previous year, I was the Project Leader for a Windows Vista
implementation of the RSA SecurID OTP EAP methods (15 & 32 - Protected OTP).
During this project we had a number of setbacks, and I achieved a new
enlightenment about where some long suffering problems with our user
intera
