Hello, First of all congratulations to all people involved in this project. I am new to this list but I watch the project for some time. I have some questions and maybe some ideas how to make this project testers or enthusiasts friendly. I work with BSCes and BTSes every day at my work but I would like to try and play with OpenBSC but the installation and configuration looks time consuming and not friendly at all. I have some questions and suggestions below: * What about some packages for OpenBSC so we can install them easier from a repository? How hard, time consuming is to make a nightly build of the git sources and have some pre-compiled Debian packages? * Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC. * Now, more like a project design request. There is not so much documentation how to configure the parameters of OpenBSC, SGSN and BTS so a web interface also would be nice and very helpful. Second thing on this topic, moving configuration from one server to another needs to be exported easily and imported in the same way to new hardware. What about a DB that keeps all the settings and with one command in CLI or web interface you export everything and import it on another hardware? I am sorry if some things are already in OpenBSC but it's kind of hard to find important stuff on that wiki. Also I know that OpenBSC is under hard development so new features might come later. Best regards, R.
On 01/08/2012 01:29 PM, Labs wrote:
Hello,
First of all congratulations to all people involved in this project. I am new to this list but I watch the project for some time. I have some questions and maybe some ideas how to make this project testers or enthusiasts friendly.
welcome! From my point of view the barrier is not lack of packages or documentation but more the lack of affordable hardware.
* What about some packages for OpenBSC so we can install them easier from a repository? How hard, time consuming is to make a nightly build of the git sources and have some pre-compiled Debian packages?
Thank to Jan we have packages.osmocom.org with Debian/Ubuntu packages, our libraries are also on the way into debian repositories (again thanks to Jan's effort). We do not have nightly builds though, I don't know Debian's policy of automatically signing nightly builds though.
* Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
* Now, more like a project design request.
There is not so much documentation how to configure the parameters of OpenBSC, SGSN and BTS so a web interface also would be nice and very helpful.
I have started generating XML (to be used by docbook or converted to Trac Wiki Syntax) from our VTY (Virtual TeleType) interface. The XML generated from the application can be merged (via XSLT) with additional documentation and then be included in any kind of documentation.
Second thing on this topic, moving configuration from one server to another needs to be exported easily and imported in the same way to new hardware. What about a DB that keeps all the settings and with one command in CLI or web interface you export everything and import it on another hardware?
I don't understand this part, our config files are plain text and can be copied around nicely. I assume you refer to something else. We also have the beginning of a Machine-Interface (gdb terminology) but no conclusion of how to combine that with the vty. To summarize, you are more than welcome to help us on the documentation part, bring more structure to the wiki, create a docbook for OpenBSC, include the VTY commands and config options in a reference kind of manual.
Holger Hans Peter Freyther wrote:
* Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
For anyone who wishes to try this and feed back results into the project I can recommend requesting an account for the GCC Compile Farm, which has several sparc and sparc64 hosts. No cost. http://gcc.gnu.org/wiki/CompileFarm //Peter
On 09-Jan-12 10:34, Peter Stuge wrote:
Holger Hans Peter Freyther wrote:
* Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
For anyone who wishes to try this and feed back results into the project I can recommend requesting an account for the GCC Compile Farm, which has several sparc and sparc64 hosts. No cost.
The problem is not hardware. I guess it's more like CPU architecture issue. I think many things needs to be changed...
//Peter
R.
Hi all, On Sun, Jan 08, 2012 at 02:33:04PM +0100, Holger Hans Peter Freyther wrote:
First of all congratulations to all people involved in this project. I am new to this list but I watch the project for some time. I have some questions and maybe some ideas how to make this project testers or enthusiasts friendly.
welcome! From my point of view the barrier is not lack of packages or documentation but more the lack of affordable hardware.
I whole-heartedly agree.
* Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
Well, we have to be careful here. So far, to the best of my knowledge, OpenBSC has been tested (and deployed) on x86, x86_64 and ARM, all in little endian mode. Running OpenBSC on a big endian platform like SPARC or PPC might run us into some trouble, especially if the endianness of bit-fields is different, a lot of our definitions in libosmocore/include/osmocom/gsm/protocol/ will have to be adapted/fixed. So I would suggest to at least first verify OpenBSC works for you on x86/x86_64 or ARM, and then proceed to SPARC32/SPARC64 in a next step. If you encounter a given bug, you can always test against x86 in order to see if it is caused by the architecture difference or a general bug.
There is not so much documentation how to configure the parameters of OpenBSC, SGSN and BTS so a web interface also would be nice and very helpful.
I agree there is not much documentation, but it is a community project and we invite everyone to contribute not only in code but also in documentation. There are at least several dozen people on this list who have successfully installed and used OpenBSC, and who have the skills to write and/or improvde documentation - as opposed to the handful of people who actually are working hard to improve and extend the code. Also, regarding a web interface: Tens of thousands of network administrators world wide are able to work with cisco style interfaces on routers and switches without any problem. Agreed, there is good documentation available. But I'm really against some kind of web interface. Operating a GSM network should be done by people who have at least some level of technical understanding of what they are doing. If we appear to make it usable by everone, even people with zero technical knowledge, we can assume that they will run RF equipment in configurations which are neither legal nor safe and which will only get them in trouble eventually. So yes, there should be better reference documentation and guides/HOWTOs. But please don't talk about making this software usable to non-technical people. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hello Harald, On 09-Jan-12 12:26, Harald Welte wrote:
welcome! From my point of view the barrier is not lack of packages or documentation but more the lack of affordable hardware.
I whole-heartedly agree.
As all probably know, imagine what can happen when you sell on the street 3000 BTS units?! Operators that replace entire network will sell everything to poor countries in one package. Not all the people have enough knowledge to operate RF equipments and bad things can happen. I guess I said enough here...
Well, we have to be careful here. So far, to the best of my knowledge, OpenBSC has been tested (and deployed) on x86, x86_64 and ARM, all in little endian mode.
Running OpenBSC on a big endian platform like SPARC or PPC might run us into some trouble, especially if the endianness of bit-fields is different, a lot of our definitions in libosmocore/include/osmocom/gsm/protocol/ will have to be adapted/fixed.
So I would suggest to at least first verify OpenBSC works for you on x86/x86_64 or ARM, and then proceed to SPARC32/SPARC64 in a next step.
If you encounter a given bug, you can always test against x86 in order to see if it is caused by the architecture difference or a general bug.
This is what I was afraid of, that's why I asked first before loosing time. Thanks for confirming this point.
Also, regarding a web interface: Tens of thousands of network administrators world wide are able to work with cisco style interfaces on routers and switches without any problem. Agreed, there is good documentation available. But I'm really against some kind of web interface. Operating a GSM network should be done by people who have at least some level of technical understanding of what they are doing.
I like the CLI but to check the status of an E1 line, change some IP addresses, check the temperature of TRX modules or other small things I guess is not a problem and it's not that I cannot type a few commands.
If we appear to make it usable by everone, even people with zero technical knowledge, we can assume that they will run RF equipment in configurations which are neither legal nor safe and which will only get them in trouble eventually.
I agree with you until some point. From what you say this means that OpenBSC will never be usable because some zero technical can use it to run RF equipments and who knows what can happen. Am I wrong here?
So yes, there should be better reference documentation and guides/HOWTOs. But please don't talk about making this software usable to non-technical people.
If some people will want to run some RF equipments they will do it with or without help of OpenBSC. All new BSC hardware from X,Y,Z vendors are running Linux now. If the BSC doesn't look like a normal PC this doesn't mean anything. They use x86 HW combined with some FPGA and that's all. A little tweaking and you can run it on low cost hardware. Another thing, maybe it will be easier for a programmer to run OpenBSC than a RAN/CN engineer without programming skills. Last part was from a discussion at work today. Watching the lists and blogs I know that everybody on this project worked hard and I am sorry if what I said is wrong. Best regards, R.
On 01/08/2012 02:33 PM, Holger Hans Peter Freyther wrote:
welcome! From my point of view the barrier is not lack of packages or documentation but more the lack of affordable hardware.
What do you mean affordable hardware? I guess it's not about servers running OpenBSC but BTS hardware which is hard to find. My idea is that if you want cheap hardware go and ask an operator which is replacing the old BTS equipments with new one from other vendors. In Germany I know at least 2 operators which are swapping right now with other vendor all network so you will have on the market thousands of BTS equipments, mostly Siemens. The problem is power and space because you will not find micro-cells. They mostly have big ones.
Thank to Jan we have packages.osmocom.org with Debian/Ubuntu packages, our libraries are also on the way into debian repositories (again thanks to Jan's effort). We do not have nightly builds though, I don't know Debian's policy of automatically signing nightly builds though.
I already checked the link but the package repository doesn't keep up with updates from git repository. Most of them were built in the summer last year, that's why I wanted a nightly built to have the latest bug fixes and features.
* Did somebody try to build OpenBSC on SPARC architecture? I have some Sun servers that I would like to use for this project. Same thing like before, some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
That's bad because I wanted to run OpenBSC on SPARC and my programming skills are almost zero and some help with compiling was nice. :=)
I have started generating XML (to be used by docbook or converted to Trac Wiki Syntax) from our VTY (Virtual TeleType) interface. The XML generated from the application can be merged (via XSLT) with additional documentation and then be included in any kind of documentation.
Normally I prefer the VTY on any kind of hardware configuration but the VTY for OpenBSC is not so intuitive and helpful that's why I asked for a web interface to help setup the BSC, BTS and transmission parts. I guess you were referring to osmo-nitb. http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY My idea was to change the way it is now and split the commands in: "list or show or get" - for checking already set parameters "display" - for checking live parameters, like transport layer errors, line up, down, BTS up, down "set,add" - for adding new configuration parameters "modify" - for changing a parameter value This will be the main commands and after you can define the parameters and also split them in some classes like BTS transport layer configuration, IP or E1 configuration for BSC, Cell and frequency parameters, etc. In this way it will be much easier to know what you will configure. There is more to discuss on this topic...
I don't understand this part, our config files are plain text and can >be copied around nicely. I assume you refer to something else. We also have the beginning of a Machine-Interface (gdb terminology) but no conclusion of how to combine that with the vty.
I was talking about all config parameters to be in one DB and not in text files. Also it can be an XML file with all configuration and not many text files. From VTY just run let's say "backup live-config" command and you will have an XML with all configuration that you can move on other hardware. XML should contain everything like E1 or IP settings, BTS and cell parameters, etc.
To summarize, you are more than welcome to help us on the documentation part, bring more structure to the wiki, create a docbook for OpenBSC, include the VTY commands and config options in a reference kind of manual.
I will gladly help but I will need first to make some time. I am very busy with jobs and kids but I will try in the next weeks to set up a lab at home for OpenBSC and after we can discuss more based on real facts. Thank you, R.
Hi,
In Germany I know at least 2 operators which are swapping right now with other vendor all network so you will have on the market thousands of BTS equipments, mostly Siemens. The problem is power and space because you will not find micro-cells. They mostly have big ones.
The "micro cell" was implied ... of course not every one wants a macro cell to play with. Also "cheap" is like < 1kEUR new and probably < 500 EUR used.
That's bad because I wanted to run OpenBSC on SPARC and my programming skills are almost zero and some help with compiling was nice. :=)
Well, here's a chance to learn. And do yourself a favor and pick up any mini-itx x86 board and run it on that ...
Normally I prefer the VTY on any kind of hardware configuration but the VTY for OpenBSC is not so intuitive and helpful that's why I asked for a web interface to help setup the BSC, BTS and transmission parts.
If you had any experience with cisco, it would be pretty intuitive ... also there is autocompletion
My idea was to change the way it is now and split the commands in: "list or show or get" - for checking already set parameters "display" - for checking live parameters, like transport layer errors, line up, down, BTS up, down "set,add" - for adding new configuration parameters "modify" - for changing a parameter value
Just because _you_ don't like it doesn't mean we'll all change our way of doing things to accommodate you. I personally like the current config method and it allows to do everything you listed above (with different command names) and so I don't see any benefit of spending a significant amount of time rewriting code that works ....
I was talking about all config parameters to be in one DB and not in text files. Also it can be an XML file with all configuration and not many text files.
"many" ? OpenBSC has exactly 1 text file ... and why on earth would we want to change that to a binary db format, or worse an XML ... The text file is easily readable and editable by hand and matches the VTY commands (so once you know one, you know the other)
From VTY just run let's say "backup live-config" command and you will have an XML with all configuration that you can move on other hardware.
XML should contain everything like E1 or IP settings, BTS and cell parameters, etc.
The OpenBSC config contains ... the OpenBSC config. All other parameters (IP or E1 card driver settings ...) are outside of scope of this project. This is meant to be a software BSC, not an "appliance". If you want to make it "appliance" like with all the OS and surrounding drivers and some kind of unified config for everything and such, feel free to start a new project for that, but this is independent of the core BSC software. If you don't have the time or skill for that, you can always hire someone to do it for you. Cheers, Sylvain
On 09-Jan-12 09:16, Sylvain Munaut wrote:
The "micro cell" was implied ... of course not every one wants a macro cell to play with. Also "cheap" is like< 1kEUR new and probably< 500 EUR used.
500 EUR for a used micro-cell is not much considering what is inside and what you can do with it. The problem is who is selling you one? You can get a Layer 3 switch for a lot more so the price is ok
Well, here's a chance to learn. And do yourself a favor and pick up any mini-itx x86 board and run it on that ...
My main issue is that where I have the BTS, I cannot go with my own server/laptop and I need to use the servers/workstations in there.
If you had any experience with cisco, it would be pretty intuitive ... also there is autocompletion
I have experience with Cisco and Juniper hardware and CLI but for some basic things I prefer to have a web console.
Just because _you_ don't like it doesn't mean we'll all change our way of doing things to accommodate you. I personally like the current config method and it allows to do everything you listed above (with different command names) and so I don't see any benefit of spending a significant amount of time rewriting code that works ....
I didn't say that I don't like it but the VTY commands are not so intuitive. For example tell me how I can check what "CellID" I have configured for BTS "X" from the VTY? There is no option from what I can see in the wiki to list configured parameters on BSC?! I didn't yet installed OpenBSC so I am telling this after reading the wiki. Sorry if there is such option but not documented.
OpenBSC has exactly 1 text file ... and why on earth would we want to change that to a binary db format, or worse an XML ... The text file is easily readable and editable by hand and matches the VTY commands (so once you know one, you know the other)
When I refer to config this means also the config for management interfaces of server, users, firewall settings (if any configured).
The OpenBSC config contains ... the OpenBSC config. All other parameters (IP or E1 card driver settings ...) are outside of scope of this project. This is meant to be a software BSC, not an "appliance".
OpenBSC config should also contain the config for IP or E1 cards because otherwise you software BSC will not work without it. I would say that is a mandatory dependency. This is just my way of thinking...
If you want to make it "appliance" like with all the OS and surrounding drivers and some kind of unified config for everything and such, feel free to start a new project for that, but this is independent of the core BSC software. If you don't have the time or skill for that, you can always hire someone to do it for you.
I am not planning to make any appliance for it. I was just thinking for a way to make a fast recovery of a deployment/test lab. It will take a couple of days to make all the settings again if something goes wrong with hardware, right?
Cheers,
Thanks's for sharing some light and excuse me if some things are wrong. This is how I am seeing things from outside and after reading the project pages.
Sylvain
Regards, R.
On 01/09/2012 07:39 PM, Labs wrote:
On 09-Jan-12 09:16, Sylvain Munaut wrote:
Thanks's for sharing some light and excuse me if some things are wrong. This is how I am seeing things from outside and after reading the project pages.
It is not wrong, we appear to follow different philosophies here. We follow the Unix one, our BSC is doing what a BSC should do by definition (assigning radio resources). What you want is that OpenBSC is an appliance and include things that would be provided by other parts of the system. E.g. Link State, Firewall settings should probably go through SNMP, mISDN should export the MIB via procfs, the SNMP daemon should read this file to provide the status to whoever asks. In case the A-link is the only interface to the outside the BSC could help to tunnel SNMP over the O&M link. In one point you are right, our documentation is not mature, incomplete, outdated. Do you want to help to correct that? holger
On 09-Jan-12 20:57, Holger Hans Peter Freyther wrote:
Thanks's for sharing some light and excuse me if some things are wrong. This is how I am seeing things from outside and after reading the project pages.
It is not wrong, we appear to follow different philosophies here. We follow the Unix one, our BSC is doing what a BSC should do by definition (assigning radio resources). What you want is that OpenBSC is an appliance and include things that would be provided by other parts of the system.
Let's see; below is quote from the main page: Quote: "What this means: OpenBSC is not just a standard BSC, but a GSM network in a box software, implementing the minimal necessary parts to build a small, self-contained GSM network. OpenBSC includes functionality normally performed by the following components of a GSM network: BSC (Base Station Controller), MSC (Mobile Switching Center), HLR (Home Location Register), AuC (Authentication Center), VLR (Visitor Location Register), EIR (Equipment Identity Register)." What you have here in real/live network are a few racks, not to mention the SGSN and GGSN that you have already implemented. Am I missing something? Sorry for saying that but it looks like to me that it is an appliance.
E.g. Link State, Firewall settings should probably go through SNMP, mISDN should export the MIB via procfs, the SNMP daemon should read this file to provide the status to whoever asks. In case the A-link is the only interface to the outside the BSC could help to tunnel SNMP over the O&M link.
I didn't install yet the OpenBSC but as I said in a previous email I will have it done by the end of next week and check all configs. I was thinking that you already have everything implemented in OpenBSC (BSC/MSC/VLR/HLR/AuC/EIR/SGSN/GGSN) and the only interfaces out are Abis (IP or E1) and another ethernet for management of OpenBSC box. So from my assumption above it started the idea with all-in-one config and GUI for the mentioned pieces of this puzzle. I guess I am wrong here...
In one point you are right, our documentation is not mature, incomplete, outdated. Do you want to help to correct that?
I would really like to do that but I am not a programmer and I will/can write documentation based on my tests and real life experience. We need to discuss more on this topic.
holger
Best regards, R.
Labs wrote:
Am I missing something? Sorry for saying that but it looks like to me that it is an appliance.
I understand your reasoning. Some points come to mind: * An appliance is an integrated system and not only a software package OpenBSC can certainly be part of something larger, but it is "just" a software package, even if a very comprehensive one. So far I don't know about any open source appliances using OpenBSC. One thing that might be interesting to make the very first testing easier would be a preconfigure VM image that could be started to have an OpenBSC running in seconds, for when the environment being used is not so convenient for downloading and building the source, and configuring network interfaces. We had some tangential discussions at 28c3 in Berlin between X-mas and NYE, where we last ran an OpenBSC test network. * The OpenBSC software may be integrated in many different ways OpenBSC does not neccessarily run only on Linux operating systems (maybe this is actually a requirement now, but I don't think it needs to be, and generally it is good to have software be portable across many different operating systems) - this is significant because any interface configuration is always highly system specific, and every integration will have different processes here. Following the UNIX principle, this is outside the scope of OpenBSC. Ie. interface configuration is one step considered belonging to the base system, while software configuration to use those interfaces is a separate step which needs to match the system base configuration. I actually don't think it is such a bad idea to also have OpenBSC be involved in, or even take responsibility for, some interface configuration, but this may well require some significant changes in the source code, so it will not happen very quickly. If it happens I would argue that OpenBSC should configure only those interfaces which are related to GSM, and that they be kept separate from the "regular" interfaces used by the system. Such a change will tie OpenBSC more strongly to the particular operating systems it runs on, which is generally considered a bad thing. However, I agree with you that there is a certain value to indeed have all GSM-network-related configuration, including IP, in the configuration file. Also note that I'm not really a core developer, so even if I kindof like the idea that does not have to mean very much. :)
I didn't install yet the OpenBSC but as I said in a previous email I will have it done by the end of next week and check all configs.
You should be able to do it rather quickly, also without being a programmer. The dependencies are not very many.
I was thinking that you already have everything implemented in OpenBSC (BSC/MSC/VLR/HLR/AuC/EIR/SGSN/GGSN) and the only interfaces out are Abis (IP or E1) and another ethernet for management of OpenBSC box. So from my assumption above it started the idea with all-in-one config and GUI for the mentioned pieces of this puzzle.
I guess I am wrong here...
GUI or CLI is a matter of (sometimes strong) taste. I think it's fine to have different types of user interfaces, but this will possibly require re-engineering of the existing CLI config interface a bit, so that other types of interfaces can be integrated seamlessly. Of course it's also possible to build a GUI which in fact just uses the CLI and has nice buttons to click on. All relevant information must be available through CLI anyway.
I will/can write documentation based on my tests and real life experience. We need to discuss more on this topic.
All contributions are valuable, and you absolutely don't have to be a programmer to be able to contribute. Documentation contributions, in particular from real life experience, are indeed very welcome! //Peter
On 09-Jan-12 23:48, Peter Stuge wrote:
I understand your reasoning. Some points come to mind:
* An appliance is an integrated system and not only a software package
OpenBSC can certainly be part of something larger, but it is "just" a software package, even if a very comprehensive one. So far I don't know about any open source appliances using OpenBSC. One thing that might be interesting to make the very first testing easier would be a preconfigure VM image that could be started to have an OpenBSC running in seconds, for when the environment being used is not so convenient for downloading and building the source, and configuring network interfaces.
This is what I will do so I will be able to move the image in different labs but my main issue will be how I will connect an E1 transmission based BTS to a VM?! I also don't have an E1 PCI card to plug-in in a PC. I will check if I can use a Cisco router with an E1 port WIC or NM module and send the traffic via ethernet to VM. Did somebody try it? I will start a new topic for this one...
We had some tangential discussions at 28c3 in Berlin between X-mas and NYE, where we last ran an OpenBSC test network.
So there are more people thinking like me?
* The OpenBSC software may be integrated in many different ways
OpenBSC does not neccessarily run only on Linux operating systems (maybe this is actually a requirement now, but I don't think it needs to be, and generally it is good to have software be portable across many different operating systems) - this is significant because any interface configuration is always highly system specific, and every integration will have different processes here. Following the UNIX principle, this is outside the scope of OpenBSC. Ie. interface configuration is one step considered belonging to the base system, while software configuration to use those interfaces is a separate step which needs to match the system base configuration.
I am thinking that you always need to separate the traffic based on destination. That being said you will not use the same interface for management of the box and also for Abis or A interfaces. All of them should be separately defined. Management interface can be defined via normal OS way (or an OpenBSC GUI/startup menu?) but the rest of interfaces should be defined via OpenBSC config. I don't know how it works now, is there any "limitation" or you can have everything on one ethernet interface?
I actually don't think it is such a bad idea to also have OpenBSC be involved in, or even take responsibility for, some interface configuration, but this may well require some significant changes in the source code, so it will not happen very quickly.
I know all of you dedicated a lot of time for this project but design should be done in advance so there will not be a complete re-write of the code in case of small/big? changes. Sorry if somebody feels hurt here. It is just my thinking about this, please no hard feelings.
If it happens I would argue that OpenBSC should configure only those interfaces which are related to GSM, and that they be kept separate from the "regular" interfaces used by the system.
Correct, agree.
Such a change will tie OpenBSC more strongly to the particular operating systems it runs on, which is generally considered a bad thing. However, I agree with you that there is a certain value to indeed have all GSM-network-related configuration, including IP, in the configuration file.
It is considered bad but you cannot just keep on testing different behaviors on all Linux flavors. I think most, probably 99%, are running the project on Debian. Regarding configuration, maybe it will change in time, who knows?
Also note that I'm not really a core developer, so even if I kindof like the idea that does not have to mean very much. :)
It is an open source project so I guess we can have an open discussion on different ideas or design changes that's why I started this thread.
I didn't install yet the OpenBSC but as I said in a previous email I will have it done by the end of next week and check all configs.
You should be able to do it rather quickly, also without being a programmer. The dependencies are not very many.
I know it will be fast just need some time to power on my VMware server. I shut it down last year...
GUI or CLI is a matter of (sometimes strong) taste. I think it's fine to have different types of user interfaces, but this will possibly require re-engineering of the existing CLI config interface a bit, so that other types of interfaces can be integrated seamlessly.
Of course it's also possible to build a GUI which in fact just uses the CLI and has nice buttons to click on. All relevant information must be available through CLI anyway.
I guess I put it in the wrong way in my first email. I work with CLI everyday but for some things I like the GUI. I am probably used with the commercial BSC CLI/GUI so... I prefer to have a GUI for checking fast some transmission line parameters (type/line code/BER results/IP address of BTS), check and reset different BTS boards that go crazy sometime... I am not sure what you can do now in regard to BTS components/modules and if the OML commands sent to BTS can do the above things. I am working on integration/operation of RAN so I need to combine both to be fast and fix the issues.
I will/can write documentation based on my tests and real life experience. We need to discuss more on this topic.
All contributions are valuable, and you absolutely don't have to be a programmer to be able to contribute. Documentation contributions, in particular from real life experience, are indeed very welcome!
I will definitely start to write some docs and update the wiki after I will install and get used with the project.
//Peter
R.
If you have a nanoBTS, you can install/setup and run your own network very easy. There is no E1 interface needed or a special lib or a modified kernel or something. Just install debian and other libs you can easily install it with apt, git-clone the project and connect the bts with a utp-cable and you're on the go. If I can do it, I'm sure everybody else can do it. When you get that running, than you can talk about lack of documentation, or better design or whatever. Good luck. On 10-1-2012 0:43, Labs wrote:
On 09-Jan-12 23:48, Peter Stuge wrote:
I understand your reasoning. Some points come to mind:
* An appliance is an integrated system and not only a software package
OpenBSC can certainly be part of something larger, but it is "just" a software package, even if a very comprehensive one. So far I don't know about any open source appliances using OpenBSC. One thing that might be interesting to make the very first testing easier would be a preconfigure VM image that could be started to have an OpenBSC running in seconds, for when the environment being used is not so convenient for downloading and building the source, and configuring network interfaces.
This is what I will do so I will be able to move the image in different labs but my main issue will be how I will connect an E1 transmission based BTS to a VM?!
I also don't have an E1 PCI card to plug-in in a PC. I will check if I can use a Cisco router with an E1 port WIC or NM module and send the traffic via ethernet to VM. Did somebody try it? I will start a new topic for this one...
We had some tangential discussions at 28c3 in Berlin between X-mas and NYE, where we last ran an OpenBSC test network.
So there are more people thinking like me?
* The OpenBSC software may be integrated in many different ways
OpenBSC does not neccessarily run only on Linux operating systems (maybe this is actually a requirement now, but I don't think it needs to be, and generally it is good to have software be portable across many different operating systems) - this is significant because any interface configuration is always highly system specific, and every integration will have different processes here. Following the UNIX principle, this is outside the scope of OpenBSC. Ie. interface configuration is one step considered belonging to the base system, while software configuration to use those interfaces is a separate step which needs to match the system base configuration.
I am thinking that you always need to separate the traffic based on destination. That being said you will not use the same interface for management of the box and also for Abis or A interfaces. All of them should be separately defined.
Management interface can be defined via normal OS way (or an OpenBSC GUI/startup menu?) but the rest of interfaces should be defined via OpenBSC config. I don't know how it works now, is there any "limitation" or you can have everything on one ethernet interface?
I actually don't think it is such a bad idea to also have OpenBSC be involved in, or even take responsibility for, some interface configuration, but this may well require some significant changes in the source code, so it will not happen very quickly.
I know all of you dedicated a lot of time for this project but design should be done in advance so there will not be a complete re-write of the code in case of small/big? changes. Sorry if somebody feels hurt here. It is just my thinking about this, please no hard feelings.
If it happens I would argue that OpenBSC should configure only those interfaces which are related to GSM, and that they be kept separate from the "regular" interfaces used by the system.
Correct, agree.
Such a change will tie OpenBSC more strongly to the particular operating systems it runs on, which is generally considered a bad thing. However, I agree with you that there is a certain value to indeed have all GSM-network-related configuration, including IP, in the configuration file.
It is considered bad but you cannot just keep on testing different behaviors on all Linux flavors. I think most, probably 99%, are running the project on Debian.
Regarding configuration, maybe it will change in time, who knows?
Also note that I'm not really a core developer, so even if I kindof like the idea that does not have to mean very much. :)
It is an open source project so I guess we can have an open discussion on different ideas or design changes that's why I started this thread.
I didn't install yet the OpenBSC but as I said in a previous email I will have it done by the end of next week and check all configs.
You should be able to do it rather quickly, also without being a programmer. The dependencies are not very many.
I know it will be fast just need some time to power on my VMware server. I shut it down last year...
GUI or CLI is a matter of (sometimes strong) taste. I think it's fine to have different types of user interfaces, but this will possibly require re-engineering of the existing CLI config interface a bit, so that other types of interfaces can be integrated seamlessly.
Of course it's also possible to build a GUI which in fact just uses the CLI and has nice buttons to click on. All relevant information must be available through CLI anyway.
I guess I put it in the wrong way in my first email. I work with CLI everyday but for some things I like the GUI. I am probably used with the commercial BSC CLI/GUI so...
I prefer to have a GUI for checking fast some transmission line parameters (type/line code/BER results/IP address of BTS), check and reset different BTS boards that go crazy sometime...
I am not sure what you can do now in regard to BTS components/modules and if the OML commands sent to BTS can do the above things.
I am working on integration/operation of RAN so I need to combine both to be fast and fix the issues.
I will/can write documentation based on my tests and real life experience. We need to discuss more on this topic.
All contributions are valuable, and you absolutely don't have to be a programmer to be able to contribute. Documentation contributions, in particular from real life experience, are indeed very welcome!
I will definitely start to write some docs and update the wiki after I will install and get used with the project.
//Peter
R.
On 10-Jan-12 11:40, nordin wrote:
If you have a nanoBTS, you can install/setup and run your own network very easy. There is no E1 interface needed or a special lib or a modified kernel or something. Just install debian and other libs you can easily install it with apt, git-clone the project and connect the bts with a utp-cable and you're on the go. If I can do it, I'm sure everybody else can do it.
I installed today Debian and compiled OpenBSC in a VMware machine according to the guide here: http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC After this I tried to load run osmo-nitb -c and one example config and I got the error: "(000) telnet_interface.c:85 Telnet interface failed to bind" After 4 hours of searching and trying to see what is wrong I just quit.
When you get that running, than you can talk about lack of documentation, or better design or whatever. Good luck.
Do you have any idea what is wrong with that error? I don't have access to any nanoBTS and apparently is hard to get one. I have other BTS units to test with but all are using E1 and I don't have any PCI E1 card. After I will see it running in a VM I will try to use a Cisco router to send the Abis from E1 to ethernet in VM. Regards, R.
Hi,
"(000) telnet_interface.c:85 Telnet interface failed to bind"
No idea how that could be unless you are on a heavily restricted system ... or if you have something else listening on port 4242 Basically it means it wasn't able to "listen/open" the port for the telnet config on port 4242
I will try to use a Cisco router to send the Abis from E1 to ethernet in VM.
I've never been able to find how to do that ... that doesn't seem to be supported AFAICT ... Cheers, Sylvain
On 10-Jan-12 21:18, Sylvain Munaut wrote:
Hi,
"(000) telnet_interface.c:85 Telnet interface failed to bind"
No idea how that could be unless you are on a heavily restricted system ... or if you have something else listening on port 4242 Basically it means it wasn't able to "listen/open" the port for the telnet config on port 4242
The system was installed fresh today with Debian net-install CD (minimal install with SSH server option). After this I installed the packages listed in wiki plus another one not listed in there, I guess it was libortp8 and was a dependency to openbsc. I checked with netstat and nothing is running on that port. There is no SElinux or iptables running on that machine... Strange behavior.
I will try to use a Cisco router to send the Abis from E1 to ethernet in VM.
I've never been able to find how to do that ... that doesn't seem to be supported AFAICT ...
I will manage it somehow and if not I will try to get a native IP BTS to connect to OpenBSC but that one doesn't have any Abis written in OpenBSC so it will be tough... I have the traces for new hardware and I will have to compare with what you have to see which one is closer. Many things to do with no spare time...
Cheers,
Sylvain
Thank you Sylvain, R.
On 10-Jan-12 21:19, Alex J Lennon wrote:
"(000) telnet_interface.c:85 Telnet interface failed to bind"
Perhaps a silly question but there isn't anything listening on the socket you are trying to bind is there? 'netstat -an' would tell you I guess?
No, nothing is listening on that port. Checked it a few times and also no fw in place...
Alex
Thanks, R.
No, nothing is listening on that port. Checked it a few times and also no fw in place...
Stop me if this is all noddy stuff you've already tried, but is it worth running strace to see what exactly is going wrong? Cheers, A/ On 10/01/2012 21:13, Labs wrote:
On 10-Jan-12 21:19, Alex J Lennon wrote:
"(000) telnet_interface.c:85 Telnet interface failed to bind"
Perhaps a silly question but there isn't anything listening on the socket you are trying to bind is there? 'netstat -an' would tell you I guess?
No, nothing is listening on that port. Checked it a few times and also no fw in place...
Alex
Thanks, R.
No, nothing is listening on that port. Checked it a few times and also no fw in place...
Stop me if this is all noddy stuff you've already tried, but is it worth running strace to see what exactly is going wrong?
Yes it'd be interesting because that's an issue that doesn't come up often ... Cheers, Sylvain
On 10-Jan-12 22:29, Sylvain Munaut wrote:
No, nothing is listening on that port. Checked it a few times and also no fw in place...
Stop me if this is all noddy stuff you've already tried, but is it worth running strace to see what exactly is going wrong?
I will do that and report back. I will connect now on the box.
Yes it'd be interesting because that's an issue that doesn't come up often ...
I was thinking that it is a particular case because there is no info about it searching on the web..
Cheers,
Sylvain
Regards, R.
On 10-Jan-12 22:47, Labs wrote:
I will do that and report back. I will connect now on the box.
When I left from work I shut down the VM and now after power on it seems to work using the command: osmo-nitb -c hsl/openbsc.cfg But that is not all, if I stop the process with Ctrl+Z and run it again (same command) I get the error mentioned below: "(000) telnet_interface.c:85 Telnet interface failed to bind" I just pressed the Ctrl+Z because Ctrl-C was not working and I forgot to use -D parameter to run it as a daemon. I will install strace and give you more details. If you have a test machine try the same steps maybe you can reproduce it on another installation. If not it means is something wrong on my machine only. Version used is the one available on git repository in the morning. Don't know if other code was committed in the mean time. Thanks, R.
When I left from work I shut down the VM and now after power on it seems to work using the command:
osmo-nitb -c hsl/openbsc.cfg
But that is not all, if I stop the process with Ctrl+Z and run it again (same command) I get the error mentioned below:
"(000) telnet_interface.c:85 Telnet interface failed to bind"
Well that's expected ... if you do CTRL-Z, the process is "stopped" but still exists (it's not terminated) and so the associated resources are still allocated to it, including ownership of port 4242 ... so you can't launch a second process that would use the same stuff ... That's standard unix stuff. Cheers, Sylvain
On 10-Jan-12 23:18, Sylvain Munaut wrote:
Well that's expected ... if you do CTRL-Z, the process is "stopped" but still exists (it's not terminated) and so the associated resources are still allocated to it, including ownership of port 4242 ... so you can't launch a second process that would use the same stuff ...
I replied to my email earlier and I just saw yours now.
That's standard unix stuff.
I don't know what I was thinking at that time in the morning...
Cheers,
Sylvain
On 10-Jan-12 23:08, Labs wrote:
On 10-Jan-12 22:47, Labs wrote:
I will do that and report back. I will connect now on the box.
When I left from work I shut down the VM and now after power on it seems to work using the command:
osmo-nitb -c hsl/openbsc.cfg
But that is not all, if I stop the process with Ctrl+Z and run it again (same command) I get the error mentioned below:
"(000) telnet_interface.c:85 Telnet interface failed to bind"
I just pressed the Ctrl+Z because Ctrl-C was not working and I forgot to use -D parameter to run it as a daemon.
I'm stupid! Problem was that I used Ctrl+Z (which sends SIGSUSP) and if I run strace says "Address already in use", that's why it complains that it cannot bind. After this step I saw that running netstat, 127.0.0.1:4242 is used and also a ps reports that it is running. I just killed the process and started again and it worked. This time I stopped it with Ctrl+C (odd that is working now, probably some virtual machine issue?!) and run it again. Of course it works. Thanks guys for your help. It works like a charm :-) Regards, R.
Hi all, Labs wrote:
On 10-Jan-12 11:40, nordin wrote:
If you have a nanoBTS, you can install/setup and run your own network very easy. There is no E1 interface needed or a special lib or a modified kernel or something. Just install debian and other libs you can easily install it with apt, git-clone the project and connect the bts with a utp-cable and you're on the go. If I can do it, I'm sure everybody else can do it.
I installed today Debian and compiled OpenBSC in a VMware machine according to the guide here:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
After this I tried to load run osmo-nitb -c and one example config and I got the error:
I also managed to build openBSC today succesfully an Debian VM. (jfyi: libortp-dev had to be installed additionally which had not been mentioned in the doc.) I also want to play around with the nitb configuration. Therefore I'd like to support you by testing and maybe also coding. And that's why I'd like to get me some hardware BTS for testing. Is there any available as I couldn't find any on the great bay. Cheers, ptr
Hi all, Labs wrote:
On 10-Jan-12 11:40, nordin wrote:
If you have a nanoBTS, you can install/setup and run your own network very easy. There is no E1 interface needed or a special lib or a modified kernel or something. Just install debian and other libs you can easily install it with apt, git-clone the project and connect the bts with a utp-cable and you're on the go. If I can do it, I'm sure everybody else can do it.
I installed today Debian and compiled OpenBSC in a VMware machine according to the guide here:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
After this I tried to load run osmo-nitb -c and one example config and I got the error:
I also managed to build openBSC today succesfully an Debian VM. (jfyi: libortp-dev had to be installed additionally which had not been mentioned in the doc.) I also want to play around with the nitb configuration. Therefore I'd like to support you by testing and maybe also coding. And that's why I'd like to get me some hardware BTS for testing. Is there any available as I couldn't find any on the great bay. Cheers, ptr
On 10-Jan-12 23:25, Peter Yuan wrote:
Hi all,
Hello Peter,
I also managed to build openBSC today succesfully an Debian VM. (jfyi: libortp-dev had to be installed additionally which had not been mentioned in the doc.)
Yes, that's the package.
I also want to play around with the nitb configuration.
It looks much better than the wiki doc. I really like it.
Therefore I'd like to support you by testing and maybe also coding. And that's why I'd like to get me some hardware BTS for testing. Is there any available as I couldn't find any on the great bay.
I just saw this one earlier but the guy says it sends it to US only. http://www.ebay.com/itm/1-USED-NANO-BTS-165B-PARTS-REPAIR-ONLY-/220926719447... I have the hardware at work and I also look for something small at home. We have some old Siemens that might work with BS-11 config and new ones that are totally different in concept that I will not be able I guess to use it besides the vendor BSC.
Cheers, ptr
Regards, R.
Hi, Labs wrote:
I just saw this one earlier but the guy says it sends it to US only. http://www.ebay.com/itm/1-USED-NANO-BTS-165B-PARTS-REPAIR-ONLY-/220926719447...
I have the hardware at work and I also look for something small at home.
We have some old Siemens that might work with BS-11 config and new ones that are totally different in concept that I will not be able I guess to use it besides the vendor BSC.
so it seems kind of hard to get hardware at the moment. Quote of http://openbsc.osmocom.org/trac/wiki/OpenBSC#Thingsthatwork:
Things that are not implemented Cell Broadcast Any type of transcoding of voice data TCH/H voice calls (they work in osmo-bsc, but not in osmo-nitb) CSD? calls emergency call handling (works in osmo-bsc, but not in osmo-nitb) Discontinuous TX and RX (DTX? / DRX?) support Is this list still up to date? Somebody working on one of these topics? Which of these topics do you think is easiest to get one's hands on?
Cheers ptr
On 11-Jan-12 13:49, Peter Yuan wrote: Hello Peter,
so it seems kind of hard to get hardware at the moment.
Yes it is. On ebay in EU it's almost zero chance if you want one fast. I found a lot of modules from Ericsson but not a complete BTS so you will have to wait. If you don't mind paying the shipping from overseas and taxes you can find many BTS units from US or Asian countries. Regards, Razvan
Labs wrote:
We had some tangential discussions at 28c3 in Berlin between X-mas and NYE, where we last ran an OpenBSC test network.
So there are more people thinking like me?
I started an early discussion because I was thinking of how we could make it even easier to run an OpenBSC CCC event network, which has been done on a handful of times by now but mostly with some amount of manual labour also on the software side, and without producing documentation. My idea so far is to start with a so-called spec file for the Gentoo catalyst tool, which can be used to very conveniently build a ready-to-run system. That work would be reusable for a VM image.
* The OpenBSC software may be integrated in many different ways
OpenBSC does not neccessarily run only on Linux operating systems (maybe this is actually a requirement now, but I don't think it needs to be, and generally it is good to have software be portable across many different operating systems) - this is significant because any interface configuration is always highly system specific, and every integration will have different processes here. Following the UNIX principle, this is outside the scope of OpenBSC. Ie. interface configuration is one step considered belonging to the base system, while software configuration to use those interfaces is a separate step which needs to match the system base configuration.
I am thinking that you always need to separate the traffic based on destination. That being said you will not use the same interface for management of the box and also for Abis or A interfaces.
You can.
All of them should be separately defined.
Not neccessarily.
Management interface can be defined via normal OS way (or an OpenBSC GUI/startup menu?)
This part falls very clearly outside the scope of the OpenBSC software. It could however be part of another, "higher level" software project, something like a Linux distribution tailed to OpenBSC.
but the rest of interfaces should be defined via OpenBSC config. I don't know how it works now, is there any "limitation" or you can have everything on one ethernet interface?
OpenBSC does nothing at all with interfaces, and does not care where or how communication goes as long as it has IP connectivity with the units it needs to communicate with. Management and BTSes can be on the same network if so desired.
design should be done in advance
I am sure that you appreciate that OpenBSC was not put together without design. Please be careful with wording.
so there will not be a complete re-write of the code in case of small/big? changes.
If you're not a programmer it seems you're now venturing into a field you may not be experienced in. The developers in OpenBSC are, on the other hand, quite experienced. Don't worry about the code quality. Re-write is not neccessary to avoid at all cost, especially not at very high design cost. In fact, one solution in the short term is perfectly fine even if a different solution has already been foreseen to be neccessary in the medium term.
If it happens I would argue that OpenBSC should configure only those interfaces which are related to GSM, and that they be kept separate from the "regular" interfaces used by the system.
Correct, agree.
It's important to remember that OpenBSC supporting such configuration MUST NOT mean that operations and management are suddenly required to be on different interfaces. But this is easy; OpenBSC will just not do any configuration at all unless told to do it.
Such a change will tie OpenBSC more strongly to the particular operating systems it runs on, which is generally considered a bad thing.
It is considered bad but you cannot just keep on testing different behaviors on all Linux flavors.
Oh it's not about Linux distributions. Linux is a single operating system. Distributions are not relevant. I'm talking about various variants of BSD, Windows and Solaris.
I think most, probably 99%, are running the project on Debian.
Again, this does not, and MUST NOT, matter. OpenBSC is not and will quite likely never be debian specific.
I guess I put it in the wrong way in my first email. I work with CLI everyday but for some things I like the GUI. I am probably used with the commercial BSC CLI/GUI so...
Of course all constructive ideas for the user interface are interesting. Since the CLI is what is currently there it can be compared with other BSC CLI, and if OpenBSC can be made even better than it is then of course the good ideas should not get lost.
I prefer to have a GUI for checking fast some transmission line parameters (type/line code/BER results/IP address of BTS), check and reset different BTS boards that go crazy sometime...
I am not sure what you can do now in regard to BTS components/modules
The "show bts 1" command is probably a good start. Of course, if you think it should be extended with further important information then let's hear about it.
and if the OML commands sent to BTS can do the above things.
That depends on the BTS, right? //Peter
Hi again, On Mon, Jan 09, 2012 at 08:32:26AM +0100, Labs wrote:
I already checked the link but the package repository doesn't keep up with updates from git repository. Most of them were built in the summer last year, that's why I wanted a nightly built to have the latest bug fixes and features.
Are you volunteering to setup and maintain such a repository? Pleaes don't try to issue complaints/demands to people who are constantly overworked and who already give away all the results of their work as Free Software. We publish our software in source code form for everyone to be used. If somebody steps up and maintains such repositories, fine, we certainly welcome that. But I don't see the very small group of developers spending their non-existing spare time on building packages for god-knows-how-many different Linux distributions and other platforms out there, sorry.
I was talking about all config parameters to be in one DB and not in text files. Also it can be an XML file with all configuration and not many text files.
It right now is exactly _one_ text file for OpenBSC, containing _all_ parameters. So I don't really see what XML would gain us, apart from being unreadable by human users, and requiring bloated large libraries for parsing and validation of the data.
From VTY just run let's say "backup live-config" command and you will have an XML with all configuration that you can move on other hardware.
XML should contain everything like E1 or IP settings, BTS and cell parameters, etc.
we have exactly that with openbsc.cfg. Just not XML. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 01/09/2012 08:32 AM, Labs wrote:
On 01/08/2012 02:33 PM, Holger Hans Peter Freyther wrote:
I guess you were referring to osmo-nitb. http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY
The above page shows the problem. We have an outdated and incomplete VTY documentation, being the engineer I am, I think we should automatically generate it (see mails from December/November). holger
On 09-Jan-12 19:45, Holger Hans Peter Freyther wrote:
I guess you were referring to osmo-nitb. http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY
The above page shows the problem. We have an outdated and incomplete VTY documentation, being the engineer I am, I think we should automatically generate it (see mails from December/November).
I think you are referring to this link? http://lists.osmocom.org/pipermail/openbsc/2011-December/003441.html No reply to your thread... I will try to get an OpenBSC running by the end of next week and check the VTY/CLI commands. :)
holger
R.
participants (8)
-
Alex J Lennon -
Harald Welte -
Holger Hans Peter Freyther -
Labs -
nordin -
Peter Stuge -
Peter Yuan -
Sylvain Munaut