OpenBSC

openbsc@lists.osmocom.org

2 participants
4173 discussions

Proposal: Code + directory restructuring

by Harald Welte

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)

14 years, 6 months

R: Re: [GSM Receiver] using OpenBSC as a GSM Receiver

by screaming-pain＠libero.it

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) > >

14 years, 6 months

[GSM Receiver] using OpenBSC as a GSM Receiver

by screaming-pain＠libero.it

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

14 years, 6 months

spec download

by Joe Eggleston

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

14 years, 6 months

libosmovty and OpenBSC Build Issues

by Matthew Harper

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

14 years, 6 months

[PATCH] sms: introduce new command to trigger the sending process for specific subscribers only

by Nico Golde

Hi, I'm not sure how useful this patch is for others, I found it quite useful during my sms testing. See attached patch file. Cheers Nico

14 years, 6 months

Timing Advance

by Nordin

Hello guys, I haven't been busy with openbsc for a while, however, I was following the mailing-list. I have the following question, is timing advance also implemented for the nanoBTS? Cause I don't really know where to look in the sources, thank you.

14 years, 6 months

Re: How to download firmware and configure NanoBTS the first time...

by Ravi Shankar

Nothing required actually. The firmware is preloaded.Just configure the Nanobts using the installation CD given. Some jar file is there for configuring part. > https://lists.osmocom.org/mailman/listinfo/openbsc > or, via email, send a message with subject or body 'help' to > openbsc-request(a)lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenBSC digest..." > > > Today's Topics: > > 1. Re: How to download firmware and configure NanoBTS the first > time... (Harald Welte) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Feb 2011 22:52:33 +0100 > From: Harald Welte <laforge(a)gnumonks.org> > Subject: Re: How to download firmware and configure NanoBTS the first > time... > To: Omar Atia <omar.atia(a)its.ws> > Cc: 'Peter Hasse' <peter.hasse(a)fokus.fraunhofer.de>, > openbsc(a)lists.osmocom.org > Message-ID: <20110216215233.GO25856(a)prithivi.gnumonks.org> > Content-Type: text/plain; charset=us-ascii > > Omar, > > how should we know in what you get your particular nanoBTS units delivered? > > You have to talk to your supplier about that. > > For all I know, it is customary for the nanoBTS to ship with pre-installed > firmware. Based on your support contract with ip.access you may receive > firmware updates from time to time, which you can then apply either using > tools from ip.access or using our ipaccess-config. Our tool is of course > not officially recognized/authorized/recommended/endorsed for this purpose. > > 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) > > > > ------------------------------ > > _______________________________________________ > OpenBSC mailing list > OpenBSC(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/openbsc > > > End of OpenBSC Digest, Vol 26, Issue 15 > *************************************** >

14 years, 6 months

[PATCH] sms: introduce new command to trigger the sending process for specific subscribers only

by Nico Golde

--- openbsc/src/vty_interface_layer3.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c index a575274..6cb9cbf 100644 --- a/openbsc/src/vty_interface_layer3.c +++ b/openbsc/src/vty_interface_layer3.c @@ -206,6 +206,24 @@ DEFUN(show_subscr, return CMD_SUCCESS; } +DEFUN(subscriber_send_pending_sms, + subscriber_send_pending_sms_cmd, + "subscriber " SUBSCR_TYPES " ID sms pending send", + SUBSCR_HELP "SMS Operations\n" "Send pending SMS\n") +{ + struct gsm_network *gsmnet = gsmnet_from_vty(vty); + struct gsm_subscriber *subscr = get_subscr_by_argv(gsmnet, argv[0], argv[1]); + struct gsm_sms *sms; + + sms = db_sms_get_unsent_by_subscr(gsmnet, subscr->id, UINT_MAX); + if(sms) + gsm411_send_sms_subscr(sms->receiver, sms); + + subscr_put(subscr); + + return CMD_SUCCESS; +} + DEFUN(subscriber_send_sms, subscriber_send_sms_cmd, "subscriber " SUBSCR_TYPES " ID sms send .LINE", @@ -766,6 +784,7 @@ int bsc_vty_init_extra(void) install_element(ENABLE_NODE, &smsqueue_max_cmd); install_element(ENABLE_NODE, &smsqueue_clear_cmd); install_element(ENABLE_NODE, &smsqueue_fail_cmd); + install_element(ENABLE_NODE, &subscriber_send_pending_sms_cmd); return 0; } -- 1.7.4.1 --fdj2RfSjLxBAspz7--

14 years, 6 months

AW: fix of chan_lcr / new socket interface for openbsc

by Andreas.Eversberg

hi harald, i would also suggest to combine mncc.h of openbsc and osmocom-bb first, and move it to libosmocore. this way the LCR (or other mncc_socket client) does not depend on any files of openbsc and osmocom-bb, just on libosmocore. because i like to use the same socket interface for osmocom-bb, i would suggest to to put mncc_sock.c into libosmocore too, so it must not be implemented twice. then i would make lcr to be able to connect to both osmocom-bb and openbsc sockets. finally there is no more polling of file descriptor required at lcr. if you agree, can you move the code to libosmocore? i will work on the socket configuration and see what i can do with the versioning. andreas -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Dienstag, 22. Februar 2011 13:22 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: fix of chan_lcr / new socket interface for openbsc Andreas, thanks for integrating the mncc socket patch into lcr. I would personally like to see the following improvements: * add some (preferrable automatically computed) version to the mncc, to make sure you cannot run lcr + bsc_hack built from a different mncc.h file. We could do something like a md5sum over the header at compilation time, stored in both openbsc and lcr. Once they connect the mncc socket, they request the remote side md5-value and compare it with the local-side value. If they don't match, print an error message and exit the program. * make the socket path configurable, which is required for running multiple instances of openbsc+lcr on the same machine. If you (or anyone else on this list) happens to have some time to work on that, it would be greatly appreciated. Regards, Harald

14 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC