July 2009 - OpenBSC - lists.osmocom.org

HAR2009 TODO list
by Harald Welte 04 Aug '09

04 Aug '09

Hi again, I'm currently in the train, so forgive me posting the initial TODO list to the mailing list rather than the wiki. I'll put it in the wiki soon. If you want to take on of the items, just let me know! What I think we have to do before HAR is as follows: == Actual code == === absolutely required === * finish and test the SMS implementation [Harald] * make sure we enable MS power control and impose a global limit of 100mW for the uplink (MS->BSC) direction by means of the MS POWER IE's and the BCCH information. That sounds like something for Dieter to figure out, especially since he has measurement equipment ;) * test dual-BTS-on-single-E1-card config [Harald] ** up to now, we have only tested with two nanoBTS, not BS-11 ! * test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you do that?] ** channel allocator can be tweaked to give 2nd TRX a preference for debugging [I'll add those to trac, since they are really important] === optional === * implement a 'provisioning mode' to OpenBSC that ** acccepts every new IMSI the first time we see it ** sends a SMS with a auth token to that mobile ** disconnects that mobile immediately * implement a web site / cgi script ** once user enters correct tuple of ISMI + auth code, we *** assign him a number (user cannot choose, we assign) *** set authorized=1 in the sql table * implement a web site bug tracker for user bug reports ** the should include detailed information about the phone model, his phone number and the exact timestamp, so we can match it in the pcap's * add more introspection code for the VTY interface to explore the run-time data structures in OpenBSC * implement different TCH assignment schemes (early / very early / OCASU) * do we really want a SDCCH/8 or is SDCCH/4 for each BTS sufficient? * some more testing with two BTS * in case we call a user who is currently offline/busy, generate SMS about missed call and store it in the SMS table * web interface ideas ** SMS gateway where people can send SMS from the web site *** SMS spam function for us in case we want to inform users about something ** simplistic phone book * enhance vty interface with administrative functions such as ** ability to close arbitrary channels (i.e. terminate a call) ** ability to kick-ban a user out of the network *** set authorized=0 *** perform authentication procedure with reject at its end * make sure we store all the 'this phone was registerd before to MCC/MNC/LAC' from the LOC UPD REQ data * make sure we really store the classmark1/2/3 together with IMEI in SQL table == Things to bring to the event == * spectrum analyzer [from CCCB] * stable OCXO reference to calibrate BS-11 internal clock ** this could be done before the event, but Harald has no precision clock source * trace mobiles / monitor mode mobiles (if anyone has some) * some poles to which we can mount the BS-11 ? == Misc == * draft 'usage terms & conditions' to be put on the registration web site and the HAR2009 wiki, indicating ** all signalling and traffic data will be stored for R&D purpose ** we do not employ authentication and/or encryption ** we do not provide any service guarantee ** this is for evaluation+testing only ** no handover/roaming and/or external calls ** no warranty for any damage to MS, SIM, ... ** IMSI/IMEI information will not be disclosed by us, but people can sniff it Regards, -- - 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)

2 4

UMA a possibility in the future?
by Dakota C 03 Aug '09

03 Aug '09

Hi, I'm a long time lurker into this project and I've wondered something for a bit of time.Knowing that we can use an ip.access nanoBTS to work on OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access) standards? I know over here in the US we currently use UMA with T-Mobile over WiFi to communicate back to the T-Mobile servers and eventually off to the GSM and regular ol' networks. http://www.umatechnology.org/specifications/index.htm is the UMA specification, and to my knowledge T-Mobile US's @Home service uses the 1.0.3 protocol revision. To me it seems like it'd be trivial to make a derived copy of OpenBSC with UMA support up and running, but I'd like some other thoughts into this matter. I'm not a programmer by any means here, so if this is impossible, well, then so be it. -DC

3 5

Re: wireshark, viewing Abis communication
by Nordin 31 Jul '09

31 Jul '09

Hello Harald, Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal? I now try to follow the communication flow, but can't seem to understand the multiple OML messages. It starts with 0x00, than a datalen and than protocol (0xFF) and than it starts with 0x80, 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source. I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked at the wrong place.

4 17

Re: How to attack mobile networks with an iPhone (according to Apple)
by Dieter Spaar 31 Jul '09

31 Jul '09

Hello David, On Wed, 29 Jul 2009 11:02:15 -0700, "David A. Burgess" <dburgess(a)jcis.net> wrote: > > So you can jailbreak an iPhone and get direct access to L3 to run a > DOS? That would be very interesting if it were true, but I suspect > it's just horseshit put in there to deceive the court, which isn't > hard to do in technology cases. I don't think its that easy (if it would be, why not modify the TSM30 instead which should be much easier). I just found it very interesting that Apple uses it as an argument. Of course such arguments are also bad for opening the phone GSM stack to a larger group of people (if this ever happens) or developing an open source GSM phone stack which could be used for anything else than research. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Nordin, On Tue, 07 Jul 2009 14:08:22 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > I have good news now, I'm able to register to our bts manually. What I > did is download the latest openbsc sources and compiled the whole > project, that's it. I downloaded the project using git via port 80, I > posted a mail about that. So I guess the GPRS in the Rest Octets have > nothing to do, just the SIs were not complete. I'll analyze what went > wrong with the SIs. You don't mention which git branch you use, so its probably the master branch. If you look at the recent changes you will notice that the SYSTEM INFORMATION 3 and 4 rest octets are now set to the padding bytes which means they contain no information (which also means no GPRS). So this is the most important part where you have to look for differences. I can confirm that a HTC Touch Pro will not register to the BTS if the GPRS indication is set, it will register if it is not set. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 4

Re: Dummy load / direct wire connection concept
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Philipp, On Sun, 26 Jul 2009 21:43:22 +0200, "dexter" <zero-kelvin(a)gmx.de> wrote: > > I have no experience in those things, i never connected a sender and a > receiver directly for measurement proposes. I am afraid to damage BTS > and/or MS by trying the first solution. If you want to connect the BTS and an MS directly, you have to use an attenuator to reduce the signal to some "reasonable" level. To give you some numbers about "reasonable": The maximum RF output level of two different GSM tester which are intended for direct connection to an MS are -14 dBm for one of them and -40 dBm for the other. To be on the safe side I would make sure that the level is below -40 dBm, this is more than enough for good receiption (poor receiption is around -100 dBm). If the signal is too strong, you can damage the MS and/or BTS. Please note that I have not tried to connect a BTS and an MS yet, my experience comes from the GSM testers only. One problem I see with this approach is how to handle the separate RX and TX connectors of the BS-11. > What do you think, what would you do? How do you ensure that you do not > interfere with the with the official GSM networks? I think sometimes it > would be very nice to make 100% sure that no HF signals leave the desktop. I you can't make sure that no RF signal is emitted, you can at least try to cause as little trouble as possible: - use a GSM channel which is not used by an official network, make sure that there is at least one free guard channel in between the channel you use and the official channels. - set the power level of the BTS to its minimum (0.03 Watt for the BS-11) and set the NM_ATT_RF_MAXPOWR_R attribute to its maximum (6 for the BS-11). For the BS-11 the RF output level should then be around 1 dBm. - If you want to further reduce the BTS power, you can put an attenuator between antenna and TX output. - for the MS make sure that the power class is as low as possible when activatig a channel. - set the power for RACH access to a low level (in SYSTEM INFORMATION TYPE 3 and 4). - use an MCC and MNC which is not an official one. - only allow a know MS to register on your network. - To make sure that normal MSs won't be able to see your network, you can set the cell to "barred". However you then need a special MS to test, for example the Nokia Network Monitor allows to set the MS in a mode which allows to access barred cells. And with a special Test SIM it should be possible to access such a cell with other phones too (the "cell test" operation mode has to be enabled on the SIM). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

How to attack mobile networks with an iPhone (according to Apple)
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello, not sure if you already noticed this statement from Apple: http://www.wired.com/threatlevel/2009/07/jailbreak/ Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Harald, On Wed, 29 Jul 2009 16:55:23 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > Great! can you please provide one FR and one EFR pcap file for Andreas > Eversberg? It's probably best to replace the two corrupted files that I've > attached to the nanoBTS wiki-page. I am not sure if my two FR and EFR cpatures are good examples for the Wiki, the call is from one person only (me) counting numbers and saying "Hello Test" or similar things and you hear the voice on both channels because the two phones are close to each other. Of course they are good enough as an example for implementing the RTP media feature. So let me know if I shall provide them to Andreas only (Andreas, shall I send them to you as email, they are about 240 KByte as ZIP file ?). > You do have a wiki account, I assume. I don't think so, at least I have not yet requested an account. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Harald, On Wed, 29 Jul 2009 15:48:32 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > I'm telling you, OpenBSC's RTP proxy works fine. I've just made another call > and there are no drop-outs of .8 seconds or anything like that. I am sure that the proxy is working, I never doubt that. I guess for some reason Wireshark is just missing the data. I was joking about Windows versus Linux performance, but maybe this was not clear enough. > As all it uses is the sockets API, i.e. the very same calls that the > input/ipaccess.c module already uses, I think it should be very easy to make it > build using the posix compatibility of cygwin. I tried it in the meantime. No problem at all. The git version works as expected and Wireshark does not miss any packets here, each call is about 30 seconds. I tried it with EFR and FR, Wireshark can save the RTP payload, for EFR I had to convert the data first so that they fit to the GSM 06.35 reference implementation (they use a strange format which stores every bit into two bytes). For FR, Toast can convert the payload immediately. Tested on Windows XP and cygwin, Wireshark and bsc_hack running on the same machine. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

OpenBSC should now have full support for BS-11 with two TRX
by Harald Welte 29 Jul '09

29 Jul '09

Hi! Please note: =========================== commit d46299da00f923b24043aa37fa2bae17ffcc1ff7 make channel allocator policy multi-TRX aware For now, we assume that TRX1 (and higher) all have a TCH/F configuration on all of their timeslots commit 67b4c30a9de972d199830bba5535e934bd47ac0f complete TRX1 support for BS11 * remove old HAVE_TRX1 definition, replace it with '-1' commandline argument * make sure we actually configure the OML TRX attributes with a different ARFCN than TRX0 * make sure we configure timeslot 0 of TRX1 also in TCH/F mode This code is untested, but if you have a dual-trx BS-11, and the second TRX is activated, you should be able to run bsc_hack with the -1 option to enable and use the second trx. It works like this: * TRX1 shares E1 timeslot 0 for signalling * TRX1 RSL link uses TEI2 (TRX0 uses 1) * TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124 =========================== I'm very happy if somebody wans to test this. First of all, it is important to see if there are any error messages during OML and RSL brigup, and if the TEI2 link is actually established from mISDN. If you want to actually use the second TRX, you will either have to make sure all TCH/H on TRX0 are used (establish sufficient simultaneous calls), or hack chan_alloc.c to give a preference to TRX1, or to do round-robin or whatever :) Regards, -- - 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)

1 0