summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-05-29validation/validlib: send real bidir traffic instead of down only, refs #4002Ludovic Maillard
2013-05-29validation/validlib: send real bidir traffic instead of down only, closes #4002Jean-Philippe NOEL
2013-05-27validation/validlib/ixia_tcl_templates: send more learning frames, closes #4000Jean-Philippe NOEL
Send learning frames for each iteration, instead of for each test, to address the expiration of the bridge table.
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-24validation/test/P2MP_throughput/configs: suppress obsolete configs, closes #4001Jean-Philippe NOEL
2013-05-24validation/test/P2P_throughput: add test to validate the configs, refs #4001Jean-Philippe NOEL
2013-05-24validation: define a default station number, refs #4001Jean-Philippe NOEL
2013-05-24validation/test/P2MP_throughput: add unit tests for configs, refs #4001Jean-Philippe NOEL
2013-05-24validation/test/P2MP_throughput/configs: clean the configs, refs #4001Jean-Philippe NOEL
2013-05-24validation/validlib: remove a useless print, refs #4001Jean-Philippe NOEL
2013-05-24validation/validlib: refactor list substraction, refs #4001Jean-Philippe NOEL
2013-05-24validation: start the CCO first, refs #4001Jean-Philippe NOEL
2013-05-24validation/test/P2MP_throughput/configs: simplify the configs, refs #4001Jean-Philippe NOEL
2013-05-24validation: filter the inactive plugs, refs #4001Jean-Philippe NOEL
2013-05-24validation/test/P2MP_throughput/configs: get config of real AV bench, refs #4001Jean-Philippe NOEL
2013-05-24validation: possibility to define a parent configuration, refs #4001Jean-Philippe NOEL
2013-05-24validation: adjunction of .eps files in .gitignore, refs #4001Jean-Philippe NOEL
2013-05-24adjunction of .pyc files in .gitignore, refs #4001Jean-Philippe NOEL
2013-05-24validation/test/P2MP_throughput: truncate lines at 80 characters, refs #4001Jean-Philippe NOEL
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-24common/tests: add ce/rx/bl/test/intervals/ in automatic testsCyril Jourdan
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
2013-05-17cesar/mac/pbproc: factorize rts-cts frame prepare, refs #3976Milenko Jelisavcic
2013-05-17cesar/hal/phy/maximus: decrease log level because collision could happenThierry Carré
2013-05-17cesar/host/station: enable warnings and errors messages to be write on stderrThierry Carré
2013-05-17cesar/ecos/packages/hal/maximus: stop ecos synthetic on errorThierry Carré
2013-05-17cesar/hal/phy/maximus: accept to program a timer in the past (less than 1ms)Thierry Carré
Add some tolerance on timer management.
2013-05-17cleo/buildroot/target: fix buildroot package syntax, refs #3956Olivier Dufour
2013-05-16cesar/mac/pbproc: always send MMEs using ROBO mode, closes #3936Cyril Jourdan
This is a hack to improve CE sync between stations. We should think of another ways to ensure that this sync is OK and revert this (see #3988).
2013-05-16cesar/ce/rx/bl: fix intervals bitloading contexts init, refs #3936Cyril Jourdan
The table of next restart dates was not initialized. Random values could make the CE believe that it is not allowed to restart before a very long time...
2013-05-16cesar/cp: increase the number of allowed central beacon loss, closes #3971Nélio Laranjeiro
Gigle's CCo may forget to send central beacon for 600ms and the L.A.N. (Laboratoire des Applications Numériques) considers the test fail if the station deassociate during a run. cf wiki page wiki/Interoperability/gg-cco there are some details related with this beacon loose already seen with SPC300.
2013-05-16cesar/maximus/{interface, sci}: set stderr of station to stderr of user.Thierry Carré
Maximus option 's' is no more available, because it's a lot of complexity for a little feature. If an user want to save stderr of stations in a file. He can add on end of command line a redirection, like : '2>XXX.log'