summaryrefslogtreecommitdiff
path: root/cesar/bsu/src
AgeCommit message (Collapse)Author
2013-06-06cesar/bsu: reset the beacon in the avln structure in bsu_avln_init, refs #2869Nélio Laranjeiro
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/{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/{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-03-22cesar/bsu: program an allocation even if it have no one, closes #3885Nélio Laranjeiro
It is for interop purpose with Gigle.
2012-12-12cesar/bsu: add a context to bsu_init_beacon_cb, refs #3386Nélio Laranjeiro
2012-12-12cesar/bsu: make BSU_WAKEUP_DELAY_MS configurable, refs #3341Nélio Laranjeiro
2012-12-12cesar/cp/av/cco/bw: add start_time_atu on allocation for Gigle, closes #2437Nélio Laranjeiro
2012-12-12cesar/bsu: modify special patch for atheros in csma only mode, closes #3503Nélio Laranjeiro
2012-12-12cesar/bsu: move a traceNélio Laranjeiro
2012-12-12cesar/bsu: add a tolerance to accept central beacons, closes #3502Nélio Laranjeiro
2012-10-22cesar: use CALLBACK macro to register callbacks, refs #3414Nélio Laranjeiro
2012-09-11cesar: make test code compile with CONFIG_STATS = n, closes #3234Nélio Laranjeiro
* VS_GET_STAT_REQ returns an MME with the result, failure or empty. * host unit tests of the SAR uses the override CE context to compute stats.
2012-07-24cesar/bsu: add stats for neighbor networks, closes #3159Nicolas Schodet
2012-07-18cesar/bsu: fix deactivate/activate, closes #3060Nélio Laranjeiro
2012-07-18cesar/{bsu,mac}: add an expiration ntb to pb_beacon_t, closes #3057Nélio Laranjeiro
A frame reception on PBProc can cancel an emission. To avoid to not transmit the frame the PBProc reschedule it, but before sending the frame it will check the expiration ntb date of the PBs it should send in the frame. This is correct for any PB but for Beacon PB it is not, those special PB did not have an expiration ntb date in their descriptor. So at the end some beacons were dropped because the PBProc was comparing an expiration ntb date to something which was not. This commit fix it by adding an expiration ntb date in the Beacon PB corresponding to the end of the beacon period within the one it is valid.
2012-07-18cesar/bsu: clear synced bpsd in aclf, closes #2920Nélio Laranjeiro
A new function called by BSU when the tracking data are cleared will be called in order to un-synchronize the beacon period start date. Only the next beacon period date will have a delay corresponding to N beacon slots with N in [0, HPAV_BEACON_NUMSLOTS_MAX[, N is randomly get using lib_rnd_uniform function. This modification should help in coexistence problems.
2012-05-10cesar: replace BSU_BEACON_NM and CP_NET_NM by MAC_NMNélio Laranjeiro
2012-01-13Revert "cesar/bsu: don't set track_new when reseting tracking data" closes #2713Nélio Laranjeiro
This reverts commit 691b04b86b4634fc059517a3046841e7051f0a5b. BSU need the track_new flag to compute correctly the schedules for the CA, if this is modified the BSU can wrongly synchronise on the new beacon and have more consequences.
2011-11-02cesar/bsu: don't set track_new when reseting tracking data, closes #2807Nélio Laranjeiro
When the station receives an untrack command, it should not set track_new to true because on poweron avln it does not have beacon data.
2011-11-02cesar/bsu: get the AVLN instead of adding it on track request, closes #2805Nélio Laranjeiro
In track function called by the CP, BSU was adding the AVLN instead of getting it from its own lists.
2011-11-02cesar/bsu: add track trace into tracesNélio Laranjeiro
2011-11-02cesar/bsu:call avln_identify when the BSU is unactivated, closes #2804Nélio Laranjeiro
2011-09-22cesar/bsu: update both nid and snid, closes #2708Nélio Laranjeiro
When the station update the NID, it is useful to update the SNID of the current network. For example when the NMK change, a new NID is computed. If the station stay acting as STA there is no problem, but if it starts acting as CCo it should get a new SNID which can be different from the current one.
2011-09-22cesar: update tracking after handover, refs #2693, #2524Nélio Laranjeiro
2011-09-08cesar/bsu: add clock error precision estimation, closes #2679Nicolas Schodet
2011-09-08cesar/bsu: remove unused phy parameterNicolas Schodet
2011-09-08cesar/bsu: add tunable NTB smooth coefficient, closes #2680Nélio Laranjeiro
2011-05-23cesar/bsu: should have at least two blocks for locked traceNicolas Schodet
2011-05-05cesar/bsu: replace BSU_BEACON_SCHEDULES_MAX by BSU_BEACON_SCHEDULES_NBNélio Laranjeiro
2011-05-05cesar/bsu: fix schedule generation, closes #2432Nélio Laranjeiro
When the station was acting as CCo. BSU was unable to modify the current schedule.
2011-05-05cesar/bsu: replace static keyword by PRIVATE keywordNélio Laranjeiro
2011-04-20cesar/bsu: avoid computing twice the BTS in phy clock, closes #2450Nélio Laranjeiro
2011-04-18cesar: add bsu context to all bsu function calls, closes #2400Nélio Laranjeiro
2011-04-18cesar/bsu: lock dsr for function called by CP, closes #2398Nélio Laranjeiro
2011-04-14cesar/bsu: set allocation end time to the max value, closes #2422Nélio Laranjeiro
This must be revert once the CP is able to handle it.
2011-04-14cesar/bsu/aclf: track crossing edge of the power line, refs #2341Nélio Laranjeiro
This replaces the beacon duration computation by tracking powerline cross
2011-04-01cesar/bsu: avoid to provide future schedules to the CA, closes #2333Nélio Laranjeiro
2011-04-01cesar/bsu: make bsu to point to the poweron structure, refs #2333Nélio Laranjeiro
2011-03-15cesar/bsu: save sta_avln when positioned after the removed avln, closes #2399Nélio Laranjeiro
bsu_avln_remove corrupts the sta_avln pointer when it removes the AVLN in positions before in the table.
2011-03-15cesar/bsu: remove oldest AVLN when adding a new one, closes #2395Nélio Laranjeiro
When AVLN array is full, BSU should use the structure of the oldest one registered.
2011-02-18cesar/{cp, bsu}: add CCo's mac address to track on it too, refs #2235Nélio Laranjeiro
BSU will track on CCo's mac address if the CCo provides it in the central beacon. If the CCo does not provide it, MAC_ZERO should be used to inform BSU to not filter on this field.
2011-02-18cesar/bsu/beacon: rename mac_address_present bentryNélio Laranjeiro
2011-02-07Merge branch 'master' into avNélio Laranjeiro
Conflicts: cesar/bsu/aclf/aclf.h cesar/bsu/aclf/src/aclf.c cesar/bsu/aclf/test/utest/src/aclf.c cesar/bsu/src/bsu.c
2011-02-07cesar/bsu: add stats, closes #2213Nélio Laranjeiro
- current ntb_tck_offset - current frequency error in q30.
2011-02-02cesar/bsu: avoid valgrind error, refs #2256Nélio Laranjeiro