OpenBSC

openbsc@lists.osmocom.org

4317 discussions

Re: L3proc login password
by Dieter Spaar 06 Feb '09

06 Feb '09

Hello Bjoern, > Can't get logged in to the LMT. > It asks for a password (cambio menu). > "L3proc" isn't working... This is not the LMT COM Port, you have plugged the cable into the wrong port. Besides the LMT COM port, which is close to the E1 BNC connectors, there are several other COM ports which are directly routed to the various microcontrollers. There are some simple debug menues active during startup, but on the LMT port you won't get any reply without sending the correct message first. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

L3proc login password
by Bjoern Heller 06 Feb '09

06 Feb '09

Hi, Can't get logged in to the LMT. It asks for a password (cambio menu). “L3proc” isn't working... tec - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Björn Heller Jabber: tec(a)jabber.hellercom.de

1 0

major rework on the misdn / input plugin side
by Harald Welte 03 Feb '09

03 Feb '09

Hi! I was trying to get the data model right for the TRAU mux/demux handling, and discovered it is about time to re-do the entire 'input' side, i.e. the interface towards the actual E1 link. The main objectives are: 1) ability to deal with multiple BTS on one E1 link 2) ability to easily integrate E1 drivers != mISDN, e.g. zaptel while still keeping most of the E1 related functionality in common code 3) ability to easily add things like Abis over IP later So please stay tuned for some potentially quite big committs in that area during the next couple of days. -- - 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

software load via A-bis
by Harald Welte 02 Feb '09

02 Feb '09

Hi! JFYI: Software load through the A-bis / E1 interface is only marginally faster than through the serisal RS232 line. The theoretical maximum speed is the 64kbps of the E1 timeslot, which should give quite a bit of improvement over the 19200bps serial line. However, the BS-11 is throttling down the transver even via A-bis. I have tried to increase the window size to 20 (LMT has a max of 8. I tried up to 32 but then the transfer fails) The speed that I'm getting now is somewhere around 1232 bytes per second, which is about 9656bps. Do they use a 9600bps serial line somewhere inside the BS-11 to route those software updates through? I haven't finished an entire transfer, but it seems like the transfer would take some 36 minutes using this method. Not too far off the 45minutes that we get with LMT or bs11_config. I guess "in the field" this doesn't really matter since they can install the software image while the BTS is still in operation, and then at some point schedule a reboot which activates the new software. p.s.: yes, I removed all delays (usleep calls) from misdn.c before testing. -- - 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

bs11_config update
by Harald Welte 01 Feb '09

01 Feb '09

Hi! Just a quick update on bs11_config, the program used for BS-11 configuration over a serial line. I have now * successfully loaded SMU safety and software (SWL) from regular files in the filesystem (not as easy since BS-11 firmware comes as multiple files that need to be loaded consecutively) * created all objects required for minimal config, including TRX1/PA1 activation * display the A-bis/T link state, phase/subphase and MBBCU status from bs11_config Furthermore, I have added abis_nm functions to * set the A-bis external time (important for getting correct timestamps for alarms) * obtain the BS-11 serial number (as printed on the case). -- - 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

Re: Documentation of the BS-11 - what do we know?
by Dieter Spaar 21 Jan '09

21 Jan '09

Hello Holger, > Couldn't we use a GNU-Radio combined with the GSM-HF-RX? We had a > student research project which used that with Wireshark. I think I could > borrow it for a few days and sniff some stuff at our lab. Just tell me > what sequences you need. You mean the USRP ? As far as I know its no big problem to save the raw RF data with it but there is no easy-to-use software yet to get nice traces from those data (e.g. extract all the different channels like BCCH, CCCH and so on) which for example could be used to see the messages between the BTS and the phone. I am not interested in the traffic (speech or data), just the signaling on the Air-Interface would be nice to have. But lets see what the future brings, projects like airprobe.org might fill this gap. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: Documentation of the BS-11 - what do we know?
by Dieter Spaar 19 Jan '09

19 Jan '09

Hello Holger, > If you need some help in the near future (as soon our equipment arrives, > orders left the building today... or at least they should): we have full > equipped and licensed GSM-E1-Analyzers. I think we can provide some > traces if required (I know that Harald has shoot an ELMI-Abis-Analyzer > at EBay, just for notice). Good to know that. What about a GSM Analyzer for the Air Interface :-) ? In the moment ISDN E1 traces are not that important because its under control of OpenBSC anyway. The traces of the Siemens specific configuration commands were done on the RS232 interface of the BS-11, the configuration software under NDA uses RS232 only, at least I don't have any other BS-11 specific software which uses the ISDN interface. I anyone has access to a real GSM Abis Interface and can provide traces of a working network this could be very interesting to have a look at. And for tracing the GSM air inteface with cheap equipment, well, lets hope that we can get something for that in the future... Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: Documentation of the BS-11 - what do we know?
by Dieter Spaar 19 Jan '09

19 Jan '09

Hello Holger, The following is what I can say, Harald might add more or correct me: On Mon, 19 Jan 2009 10:15:17 +0100, "Holger Adams" <holger(a)kernreaktor.org> wrote: > > as we all know, the documentation of the BS-11 is under NDA. Harald > said, the BTS respects 99.9% of the A-bis 3GPP standardization. So my > questions are: > > 1) What's the part of the 0.1% we don't know? Which part differs from > the specs? There are Siemens specific commands for configuring the BS-11. They are not documented and also not included in the NDA documentation. The important commands are however going to become part of OpenBSC. Harald is currently working on a tool for configuring the BS-11, it is based on analyzing what the configuration tool (under NDA) is sending over the wire. So you will most certainly find all the required information in OpenBSC soon. > 2) During the 25c3 talk there was mentioned that the BTS uses ~6 DSPs > and a bunch of uCs. What kind of DSPs and uCs are used (well Siemens... > I guess some creepy 8051/C16x/... and Motorola stuff)? Its nothing from the more common stuff. The microcontrollers are from the HPC family from National Semiconductor, the DSPs are from the DSP16 family from Lucent. My guess is that the HPC was mainly used in the telcommunication area, for the DSP16 there was at least one more common analog modem around which uses it. BTW, the information about the microcontrollers and the DSPs is also not contained in the NDA documentation, so this is no secret what I am writing here. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

Documentation of the BS-11 - what do we know?
by Holger Adams 19 Jan '09

19 Jan '09

Hello Everybody, as we all know, the documentation of the BS-11 is under NDA. Harald said, the BTS respects 99.9% of the A-bis 3GPP standardization. So my questions are: 1) What's the part of the 0.1% we don't know? Which part differs from the specs? 2) During the 25c3 talk there was mentioned that the BTS uses ~6 DSPs and a bunch of uCs. What kind of DSPs and uCs are used (well Siemens... I guess some creepy 8051/C16x/... and Motorola stuff)? Regards, Holger -- () Holger Adams, <holger(a)kernreaktor.org> /\ WWW: http://www.kernreaktor.org

2 1

(no subject)
by David A. Burgess 17 Jan '09

17 Jan '09

Holger, Harald - I've been observing TMSI-handling bugs in GSM handsets for a while and saw a really good one last night, so I'm going to offer some comments here. > On Sat, Jan 10, 2009 at 01:40:33AM +0100, Holger Freyther wrote: > > Hey Guys, > > > > I'm currently implementing the CM Service Request of GSM 04.08 > and I wonder > > about the following: > > > > 1.) Some phones send us the TMSI of their current network > > 2.) One can ask the phone for the IMEISV/IMSI > > 3.) One can accept the LOCATION UPDATING REQUEST (or wait) > > 4.) A rogue MS could now request a channel with the BTS of the > original > > network > > 5.) Could send a CM Service Request with the TMSI of the > original phone and > > claim to not support A5 and such... > > 6.) Could initiate a call on the behalf of the other phone...? > > I think this would work, if > * we had a MS that we could fully control. > * the old network would accept the sudden classmark change for no > A5 support, > which in fact also depends on the cell itself. I would assume > that most > BTS in real-world netwokrs never announce that they support A5/0 According to GSM 02.07 Section 2, all GSM handsets are required support A5/1 and A5/2. According to GSM 02.09 Section 3.3, the network is SUPPOSED to deny service to any handset that doesn't support either A5/1 or A5/2. I'd be curious to see who's enforcing that, though. And any prudent operator will do an authentication at the start of a call, even for A5/0. Again, I'd be curious to see who's really doing it, but I'll bet most European operators do. You may not need to fully controlled a handset to do this, though. This is where TMSI handling bugs come into play. Last night, I was playing with a Treo 650. Having last registered in an AT&T network, the Treo sent a location updating request to my system (MNC=910, MCC=55) using that AT&T TMSI, which it is not supposed to do. I removed the SIM and cycled power. THAT should have cleared the old TMSI, but it came back to register by TMSI again. I sent a location updating accept, without sending a new TMSI. THAT should have cleared the old TMSI, but when I tried to place a mobile-oridinated call the Treo sent the same old AT&T-assigned TMSI in the CM service request. I am certain that if I had assigned a new TMSI to this handset and then switched off my system, that Treo would have taken my TMSI back the the AT&T network and tried to use it there. I suspect this kind of bug is fairly common and may be exploitable by a rogue network, even if only to expose the IMSI-TMSI relationships in the real carrier's BSC. As Harald points out, the attack described in the original e-mail should not work in a properly managed network. But I'll wager that most of the world's networks are not properly managed. -- David David A. Burgess OpenBTS on the web: http://openbts.sourceforge.net http://openbts.blogspot.com http://en.wikipedia.org/wiki/OpenBTS http://www.gnuradio.org/trac/wiki/OpenBTS

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC