Since there is a limit on the EAP exchange due to maximum number of
roundtrips, there is no point in allowing excessively large buffers to
be allocated based on what the peer device claims the total message to
be. Instead, reject the message if it would not be possible to receive
it in full anyway.
Signed-off-by: Jouni Malinen <j@w1.fi>
TNC IF-T is somewhat unclear on this are, but
draft-hanna-nea-pt-eap-00.txt, which is supposed to define the same
protocol, is clearer on the Flags field being included.
This change breaks interoperability with the old implementation if
EAP-TNC fragmentation is used. The old version would not accept
the acknowledgement message with the added Flags octet while the
new version accepts messagss with with both options.
TNC IF-T specification is unclear on the exact contents of the fragment
acknowledgement frame. An interoperability issue with the tncs@fhh
implementation was reported by Arne Welzel
<arne.welzel@stud.fh-hannover.de> due to the different interpretations
of the specification. Relax EAP-TNC server/peer validation rules to
accept fragmentation acknowledgement frames to include the Flags field
to avoid this issue.
On "eap_tnc_process" function error case, data->in_buf keeps reference
to a local scope variable. For example this will cause segmentation
fault in "eap_tnc_deinit" function "wpabuf_free(data->in_buf)"
statement.
The change to support fragmentation added extra function to generate the
EAP header, but forgot to remove the original code and ended up getting two
EAP headers and TNC flags field in the generated message. These header
fields need to be added only in the function that builds the final message
(and if necessary, fragments the data).
