Proposed OpenBSC application interface

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Holger Freyther zecke at selfish.org
Thu Apr 15 00:53:02 UTC 2010


On Wednesday 14 April 2010 23:48:22 Harald Welte wrote:
> Hi!
> 
> Collin Mulliner, Tobias Engel and myself have been meeting yesterday to
> discuss a generic application interface for OpenBSC.

very nice.

> 
> They are both doing security analysis and want to achieve a clean way
> how an external application can get access to a more or less transparent
> communication channel to the phone.
> 
> The purpose of this is to be able to send intentionally malformed
> packets to the mobile phone GSM stack at various different levels within
> the stack.


Let me answer to your question from the bottom. If our only goal is to send 
malformed packets to the MS I think this interface is way too low level and 
for now all requirements can be handled by basic GSM08.08 messages.



> 1) Ability to establish a SDCCH or TCH channel by paging the phone
>    As of now, the 'silent call' feature from the VTY already does this.

GSM08.08 Paging Request which will be answered with a GSM08.08 Complete Layer3 
Information (a new connection)

> 
> 2) Ability to send arbitrary layer3 protocol messages to the phone
>    Adding this is relatively easy (use rsl_sendmsg on the lchan from the
>    silent call)

GSM08.08 DTAP

> 
> 3) Ability to receive responses from the phone, as well as error
>    conditions such as 'readio link failure'.  We don't have a solution
>    for this yet, and we also have no clean way to identify what might
>    be a response from the phone to the external app, and what might
>    be a message from the phone to the normal network code in OpenBSC

GSM08.08 DTAP and GSM08.08 Cleanup Request (Error Cause Radio Link Failure)




> So what I've been thinking of as a solution to the problem:
> 
> * store a bypass_flags bitmask related to the subscriber structure,
>   where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC,
>   BYPASS_SAPI3.

That sounds easy so far. We could easily extend it to MSG type in the future.




More information about the OpenBSC mailing list