summaryrefslogtreecommitdiff
path: root/cesar/test_general/station
diff options
context:
space:
mode:
authorYacine Belkadi2013-04-02 17:27:57 +0200
committerYacine Belkadi2013-05-22 10:53:36 +0200
commite981d61d72c4d29f5bac7c7139ab50e98a0e625d (patch)
treef5843523e5211a039a7f6756a9b8f18131b777a2 /cesar/test_general/station
parent96e8bd48bd068f01a8c00649328c554677e756f2 (diff)
cesar/{bsu{,beacon},cp}: let the bsu decrease KCCD on each beacon, closes #3794
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.
Diffstat (limited to 'cesar/test_general/station')
-rw-r--r--cesar/test_general/station/scenario/av/py/sc08_bentry_change.py2
1 files changed, 1 insertions, 1 deletions
diff --git a/cesar/test_general/station/scenario/av/py/sc08_bentry_change.py b/cesar/test_general/station/scenario/av/py/sc08_bentry_change.py
index 6d33247ad6..5bb9d6ac29 100644
--- a/cesar/test_general/station/scenario/av/py/sc08_bentry_change.py
+++ b/cesar/test_general/station/scenario/av/py/sc08_bentry_change.py
@@ -298,7 +298,7 @@ class TestBentryChange (unittest.TestCase):
self.failUnless (beacons)
bentry = BEntryEncryptionKeyChange (
header = scammer.BENTRY_HDR['ENCRYPTION_KEY_CHANGE'],
- length = 2, kccd = 4, kbc = 0, neweks = 1)
+ length = 2, kccd = 5, kbc = 0, neweks = 1)
for i in beacons:
vs_sniffer_ind = Ether (i.get ())
beacon = scammer.get_sniffed_mme (vs_sniffer_ind)