Re: IAS WPS Extension DLL With EAP-TLV URI AVP Using Guest Authentication

Hi Eliot,
Yes this is there from a long time.
The great difference is that on MS C/C++ Compiler, the bit order is from the
low order bits to the high order bits. On traditonal C language this is from
high order to the low order, as you can found in the famous book "Practical
C" writed by Steve Oualline (O'Reilly & Associates, Inc - July 1991/January
1993/August 1997 - Three Editions at all.)

By the the way, the raatMinimum is an attribute from
RAS_AUTH_ATTRIBUTE_TYPE and this is territory of EAP interface.
I don't know how to by-pass the flow process to indicate to IAS that I have
two attributes on one unique insert operation. Perhaps indicating to
cbDatalength one value that is the sum of the two attributes. I hope that
you have success, and report me please. I will report to you any progress on
my fight results.

Washington Moreira

"Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
news:xcCdnX0Q_vSzSxDenZ2dnUVZ_tKdnZ2d@xxxxxxxxxxxxxx
> Thanks! I had no idea you could do that. That is a big help! Has this
> construct been in C/C++ for a long time? I haven't programmed much in
> C/C++ for over 5 years. Did it come out in the past 5 years, or was it in
> there before that?
>
> So, yes, the struct you posted in
> microsoft.public.win32.programmer.network s looks correct based on this
> new information.
>
> "Washington Moreira" <digisystem@xxxxxxxxxxxxxxxx> wrote in message
> news:egNkWSc9FHA.2176@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi Eliot,
>> Please check this link for C:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/decla_17.asp
>>
>> And other for C++ but the MS C compiler understand in the same way:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_c.2b2b_.bit_fields.asp
>>
>> Thanks
>>
>> Washington Moreira
>>
>>
>> "Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
>> news:3N-dndTszq2BXxDeRVn-ow@xxxxxxxxxxxxxx
>>> Ok, as near as I can tell, there is no BINARY data type in Microsoft's
>>> implementation of C. So, that means we need a USHORT for the first field
>>> in the packet, followed by two UCHARs. In the Result packets, there
>>> should be three USHORTs instead of one UCHAR and two USHORTs.
>>>
>>> Unfortunately, I won't be able to test the new packet structure until
>>> tomorrow. But, I surmise that we will still get the same error, as I do
>>> not believe the error code 87 has anything to do with the structure of
>>> the data (but I could be wrong on this point).
>>>
>>> Also, on my way home yesterday, I made a realization: the documents I've
>>> read state that the EAP attributes are in an array terminated by a
>>> raatMinimum entry. That means, if we want to add one value, we actually
>>> need to add two. The first one is an EAP-TLV URI entry and the second is
>>> a raatMinimum entry to denote the end of the array. Therefore, my code
>>> should actually malloc enough space for the EAP-TLV URI with the URL in
>>> it plus enough space for a raatMinimum entry to terminate the array. It
>>> should all be one contiguous block of memory and the lpValue should
>>> point to the beginning of that block of allocated memory.
>>>
>>> This is all assuming I have correctly understood what I've read. The
>>> documents are not very specific and don't offer any examples.
>>>
>>>
>>> "Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
>>> news:F66dnfaCcvFqKRDeRVn-jg@xxxxxxxxxxxxxx
>>>> You're right; we're both loosing our minds. That should be a u16 for
>>>> the first one. Although, the second two, according to the WPS
>>>> Deployment document, should be UCHAR data types. Now, it actually
>>>> specifies BINARY data type for the first 3, but I don't know how it
>>>> would know what the length of the BINARY value is in binary digits if
>>>> we just put a binary number in it. Also, I do not know if this is even
>>>> a valid type in C for Microsoft. I am trying to find that out right
>>>> now. But it certainly isn't a type in ISO C. It may be implemented as a
>>>> class in C++, but I'm not that familiar with Windows programming, so
>>>> I'm kind of learning the Windows specific stuff as I go.
>>>>
>>>> "Washington Moreira" <digisystem@xxxxxxxxxxxxxxxx> wrote in message
>>>> news:uvUahkW9FHA.3760@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Very thanks Eliot.
>>>>> Thanks for your comments about my struct. I'm 54 years old and
>>>>> sometimes my mind fails, and for many years I have not used one packet
>>>>> structure. My wrong packed struct would be correct for an old 16 bit
>>>>> environment.
>>>>> Excuse-me if I'm an idiot asking about your struct layout:
>>>>> I need 16 bits to define the first three fields, but you are using an
>>>>> UCHAR data type encompassing these 16 bits. Is this correct?
>>>>>
>>>>> Please look below to these few code lines writed for an Unix Like
>>>>> environment (from
>>>>> http://hostap.epitest.fi/wpa_supplicant/devel/eap__tlv_8h.html)( from
>>>>> header file):
>>>>>
>>>>> 00048 struct eap_tlv_result_tlv {
>>>>> 00049 u16 tlv_type;
>>>>> 00050 u16 length;
>>>>> 00051 u16 status;
>>>>> 00052 } __attribute__((packed));
>>>>>
>>>>> And from C source file (from
>>>>> http://hostap.epitest.fi/wpa_supplicant/devel/eap__tlv_8c.html) Note
>>>>> that the function below constructs the complete EAP response including
>>>>> the TLV packet:
>>>>>
>>>>> 00058 u8 * eap_tlv_build_result(int id, u16 status, size_t *resp_len)
>>>>> 00059 {
>>>>> 00060 struct eap_hdr *hdr;
>>>>> 00061 u8 *pos;
>>>>> 00062
>>>>> 00063 *resp_len = sizeof(struct eap_hdr) + 1 + 6;
>>>>> 00064 hdr = malloc(*resp_len);00065 if (hdr == NULL)
>>>>> 00066 return NULL;
>>>>> 00067
>>>>> 00068 hdr->code = EAP_CODE_RESPONSE;
>>>>> 00069 hdr->identifier = id;
>>>>> 00070 hdr->length = host_to_be16(*resp_len);
>>>>> 00071 pos = (u8 *) (hdr + 1);
>>>>> 00072 *pos++ = EAP_TYPE_TLV;
>>>>> 00073 *pos++ = 0x80; /* Mandatory */
>>>>> 00074 *pos++ = EAP_TLV_RESULT_TLV;
>>>>> 00075 /* Length */
>>>>> 00076 *pos++ = 0;
>>>>> 00077 *pos++ = 2;
>>>>> 00078 /* Status */
>>>>> 00079 WPA_PUT_BE16(pos, status);
>>>>> 00080
>>>>> 00081 return (u8 *) hdr;
>>>>> 00082 }
>>>>>
>>>>>
>>>>> If I'm not wrong, looking above, there is two bytes for the first
>>>>> three fields(not declared in this way), more two bytes to define the
>>>>> length of the value. In this case the status is a two bytes value.
>>>>>
>>>>> If 16 bits is correct to define the first three fields, rewriting my
>>>>> packed struct woul be:
>>>>>
>>>>> typedef struct _PEAPTLV_URI{
>>>>> WORD TLVType :
>>>>> 14; //bit fields from position 0 - 13
>>>>> WORD TLVReserved : 1;
>>>>> //bit field position 14
>>>>> WORD TLVMandatory : 1; //bit
>>>>> field position 15 closing the first two bytes
>>>>> UCHAR TLVValueLength; //Here
>>>>> the big doubt, IETF docs ponts this as a 16 bits
>>>>> UCHAR TLVValue[UNLEN];
>>>>> }PEAPTLV_URI, *pPEAPTLV_URI;
>>>>>
>>>>> (note the bit fields declared from right (low order) to the left (high
>>>>> order) In this way I don't need to use bitwise operators.
>>>>>
>>>>> Please I'm waiting your comments. Perhaps, exchanging our tests and
>>>>> informations we can solve our problems.
>>>>>
>>>>> Thanks
>>>>> Washington Moreira
>>>>>
>>>>>
>>>>>
>>>>> "Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
>>>>> news:1133306452_43599@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>> This is what I have based on the WPS Deployment documentation on the
>>>>>> structure of the EAP packets:
>>>>>>
>>>>>> #define EAP_TLV_RESULT_TLV 3 /* Acknowledged Result */
>>>>>> #define EAP_TLV_NAK_TLV 4
>>>>>> #define EAP_TLV_CRYPTO_BINDING_TLV 5
>>>>>> #define EAP_TLV_CONNECTION_BINDING_TLV 6
>>>>>> #define EAP_TLV_VENDOR_SPECIFIC_TLV 7
>>>>>> #define EAP_TLV_URI_TLV 8
>>>>>> #define EAP_TLV_EAP_PAYLOAD_TLV 9
>>>>>> #define EAP_TLV_INTERMEDIATE_RESULT_TLV 10
>>>>>> #define EAP_TLV_PAC_TLV 11 /* draft-cam-winget-eap-fast-01.txt */
>>>>>> #define EAP_TLV_CRYPTO_BINDING_TLV_ 12 /*
>>>>>> draft-cam-winget-eap-fast-01.txt */
>>>>>>
>>>>>> #define EAP_TLV_RESULT_SUCCESS 1
>>>>>> #define EAP_TLV_RESULT_FAILURE 2
>>>>>>
>>>>>> #define EAP_TLV_TYPE_MANDATORY 0x80
>>>>>> #define EAP_TLV_TYPE_ACK_RESULT 0x03
>>>>>>
>>>>>>
>>>>>> typedef struct eap_tlv_uri_packet {
>>>>>> UCHAR TLVType; /* Bit 1: Mandatory Requirement */
>>>>>> /* Bit 2: TLVReserved */
>>>>>> /* Bit 3-16: TLVType */
>>>>>> UCHAR TLVValueLength;
>>>>>> UCHAR TLVValue;
>>>>>> } EAPTLVURIPACKET;
>>>>>>
>>>>>> typedef struct eap_tlv_result_packet {
>>>>>> UCHAR TLVPacketType; /* Bit 1: Mandatory Requirement */
>>>>>> /* Bit 2: TLVReserved */
>>>>>> /* Bit 3-16: TLVPacketType */
>>>>>> USHORT TLVStatusLength;
>>>>>> USHORT TLVStatus;
>>>>>> } EAPTLVRESULTPACKET;
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> In my actual code block that adds the EAP-TLV URI, I have this:
>>>>>>
>>>>>>
>>>>>> ucTLVValueLength = (UCHAR) strlen(url);
>>>>>> cbDataLength = sizeof(EAPTLVURIPACKET) + (sizeof(UCHAR) *
>>>>>> ucTLVValueLength) + 1;
>>>>>> sprintf(mesg, "About to malloc %d bytes for EAPTLV Packet.\n",
>>>>>> cbDataLength);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> euEAPTLV = RadiusAlloc(cbDataLength);
>>>>>> sprintf(mesg, "Finished malloc.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> euEAPTLV->TLVType = EAP_TLV_URI_TLV;
>>>>>> euEAPTLV->TLVValueLength = ucTLVValueLength;
>>>>>> sprintf(mesg, "About to copy %d bytes data into TLVValue location at
>>>>>> %X.\n", strlen(url), &euEAPTLV->TLVValue);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> strcpy(&euEAPTLV->TLVValue, url);
>>>>>> sprintf(mesg, "Done copying.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> cbDataLength = strlen((const char*)euEAPTLV);
>>>>>> sprintf(mesg, "Length of EAP TLV Packet: %d.\n", cbDataLength);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>>
>>>>>> /* Fill in the RADIUS_ATTRIBUTE struct. */
>>>>>> /*cbDataLength = strlen(url);*/
>>>>>> raEAPTLV.dwAttrType = ratEAPTLV;
>>>>>> raEAPTLV.fDataType = rdtUnknown;
>>>>>> raEAPTLV.cbDataLength = cbDataLength;
>>>>>> raEAPTLV.lpValue = (PCSTR) euEAPTLV;
>>>>>>
>>>>>> /* Add as the ratPEAPTLV URI TLV. */
>>>>>> sprintf(mesg, "Replacing first attribute of ratEAPTLV.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> dwResult = RadiusReplaceFirstAttribute(pInRespAttrs, &raEAPTLV);
>>>>>>
>>>>>>
>>>>>>
>>>>>> Then, in RadiusReplaceFirstAttribute:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> DWORD
>>>>>> WINAPI
>>>>>> RadiusReplaceFirstAttribute(
>>>>>> PRADIUS_ATTRIBUTE_ARRAY pAttrs,
>>>>>> const RADIUS_ATTRIBUTE* pSrc
>>>>>> )
>>>>>> {
>>>>>> DWORD dwIndex, dwResult;
>>>>>> char mesg[255];
>>>>>> bzero(mesg, 255);
>>>>>>
>>>>>> if ((pAttrs == NULL) || (pSrc == NULL))
>>>>>> {
>>>>>> return ERROR_INVALID_PARAMETER;
>>>>>> }
>>>>>>
>>>>>> dwIndex = RadiusFindFirstIndex(pAttrs, pSrc->dwAttrType);
>>>>>>
>>>>>> if (dwIndex != RADIUS_ATTR_NOT_FOUND)
>>>>>> {
>>>>>> sprintf(mesg, "Attribute found at index %d.\n", dwIndex);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> /* It already exists, so overwrite the existing attribute. */
>>>>>> dwResult = pAttrs->SetAt(pAttrs, dwIndex, pSrc);
>>>>>> } else {
>>>>>> sprintf(mesg, "Attribute not found (%d). Adding one (pAttrs := %X;
>>>>>> pSrc := %X).\n", dwIndex, pAttrs, pSrc);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> /* It doesn't exist, so add it to the end of the array. */
>>>>>> dwIndex = pAttrs->GetSize(pAttrs) - 1;
>>>>>> dwResult = pAttrs->InsertAt(pAttrs, dwIndex, pSrc);
>>>>>> }
>>>>>>
>>>>>> if(dwResult == E_ACCESSDENIED) {
>>>>>> sprintf(mesg, "Access denied while replacing attribute.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> }
>>>>>> if(dwResult == ERROR_INVALID_PARAMETER) {
>>>>>> sprintf(mesg, "Invalid parameter while replacing attribute: index
>>>>>> out of range.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> }
>>>>>> if(dwResult == NO_ERROR) {
>>>>>> sprintf(mesg, "Success. Attribute replaced or added.\n");
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>> }
>>>>>> sprintf(mesg, "Done replacing attribute. Returning with result:
>>>>>> %d.\n", dwResult);
>>>>>> Debug(mesg);
>>>>>> bzero(mesg, 255);
>>>>>>
>>>>>> return dwResult;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Of course, when I try to add the parameter, I get the error 87
>>>>>> (ERROR_INVALID_PARAMETER). I do not get an error in IASSAM.log.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Washington Moreira" <digisystem@xxxxxxxxxxxxxxxx> wrote in message
>>>>>> news:OlChE9S9FHA.952@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> Hi Eliot,
>>>>>>
>>>>>> First, thank you for your post on my previous thread. At least I'm
>>>>>> not alone with this problem.
>>>>>>
>>>>>> Looking for my rastls.log I think that my big problem is the EAPTLV
>>>>>> URI struct format that I have created based on docs from the
>>>>>> WPSDeploy.doc and WPS Protocol description on MSDN (
>>>>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/peap-tlv_packets.asp )
>>>>>> As I have explaned in other posts, from WPS Protocol description we
>>>>>> have:
>>>>>>
>>>>>> PEAP-TLV URI Packet
>>>>>> Fields
>>>>>>
>>>>>> MandatoryRequirement Type Binary(1 bit) Mandatory TLV set to 1
>>>>>> TLVReserved Type Binary(1 bit) set to 0
>>>>>> TLVType Type Binary(14 bits) set to 8
>>>>>> TLVValueLength Type UCHAR Length of TLVValue field
>>>>>> TLVValue Type UCHAR URI to a master document
>>>>>>
>>>>>> From these infromations above we can create a packet struct. But look
>>>>>> now to the informations from
>>>>>> draft-josefsson-pppext-eap-tls-eap-10.txt (15 October 2004)
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> 4.8. URI TLV
>>>>>>
>>>>>> The URI TLV allows a server to send a URI to the client to refer it
>>>>>> to a resource. The TLV contains a URI in the format specified in
>>>>>> RFC2396 with UTF-8 encoding. Interpretation of the value of the
>>>>>> URI
>>>>>> is outside the scope of this document.
>>>>>>
>>>>>> If a packet contains multiple URI TLVs, then the client SHOULD
>>>>>> select
>>>>>> the first TLV it can implement, and ignore the others. If the
>>>>>> client
>>>>>> is unable to implement any of the URI TLVs, then it MAY ignore the
>>>>>> error. PEAP implementations MAY support this TLV; and this TLV
>>>>>> cannot be responded to with a NAK TLV. The URI TLV is defined as
>>>>>> follows:
>>>>>>
>>>>>> 0 1 2 3
>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |M|R| TLV Type | Length |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> | URI...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>
>>>>>> M
>>>>>>
>>>>>> 0 - Optional TLV
>>>>>>
>>>>>> R
>>>>>>
>>>>>> Reserved, set to zero (0)
>>>>>>
>>>>>> TLV Type
>>>>>>
>>>>>> 8
>>>>>>
>>>>>> Length
>>>>>>
>>>>>> >=0
>>>>>>
>>>>>> URI
>>>>>>
>>>>>> This field is of indefinite length, and conforms to the format
>>>>>> specified in [RFC2396].
>>>>>> ______________________________________________________________________________________________
>>>>>>
>>>>>> As you can see, we have conflicts. Note that the field Length is a 16
>>>>>> bit value and the mandatory field is zero (non mandatory)
>>>>>>
>>>>>> My doubt is how MS have implemented on IAS?
>>>>>>
>>>>>> OK. Returning to my rastls.log you will see that my TLV URI packet
>>>>>> sent to the eap dll was discarded because was considered as a invalid
>>>>>> attribute. Below a relevant lines from the log:
>>>>>> _______________________________________________________________________________
>>>>>> [1912] 16:47:40:703: EapTlsBegin()
>>>>>> [1912] 16:47:40:703: SetupMachineChangeNotification
>>>>>> [1912] 16:47:40:703: State change to Initial
>>>>>> [1912] 16:47:40:703: EapTlsBegin: Detected PEAP authentication
>>>>>> [1912] 16:47:40:703: MaxTLSMessageLength is now 16384
>>>>>> [1912] 16:47:40:703: CRYPT_E_NO_REVOCATION_CHECK will not be ignored
>>>>>> [1912] 16:47:40:703: CRYPT_E_REVOCATION_OFFLINE will not be ignored
>>>>>> [1912] 16:47:40:703: The root cert will not be checked for revocation
>>>>>> [1912] 16:47:40:703: The cert will be checked for revocation
>>>>>> [1912] 16:47:40:703: EapPeapBegin done
>>>>>> [1912] 16:47:40:703: EapPeapMakeMessage
>>>>>> [1912] 16:47:40:703: EapPeapSMakeMessage
>>>>>> [1912] 16:47:40:703: PEAP:PEAP_STATE_INITIAL
>>>>>> [1912] 16:47:40:703: EapTlsSMakeMessage
>>>>>> [1912] 16:47:40:703: EapTlsReset
>>>>>> [1912] 16:47:40:703: State change to Initial
>>>>>> [1912] 16:47:40:703: GetCredentials
>>>>>> [1912] 16:47:40:703: Flag is Server and Store is local Machine
>>>>>> [1912] 16:47:40:703: GetCachedCredentials Flags = 0x4061
>>>>>> [1912] 16:47:40:703: GetCachedCredentials: Using Cached Credentials
>>>>>> [1912] 16:47:40:703: GetCachedCredentials: Hash of the cert in the
>>>>>> cache is
>>>>>>
>>>>>> 6 4 3 E 5 8 D 2 5 2 2 5 C 4 0 3 6 D 1 C 6 9 A D
>>>>>> D 0 5 2 F C F 5 | d > X . R % . . m . i . . R . . |
>>>>>>
>>>>>> C A 1 B 8 0 A 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0 | . . . . . . . . . . . . . . . . |
>>>>>> [1912] 16:47:40:703: BuildPacket
>>>>>> [1912] 16:47:40:703: << Sending Request (Code: 1) packet: Id: 33,
>>>>>> Length: 6, Type: 13, TLS blob length: 0. Flags: S
>>>>>> [1912] 16:47:40:703: State change to SentStart
>>>>>> [1912] 16:47:40:703: EapPeapSMakeMessage done
>>>>>> [1912] 16:47:40:703: EapPeapMakeMessage done
>>>>>> [1912] 16:47:40:703: EapPeapMakeMessage
>>>>>> [1912] 16:47:40:703: EapPeapSMakeMessage
>>>>>> [1912] 16:47:40:703: PEAP:PEAP_STATE_WAIT_FOR_APPLICATION_TLV
>>>>>> [1912] 16:47:40:703: Received invalid attributes from application.
>>>>>> [1912] 16:47:40:703: EapPeapSMakeMessage done
>>>>>> [1912] 16:47:40:703: EapPeapMakeMessage done
>>>>>> [1912] 16:47:40:703: EapPeapEnd
>>>>>> [1912] 16:47:40:703: EapTlsEnd
>>>>>> [1912] 16:47:40:703: EapTlsEnd()
>>>>>> [1912] 16:47:40:703: EapPeapEnd done
>>>>>> ___________________________________________________________________________________________________
>>>>>>
>>>>>>
>>>>>> I hope that we find someone that help us.
>>>>>> Thanks for your attention
>>>>>>
>>>>>> Washington Moreira
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
>>>>>> news:1133294445_42627@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>I am trying to write an extension DLL for IAS that does the WPS guest
>>>>>>> authentication. I have it successfully registering itself, grabbing
>>>>>>> packets,
>>>>>>> testing cases, selectively converting Access-Reject packets to
>>>>>>> Access-Accept
>>>>>>> packets, etc. The only part I cannot figure out is how and when to
>>>>>>> do the
>>>>>>> EAP-TLV URI attribute-value pairs. I imagine I do them in an
>>>>>>> Access-Challenge packet, but I do not know how to figure out WHICH
>>>>>>> packet to
>>>>>>> put them in or HOW to put them in the packet. I cannot find any
>>>>>>> USEFULL
>>>>>>> documentation on doing the EAP programming stuff in an IAS DLL. I
>>>>>>> also do
>>>>>>> not understand how my EAP messages get encrypted along with the
>>>>>>> rest, or how
>>>>>>> I can modify them inside a call to the RadiusExtensionProcess2
>>>>>>> function. Any
>>>>>>> help or examples on how to do this would be greatly appreciated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Eliot Gable
>>>>>>> CCNA, CWNA, CWSP,
>>>>>>> Security+, Network+
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure
>>>>>>> Usenet News==----
>>>>>>> http://www.newsfeeds.com The #1 Newsgroup Service in the World!
>>>>>>> 120,000+ Newsgroups
>>>>>>> ----= East and West-Coast Server Farms - Total Privacy via
>>>>>>> Encryption =----
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure
>>>>>> Usenet News==----
>>>>>> http://www.newsfeeds.com The #1 Newsgroup Service in the World!
>>>>>> 120,000+ Newsgroups
>>>>>> ----= East and West-Coast Server Farms - Total Privacy via Encryption
>>>>>> =----
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Loading