Re: [PATCH] sysmobts: Deal with ciphering when we have a transport clash

Hi Holger, the patches look fine to me, although it hurts that such a hack and layering violations is actually needed. I'm wondering if the spec designers didn't come up with a more elegant method. In OpenBSC we could of course disable early classmark sending, but we cannot exclude osmo-bts / sysmobts from being used with other implementations either. What about OpenBSC waiting for the classmark change to arrive _if_ early classmark sending is enabled? At least, if A5/4 is ever used, this is the only way to support it anyway, as A5/4 is indicated only in CM3, and CM3 is only part of CLASSMARK CHANGE, but not part of the CM SERVICE REQUEST or PAGING RESPONSE. However, as we are probably all quite sure that the GSM industry is not capable of rolling out a 'new' cipher in less than 10 years, I'm not sure if we should worry about this here. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)