On Wed, Apr 18, 2018 at 01:21:27PM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
> Hi,
> 
> I migrated my setup to the new Network In The Box configuration with 
> separated components (from latest, not nightly). I tested whether the 
> described issue with A5/3 is resolved, but it still does not work. Though, 
> the behavior has changed.
> 
> In the old setup a Ciphering Mode Command for A5/3 was sent, but a Ciphering 
> Mode Complete was never received. Probably, what was happening is the 
> following:
> > The details there are that the Ciphering Mode Command is asking to start 
> > ciphering on the air, and the Ciphering Mode Complete is already sent > 
> > ciphered.
> > So it might be received, but the received data may be discarded as 
> > gibberish.
> 
> In the new setup not even the Ciphering Mode Command is sent to the MS.

Commented in OS#3043 on the reason why A5/3 gets rejected.
I'm continuing discussion there instead of duplicating on the mailing list.

> Instead the BSC sends a Cipher Mode Reject to the MSC, if I am reading the 
> logs correctly:
>
> <000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE REJECT
> <000a> a_iface_bssap.c:453 BSC sends cipher mode reject (conn_id=65)

This bit confuses me: how can the BSC reject a Cipher Mode if the MSC never
sent a Cipher Mode Command?

The BSC would send a Cipher Mode Reject if it finds the algorithm requested by
the MSC not supported in the osmo-bsc.cfg. Maybe we also do that if A5/0 (no
encryption) is not listed in osmo-bsc.cfg??

> <000a> a_iface_bssap.c:457 Cause code is missing -- discarding message!

Interesting. I have identified https://osmocom.org/issues/3186 and 
https://osmocom.org/issues/3187

> A5/1 continues to work without any problems.

The root cause for all of this is most probably above missing-classmark
problem, but it turns out to be a good thing that it helped us uncover a bunch
of errors in error handling.

Thanks for your reports!

~N

Attachment: signature.asc
Description: PGP signature

Reply via email to