From axilirator at gmail.com Tue Jan 9 17:47:39 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 9 Jan 2018 23:47:39 +0600 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Hi, > I tried to install Jolly branch many times and this is > the debug result which always stop when sync to BTS. > > I was thinking the package is broken? testing with sylvain > is work, just like yesterday my registering still problem. > but this Jolly branch even cannot produce sync. Hmm, I just found out that both handover related commands are implemented in jolly/testing, but not in sylvain/testing: http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ transceiver/trx.c?h=jolly/testing#n440 http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ transceiver/trx.c?h=sylvain/testing#n369 You can implement a dummy command handler for sylvain/testing. Or use jolly's branch. But as I remember, there was a problem with some firmware images: http://osmocom.org/projects/baseband/wiki/Toolchain > note: as of 2013-10-20, if you use a toolchain with gcc >=4.8, > the firmware can be compiled, but will hang as soon as you want > to sync to an ARFCN. This issue has been fixed in master. > > http://cgit.osmocom.org/osmocom-bb/commit/ > ?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e I think this information is enough to solve your problem. And moreover, we are using the openbsc mailing list, while there is a dedicated one. Let's finish this thread here. And good luck! With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marek.sebera at gmail.com Tue Jan 9 20:08:13 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Tue, 9 Jan 2018 21:08:13 +0100 Subject: Building RFFE to work on MSM Message-ID: Hi, if following architecture is correct https://images.anandtech.com/doci/6541/RadioToday2.png What are currently available chips, using which we can build the RFFE part of BBP (such as Analog Devices ADF4602 or Avago ACPM-7600) so we can start working on UMTS/LTE software/protocol stack implementation on some commonly available Intel/ARM/AMD SoC (or multi-core SoC) ? If the RFFE part of BBP will be stable, work needed on MSM (Mobile Station Modem, i know it's Qalcomm's term) will be tremendous, but not unreal. Also might be partially ported current osmocomBB, but without working RFFE it is really hard to get the software started imho. Or is there something I don't get right now? Thank you Cheers! Marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From holger at freyther.de Wed Jan 10 00:24:47 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 10 Jan 2018 00:24:47 +0000 Subject: Approach to system testing for Osmocom stack Message-ID: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Hi, the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project... The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes. For some degrees of freedom I don't have a good idea.. and feedback is welcome. I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester. If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first). any ideas/comments? holger From pespin at sysmocom.de Wed Jan 10 09:49:57 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 10 Jan 2018 10:49:57 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Message-ID: <4a24d738-a44c-e278-d581-6d2c5ef19bcd@sysmocom.de> Hi Holger, I never used virtbts but I think it should be quite easy adding support for it in osmo-gsm-tester. The only big issue I can think of is that we need to find a way to differentiate between virtbs and other bts since they use a different communication medium and then that means that the requested modems to run for the test with virtbts need to be selected accordingly (ie. don't allocate an ofono modem from the object pool if we are using a virbts). That can probably accomplished easily too, by adding new attributes to objects to describe that characteristic. It can be a good idea to support this at some point if we want to test for compatibility between "mobile" app + virtbs and other BTS and modems, for instance see if we can place a call between a regular modem with a sysmobts and a "mobile" app + virtbts. Then we can make sure we don't add regressions in the future. Regarding the performance, I imagine osmo-gsm-tester will have a hard time running that amount of objects/processes, as we didn't have this kind of scenarios in mind since it was developed having real hardware in mind. Furthermore, the unit running osmo-gsm-tester is not a big machine so I guess it would have problems running that amount of processes alone. I don't think the language is going to be that important, it depends more on how do you plan intend to manage all of those processes in a efficient way from system OS point of view. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From pespin at sysmocom.de Wed Jan 10 09:50:52 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 10 Jan 2018 10:50:52 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Message-ID: <176b1459-0e02-49ab-ae1a-475773ac56ac@sysmocom.de> Hi Holger, I never used virtbts but I think it should be quite easy adding support for it in osmo-gsm-tester. The only big issue I can think of is that we need to find a way to differentiate between virtbs and other bts since they use a different communication medium and then that means that the requested modems to run for the test with virtbts need to be selected accordingly (ie. don't allocate an ofono modem from the object pool if we are using a virbts). That can probably accomplished easily too, by adding new attributes to objects to describe that characteristic. It can be a good idea to support this at some point if we want to test for compatibility between "mobile" app + virtbs and other BTS and modems, for instance see if we can place a call between a regular modem with a sysmobts and a "mobile" app + virtbts. Then we can make sure we don't add regressions in the future. Regarding the performance, I imagine osmo-gsm-tester will have a hard time running that amount of objects/processes, as we didn't have this kind of scenarios in mind since it was developed having real hardware in mind. Furthermore, the unit running osmo-gsm-tester is not a big machine so I guess it would have problems running that amount of processes alone. I don't think the language is going to be that important, it depends more on how do you plan intend to manage all of those processes in a efficient way from system OS point of view. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Wed Jan 10 11:55:13 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jan 2018 12:55:13 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Message-ID: <20180110115513.GZ13147@nataraja> Hi Holger, On Wed, Jan 10, 2018 at 12:24:47AM +0000, Holger Freyther wrote: > the lua binding code was added to be able to automate OpenBSC tests. > In theory we should be able to do this for SMS and UpdateLocation > (call handling with MNCC exposing is left as a todo) but in practice > we miss a piece of software to coordinate this and run the test. We > miss it because it is an interesting problem but also I lost time on > switching countries, learning new tricks at a project... Sure, I understand. However, it is definitely a part that we're very much looking forward to have :) > The basic testing structure looks easy as well. We want to define the > number of concurrent subscribers (0, 10, 100, 1000, n) and to make it > simple a single test (UL, send SMS, t) and execute the same test for > each subscriber and call it a success if y% of tests succeed within > time T. The way to measure this is easy as well. The lua script would > print some data (e.g. the name of the ms) when it starts and > completes. One might also think of a more structured format to return the data, but that could always added later. One could e.g. print a XML or JSON snippet that's easier to parse/consume by whoever processes it. What I also believe is very important is some kind of rate limiting / staggering when starting up. We know a single-BTS setup will for sure fail lots of LU if you stat 1k MS at the same time. So there should be some kind of provision to say something "start 1000 MS at a rate of 10 per second". I wouldn't go for more elaborate schemes, but simply a single linear rate/slope. > I am not sure if I should spawn, configure, add subscribers, a flavor > of Osmocom cellular? I look into having some set of templates for the > config, the stack to launch and in concept it looks awfully similar to > something the GSM tester is doing. Shall we leave virtbts/cellular to > the Osmocom tester and just focus on coordinating mobile? My feeling > is to leave this to the Osmo GSM tester. Yes, I think it's ok to focus on the "tester" side and not on the IUT (implementation under test) side. So we assume that the user will somehow bring up the [virtual] cellular network before excuting the load test. One preferred way of doing this is - I agree - by reusing those parts from osmo-gsm-tester. > If we have n subscribers I would launch m copies of "mobile" (but run > multiple MS in a single binary). I would argue the number of MS per 'mobile' should be configurable from 1-N. > So with 4 MS per mobile process and 10k subs we would end with 2.5k > processes + many log messages coming from each. The question is how many of those log messages do we need/want. In order to avoid the risk of 'mobile' blocking on writing to stdout/stderr, I think it would be best not to pipe that into other processes but write to files (could even be tmpfs!) and process the files after the run? > Would that scale with python? Should we look into doing this one in > Go? > Or can some of GSM tester be used (the template part)? I'm not sufficiently familiar with osmo-gsm-tester to say if we can use it. On an abstract level, I would think the "defining resources and generating configuration files" part should be reusable, but then it also just uses (jinja2?) templates that anyone can use in python. And whether it's sufficiently scalable to generate thousands of config files, I don't know either. > I would probably design this concurrently with Go(besides being the > first). I would suggest we keep not further the number of programming languages one needs to understand. But then, it's "just" a tool for load testing, so probably not that critical after all. My naive assumption would be that starting 2.5k processes (and processing the SIGCHILD from python should be possible without causing a performance/scalability problem? As indicated, log file processing could be handled later, or one could configure stdio logging to be absolutely minimal (with verbose logs going to files)? My attached test program (not using python 'subprocess' as I couldn't find a way to make it do non-blocking wait for the child to terminate) runs perfectly fine here, even without any rate limiting I get the following on my laptop: $ time ./subproc.py 2018-01-10 12:44:14,811 INFO Beginning starting of processes 2018-01-10 12:44:15,603 INFO Started 2500 processes 2018-01-10 12:44:18,607 INFO Waited for all processes ./subproc.py 2.74s user 1.46s system 108% cpu 3.881 total So 2500 processes could be forked in less than one second, and the starting/reaping in python needed onyl very few seconds of system time - compared with the amount of resources required to run the 'mobile' programs including the GSMTAP socket traffic etc. for sure neglectable? Now of course '/bin/sleep' is a much simpler program to start, but the overhead of the python "orchestration" doesn't change with the resource footprint of the program started. Just my thoughs, as usual. The decision is yours... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: subproc.py Type: text/x-python Size: 979 bytes Desc: not available URL: From holger at freyther.de Wed Jan 10 22:52:59 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 10 Jan 2018 22:52:59 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180110115513.GZ13147@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> Message-ID: > On 10. Jan 2018, at 11:55, Harald Welte wrote: > > Hi Holger, > Sure, I understand. However, it is definitely a part that we're very > much looking forward to have :) me too... I dislike not having made progress here. > One might also think of a more structured format to return the data, but > that could always added later. One could e.g. print a XML or JSON > snippet that's easier to parse/consume by whoever processes it. Good point. There is nothing that prevents us opening a file/socket/pipe from the lua code and writing out something. We would need to write out complete XML/JSON documents (and likely multiple of them) or define a framing ourselves.. > What I also believe is very important is some kind of rate limiting / > staggering when starting up. We know a single-BTS setup will for sure > fail lots of LU if you stat 1k MS at the same time. So there should be > some kind of provision to say something "start 1000 MS at a rate of 10 > per second". I wouldn't go for more elaborate schemes, but simply a > single linear rate/slope. Makes sense. > Yes, I think it's ok to focus on the "tester" side and not on the IUT > (implementation under test) side. So we assume that the user will > somehow bring up the [virtual] cellular network before excuting the load > test. One preferred way of doing this is - I agree - by reusing those > parts from osmo-gsm-tester. Good. I will leave this part. > Now of course '/bin/sleep' is a much simpler program to start, but the > overhead of the python "orchestration" doesn't change with the resource > footprint of the program started. Thanks for looking at the process creation. I was concerned of Python's IO model to read from 2.5k FDs but apparently it has epoll. Computers are powerful and a single python process could be fine here... okay. That reduces some degrees of the freedom. Where to put it? Into the OsmocomBB sources? Osmo GSM tester even if it might not share much code? holger From laforge at gnumonks.org Wed Jan 10 23:39:26 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Jan 2018 00:39:26 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> Message-ID: <20180110233926.GE13147@nataraja> Hi Holger, On Wed, Jan 10, 2018 at 10:52:59PM +0000, Holger Freyther wrote: > okay. That reduces some degrees of the freedom. Where to put it? Into the > OsmocomBB sources? Osmo GSM tester even if it might not share much code? If you reuse osmo-gsm-tester code for templates or the like, then it should probably go there. If not, OsmocomBB seems like the more logical place. Would be great if in that case it is some kind of python library/module and a small 'main' wrapper around. This way the library could later be used by whatever is starting both the network and the 'mobile's. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Sat Jan 13 20:19:46 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 14 Jan 2018 02:19:46 +0600 Subject: GAPK merge request Message-ID: Hi Sylvain, as you probably already know, I made a few changes in GAPK and now they are in a separate branch called 'fixeria/lib'. In a few words, the main idea of this set of changes is to compose a shared library called libosmogapk and add some basic test coverage. Please see: http://git.osmocom.org/gapk/log/?h=fixeria/lib As you're the maintainer and author of this project, I would like to ask you: is it possible to merge this branch into the mainline? At the moment, the new library is used by OsmocomBB, see: http://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=0ed60f68b86b47417e2ec587320e27c84737695b and moreover I am developing a set of GNU Radio blocks for GSM audio transcoding based on the GAPK library. Probably, some other projects may also benefit from a possibility to link against a shared library and use its features... If you support this idea, please let me know, which way of merging the branch is better for you: - using Gerrit, where I am not sure: if I will send a merge commit for review, would it 'drag' the whole long chain of commits, or the only one? - or using your write access rights. In both cases, I'll provide you detailed description of the merge commit. But first, I need to know your decision. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jan 14 10:28:17 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 14 Jan 2018 11:28:17 +0100 Subject: GAPK merge request In-Reply-To: References: Message-ID: <20180114102815.xusgdrxhhuttkfug@nataraja> Hi Vadim, just some feedback "from the side": On Sun, Jan 14, 2018 at 02:19:46AM +0600, Vadim Yanitskiy wrote: > http://git.osmocom.org/gapk/log/?h=fixeria/lib I've done some casual review and it looks great to me. There are some minor issues: * I would suggest internal symbols (those not with osmo_gapk_ prefix, like gapk_log_subsys, LOGPAPK, ...) use an internal header file which is not installed in the system. The header files installed during 'make install' should only describe the external API of the library * the source/sink/coec category name stringification at http://git.osmocom.org/gapk/commit/?h=fixeria/lib&id=459791c488c6b66a5cd0d7cff9392a7a0b8ca733 should not define those strings in every file, but have a value_string or at least some #defines or the like. This is just my point of view, detailed review of course depends on Sylvain. I suggest you simply rebase your chain of commits on current master and push it into gerrit. That's what we have it for, and as indicated in http://lists.osmocom.org/pipermail/openbsc/2017-December/011523.html gapk has been introduced to gerrit. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Sun Jan 14 17:40:30 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 14 Jan 2018 23:40:30 +0600 Subject: GAPK merge request In-Reply-To: <20180114102815.xusgdrxhhuttkfug@nataraja> References: <20180114102815.xusgdrxhhuttkfug@nataraja> Message-ID: Hi Harald, > I've done some casual review and it looks great to me. Thanks. > I would suggest internal symbols (those not with osmo_gapk_ prefix, > like gapk_log_subsys, LOGPAPK, ...) use an internal header file which > is not installed in the system. The header files installed during > 'make install' should only describe the external API of the library The mentioned logging related symbols are not installed: > noinst_HEADERS = \ > osmocom/gapk/logging.h \ > ... The only thing I am not sure about is 'get_cycles.h' header. At the moment, it is installed together with other headers, because it's a dependency of 'benchmark.h'. But, it seems I just got an idea, how to avoid this dependency - simply use 'unsigned long long' instead of the 'cycles_t', which is imported from 'get_cycles.h'. > the source/sink/coec category name stringification should not > define those strings in every file, but have a value_string > or at least some #defines or the like. Thanks, good idea. > I suggest you simply rebase your chain of commits on current > master and push it into gerrit. But this way, each commit of the whole chain would require +2 and V+1, because 'make check' was implemented at the end of the chain. What if I merge 'fixeria/lib' into a local 'master' and send it for review? I think, this would be simpler. Or would this anyway send the whole chain to review? :) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jan 14 18:35:59 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 14 Jan 2018 19:35:59 +0100 Subject: GAPK merge request In-Reply-To: References: <20180114102815.xusgdrxhhuttkfug@nataraja> Message-ID: <20180114183557.trlo5falz3435ugj@nataraja> On Sun, Jan 14, 2018 at 11:40:30PM +0600, Vadim Yanitskiy wrote: > The mentioned logging related symbols are not installed: ok, thanks. > > I suggest you simply rebase your chain of commits on current > > master and push it into gerrit. > > But this way, each commit of the whole chain would require +2 > and V+1, because 'make check' was implemented at the end of > the chain. fine with me. > What if I merge 'fixeria/lib' into a local 'master' and send > it for review? I think, this would be simpler. Or would this > anyway send the whole chain to review? :) I don't really know what gerrit does in case of merges, as we don't generally use merges much but prefer a linear history. You could try, if you're interested. In any case, let's wait and see what Sylvain says regarding the code -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Jan 21 20:16:42 2018 From: holger at freyther.de (Holger Freyther) Date: Sun, 21 Jan 2018 20:16:42 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180110233926.GE13147@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> Message-ID: <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> > On 10. Jan 2018, at 23:39, Harald Welte wrote: > Hi! > If you reuse osmo-gsm-tester code for templates or the like, then it should > probably go there. If not, OsmocomBB seems like the more logical place. > Would be great if in that case it is some kind of python library/module > and a small 'main' wrapper around. This way the library could later be > used by whatever is starting both the network and the 'mobile's. small progress update. I will use "luasocket" to open a af_unix dgram socket from the testcase, a small json library, the template, log and maybe the process code from osmo-gsm-tester. I will give Python's asyncio a try as well. It has unix socket and subprocess support. Right now there a lot of loose ends but I should be able to make progress from here. holger From holger at freyther.de Sun Jan 28 22:41:33 2018 From: holger at freyther.de (Holger Freyther) Date: Sun, 28 Jan 2018 22:41:33 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> Message-ID: <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> > On 21. Jan 2018, at 20:16, Holger Freyther wrote: > Hey! some more progress. I had to learn a bit about asyncio and in the end will be forced to use a stream socket[1] and will end up using the IPA and add a reservation for JSON events. I will probably push my unfinished code to gerrit but it is too early to review. holger > small progress update. I will use "luasocket" to open a af_unix dgram socket > from the testcase, a small json library, the template, log and maybe the > process code from osmo-gsm-tester. I will give Python's asyncio a try as > well. It has unix socket and subprocess support. > > Right now there a lot of loose ends but I should be able to make progress > from here. > > holger [1] There is a asyncio.start_unix_server to create a AF_UNIX socket but only with SOCK_STREAM. The API has (thought not documented) a way to pass a file descriptor but when passing a socket they will check if it is a stream socket and if not fail. This is quite annoying in some ways.. First I want reliable delivery (excludes UDP) and have messages/datagrams (don't want to do an IPA style header..). Second thanks to the BSD socket API the accept will behave exactly the same for TCP, SCTP, UNIX, Bluetooth, etc and the python API allows to pass a socket factory. From laforge at gnumonks.org Mon Jan 29 10:50:17 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jan 2018 11:50:17 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> Message-ID: <20180129105017.GM6630@nataraja> Hi Holger, thanks for your status update. Looking forward to the related code. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Jan 29 21:52:34 2018 From: holger at freyther.de (Holger Freyther) Date: Mon, 29 Jan 2018 21:52:34 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180129105017.GM6630@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> <20180129105017.GM6630@nataraja> Message-ID: <54F00998-3383-47E2-8399-E53781864F3D@freyther.de> > On 29. Jan 2018, at 10:50, Harald Welte wrote: > > Hi Holger, > > thanks for your status update. Looking forward to the related code. hehe. It is just a couple of hundred lines so far. It should bring us far enough. Will continue with it in a few minutes. For simplicity I am not segmenting mobile instances (one lua script for one mobile process). holger From djks74 at gmail.com Tue Jan 9 17:59:14 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Tue, 09 Jan 2018 17:59:14 -0000 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Ok. Thanks Vadim. really helpfull. :-) DUO On Wed, Jan 10, 2018 at 12:47 AM, Vadim Yanitskiy wrote: > Hi, > > > I tried to install Jolly branch many times and this is > > the debug result which always stop when sync to BTS. > > > > I was thinking the package is broken? testing with sylvain > > is work, just like yesterday my registering still problem. > > but this Jolly branch even cannot produce sync. > > Hmm, I just found out that both handover related commands > are implemented in jolly/testing, but not in sylvain/testing: > > http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ > transceiver/trx.c?h=jolly/testing#n440 > > http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ > transceiver/trx.c?h=sylvain/testing#n369 > > You can implement a dummy command handler for sylvain/testing. > Or use jolly's branch. But as I remember, there was a problem > with some firmware images: > > http://osmocom.org/projects/baseband/wiki/Toolchain > > > note: as of 2013-10-20, if you use a toolchain with gcc >=4.8, > > the firmware can be compiled, but will hang as soon as you want > > to sync to an ARFCN. This issue has been fixed in master. > > > > http://cgit.osmocom.org/osmocom-bb/commit/ > > ?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e > > I think this information is enough to solve your problem. > And moreover, we are using the openbsc mailing list, while > there is a dedicated one. Let's finish this thread here. > > And good luck! > > > With best regards, > Vadim Yanitskiy. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xidianzhanghao at 126.com Wed Jan 10 02:41:58 2018 From: xidianzhanghao at 126.com (hao_zhang) Date: Wed, 10 Jan 2018 02:41:58 -0000 Subject: help : osmocombb transfer problem Message-ID: sorry to bother you, i install openbsc and osmocombb in a pc. i want to transfer authentication information rand from osmocombb to openbsc, and transfer sres information from openbsc to osmocombb. What should I do? thanks zhanghao -------------- next part -------------- An HTML attachment was scrubbed... URL: