summaryrefslogtreecommitdiff
path: root/cesar
AgeCommit message (Collapse)Author
2013-06-14cesar/mac/common: backport mac_store_sta_get_noref from EoC, refs #4018Cyril Jourdan
2013-06-14cesar/hal/phy/spoc/test: store constant in a variable, refs #4044Olivier Dufour
2013-06-14cesar/mac/common: increase MAC tolerance, closes #4043Nicolas Schodet
This is needed for extra long cables (up to 1200m).
2013-06-14cesar/hal/phy: set default SPOC matrix mask, closes #4041Nicolas Schodet
2013-06-14cesar/hal/phy: add spoc matrix mask, refs #4041Nicolas Schodet
2013-06-12cesar/mac/pbproc: update backoff, closes #4037Milenko Jelisavcic
2013-06-12cesar/mac/pbproc: refactor access partMilenko Jelisavcic
2013-06-07cesar/ce/rx/test: fix unit test, refs #4007Thierry Carré
The 'test_fail_if' added previously, must be activated only when we have some interval repetition. Currently, there is many interval in AV, and only one interval in EoC.
2013-06-07cesar/ce/rx: activate intervals by default, closes #2365Cyril Jourdan
2013-06-06cesar/ce/rx: fix assert with interval index, refs #4007Thierry Carré
Fix assert when interval index is wrong, and current interval version is good.
2013-06-06cesar/ce/rx/bl: enable snr collect with interval, refs #4007Thierry Carré
2013-06-06cesar/cp/sta/mgr: release releasable stations, closes #2869Nélio Laranjeiro
The release list can be release by any status in the plug, but only the CCo can move a plug into this list.
2013-06-06cesar/cp/av/sta/mgr: inform the bsu when a CCo is removed, closes #2869Nélio Laranjeiro
The BSU must be informed when a CCo is removed from the station manager.
2013-06-06cesar/bsu: reset the beacon in the avln structure in bsu_avln_init, refs #2869Nélio Laranjeiro
2013-06-06cesar/cp/sta/mgr: remove a duplicated instructionNélio Laranjeiro
2013-06-06cesar/{hal/phy,mac/pbproc}: on SPOC reset, set initial rho_q30 value, closes ↵Yacine Belkadi
#4004 When SPOC_RHO_INITIAL_Q30 is set in the internal.conf file, that value should be the one set on a SPOC reset, not 0. Make pbproc_spoc_reset() use the initial spoc rho q30 value. This also moves the knowledge about the initial SPOC parameters to the phy layer, which seems more appropriate.
2013-06-06cesar/hal/phy/{spoc,}: add phy_compute_spoc_{initial,}_coeff(), refs #4004Yacine Belkadi
Add phy_compute_spoc_initial_coeff() to allow callers to get the initial SPOC coefficients. This function is put in hal/phy because this is where the knowledge about the initial rho_q30 is, as it comes from phy_tunable.spoc_rho_initial_q30. This will be used in next commits. Add phy_compute_spoc_coeff(), just for completeness. Refactoring only. No (intended) functional changes.
2013-06-06cesar/{cp/{av,}/beacon,mac/pbproc}: add pbproc_spoc_reset(), refs #4004Yacine Belkadi
Add a pbproc_spoc_reset() that the cp can use to reset SPOC parameters, without having to know what the reset parameters are. This allows to move the knowledge of reset values to the pbproc, and will help for next commits. Refactoring only. No (intended) functional changes.
2013-06-06cesar/{cp/{av,}/beacon,mac/pbproc}: add/use pbproc_spoc_update(), refs #4004Yacine Belkadi
Add a pbproc_spoc_update() that the cp can use to update SPOC parameters without having to know about implementation details like allocating coefficients, computing them, then setting them. These changes will help for next commits. No (intended) functional changes.
2013-06-06cesar/cp/beacon: don't reset spoc if SPOC_UPDATE_INTERVAL == 0, refs #4004Yacine Belkadi
When SPOC_UPDATE_INTERVAL_MS is set to 0 in the internal.conf file, the cp should not update SPOC.
2013-06-06cesar/cp/av/beacon/test/utest2: add pbproc_stub.cYacine Belkadi
Put pbproc stubs in the new pbproc_stub.c instead of phy_stub.c
2013-06-06cesar/ce/rx/bl: send new default tonemap after computation, closes #4026Cyril Jourdan
2013-06-06cesar/cp/av/sta/action: fix a forgotten unit test, refs #3968Nélio Laranjeiro
The test concerning the simple connect has not been updated.
2013-06-06cesar/cp/av/msg/test/utest: hack_key field is unwritten when key type isn't ↵Thierry Carré
"hash", closes #4008
2013-06-06cesar/cp/av/msg/test/utest: fix valgrind warnings, refs #4008Thierry Carré
Use of uninitialised value of size 4 at 0x807FFC6: crc_compute_continue_block_le (crc.c:252) by 0x806CA84: cp_msg_mme_send (msg.c:1037) by 0x807253E: cp_msg_cm_get_key_req_send (msg_cm.c:423) by 0x804AC91: test_case_cm_get_key (msg_cm.c:328) by 0x8069D2F: main (msg_cm.c:3621)
2013-06-06cesar/cp/av/msg/test/utest: remove warnings on compilation, refs #4008Thierry Carré
Homeplug AV specification (11.5.7): EKS field => EKS or PEKS value depending upon Key Type The enum usage seems in order.
2013-06-06cesar/cp/av/msg/test/utest: remove variables set but not used, refs #4008Thierry Carré
2013-06-06cesar/cp/av/msg/test/utest: fix a memory corruption in utest, refs #4008Thierry Carré
2013-06-04cesar/cp[av]: set CP_TIMER_OFFSET_STA to allow beacon reception, closes #3990Nélio Laranjeiro
When there is not traffic on the medium, our CCo sends the central beacon 10ms after the beginning of the beacon period according with CA_ACCESS_MERGE_MARGIN_TCK margin.
2013-05-24cesar/cp/av/sta/action: compute the TEI renew date, closes #3968Nélio Laranjeiro
HPAV allows the TEI lease to be configurable on a range from 0x0001 to 0xffff (1 minute to approximatively 45days). As we used a renew margin of 5 minutes, we were not able to renew our TEI if the lease time was lesser of equal to 5 minutes, it had for consequence in our product to program the renew event in a far future. Another change in this commit concerns the behavior of the renew when the station is authenticated. To detect a request failure, a timer was programmed with the MARGIN value divided by 2 i.e. 2.5 minutes. From now the request is considered failed after the half of the calculated margin i.e. 15s if the lease was a minute, 30s if the lease was greater than a minute (see cp_av_sta_action_lease_renew function). Note: This bug has been confirmed during the Interoperability certification tests with the Gigle Test Matrix plugs when it acts as a CCo. Gigle's CCo provides a lease of 5 minutes value at the first CC_ASSOC.REQ (i.e. Join) request.
2013-05-24cesar/ce/rx/bl: compute a worst case tonemap when needed, closes #3880Cyril Jourdan
This tonemap will be used as default tonemap when intervals are activated.
2013-05-24cesar/ce/rx/bl: give CE RX context to update_default_tm function, refs #3880Cyril Jourdan
This is needed for the next commits.
2013-05-24cesar/ce/rx/bl: remove useless global variablesCyril Jourdan
A structure has been created for this parameters, this globals should not be used anymore.
2013-05-24cesar/ce/rx/bl: handle interval_sound events in global FSM, closes #3957Cyril Jourdan
The goal is to avoid that sound directed to an interval we can not match are treated by global FSM as sound events, what causes a global CE restart. This can lead to too many CE restarts and to an accumulation of measure in CE's mailbox, which leads to the observed assert.
2013-05-23cp/beacon/av: only request a NEK onceYacine Belkadi
If for some reason the Sta doesn't have the new NEK when a NEK change countdown starts, it asks for it using the CM_GET_KEY MME. But it was asking for it in each beacon period of the countdown where it didn't have the new NEK. It doesn't seem useful to insist that much. If the new NEK is missing on a NEK change, only ask for it once.
2013-05-23cesar/{bsu,cp,mac/pbproc}: change NEK managementYacine Belkadi
Two slots were used to store the NEKs. One for the current NEK, the other for the next NEK. The CP could update any slot at any time, by setting the EKS to MAC_EKS_CLEAR first. One problem is that the pbproc doesn't expect someone to change a key that it is in use. If the cp sets the EKS to MAC_EKS_CLEAR for a key that is in use, may make the pbproc send data unencrypted, which is a problem. Another problem may occur during a NEK change, if the new NEK is not received via the SET_KEY_CNF. In that case, when the countdown starts, the cp sends a GET_KEY_CNF to get the new NEK. When it receives it, it puts the new key in the next slot. To identify the next slot the cp uses bsu_nek_index_next(). This is not reliable around a NEK change: - the cp receives the new NEK - the cp starts setting the new NEK - the cp is suspended - the bsu changes nek_switch - the cp is resumed and calls bsu_nek_index_next() which returns the index of the current NEK instead of the next NEK - the cp writes the new NEK in the current slot instead of the next slot - the pbproc may send packets unencrypted - the NEK change occurs - the new NEK is used in Rx (because the new NEK is in one of the two slots) but not in Tx (because it's not the in the current slot) To fix that, change the way the NEKs are managed: Use pointers and indirection to be able to atomically change a NEK transparently from the pbproc's point of view. Make the cp store the NEKs and set the current NEK, but let the bsu grab the next NEK if it's available.
2013-05-22cesar/{bsu,{cp/{av,}/beacon}: in the cp, use the KCCD value maintained by ↵Yacine Belkadi
the bsu On a Sta, when no beacon was received, the cp updated the KCCD value in cp_beacon_countdowns() according to the number of beacon periods elapsed since its last run. The problem is that the number of elapsed beacon periods is tricky to determine reliably. Considering that: - The bsu already maintains the value of KCCD on its own. - The changes introduced by a previous commit made the bsu send a fake beacon when an expected beacon is not received. Then make the bsu pass its value of KCCD to the cp via the fake beacon. This way, the cp won't have to determine how much beacon periods it missed. It will just have to process n fake beacons if it missed n beacon periods. In addition, this allows to centralize key change related code in one place (cp_beacon_process_bmi_eks()).
2013-05-22cesar/{bsu,cp}/beacon: make bsu send a fake beacon to cp when no beacon is ↵Yacine Belkadi
received On a Sta, when an expected beacon is not received, make the bsu send a fake beacon to the cp. This allows the bsu to communicate with the cp when no beacon is received, and will be used in following commits.
2013-05-22cesar/bsu: use MAC_TOLERANCE_TCK when comparing beacon date to beacon period ↵Yacine Belkadi
date It may be possible for the beacon_period_start_date to be just a few ticks before bpsd0 (the beacon period start date) even though it's the beacon for the current beacon period. Use MAC_TOLERANCE_TCK to account for that.
2013-05-22cesar/cp/beacon: add cp_beacon_process_bmi_eks()Yacine Belkadi
To prepare for next commits, move the code processing the key change bentry into a new function cp_beacon_process_bmi_eks().
2013-05-22cesar/{bsu{,beacon},cp}: let the bsu decrease KCCD on each beacon, closes #3794Yacine Belkadi
When announcing a key change (e.g. NEK), the countdown field (KCCD) must decrease on each sent beacon. (c.f. HPAV Specification: 4.4.3.15.4.8.1 Key Change Countdown (KCCD) KCCD values were managed by the cp. But the cp is not assured to run on time to prepare each beacon. The bsu tried to compensate that in bsu_beacon_countdown() and the cp in cp_beacon_countdowns(). So both of them were touching KCCD, each one somehow guessing the appropriate current value. That seems fragile. In addition, cp_beacon_countdowns() has a bug which may prevent KCCD from being updated: Suppose that we are in beacon period b0. Suppose that the function is called just before the start of the next beacon period b1 (returned by bsu_aclf_beacon_period_start_date_next()). It enters the main if, and updates KCCD (for b0). Then it goes to update last_countdown_call_date, but the beacon period b1 has started. So bsu_aclf_beacon_period_start_date_next() returns b2, and last_countdown_call_date is set to b2. Because of this, when the function is called in b1, the main if will not be entered and KCCD will not be updated for b1. If the same scenario happens again, i.e. the function runs just before b2 but b3 starts just before updating last_countdown_call_date, then KCCD will not be updated in b2 neither. So KCCD may have the same value on consecutive beacons, which is a problem. Fix this by letting the bsu handle the decrease of the KCCD value. On the CCo, the cp decides when to initiate a key change. It tells sets the initial value of KCCD in one and only one beacon passed to the bsu. When the bsu sees that a key bentry is present in the beacon prepared by the cp, it knows that it has to handle the countdown. For each consecutive beacon, the bsu takes care of decreasing KCCD appropriately. The cp on the CCo doesn't need to know about it.
2013-05-22cesar/cp/beacon: only initiate the key change countdown on the CCo, refs #3794Yacine Belkadi
When cp_beacon_change_nek() is called with now == false, i.e. when setting the next NEK, only the CCo should initiate the countdown by setting the ctx->beacon.eks.* values that will end up in the sent beacon. The sta's ctx->beacon.eks.* values should come from the received beacon and shouldn't be set when receiving the next NEK.
2013-05-22cesar/{bsu,cp/beacon}: let the bsu clear the previous NEK, refs #3794Yacine Belkadi
After a NEK change, the previous NEK needs to be cleared. This was done by the cp. But: 1) The cp may run long after the NEK change, and may get interrupted. This delays the removal of the old key. 2) The cp only _guesses_ when the NEK change is done (see cp_beacon_countdowns()). If, for some reasons, the guess is wrong because the NEK change didn't happen yet, then the cp will actually clear the new key before it's used. It seems more reliable to let the bsu clear the old key, because the bsu is the one doing the NEK change.
2013-05-22cesar/bsu: add bsu_handle_key_change(), refs #3794Yacine Belkadi
In preparation for next commits, regroup KCCD related actions in a new function: bsu_handle_key_change().
2013-05-22cesar/cp/{av,}/cco/action: change NEK EKS values generationYacine Belkadi
The EKS for a new generated NEK was chosen by looking at the index of the "next" bsu NEK slot. This gave only two possible values: 0 or 1. The EKS and the index of the next slot are conceptually independent, so they shouldn't be tied together. In addition, it seems better to allow the EKS to take all the possible values allowed by the HPAV specification: 0 to 7, in order to ensure that the implementation can handle them correctly. So: - Dissociate the EKS from bsu_nek_index_next(). - Add a field (new_eks.eks) to hold the EKS of the generated NEK. - Make the EKS values cycle from MAC_EKS_MIN to MAC_EKS_MAX. Remove cp_cco_action_gen_nek_now() as it doesn't fit in with the change and was only called once. Add cp_cco_action_gen_nek() to handle the generation of the NEK (EKS + actual keys).
2013-05-17cesar/projects/plc: reduce ilram priority, closes #3976Milenko Jelisavcic
2013-05-17cesar/mac/pbproc: send beacon using rts-cts, refs #3976Milenko Jelisavcic
2013-05-17cesar/mac/pbproc: use access confirmation in rts-cts, refs #3976Milenko Jelisavcic
2013-05-17cesar/mac/pbproc: modify rts-cts part, refs #3976Milenko Jelisavcic
* limit rts-cts tolerance. * cancel prepared mpdu. * add support for sound frames. * activate tx rts-cts.
2013-05-17cesar/mac/pbproc: bursting with rts-cts, refs #3976Milenko Jelisavcic