OpenBSC March 2011

openbsc@lists.osmocom.org

20 participants
57 discussions

[PATCH] wireshark: gsm-abis-oml: convert C99 structure initialization to ANSI C
by Pablo Neira Ayuso 06 Mar '11

06 Mar '11

Hi! This patch applies on top of the wireshark/0001-abis_oml.patch. It converts the C99 structure initialization which is not accepted by the wireshark developers (Harald told me that they need it to compile with non-gcc compilers which don't always support C99). I have tested it here with four pcap files that Harald passed to me. It works fine. BTW, *with* and *without* this patch, wireshark with dissector spots warnings like: 18:14:15 Warn Dissector bug, protocol A-bis OML, in packet 13: packet-gsm_abis_oml.c:940: failed assertion "DISSECTOR_ASSERT_NOT_REACHED" It seems that some TLVs that appear in the body of packets are unknown. I'll debug which are the complaining tags and get back you.

4 14

New repository for BTS code
by Harald Welte 05 Mar '11

05 Mar '11

Hi! I've created a new git repository (osmo-bts.git) for the BTS-side code. You can browse it at http://cgit.osmocom.org/cgit/osmo-bts/ So far it only contains an import of Andreas' osmocom-bb.git jolly/bts branch, and some minimal modifications like include path changes. However, the code does not build yet. The TODO items are as follows: * de-couple the LAPDm code in OsmocomBB from references to osmcom_ms and other OsmocomBB specific data structures * put the LAPDm code into a shared library * link that library from both layer23 and osmo-bts * merge all common code and definitions/structures for RSL, OML and RTP together with the openbsc/src/lib{abis,trau} Regards, Harald -- - 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)

3 3

Proposal: Code + directory restructuring
by Harald Welte 04 Mar '11

04 Mar '11

Hi all! I've been thinking a bit about what kind of code (and directory / library) structure we should be having in order to build the various executables from the functional blocks that we have. The idea is to prepare for the upcoming / intended new projects while reusing the functional blocks / modules whenver possible. The graphical structure is at: http://openbsc.osmocom.org/trac/wiki/NewCodeStructure And the first steps in reorganizing directories and makefiles is available at http://cgit.osmocom.org/cgit/openbsc/log/?h=laforge/new_structure The new directory structure now has * directories that contain each one library openbsc/src/{abis,bsc,common,gb,mgcp,msc,trau} * directories that contain code for our daemons (BSC, etc.) openbsc/src/{gprs,osmo-bsc,osmo-bsc_mgcp,osmo-bsc_nat,osmo-nitb} * directories that contain code for utilities openbsc/src/{ipaccess,utils} There are still some additional/bogus dependencies between the libraries, but I want to fix that and make sure the TRAU directory really only contains code related to the TRAU and RTP frame processing. Some of the generic OML/RSL parsing code should be moved from 'bsc' into the 'abis' directory, etc. What do you generally think of this? If there is no big complaint, I intend to import Andreas' osmocom-bb.git/jolly/bts code into the openbsc repository (openbsc/src/bts) and start to merge the RTP code into src/trau and the generic bits of RSL+OML into src/abis. Some random ideas: * prefix the library directories with 'lib', i.e. 'libbsc', 'libmsc' to clearly state this is not a program but just library code * rename the openbsc repository to smething more generic. but what? I don't think we want to create multiple repositories but keep everything in a single repo - at least until one of the sub-libraries is self-contained enough. * should we keep bsc_hack instead of osmo-nitb? (network-in-the-box)? or should it rather be called osmo-niab (network-in-a-box)? Regards, Harald -- - 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 2

R: Re: [GSM Receiver] using OpenBSC as a GSM Receiver
by screaming-pain＠libero.it 04 Mar '11

04 Mar '11

Thanks Harald, > >No. You can only capture messages on the Abis interface between your own BTS >and BSC, but not sniff stuff off the air. I see this means I can only see the traffic that the BTS pass to the BSC but not all the on the air traffic. > That's what you can do with >Airprobe and OsmocomBB. > I know about the possibility to use OsmocomBB to sniff over the air, but I will need to transmit as well, I mean to replay some of the sniffed traffic, can this be done in anyway with OsmocomBB? or I will I have to use both OsmocomBB to sniff and OpenBTS to replay? Thanks again for the clarification, and sorry for the newbie questions but it's a bit difficult to figure out how things work without actually playing with them. Loretta >-- >- 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

[GSM Receiver] using OpenBSC as a GSM Receiver
by screaming-pain＠libero.it 03 Mar '11

03 Mar '11

hi I am new to the list, I am a phd student in the area of verification of security protocol, so not exactly a hacker or tech guru. Anyway, I am interested in using the OpenBSC to analyze GSM protocol messages. I don't want to decode them or do anything fancy, I am mainly interested in what it is sent in clear. Is it possible to use the OpenBSC architecture to capture GSM messages and later analyze them using wireshark? I know this is possible using the USRP, but I would like to use OpenBSC. Anyway is there any particular reason why you are not supporting the USRP? Thanks

2 1

spec download
by Joe Eggleston 03 Mar '11

03 Mar '11

Hi all, Maybe I'm missing something, but I haven't found an easy way to download pdf versions of all the 3gpp specs. Why would you want to do that? Well, dealing with MS-Word format is a pain. And, there's no online full-text search of all the specs. So, I threw together a quick web scraper to pull down the latest version of all the 3GPP specs from the ETSI web site in pdf format. Thought it might be useful to others - http://monkey.org/~joe/files/fetch_3gpp.py Feel free to contact me if you have any trouble using it. -Joe

2 1

libosmovty and OpenBSC Build Issues
by Matthew Harper 01 Mar '11

01 Mar '11

Hello All, I have just tried to compile the latest version of OpenBSC as cloned from git. When running the configure script I run into problems with libosmovty, I receive the error. Requested 'libosmovty >= 0.1.28' but version of Osmocom VTY Interface Library is 0.1.27.45-de79. I built libosmocore from the latest git clone. Can anyone please offer any guidance on how I can resolve this issue or how I can go about installing the latest libosmovty library. Many Thanks Matty Harper

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2011