On 09-Jan-12 10:34, Peter Stuge wrote: The problem is not hardware. I guess it's more like CPU architecture issue. I think many things needs to be changed... R.

Hello Harald, On 09-Jan-12 12:26, Harald Welte wrote: 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... This is what I was afraid of, that's why I asked first before loosing time. Thanks for confirming this point. 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. 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? 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.

Hi, 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. 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 ... If you had any experience with cisco, it would be pretty intuitive ... also there is autocompletion 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 .... "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) 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 01/09/2012 07:39 PM, Labs wrote: 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

Labs 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. 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. :) You should be able to do it rather quickly, also without being a programmer. The dependencies are not very many. 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. 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

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:

Hi, 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've never been able to find how to do that ... that doesn't seem to be supported AFAICT ... Cheers, Sylvain

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? Alex

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 22:29, Sylvain Munaut wrote: I will do that and report back. I will connect now on the box. I was thinking that it is a particular case because there is no info about it searching on the web.. Regards, R.

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:08, Labs wrote: 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: 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, Labs wrote: so it seems kind of hard to get hardware at the moment. Quote of http://openbsc.osmocom.org/trac/wiki/OpenBSC#Thingsthatwork: 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

Labs wrote: 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. You can. Not neccessarily. 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. 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. I am sure that you appreciate that OpenBSC was not put together without design. Please be careful with wording. 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. 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. 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. Again, this does not, and MUST NOT, matter. OpenBSC is not and will quite likely never be debian specific. 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. 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. That depends on the BTS, right? //Peter

On 01/09/2012 08:32 AM, Labs wrote: 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