Manuel Sánchez Cuenca wrote:
I'm modifying the PEAP module included in freeradius 1.1.4 to send in the last message of the protected channel some information to the client. Specifically, I'm including a new TLV in the eappeap_success message.
Ok...
The code of the eappeap_success method in the peap.c file is the following: ... ptr++; // [3] ... ptr++; // [13]
Why not just "ptr += 10"?
tlv_packet[18] = 1; /* Vendor ID */
int i;
That's not C.
for (i = 0; i < mydata_len; i++) {tlv_packet[19 + i] = mydata[i]; }
Why not use "memcpy"?
When the data to be sent (mydata) is small, the protocol works ok, but when the the amount of data is big, there are some problems. In this situation, the server sends the first fragment with the bits L and M sets to 1.
As it should, I think.
Then the client replies with a PEAP message without data (0x020b00061900).
That's a TLS ACK message.
Now, the server sends something that doesn't seem the right data, because in one test, the total size of the fragments was 1029, the first fragment size was 1024, and the second one (with must be 5) was 37.
The fragment that the server sends?
When the fragment ACK is received, he log of freeradius shows:
... rlm_eap_tls: Received EAP-TLS ACK message rlm_eap_tls: ack handshake fragment handler rlm_eap_tls: ack handshake is finished eaptls_verify returned 3 eaptls_verify returned 3 rlm_eap_peap: EAPTLS_SUCCESS
Yes. The TLS code inside of FreeRADIUS assumes that once the initial handshake is completed, that there is no more data to send.
Can anybody help me with this problem and tell me why the second fragment is not correct?
See the code that prints out "ack handshake is finished". It's terminating the EAP session earlier than you expect. You'll need to modify the code to have it send more data. Alan DeKok.