aboutsummaryrefslogtreecommitdiffstats
path: root/src/pae
Commit message (Collapse)AuthorAgeFilesLines
* MACsec: Convert Boolean to C99 boolJouni Malinen2020-04-247-341/+340
| | | | Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* mka: Check OLPN for exhaustion on SAKuse decodeThomas Winter2019-09-181-91/+115
| | | | | | | | | | | | | Most of the time is spent in the CP state machine RETIRE state where LKI is not set and OKI is the currently used SAK so OLPN needs to be checked for PN exhaustion. hostapd/wpa_supplicant implemented an interpretation of the standard as described in a proposed amendment titled "MKA pending PN exhastion" which was deemed to be wrong. This amendment was included in IEEE Std 802.1Xck-2018. Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
* mka: Check OLPN for exhaustion on SAKuse encodeThomas Winter2019-09-181-11/+24
| | | | | | | | | | | | | Most of the time is spent in the CP state machine RETIRE state where LKI is not set and OKI is the currently used SAK, so OLPN needs to be checked for PN exhaustion. hostapd/wpa_supplicant implemented an interpretation of the standard as described in a proposed amendment titled "MKA pending PN exhastion" which was deemed to be wrong. This amendment was included in IEEE Std 802.1Xck-2018. Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
* mka: Clear out old/latest key values on CHANGE in CP state machineThomas Winter2019-09-181-0/+18
| | | | | | | | | The associated SAs have been deleted and the key server has changed so there's no point in keeping the key values. Note that this isn't specified in IEEE Std 802.1X-2010. Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
* mka: Don't set newSAK to FALSE on ABANDON in CP state machineThomas Winter2019-09-181-1/+0
| | | | | | | Previously the ABANDON->RECEIVE state change was impossible and did not match the CP state machine in IEEE Std 802.1X-2010 Figure 12-2. Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
* mka: Change RECEIVE and RETIRE states to match the standardThomas Winter2019-09-181-16/+10
| | | | | | | | | | | | | The RECEIVE and RETIRE states were incorrect which can result in incorrect information being advertised in SAKuse MKPDUs. Change these to match IEEE Std 802.1X-2010, Figure 12-2 (CP state machine). hostapd/wpa_supplicant implemented an interpretation of the standard as described in a proposed amendment titled "MKA pending PN exhastion" which was deemed to be wrong. This amendment was included in IEEE Std 802.1Xck-2018. Signed-off-by: Thomas Winter <Thomas.Winter@alliedtelesis.co.nz>
* mka: Accept last two used MNs in Peers List of a received MKPDUJouni Malinen2019-07-291-1/+11
| | | | | | | | | | | | | | | | | | | | | | Previously, check for local MI,MN in a peer's Peers List accepted only the cases that include the last used MN from an MKPDU sent by the local device. This was problematic since it was possible to synchronize MKPDU transmission between two devices in a way that made them always miss the last MKPDU from the other device before filling in the Peers List. Relax this matching requirement of "acceptably recent MN" to mean both the last used MN and the one used just before it (i.e., copied from either of the last two MKPDUs sent by the local device) are accepted. While this might help in some real world scenarios in making the protocol converge more quickly, the main help from this is to fix consistent hwsim test cases failures in macsec_psk_ns when using UML with time travel option which happened to practically guarantee the inconvenient timing of MKPDU transmission/reception that ended up with the MKPDU processing to see MI,MN with MN being the last used MN minus 1. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* mka: Avoid memory leak in unexpected case in RECEIVEJouni Malinen2019-04-151-0/+4
| | | | | | | | | | | | It looks like it is possible for the RECEIVE state to leak memory where a previously allocated sm->lki is moved to sm->oki while sm->oki is pointing to not yet freed entry. It is not clear how this can be triggered, but it has come up in hwsim testing under heavy load. Free sm->oki if it is still set in RECEIVE before replacing it with sm->lki to avoid this memory leak. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* UBSan: Pack MACsec peer id structureJouni Malinen2019-02-251-1/+1
| | | | | | | | | | This is needed to avoid an UBSan warning and since this struct is used as part of a message construction, it needs to be packed anyway to guarantee correct functionality. ieee802_1x_kay.c:1021:3: runtime error: member access within misaligned address 0x0000031921e2 for type 'struct ieee802_1x_mka_peer_id', which requires 4 byte alignment Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: New MI should only be generated when peer's key is invalidMike Siedzik2019-01-071-6/+6
| | | | | | | | | | | | | | | | | | | | Two recent changes to MKA create a situation where a new MI is generated every time a SAK Use parameter set is decoded. The first change moved invalid key detection from ieee802_1x_decode_basic_body() to ieee802_1x_kay_decode_mpkdu(): commit db9ca18bbff1 ("mka: Do not ignore MKPDU parameter set decoding failures") The second change forces the KaY to generate a new MI when an invalid key is detected: commit a8aeaf41df95 ("mka: Change MI if key invalid") The fix is to move generation of a new MI from the old invalid key detection location to the new location. Fixes: a8aeaf41df95 ("mka: Change MI if key invalid") Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Log MI update failure in debug logJouni Malinen2018-12-301-1/+6
| | | | | | | One of the reset_participant_mi() callers did not log the error. Make this more consistent with the other callers. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Make ICV Indicator dependant on ICV lengthJaap Keuter2018-12-291-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | IEEE Std 802.1X-2010, 11.11 describes that the ICV is separate from the parameter sets before it. Due to its convenient layout the ICV Indicator 'body part' is used to encode the ICV as well. IEEE Std 802.1X-2010, 11.11.3 describes the encoding of MKPDUs. In bullet e) is desribed that the ICV Indicator itself is encoded when the ICV is not 16 octets in length. IEEE Std 802.1Xbx-2014, Table 11-7 note e) states that it will not be encoded unless the Algorithm Agility parameter specifies the use of an ICV that is not 16 octets in length. Therefore the length calculation for the ICV indicator body part must take into account if the ICV Indicator is to be encoded or not. The actual encoder of the ICV body already takes care of the rest. In practice, this change will remove the ICV Indicator parameter set (4 octets before the ICV value itself) since the only defined algorithm agility value uses an ICV of 16 octets. IEEE Std 802.1X-2010 MKPDU validation and decoding rules in 11.11.2 and 11.11.4 require the receipient to handle both cases of ICV Indicator being included or not. Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
* mka: MIB informationJouni Malinen2018-12-293-1/+103
| | | | | | | Provide MKA information through the wpa_supplicant control interface MIB command. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Provide more status information over control interfaceJouni Malinen2018-12-291-6/+63
| | | | Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Stop trying to generate and distribute new SAK when not key serverJouni Malinen2018-12-291-2/+3
| | | | | | | | | | | | It was possible for a participant to first be elected as a key server and schedule a new SAK to be generated and distributed just to be followed by another participant being elected as the key server. That did not stop the participant that disabled key server functionality to stop generating the new SAK and then trying to distribute it. That is not correct behavior, so make these steps conditional on the participant still being a key server when going through the timer. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Add more debug print detailsJouni Malinen2018-12-292-121/+263
| | | | | | | This makes it a bit easier to try to figure out what is going on with KaY operations and MKA setup. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Fix deleteSAs clearing of principal->new_keyJouni Malinen2018-12-291-2/+7
| | | | | | | | | | | | This pointer needs to be cleared when the matching SAK is being removed from the SAK list. The previous implementation was doing something pretty strange in the loop by clearing the pointer for any non-matching key that happened to be iterated through before finding the matching key. This could probably result in incorrect behavior, but not clearing the pointer for the matching key could do more harm by causing freed memory to be referenced. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Derive MACsec cipher suite and MKA algorithm table indexJouni Malinen2018-12-292-12/+9
| | | | | | | | | Instead of using a specifically set index value from table definition, use the actual real index of the table entry. This removes need for maintaining these index values separately. Furthermore, the mka_alg_tbl[] index was already off-by-one (but not used anywhere). Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Clean up KaY log outputJaap Keuter2018-12-271-18/+19
| | | | | | | | | | When running wpa_supplicant (with logging for testing) the log output is somewhat disorganized for KaY related items. E.g., items are not aligned, inconsistent type handling, wrong wording, missing labels, etc. This change tries to clean up the log output, so it is somewhat more accessible. Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
* mka: Do not force entry into INIT state on CP state machine creationJouni Malinen2018-12-271-1/+0
| | | | | | | Go through the SM_STEP_RUN() global transition to get into the INIT state to follow the state machine design more closely. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Remove unused authorization data from CPJouni Malinen2018-12-272-18/+0
| | | | | | | | | | | While IEEE Std 802.1X-2010 talks about arbitrary authorization data that could be passed to the CP from sources like RADIUS server, there is not much point in trying to implement this as an arbitrary memory buffer in wpa_supplicant. Should such data be supported in the future, it would much more likely use more detailed data structures that encode the received data in easier to use form. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Extend CAK/CKN-from-EAP-MSK API to pass in MSK lengthJouni Malinen2018-12-264-22/+22
| | | | | | | | This can be used to allow 256-bit key hierarchy to be derived from EAP-based authentication. For now, the MSK length is hardcoded to 128 bits, so the previous behavior is maintained. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Allow CAK length 32 (256-bit) to be initializedJouni Malinen2018-12-262-4/+3
| | | | | | | | | The CAK length is not hardcoded in the algorithm agility parameter, so remove that from the table. Instead, allow both 16 (128-bit) and 32 (256-bit) CAK to be used so that the following key derivations use appropriate key lengths based on the configured/derived CAK. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Determine KCK/ICK length from CAK lengthJouni Malinen2018-12-262-7/+2
| | | | | | | | The ICK and KEK are derived from a CAK and the length of the CAK determines the length of the KCK/ICK. Remove the separate ICK/KEK length parameters from the algorithm agility table. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: ICV calculation using 256-bit ICKJouni Malinen2018-12-264-13/+24
| | | | | | Add support for using AES-CMAC with 256-bit key (ICK) to calculate ICV. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Support 256-bit ICK derivationJouni Malinen2018-12-264-10/+15
| | | | | | | Support derivation of a 256-bit ICK and use of a 256-bit CAK in ICK derivation. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Support 256-bit KEK derivationJouni Malinen2018-12-264-13/+18
| | | | | | | Support derivation of a 256-bit KEK and use of a 256-bit CAK in KEK derivation. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Support 256-bit CAK in SAK derivationJouni Malinen2018-12-263-10/+10
| | | | | | | Pass the configured CAK length to SAK derivation instead of using hardcoded 128-bit length. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: AES-CMAC-256 -based KDFJouni Malinen2018-12-261-13/+23
| | | | | | | | | Extend the previously implemented KDF (IEEE Std 802.1X-2010, 6.2.1) to support 256-bit input key and AES-CMAC-256. This does not change any actual key derivation functionality yet, but is needed as a step towards supporting 256-bit CAK. Signed-off-by: Jouni Malinen <j@w1.fi>
* mka: Change MI if key invalidAndrey Kartashev2018-12-261-0/+1
| | | | | | | | | | | | | It is possible to get a situation where a peer removes the Key Server from its live peers list but the server still thinks that the peer is alive (e.g., high packet loss in one direction). In such a case, the Key Server will continue to advertise Last Key but this peer will not be able to set up SA as it has already deleted its key. Change the peer MI which will force the Key Server to distribute a new SAK. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Speed up processing of duplicated SCIAndrey Kartashev2018-12-261-0/+7
| | | | | | | Decrease timeout for a peer with duplicated SCI to speed up process in case it is a valid peer after MI change. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Support for 256-bit SAK generationAndrey Kartashev2018-12-263-9/+12
| | | | | | | | | | | | There is already partial support of GCM-AES-256. It is possible to enable this mode by setting 'kay->macsec_csindex = 1;' in ieee802_1x_kay_init() function, but the generated key contained only 128 bits of data while other 128 bits are in 0. Enables KaY to generate full 256-bit SAK from the same 128-bit CAK. Note that this does not support 256-bit CAK or AES-CMAC-256 -based KDF. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Remember LowestPN for each key serverAndrey Kartashev2018-12-261-1/+6
| | | | | | | | | According IEEE Std 802.1X-2010, 9.8 each participant shall record the values of NextPN for last SAK accepted from each Key Server to use it in case of a switch from one Key Server to another and back. Add LPN recording and set saved value as the initial PN for the created channel. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Check for errors on create Secure ChannelAndrey Kartashev2018-12-261-3/+13
| | | | | | | | It is possible that the driver fails to create Secure Channel (due to hardware limitations for example). Add checks of create_*_sc() result codes and abort procedure in case of failure. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Fix a memory leak on error pathAndrey Kartashev2018-12-261-0/+1
| | | | | | | Fix a minor memory leak in ieee802_1x_kay_create_mka() in case of KEK/ICK derivation failure. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Debug output cleanup/fixAndrey Kartashev2018-12-262-17/+19
| | | | | | Make debug output more consistent, fix several errors. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Allow configuration of MACsec replay protectionAndrey Kartashev2018-12-262-3/+6
| | | | | | | | | | | Add new configuration parameters macsec_replay_protect and macsec_replay_window to allow user to set up MACsec replay protection feature. Note that according to IEEE Std 802.1X-2010 replay protection and delay protection are different features: replay protection is related only to SecY and does not appear on MKA level while delay protection is something that KaY can use to manage SecY state. Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
* mka: Do not update potential peer liveness timerMike Siedzik2018-12-261-5/+13
| | | | | | | | | | | | | | | | | | | To prevent a remote peer from getting stuck in a perpetual 'potential peer' state, only update the peer liveness timer 'peer->expire' for live peers and not for potential peers. Per IEEE Std 802.1X-2010, 9.4.3 (Determining liveness), potential peers need to show liveness by including our MI/MN in their transmitted MKPDU (within potential or live parameter sets). When a potential peer does include our MI/MN in an MKPDU, we respond by moving the peer from 'potential_peers' to 'live_peers'. If a potential peer does not include our MI/MN in an MKPDU within MKPDU_LIFE_TIME, let the peer expire to facilitate getting back in sync with the remote peer. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Consider missing MKPDU parameter sets a failureMike Siedzik2018-12-262-2/+37
| | | | | | | | | | | | The previous commit introduced parameter set error checking. This commit extends upon that by considering missing parameter sets a failure. Two checks are added by this commit. First, verify that live peers start encoding MKA_SAK_USE within a reasonable amount of time after going live (10 MKPDUs). Second, verify that once a live peer starts encoding MKA_SAK_USE it continues to do so indefinitely. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Do not ignore MKPDU parameter set decoding failuresMike Siedzik2018-12-261-5/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The status values returned by mka_param_body_handler.body_rx functions are currently ignored by ieee802_1x_kay_decode_mkpdu(). If a failure is detected the KaY should (a) stop processing the MKDPU and (b) do not update the associated peer's liveliness. IEEE Std 802.1X-2010, Table 11-7 (MKPDU parameter sets) and 11.11.3 (Encoding MKPDUs) dictate that MKA_SAK_USE (set type 3) will always be encoded before MKA_DISTRIBUTED_SAK (set type 4) in MKPDUs. Due to implementation of mka_param_body_handler, the code will always decode MKA_SAK_USE before MKA_DISTRIBUTED_SAK. When MKA_DISTRUBUTED_SAK contains a new SAK the code should decode MKA_DISTRUBUTED_SAK first so that the latest SAK is in known before decoding MKA_SAK_USE. The ideal solution would be to make two passes at MKDPU decoding: the first pass decodes MKA_DISTRIBUTED_SAK, the second pass decodes all other parameter sets. A simpler and less risky solution is presented here: ignore MKA_SAK_USE failures if MKA_DISTRIBUTED_SAK is also present. The new SAK will be saved so that the next MKPDU's MKA_SAK_USE can be properly decoded. This is basically what the code prior to this commit was doing (by ignoring all errors). Also, the only real recourse the KaY has when detecting any bad parameter set is to ignore the MKPDU by not updating the corresponding peer's liveliness timer, 'peer->expire'. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix resource leak when detecting duplicated SCIMike Siedzik2018-12-261-6/+20
| | | | | | | | | | | | | | | | | If a live peer ever changes its Member Identifier (MI), the KaY correctly detects a "duplicated SCI" but then proceeds to delete the peer without deleting the peer's resources (i.e., RxSC, RxSAs, TxSAs). Note that a remote peer's MI will change if and when an ieee8021XPaePortInitialize is executed on the remote port. The solution here is to ignore all MKPDUs containing the new MI until after the peer (that corresponds to the old MI) expires and cleans up its resources. After the old peer is removed reception of the next MKPDU containing the new MI will result in the creation of a new peer with the new MI. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix READY to TRANSMIT logic in CP state machineMike Siedzik2018-12-261-1/+1
| | | | | | | Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), READY to TRANSMIT transition includes !controlledPortEnabled condition. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix READY to ABANDON logic in CP state machineMike Siedzik2018-12-261-1/+1
| | | | | | | Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), READY should move to ABANDON (not RECEIVE) when new_sak or changed_connect is true. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix RECEIVING to TRANSMIT logic in CP state machineMike Siedzik2018-12-261-1/+2
| | | | | | | Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), RECEIVING to TRANSMIT transition includes !controlledPortEnabled condition. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix RETIRE state deletion of SAsMike Siedzik2018-12-261-2/+5
| | | | | | | Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), deleteSAs(oki) is used upon entering RETIRE. Do that in addition to freeing sm->oki. Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix lowest acceptable Packet Number (LPN) calculation and useMike Siedzik2018-12-264-28/+77
| | | | | | | | | | | | | | | | | | | | | | The purpose of the Lowest Acceptable PN (lpn) parameters in the MACsec SAK Use parameter set is to enforce delay protection. Per IEEE Std 802.1X-2010, Clause 9, "Each SecY uses MKA to communicate the lowest PN used for transmission with the SAK within the last two seconds, allowing receivers to bound transmission delays." When encoding the SAK Use parameter set the KaY should set llpn and olpn to the lowest PN transmitted by the latest SAK and oldest SAK (if active) within the last two seconds. Because MKPDUs are transmitted every 2 seconds (MKA_HELLO_TIME), the solution implemented here calculates lpn based on the txsc->next_pn read during the previous MKPDU transmit. Upon receiving and decoding a SAK Use parameter set with delay protection enabled, the KaY will update the SecY's lpn if the delay protect lpn is greater than the SecY's current lpn (which is a product of last PN received and replay protection and window size). Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix MKPDU SAK Use Body's Delay Protect bit settingMike Siedzik2018-12-262-5/+11
| | | | | | | | | | | | | | | | | | | | | | Delay Protect and Replay Protect are two separate and distinct features of MKA. Per IEEE Std 802.1X-2010, 9.10.1 "Delay Protect, TRUE if LPNs are being reported sufficiently frequently to allow the recipient to provide data delay protection. If FALSE, the LPN can be reported as zero", and per 9.10 "NOTE--Enforcement of bounded received delay necessitates transmission of MKPDUs at frequent (0.5 s) intervals, to meet a maximum data delay of 2 s while minimizing connectivity interruption due to the possibility of lost or delayed MKPDUs." This means struct ieee802_1x_mka_sak_use_body::delay_protect should only be set TRUE when MKPDUs are being transmitted every 0.5 s (or faster). By default the KaY sends MKPDUs every MKA_HELLO_TIME (2.0 s), so by default delay_protect should be FALSE. Add a new 'u32 mka_hello_time' parameter to struct ieee802_1x_kay. If delay protection is desired, the KaY initialization code should set kay->mka_hello_time to MKA_BOUNDED_HELLO_TIME (500 ms). Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* mka: Fix conf_offset value in MKPDU when in policy mode SHOULD_SECUREMike Siedzik2018-12-261-5/+9
| | | | | | | | | | | | | | | | | | | Commit 7b4d546e ("wpa_supplicant: Add macsec_integ_only setting for MKA") introduced policy setting SHOULD_ENCRYPT (MACsec provides integrity+confidentiality) in addition to SHOULD_SECURE (MACsec provides integrity only). In both cases the KaY is populating the "Confidentiality Offset" parameter within the "Distributed SAK parameter set" with CONFIDENTIALITY_OFFSET_0=1. In the case of SHOULD_SECURE the parameter should be populated with CONFIDENTIALITY_NONE=0. IEEE Std 802.1X-2010, Table 11-6 and Figure 11-11 define how the two Confidentiality Offset bits in the "Distributed SAK parameter set" must be set: "0 if confidentiality not used" and "1 if confidentiality with no offset". When policy is SHOULD_SECURE KaY should to send the former, and when policy is SHOULD_ENCRYPT KaY should send the latter. Fixes: 7b4d546e3dae ("wpa_supplicant: Add macsec_integ_only setting for MKA") Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
* MKA: Handle unaligned CKN lengthMichael Braun2018-12-251-7/+8
| | | | | | | | | | IEEE Std 802.1X-2010, Figure 11-7 explains that "Parameter set body length" is exclusive of the suffix padding. Fix variable length encoding and decoding when CKN length is not a multiple of 4 bytes. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* MKA: Mark frame structs packedJouni Malinen2018-12-252-10/+10
| | | | | | | Mark the data structures used in construction/parsing frames packed to prevent compiler from being able to pad them. Signed-off-by: Jouni Malinen <j@w1.fi>