Bug #3253
closedosmo-bts-trx doesn't enable A5/3
100%
Description
I've implemented a set of encryption related test cases in BTS_Tests.ttcn
, see the laforge/bts-encryption
branch at http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/bts-encryptionx%x%
TC_chan_act_a51
and TC_chan_act_a52
pass without trouble, while TC_chan_act_a53
fails: The RSL/RLL message sent on Abis to the BTS never is received on L1CTL.
trxcon seems to correctly detect that A5/3 is selected, but then appears to be unable to make sense of the bursts it receives:
<0001> l1ctl.c:731 L1CTL_CRYPTO_REQ (algo=A5/3, key_len=8) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=185 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=195 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=204 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=236 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=255 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=287 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=297 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=306 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=338 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=357 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=389 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=399 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=408 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=440 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=459 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=491 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=501 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=510 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=542 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=561 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=593 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=603 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=612 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=644 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=663 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=695 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=705 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=714 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=746 (32/102) for SDCCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=765 <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=797 (83/102) for SDCCH/4(2) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=807 (93/102) for SACCH/4(2) <0005> sched_clck.c:140 Clock indication: fn=816
Files
Related issues
Updated by laforge almost 6 years ago
- File 20180509-osmobts-a53.pcapng 20180509-osmobts-a53.pcapng added
- Status changed from New to In Progress
- Assignee changed from fixeria to laforge
- % Done changed from 0 to 20
now it looks actually more like a osmo-bts problem:
when running the A5/1 testcase, I get:
DRSL <0000> rsl.c:2613 (bts=0,trx=0,ts=0,ss=2) Rx RSL CHAN_ACTIV DRSL <0000> rsl.c:1043 chan_nr=0x30 type=0x00 mode=0x00 DL1C <0006> l1sap.c:1406 activating channel chan_nr=0x30 trx=0 DL1C <0006> scheduler.c:615 Activating SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:615 Activating SACCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:664 Set mode 3, 0, handover 0 on SDCCH/4(2) of trx=0 ts=0 DTRX <000b> trx_if.c:240 Enqueuing TRX control command 'CMD NOHANDOVER 0 2' DL1C <0006> scheduler.c:729 Set a5/1 uplink for SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/1 uplink for SACCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/1 downlink for SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/1 downlink for SACCH/4(2) on trx=0 ts=0 DL1C <0006> l1sap.c:578 activate confirm chan_nr=0x30 trx=0 DRSL <0000> rsl.c:662 (bts=0,trx=0,ts=0,ss=2) Tx CHAN ACT ACK
but when running the A5/3 testcase, I see:
DRSL <0000> rsl.c:2613 (bts=0,trx=0,ts=0,ss=2) Rx RSL CHAN_ACTIV DRSL <0000> rsl.c:1043 chan_nr=0x30 type=0x00 mode=0x00 DL1C <0006> l1sap.c:1406 activating channel chan_nr=0x30 trx=0 DL1C <0006> scheduler.c:615 Activating SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:615 Activating SACCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:664 Set mode 3, 0, handover 0 on SDCCH/4(2) of trx=0 ts=0 DTRX <000b> trx_if.c:240 Enqueuing TRX control command 'CMD NOHANDOVER 0 2' DL1C <0006> scheduler.c:729 Set a5/0 uplink for SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/0 uplink for SACCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/0 downlink for SDCCH/4(2) on trx=0 ts=0 DL1C <0006> scheduler.c:729 Set a5/0 downlink for SACCH/4(2) on trx=0 ts=0 DL1C <0006> l1sap.c:578 activate confirm chan_nr=0x30 trx=0 DRSL <0000> rsl.c:662 (bts=0,trx=0,ts=0,ss=2) Tx CHAN ACT ACK
and this despite RSL CHAN ACT clearly stating A5/3 as algorithm (see attached pcap). odd.
Updated by laforge almost 6 years ago
- Related to Bug #3254: OsmoBTS doesn't reject RSL CHAN ACT for unsupported ciphers added
Updated by laforge almost 6 years ago
- Project changed from OsmocomBB to OsmoBTS
- Subject changed from trxcon doesn't interoperate with OsmoBTS on A5/3 to osmo-bts-trx doesn't enable A5/3
- Category changed from OsmocomBB Layer 0 (DSP) to osmo-bts-trx
- Priority changed from Normal to High
- % Done changed from 20 to 80
In fact, the most embarrassing part of this bug is that osmo-bts-trx/main.c simply doesn't enable A5/3. Not sure why that would be, given that the software implementation in libosmcore already in 2015.
Updated by laforge almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
patch merged.