From axilirator at gmail.com Mon May 1 17:19:17 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 2 May 2017 00:19:17 +0700 Subject: core/conv: SCH decoding problem Message-ID: Hi Tomas, I again have a question related to your SSE accelerated Viterbi decoder, and I hope it's the last issue, which prevents us from finishing this work. In short, SSE based implementation provides one-byte different decoding result for SCH transcoding test. So, the whole GSM 05.03 coding test fails. I have done some debugging, and would like to share some results. Have a look at the tests/coding/test_sch(), which first encodes a L3 packet into ubits and sbits, then some bits are getting destroyed, then the gsm0503_sch_decode() is being called to get decoded bytes back, and finally decoded bytes are being compared with original bytes. As long as encoder implementation is not covered by SSE code, it works as before. But SSE accelerated decoder outputs one-byte different result in case of SCH: int gsm0503_sch_decode(uint8_t *sb_info, sbit_t *burst) { ubit_t conv[35]; int rv; osmo_conv_decode(&gsm0503_sch, burst, conv); rv = osmo_crc16gen_check_bits(&gsm0503_sch_crc10, conv, 25, conv + 25); if (rv) return -1; // ... } // Original implementation ubit_t conv[35] = { 0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00 }; // Accelerated implementation ubit_t conv[35] = { 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00 }; As you can see, the conv[3] isn't the same in both cases. So, at the next step the osmo_crc16gen_check_bits() returns -1. Latest version of this change: https://gerrit.osmocom.org/#/c/2454/ Do you have any ideas? Despite SCH decoding isn't required on BTS side, the problem may be more global, than the test shows. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Tue May 2 06:13:01 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 2 May 2017 06:13:01 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> Message-ID: <3F7C2796-B6D0-4D01-888B-169E7C531D68@entropysolution.com> Hi Holger, Any suggestions for the error encountered? TIA. Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC] Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you. On Apr 29, 2017, at 10:41 AM, Ron > wrote: Hi Holger, Kindly see output from the ?gdb" for osmo-trx and its "backtrace full?. # gdb osmo-trx GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from osmo-trx...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/osmo-trx [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 [New Thread 0x7ffff1884700 (LWP 3777)] [New Thread 0x7ffff1083700 (LWP 3778)] [Thread 0x7ffff1083700 (LWP 3778) exited] [Thread 0x7ffff1884700 (LWP 3777) exited] [New Thread 0x7ffff1884700 (LWP 3781)] [New Thread 0x7ffff1083700 (LWP 3782)] [Thread 0x7ffff1083700 (LWP 3782) exited] [Thread 0x7ffff1884700 (LWP 3781) exited] [New Thread 0x7ffff1884700 (LWP 3783)] [New Thread 0x7ffff1083700 (LWP 3784)] [Thread 0x7ffff1083700 (LWP 3784) exited] [Thread 0x7ffff1884700 (LWP 3783) exited] [New Thread 0x7ffff1884700 (LWP 3785)] [New Thread 0x7ffff1083700 (LWP 3786)] [Thread 0x7ffff1083700 (LWP 3786) exited] [Thread 0x7ffff1884700 (LWP 3785) exited] [New Thread 0x7ffff1884700 (LWP 3787)] [New Thread 0x7ffff1083700 (LWP 3788)] [Thread 0x7ffff1083700 (LWP 3788) exited] [Thread 0x7ffff1884700 (LWP 3787) exited] [New Thread 0x7ffff1884700 (LWP 3789)] [New Thread 0x7ffff1083700 (LWP 3790)] [Thread 0x7ffff1083700 (LWP 3790) exited] [Thread 0x7ffff1884700 (LWP 3789) exited] [New Thread 0x7ffff1884700 (LWP 3791)] [New Thread 0x7ffff1083700 (LWP 3792)] [Thread 0x7ffff1083700 (LWP 3792) exited] [Thread 0x7ffff1884700 (LWP 3791) exited] [New Thread 0x7ffff1884700 (LWP 3793)] [New Thread 0x7ffff1083700 (LWP 3794)] [Thread 0x7ffff1083700 (LWP 3794) exited] [Thread 0x7ffff1884700 (LWP 3793) exited] [New Thread 0x7ffff1884700 (LWP 3795)] [New Thread 0x7ffff1083700 (LWP 3796)] -- Detected Device: B210 -- Operating over USB 3. [New Thread 0x7fffebfff700 (LWP 3797)] -- Detecting internal GPSDO.... Found an internal GPSDO -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 16.000000 MHz... -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 26.000000 MHz... -- Actually got clock rate 26.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B210 4/1 Tx/Rx SPS [New Thread 0x7ffff7ff5700 (LWP 3803)] -- Transceiver active with 1 channel(s) NOTICE 140737354094336 10:36:22.1 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 140737354094336 10:36:22.1 Transceiver.cpp:243:start: Starting the transceiver [New Thread 0x7ffff7efc700 (LWP 3812)] [New Thread 0x7ffff7fed700 (LWP 3813)] [New Thread 0x7ffff7fe5700 (LWP 3814)] [New Thread 0x7ffff7ebb700 (LWP 3815)] [New Thread 0x7ffff7eb3700 (LWP 3816)] ERR 140737353074432 10:36:22.3 UHDDevice.cpp:1426:recv_async_msg: Packet loss within a burst at 6.85643 sec. ERR 140737353074432 10:36:22.3 UHDDevice.cpp:1426:recv_async_msg: Packet loss within a burst at 6.85643 sec. Thread 26 "osmo-trx" received signal SIGILL, Illegal instruction. [Switching to Thread 0x7ffff7eb3700 (LWP 3816)] 0x00005555555956d9 in ?? () (gdb) backtrace full #0 0x00005555555956d9 in ?? () No symbol table info available. #1 0x0000555555595bc4 in ?? () No symbol table info available. #2 0x000055555558cd42 in ?? () No symbol table info available. #3 0x000055555558e48e in ?? () No symbol table info available. #4 0x000055555556bef9 in ?? () No symbol table info available. #5 0x000055555556c52d in ?? () No symbol table info available. #6 0x000055555556cb2b in ?? () No symbol table info available. #7 0x00007ffff7bc16ba in start_thread (arg=0x7ffff7eb3700) at pthread_create.c:333 __res = pd = 0x7ffff7eb3700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737352775424, 7678090699800639934, 0, 140737354089583, 140737352776128, 140736884378784, -7678108388146218562, -7678107711344281154}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = __PRETTY_FUNCTION__ = "start_thread" #8 0x00007ffff602e82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Kindly advice what are the specific commands need to be run for your needed logs. Thank you. Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you. On Apr 29, 2017, at 5:22 AM, Holger Freyther > wrote: On 28. Apr 2017, at 03:44, Ron > wrote: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp now I am curious. So your system seems to support sse4_2, avx2. Could you run osmo-trx under gdb and get us a backtrace? And keep the session open if you can. We might need to ask you to type a command to disassemble the memory area to see what has been executed. @dexter/@tom: Do you see any cpu feature that should be there but isn't? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D7861C66-51ED-4DB6-B9ED-BADEB28148EC.png Type: image/png Size: 7117 bytes Desc: D7861C66-51ED-4DB6-B9ED-BADEB28148EC.png URL: From holger at freyther.de Tue May 2 06:50:29 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 May 2017 08:50:29 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <3F7C2796-B6D0-4D01-888B-169E7C531D68@entropysolution.com> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> <3F7C2796-B6D0-4D01-888B-169E7C531D68@entropysolution.com> Message-ID: <4668079C-3774-421B-8DD7-AB525B44D03D@freyther.de> > On 2. May 2017, at 08:13, Ron wrote: > > Hi Holger, Hi! > Any suggestions for the error encountered? as Tom pointed out your CPU should be fine. Could you install osmo-trx-dbg to get debug symbols? This way the backtrace will contain more hints for us. thank you holger From ron.menez at entropysolution.com Tue May 2 09:21:03 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 2 May 2017 09:21:03 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <4668079C-3774-421B-8DD7-AB525B44D03D@freyther.de> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> <3F7C2796-B6D0-4D01-888B-169E7C531D68@entropysolution.com> <4668079C-3774-421B-8DD7-AB525B44D03D@freyther.de> Message-ID: Hi Holger, Upon installing "osmo-trx-dbg?, no errors was received and everything went well. Is there library or binary version difference between osmo-trx and osmo-trx-dbg that may cause to resolve the issue? Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC] Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you. On May 2, 2017, at 2:50 PM, Holger Freyther > wrote: On 2. May 2017, at 08:13, Ron > wrote: Hi Holger, Hi! Any suggestions for the error encountered? as Tom pointed out your CPU should be fine. Could you install osmo-trx-dbg to get debug symbols? This way the backtrace will contain more hints for us. thank you holger -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: D7861C66-51ED-4DB6-B9ED-BADEB28148EC.png Type: image/png Size: 7117 bytes Desc: D7861C66-51ED-4DB6-B9ED-BADEB28148EC.png URL: From holger at freyther.de Tue May 2 09:22:46 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 May 2017 11:22:46 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> <3F7C2796-B6D0-4D01-888B-169E7C531D68@entropysolution.com> <4668079C-3774-421B-8DD7-AB525B44D03D@freyther.de> Message-ID: > On 2. May 2017, at 11:21, Ron wrote: > > Hi Holger, > > Upon installing "osmo-trx-dbg?, no errors was received and everything went well. > > Is there library or binary version difference between osmo-trx and osmo-trx-dbg that may cause to resolve the issue? > No, the osmo-trx-dbg package only installs debug symbols that are associated with it. Maybe as part of the installation osmo-trx itself was updated too? holger From nhofmeyr at sysmocom.de Tue May 2 10:05:50 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 2 May 2017 12:05:50 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170426223538.pwcdr5k6atogocft@nataraja> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423130248.bjzo6u2w73rlxi7q@nataraja> <95995AFE-6FF2-4A8F-B2AE-060351D98ADE@freyther.de> <20170424112620.sw43e75s2yyotfmm@nataraja> <20170425134015.GE1753@ass40.sysmocom.de> <20170425213445.rv66lbdsqtffty5w@nataraja> <2620b761-f3ad-b850-95f8-41640d97a358@sysmocom.de> <2a5e5e8b-8b49-7d29-8c6b-bfc20313d878@sysmocom.de> <20170426140715.GA518@my.box> <20170426223538.pwcdr5k6atogocft@nataraja> Message-ID: <20170502100550.GC2407@ass40.sysmocom.de> On Thu, Apr 27, 2017 at 12:35:38AM +0200, Harald Welte wrote: > > osmocom-cell-net / OsmocomCellNet > due to above reasoning. agreed ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue May 2 10:29:17 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 2 May 2017 12:29:17 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> Message-ID: <20170502102917.GE2407@ass40.sysmocom.de> On Sat, Apr 29, 2017 at 11:24:00AM +0800, Tom Tsou wrote: > On Sat, Apr 29, 2017 at 5:22 AM, Holger Freyther wrote: > > @dexter/@tom: Do you see any cpu feature that should be there but isn't? > > SSE3 and SSE4_1 are the instruction sets used by osmo-trx. There > should be no instruction set concerns for a processor that supports > AVX, so I'm not sure what's going on here. Note that I'm seeing the same trying to use osmo-trx on our osmo-gsm-tester setup. See the bottom of http://osmocom.org/issues/1869 Tom, would you please take a look at the osmo-trx patches sitting on gerrit? We've been spending quite some time on the SSE issues, but now the patches for it are idling on gerrit. Would be great to move ahead there. Concerning review, dexter is currently on vacation and I don't feel qualified to fix the patches. But maybe some of them can just be merged as they are now? I really need the osmo-trx build to work cross-CPU to unstall (part of) the osmo-gsm-tester project. I'm building --without-sse but it's still failing. My hope is that the patches from dexter are solving the issue. https://gerrit.osmocom.org/#/q/project:osmo-trx+owner:%22dexter+%253Cpmaier%2540sysmocom.de%253E%22 Thanks! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue May 2 10:45:51 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 2 May 2017 12:45:51 +0200 Subject: nano3G <-> sip-connector <-> asterisk? In-Reply-To: <20170429102810.GA12407@pocken.who.de> References: <20170429102810.GA12407@pocken.who.de> Message-ID: <20170502104551.GF2407@ass40.sysmocom.de> On Sat, Apr 29, 2017 at 12:28:10PM +0200, Andreas Mueller wrote: > Hello, > > is it possible to connect the openbsc from the vlr_3G Branch with sip-connector to asterisk as described on https://osmocom.org/projects/osmo-sip-conector/wiki/Osmo-sip-connector, or are there changes in the vlr_3G Branch that makes this impossible? > When trying to set this up I was able to call an UMTS-Phone which was connected to the nano3G from a softphone using jitsi, and the UMTS-Phone was ringing, but it was not possible to answer the call. > I have only limited experiences with asterisk and so I am for example unsure about what voice-codecs to use, if my asterisk-config is correct,... and so I would like to know if it should work in principle and I have to find the correct configuration. So far the 3G has only been tested with a single femto cell, routing voice back to the cell, there's almost certainly RTP streaming flexibility missing there. Personally I'm not very familiar with SIP and osmo-sip-connector, so I can't tell you right away what the next steps would be. But we're also working on a proper A-interface to the OsmoMSC, meaning that the way the vlr_3G branch is using RTP will become the "normal" way Osmocom will handle RTP streams (IIUC). In other words, we should soon reach the point where me or others at sysmocom will actively be looking into RTP streams and multiple cells and osmo-sip-connector. If you'd like to go ahead on it, you could try to grok the MGCP communication and osmo-bsc_mgcp redirecting the RTP streams, to see if there's a simple stupidity you could patch up. See openbsc/openbsc/src/libmsc/msc_ifaces.c, which instructs osmo-bsc_mgcp to route the RTP stream with these functions: conn_iu_rab_act_cs() mgcp_response_rab_act_cs_crcx() iu_rab_act_cs() mgcp_bridge() mgcp_response_bridge_mdcx() And look at the osmo-bsc_mgcp log output to see the sequence of things. Basically it creates echoing RTP endpoints for each subscriber by sending 'CRCX' MGCP commands to osmo-bsc_mgcp, and once both RABs are assigned, calls 'MDCX' to connect those two RTP streams together. As I said that's fairly barebones, just about working, and a lot needs to be done to make it universally usable. Any help or analysis there would be very welcome! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue May 2 10:52:14 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 2 May 2017 12:52:14 +0200 Subject: autoreconf: "header not found" in generated source In-Reply-To: References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> Message-ID: <20170502105214.GG2407@ass40.sysmocom.de> On Mon, May 01, 2017 at 03:41:03AM +0700, Vadim Yanitskiy wrote: > > We generate "conv.h" and put it into the source directory? > > Actually, no. We aren't generate the "conv.h". > It's written manually and contains the conv_test_vector > structure definition and the do_check() function definition. written manually? You mean committed in gerrit, right? > One was introduced by: https://gerrit.osmocom.org/#/c/1627/ > so now the same test logic is used in two different tests > (both conv and conv_gsm0503) without code duplication. We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). To #include, you would use something like #include . > Don't you confuse it with the "gsm0503.h", which is exactly > generated by the "utils/conv_gen.py"? Loosely related: some time back I modified some generation code to put generated C files in the builddir, adding -I$(builddir) to be able to find them from srcdir... I think it was this one I fixed. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dr.blobb at gmail.com Tue May 2 17:59:35 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Tue, 2 May 2017 19:59:35 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications Message-ID: Hi all, here's a (late) recap on the "dependency-artifacts" topic discussed with Holger and Neels at OsmoDevCon. The "mv $artifact"-issue, which occurs when run within a docker container has been resolved. Now artifacts are created inside a temporary directory within the ARTIFACT_STORE and not inside the Docker container, so the "mv" command won't take as long as a "cp" anymore. Moreover, artifacts are now stored per jenkins job and not per git project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for each jenkins job to distinguish between them. This means artifacts aren't shared across jobs which build the same git project. This might change in the future, but is safe for now as some jenkins jobs might need dependencies built with different configurations. Note: the necessary disk space for openBSC artifacts of one matrix-configuration job is ~400 MB (~50 MB per axis). Furthermore, each jenkins job takes care about garbage collection on its own by simply deleting the entire content of its JOB_NAME-directory inside the ARTIFACT_STORE. The two scripts osmo-{build,artifacts}.sh have been tested [1][2], shellcheck'ed and pushed to gerrit [3]. The following actions are pending to enable the use of artifacts inside contrib/jenkins.sh within each git repository, but can not be applied by me: - setting ARTIFACT_STORE environment variable for each jenkins slave - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user - adding a new docker volume for the ARTIFACT_STORE to the image But, let's review first. =) Cheers, Andr? [1] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_testRefactoring/IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=masterSlave/57/consoleFull [2] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_testRefactoring/IU=--disable-iu,MGCP=--disable-mgcp-transcoding,SMPP=--enable-smpp,label=masterSlave/58/consoleFull [3] https://gerrit.osmocom.org/#/c/2465/ From nhofmeyr at sysmocom.de Tue May 2 18:33:52 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 2 May 2017 20:33:52 +0200 Subject: FreeBSD C compiler version Message-ID: <20170502183352.GA10814@my.box> @fixeria: re the C compiler used on the FreeBSD build slave: it is actually, apparently: FreeBSD clang version 3.4.1 20140512 x86_64-unknown-freebsd10.3 At least that's what a libosmocore ./configure step shows in its config.log. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.chemeris at gmail.com Tue May 2 18:51:17 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 2 May 2017 21:51:17 +0300 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <20170502102917.GE2407@ass40.sysmocom.de> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> <20170502102917.GE2407@ass40.sysmocom.de> Message-ID: Hi Neels (and sorry for top posting) I don't think those patches will change this if your seeing a failure with a --without-sse build. Could you try building the whole code with a specific --march --mcpu settings for the target CPU you're running it at? It looks like gcc may be putting in some optimizations into an noon optimized part of the code. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On May 2, 2017 1:29 PM, "Neels Hofmeyr" wrote: > On Sat, Apr 29, 2017 at 11:24:00AM +0800, Tom Tsou wrote: > > On Sat, Apr 29, 2017 at 5:22 AM, Holger Freyther > wrote: > > > @dexter/@tom: Do you see any cpu feature that should be there but > isn't? > > > > SSE3 and SSE4_1 are the instruction sets used by osmo-trx. There > > should be no instruction set concerns for a processor that supports > > AVX, so I'm not sure what's going on here. > > Note that I'm seeing the same trying to use osmo-trx on our > osmo-gsm-tester setup. See the bottom of http://osmocom.org/issues/1869 > > Tom, would you please take a look at the osmo-trx patches sitting on > gerrit? We've been spending quite some time on the SSE issues, but now the > patches for it are idling on gerrit. Would be great to move ahead there. > > Concerning review, dexter is currently on vacation and I don't feel > qualified to fix the patches. But maybe some of them can just be merged > as they are now? > > I really need the osmo-trx build to work cross-CPU to unstall (part of) > the osmo-gsm-tester project. I'm building --without-sse but it's still > failing. My hope is that the patches from dexter are solving the issue. > > https://gerrit.osmocom.org/#/q/project:osmo-trx+owner:% > 22dexter+%253Cpmaier%2540sysmocom.de%253E%22 > > Thanks! > > ~N > > -- > - Neels Hofmeyr http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Gesch?ftsf?hrer / Managing Directors: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Tue May 2 20:19:03 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 3 May 2017 03:19:03 +0700 Subject: autoreconf: "header not found" in generated source In-Reply-To: <20170502105214.GG2407@ass40.sysmocom.de> References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> <20170502105214.GG2407@ass40.sysmocom.de> Message-ID: Hi, > written manually? Yes. Just look at content of this header file. > We tend to put all headers used from several locations in > openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). > To #include, you would use something like #include . Yeah, I tried to put one into include/osmocom/tests/, but Harald and Sylvain voted against this approach. So I decided to go this way. With best regards, Vadim Yanitskiy. 2017-05-02 17:52 GMT+07:00 Neels Hofmeyr : > On Mon, May 01, 2017 at 03:41:03AM +0700, Vadim Yanitskiy wrote: > > > We generate "conv.h" and put it into the source directory? > > > > Actually, no. We aren't generate the "conv.h". > > It's written manually and contains the conv_test_vector > > structure definition and the do_check() function definition. > > written manually? You mean committed in gerrit, right? > > > One was introduced by: https://gerrit.osmocom.org/#/c/1627/ > > so now the same test logic is used in two different tests > > (both conv and conv_gsm0503) without code duplication. > > We tend to put all headers used from several locations in > openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). > To #include, you would use something like #include . > > > Don't you confuse it with the "gsm0503.h", which is exactly > > generated by the "utils/conv_gen.py"? > > Loosely related: some time back I modified some generation code to put > generated C files in the builddir, adding -I$(builddir) to be able to find > them from srcdir... I think it was this one I fixed. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue May 2 20:36:32 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 2 May 2017 22:36:32 +0200 Subject: autoreconf: "header not found" in generated source In-Reply-To: References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> <20170502105214.GG2407@ass40.sysmocom.de> Message-ID: <20170502203632.mhhta46do36hzo57@nataraja> Hi Vadim, On Wed, May 03, 2017 at 03:19:03AM +0700, Vadim Yanitskiy wrote: > > We tend to put all headers used from several locations in > > openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). > > To #include, you would use something like #include . > > Yeah, I tried to put one into include/osmocom/tests/, but Harald and Sylvain > voted against this approach. So I decided to go this way. The difference is: * openbsc doesn't install any headers, and thus all 'include/openbsc' headers are local to the program * libosmocore isntalls all headers, and thus all 'include/osmocom' headers are installable So if you want to have private header files in libosmcoore (or any other library) you have to put them somewhere else, e.g. in the 'src' directory, as it is already done at several other places. -- - 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 Tue May 2 21:05:54 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 3 May 2017 04:05:54 +0700 Subject: autoreconf: "header not found" in generated source In-Reply-To: <20170502203632.mhhta46do36hzo57@nataraja> References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> <20170502105214.GG2407@ass40.sysmocom.de> <20170502203632.mhhta46do36hzo57@nataraja> Message-ID: Hi Harald, > The difference is: > > * openbsc doesn't install any headers, and thus all 'include/openbsc' > headers are local to the program > * libosmocore isntalls all headers, and thus all 'include/osmocom' > headers are installable It is reasonable, and I support this idea. But anyway we have some noinst_HEADERS in include/Makefile.am, they are: noinst_HEADERS = \ osmocom/core/timer_compat.h \ osmocom/gsm/kasumi.h osmocom/gsm/gea.h So why they are among with other installable headers? Are there any reasons to keep them here? > So if you want to have private header files in libosmcoore > (or any other library) you have to put them somewhere else, > e.g. in the 'src' directory, as it is already done at several > other places. I think, you already pointed the strongest reason, why this header should be outside the include/ directory: because it only needed during unit tests, and nowhere else. And I absolutely agree with you. Now the problem is solved, and this discussion should be closed. With best regards, Vadim Yanitskiy. 2017-05-03 3:36 GMT+07:00 Harald Welte : > Hi Vadim, > > On Wed, May 03, 2017 at 03:19:03AM +0700, Vadim Yanitskiy wrote: > > > > We tend to put all headers used from several locations in > > > openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the > Makefile.am). > > > To #include, you would use something like #include . > > > > Yeah, I tried to put one into include/osmocom/tests/, but Harald and > Sylvain > > voted against this approach. So I decided to go this way. > > The difference is: > > * openbsc doesn't install any headers, and thus all 'include/openbsc' > headers are local to the program > * libosmocore isntalls all headers, and thus all 'include/osmocom' > headers are installable > > So if you want to have private header files in libosmcoore (or any other > library) you have to put them somewhere else, e.g. in the 'src' > directory, as it is already done at several other places. > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.0jacob0 at gmail.com Wed May 3 07:24:18 2017 From: sami.0jacob0 at gmail.com (sami) Date: Wed, 3 May 2017 10:24:18 +0300 Subject: UMTS Message-ID: Hi all, Does OpenBSC support UMTS like the OpenBTS-UMTS ? best regards, From laforge at gnumonks.org Wed May 3 07:37:43 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 3 May 2017 09:37:43 +0200 Subject: UMTS In-Reply-To: References: Message-ID: <20170503073743.hfpsmlegu2xelae3@nataraja> On Wed, May 03, 2017 at 10:24:18AM +0300, sami wrote: > Does OpenBSC support UMTS like the OpenBTS-UMTS ? Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G for an introduction into 3G (UMTS) support in the Osmocom universe. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sami.0jacob0 at gmail.com Wed May 3 08:21:16 2017 From: sami.0jacob0 at gmail.com (sami) Date: Wed, 3 May 2017 11:21:16 +0300 Subject: UMTS In-Reply-To: <20170503073743.hfpsmlegu2xelae3@nataraja> References: <20170503073743.hfpsmlegu2xelae3@nataraja> Message-ID: <190BA016-B085-40D8-8B7E-BCE89E03B22D@gmail.com> Hi, the described hardware requires a femto cell. Is there a way to have the setup working on a USRP ? On May 3, 2017, at 10:37 AM, Harald Welte wrote: > On Wed, May 03, 2017 at 10:24:18AM +0300, sami wrote: >> Does OpenBSC support UMTS like the OpenBTS-UMTS ? > > Please see > https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G > for an introduction into 3G (UMTS) support in the Osmocom universe. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed May 3 08:49:39 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 3 May 2017 10:49:39 +0200 Subject: UMTS In-Reply-To: <190BA016-B085-40D8-8B7E-BCE89E03B22D@gmail.com> References: <20170503073743.hfpsmlegu2xelae3@nataraja> <190BA016-B085-40D8-8B7E-BCE89E03B22D@gmail.com> Message-ID: <20170503084939.tqvxirv3ukl36puo@nataraja> On Wed, May 03, 2017 at 11:21:16AM +0300, sami wrote: > the described hardware requires a femto cell. Is there a way to have > the setup working on a USRP ? no, not unless you happen to have a UMTS PHY layer + RLC/MAC + RRC implementation that you can run on it. It might be possible to convert/adapt OpenBTS-UMTS code to function as that [only] and then talk Iuh to Osmo-HNBGW, but I'm not sure how much it would be worth the effort, given that (I understand, correct me if I'm wrong) it's Rel'99 384 kBps only (no HSDDPA/HSUPA), and data-only (no CS plane). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From radiarisainanasitraka at yahoo.fr Wed May 3 09:18:25 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Wed, 3 May 2017 09:18:25 +0000 (UTC) Subject: GRPS Only References: <715670892.2227985.1493803105402.ref@mail.yahoo.com> Message-ID: <715670892.2227985.1493803105402@mail.yahoo.com> Hello, I would like to ask , If I would like to use GPRS only without GSM with OsmoNITB , What configuration should I do !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From radiarisainanasitraka at yahoo.fr Wed May 3 09:34:41 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Wed, 3 May 2017 09:34:41 +0000 (UTC) Subject: GPRS only without GSM References: <32725768.2222679.1493804081909.ref@mail.yahoo.com> Message-ID: <32725768.2222679.1493804081909@mail.yahoo.com> Hello, I would like to use GPRS only without GSM with OsmoNITB; what kind of configuration should I do !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed May 3 09:56:32 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 3 May 2017 11:56:32 +0200 Subject: GPRS only without GSM In-Reply-To: <32725768.2222679.1493804081909@mail.yahoo.com> References: <32725768.2222679.1493804081909.ref@mail.yahoo.com> <32725768.2222679.1493804081909@mail.yahoo.com> Message-ID: <20170503095632.l5h3p2g6iqufzz7e@nataraja> On Wed, May 03, 2017 at 09:34:41AM +0000, Radiarisainana Sitraka wrote: > I would like to use GPRS only without GSM with OsmoNITB; what kind of configuration should I do !? Please be more specific what is the exact behaviour you would like. * The GSM side should reject all location updates, but only GPRS LU + ATTACH should work? This should be possible by having no subscribers in your NITB HLR and white-listing them in the SGSN ACL. However, 99% of all MS that I've seen will attempt a GSM LU before doing a GPRS LU, and if they get rejected on GSM, they will not try to register on GSM. Only some very few MS (like certain cellular modems for M2M applications) can be configured to only attach on GPRS without performing a GSM LU first. * GSM LU should work, but all calls and SMS shall be rejected This is not possible currently, it would require some smaller modifications/extensions to the code. Would fit quite easily into the new OsmoMSC + OsmoHLR model, where the HLR could be extended with subscription information for all individual teleservices. -- - 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 Wed May 3 11:45:39 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 3 May 2017 18:45:39 +0700 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) Message-ID: Hi Alexander and all, > I don't think those patches will change this if your seeing a failure with > a --without-sse build. I hope, it should, because even with --without-sse we still had -march=native. http://git.osmocom.org/osmo-trx/commit/?id=78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f Neels, do you still have the same problem with running on osmo-gsm-tester setup? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Wed May 3 11:48:57 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 3 May 2017 13:48:57 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: Message-ID: <6b2ef79f-5121-aea9-4c00-90adc5bb4cc2@sysmocom.de> You might want to have a look at 78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f in osmo-trx which seems to be related. On 03.05.2017 13:45, Vadim Yanitskiy wrote: > Hi Alexander and all, > > > I don't think those patches will change this if your seeing a failure with > > a --without-sse build. > > I hope, it should, because even with --without-sse we still had -march=native. > http://git.osmocom.org/osmo-trx/commit/?id=78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f -- Max Suraev 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 dga-mi.imi.fct at intradef.gouv.fr Thu May 4 09:40:14 2017 From: dga-mi.imi.fct at intradef.gouv.fr (dga-mi.imi.fct at intradef.gouv.fr) Date: Thu, 4 May 2017 09:40:14 +0000 Subject: 3G openBSC In-Reply-To: References: Message-ID: <2BB505A96EF4274B86685F94F1A1B6FD23007140@INF31BRUZ--WM15.DR-RES.INTRADEF.GOUV.FR> Hello, I would like to know whether the 3G openBSC platform is enough stable to start using it for data and voice services. Which 3G femtocell do you recommand ? Is it possible to use Sysmocom SIM for 3G UE registration? Best regards, Remi [ENVOYE PAR INTERNET] -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 4 12:40:43 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 4 May 2017 14:40:43 +0200 Subject: 3G openBSC In-Reply-To: <2BB505A96EF4274B86685F94F1A1B6FD23007140@INF31BRUZ--WM15.DR-RES.INTRADEF.GOUV.FR> References: <2BB505A96EF4274B86685F94F1A1B6FD23007140@INF31BRUZ--WM15.DR-RES.INTRADEF.GOUV.FR> Message-ID: <20170504124043.cv7lgerd7jnjrxtw@nataraja> Hi Remi, On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct at intradef.gouv.fr wrote: > I would like to know whether the 3G openBSC platform is enough stable > to start using it for data and voice services. I think it is the right time to start with trials and testing, but not for production use. > Which 3G femtocell do you recommand ? We have currently tested it with nano3G and with a small cell hardware we call sysmoCell 5000. you can contact sales at sysmocom.de for related information. Of course anyone is free to integrate and/or tests osmo-iuh with other femtocell or small cell products, but so far I have not heard of anyone doing that. > Is it possible to use Sysmocom SIM for 3G UE registration? sure! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dga-mi.imi.fct at intradef.gouv.fr Thu May 4 15:28:40 2017 From: dga-mi.imi.fct at intradef.gouv.fr (dga-mi.imi.fct at intradef.gouv.fr) Date: Thu, 4 May 2017 15:28:40 +0000 Subject: 3G openBSC In-Reply-To: <20170504124043.cv7lgerd7jnjrxtw@nataraja> References: <2BB505A96EF4274B86685F94F1A1B6FD23007140@INF31BRUZ--WM15.DR-RES.INTRADEF.GOUV.FR> <20170504124043.cv7lgerd7jnjrxtw@nataraja> Message-ID: <1AF67E76B86DB04F8551E2C311C0F7DC20F2DC9C@INF31BRUZ--WM16.DR-RES.INTRADEF.GOUV.FR> Harald, Thank you very much for your response. I will contact sysmocom sales to get further information on 3G nano cell. Best regards, Remi [ENVOYE PAR INTERNET] -----Message d'origine----- De?: Harald Welte [mailto:laforge at gnumonks.org] Envoy??: jeudi 4 mai 2017 14:41 ??: dga-mi.imi.fct Cc?: 'openbsc at lists.osmocom.org' Objet?: Re: 3G openBSC Hi Remi, On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct at intradef.gouv.fr wrote: > I would like to know whether the 3G openBSC platform is enough stable > to start using it for data and voice services. I think it is the right time to start with trials and testing, but not for production use. > Which 3G femtocell do you recommand ? We have currently tested it with nano3G and with a small cell hardware we call sysmoCell 5000. you can contact sales at sysmocom.de for related information. Of course anyone is free to integrate and/or tests osmo-iuh with other femtocell or small cell products, but so far I have not heard of anyone doing that. > Is it possible to use Sysmocom SIM for 3G UE registration? sure! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu May 4 15:52:28 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 4 May 2017 17:52:28 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: References: Message-ID: <20170504155228.GA8279@ass40.sysmocom.de> On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote: > Hi all, > > here's a (late) recap on the "dependency-artifacts" topic discussed > with Holger and Neels at OsmoDevCon. > > > The "mv $artifact"-issue, which occurs when run within a docker > container has been resolved. Now artifacts are created inside a > temporary directory within the ARTIFACT_STORE and not inside the > Docker container, so the "mv" command won't take as long as a "cp" > anymore. > > Moreover, artifacts are now stored per jenkins job and not per git > project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for > each jenkins job to distinguish between them. This means artifacts > aren't shared across jobs which build the same git project. This might > change in the future, but is safe for now as some jenkins jobs might > need dependencies built with different configurations. > > Note: the necessary disk space for openBSC artifacts of one > matrix-configuration job is ~400 MB (~50 MB per axis). > > Furthermore, each jenkins job takes care about garbage collection on > its own by simply deleting the entire content of its > JOB_NAME-directory inside the ARTIFACT_STORE. Which is, for the record, the reason to have it per-job: we always know which artifacts need to be / we are allowed to clean up. With multiple jobs accessing the same artifact store, GC is not trivial. > The two scripts osmo-{build,artifacts}.sh have been tested [1][2], > shellcheck'ed and pushed to gerrit [3]. nice! > The following actions are pending to enable the use of artifacts > inside contrib/jenkins.sh within each git repository, but can not be > applied by me: > > - setting ARTIFACT_STORE environment variable for each jenkins slave > - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user Add to osmo-ci. Could you submit a patch for it? git clone https://gerrit.osmocom.org/osmo-ci > - adding a new docker volume for the ARTIFACT_STORE to the image We're talking about the docker invocation in the OpenBSC and OpenBSC-gerrit jobs. > But, let's review first. =) I notice there are hashes of various dependent builds in the tar names: libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652_libsmpp34.master.cc0bcd6_openggsn.master.19e19e3.tar.gz I remember that we said to instead have each on its own -- but not saying we have to, just curious. So the semantics are: figure out all of the hashes of all dependencies, as soon as one of them mismatches rebuild all and make a new single tar with all included. Right? Also curious about how a matrix build would do it: would every matrix rebuild the same dependency? (We said that that's fine IIRC) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu May 4 20:35:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 4 May 2017 22:35:12 +0200 Subject: gerrit: thanks for login link Message-ID: <20170504203512.GA9220@my.box> BTW, the "Sign in with Osmocom" link on the gerrit login page is really nice! It even works as a bookmark. Many Thanks!! (@holger?) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Thu May 4 20:49:51 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 4 May 2017 22:49:51 +0200 Subject: gerrit: thanks for login link In-Reply-To: <20170504203512.GA9220@my.box> References: <20170504203512.GA9220@my.box> Message-ID: > On 4. May 2017, at 22:35, Neels Hofmeyr wrote: > > Many Thanks!! (@holger?) maybe I have a future in frontend development after all ;) From nhofmeyr at sysmocom.de Thu May 4 22:31:09 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 5 May 2017 00:31:09 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: <20170504155228.GA8279@ass40.sysmocom.de> References: <20170504155228.GA8279@ass40.sysmocom.de> Message-ID: <20170504223109.GA12415@my.box> On Thu, May 04, 2017 at 05:52:28PM +0200, Neels Hofmeyr wrote: > On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote: > > The following actions are pending to enable the use of artifacts > > inside contrib/jenkins.sh within each git repository, but can not be > > applied by me: > > > > - setting ARTIFACT_STORE environment variable for each jenkins slave > > - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user > > Add to osmo-ci. Could you submit a patch for it? > git clone https://gerrit.osmocom.org/osmo-ci Of course that's https://gerrit.osmocom.org/2465 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From radiarisainanasitraka at yahoo.fr Fri May 5 05:39:11 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Fri, 5 May 2017 05:39:11 +0000 (UTC) Subject: OpenBSC Digest, Vol 31, Issue 6 In-Reply-To: References: Message-ID: <734096548.5184049.1493962751884@mail.yahoo.com> Hello, And, what is the different of "nano3G" and the "sysmocell 5000" !? Chears, De?: "openbsc-request at lists.osmocom.org" ??: openbsc at lists.osmocom.org Envoy? le : Jeudi 4 mai 2017 18h32 Objet?: OpenBSC Digest, Vol 31, Issue 6 Send OpenBSC mailing list submissions to ??? openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit ??? https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to ??? openbsc-request at lists.osmocom.org You can reach the person managing the list at ??? openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: ? 1. Re: osmo-bts-trx error / osmo-trx illegal instruction (core ? ? ? dumped) (Max) ? 2. 3G openBSC (dga-mi.imi.fct at intradef.gouv.fr) ? 3. Re: 3G openBSC (Harald Welte) ? 4. RE: 3G openBSC (dga-mi.imi.fct at intradef.gouv.fr) ? 5. Re: dependency artifacts for faster ? ? ? builds/gerrit-verifications (Neels Hofmeyr) ? 6. gerrit: thanks for login link (Neels Hofmeyr) ? 7. Re: gerrit: thanks for login link (Holger Freyther) ? 8. Re: dependency artifacts for faster ? ? ? builds/gerrit-verifications (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 May 2017 13:48:57 +0200 From: Max To: openbsc at lists.osmocom.org Subject: Re: osmo-bts-trx error / osmo-trx illegal instruction (core ??? dumped) Message-ID: <6b2ef79f-5121-aea9-4c00-90adc5bb4cc2 at sysmocom.de> Content-Type: text/plain; charset=utf-8 You might want to have a look at 78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f in osmo-trx which seems to be related. On 03.05.2017 13:45, Vadim Yanitskiy wrote: > Hi Alexander and all, > > > I don't think those patches will change this if your seeing a failure with > > a --without-sse build. > > I hope, it should, because even with --without-sse we still had -march=native. > http://git.osmocom.org/osmo-trx/commit/?id=78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f -- Max Suraev 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 ------------------------------ Message: 2 Date: Thu, 4 May 2017 09:40:14 +0000 From: "dga-mi.imi.fct at intradef.gouv.fr" ??? To: "'openbsc at lists.osmocom.org'" Subject: 3G openBSC Message-ID: ??? <2BB505A96EF4274B86685F94F1A1B6FD23007140 at INF31BRUZ--WM15.DR-RES.INTRADEF.GOUV.FR> ??? Content-Type: text/plain; charset="us-ascii" Hello, I would like to know whether the 3G openBSC platform is enough stable to start using it? for data and voice? services. Which 3G femtocell do you recommand ? Is it possible? to? use? Sysmocom SIM for 3G UE registration? Best regards, Remi [ENVOYE PAR INTERNET] -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 4 May 2017 14:40:43 +0200 From: Harald Welte To: "dga-mi.imi.fct at intradef.gouv.fr" ??? Cc: "'openbsc at lists.osmocom.org'" Subject: Re: 3G openBSC Message-ID: <20170504124043.cv7lgerd7jnjrxtw at nataraja> Content-Type: text/plain; charset=us-ascii Hi Remi, On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct at intradef.gouv.fr wrote: > I would like to know whether the 3G openBSC platform is enough stable > to start using it? for data and voice? services. I think it is the right time to start with trials and testing, but not for production use. > Which 3G femtocell do you recommand ? We have currently tested it with nano3G and with a small cell hardware we call sysmoCell 5000.? you can contact sales at sysmocom.de for related information. Of course anyone is free to integrate and/or tests osmo-iuh with other femtocell or small cell products, but so far I have not heard of anyone doing that. > Is it possible? to? use? Sysmocom SIM for 3G UE registration? sure! -- - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 4 Date: Thu, 4 May 2017 15:28:40 +0000 From: "dga-mi.imi.fct at intradef.gouv.fr" ??? To: "'openbsc at lists.osmocom.org'" Subject: RE: 3G openBSC Message-ID: ??? <1AF67E76B86DB04F8551E2C311C0F7DC20F2DC9C at INF31BRUZ--WM16.DR-RES.INTRADEF.GOUV.FR> ??? Content-Type: text/plain; charset="iso-8859-1" Harald, Thank you very much for your? response. I will contact? sysmocom sales to get further information on 3G nano cell. Best regards, Remi [ENVOYE PAR INTERNET] -----Message d'origine----- De?: Harald Welte [mailto:laforge at gnumonks.org] Envoy??: jeudi 4 mai 2017 14:41 ??: dga-mi.imi.fct Cc?: 'openbsc at lists.osmocom.org' Objet?: Re: 3G openBSC Hi Remi, On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct at intradef.gouv.fr wrote: > I would like to know whether the 3G openBSC platform is enough stable > to start using it? for data and voice? services. I think it is the right time to start with trials and testing, but not for production use. > Which 3G femtocell do you recommand ? We have currently tested it with nano3G and with a small cell hardware we call sysmoCell 5000.? you can contact sales at sysmocom.de for related information. Of course anyone is free to integrate and/or tests osmo-iuh with other femtocell or small cell products, but so far I have not heard of anyone doing that. > Is it possible? to? use? Sysmocom SIM for 3G UE registration? sure! -- - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 5 Date: Thu, 4 May 2017 17:52:28 +0200 From: Neels Hofmeyr To: Andr? Boddenberg Cc: OpenBSC Subject: Re: dependency artifacts for faster ??? builds/gerrit-verifications Message-ID: <20170504155228.GA8279 at ass40.sysmocom.de> Content-Type: text/plain; charset="iso-8859-1" On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote: > Hi all, > > here's a (late) recap on the "dependency-artifacts" topic discussed > with Holger and Neels at OsmoDevCon. > > > The "mv $artifact"-issue, which occurs when run within a docker > container has been resolved. Now artifacts are created inside a > temporary directory within the ARTIFACT_STORE and not inside the > Docker container, so the "mv" command won't take as long as a "cp" > anymore. > > Moreover, artifacts are now stored per jenkins job and not per git > project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for > each jenkins job to distinguish between them. This means artifacts > aren't shared across jobs which build the same git project. This might > change in the future, but is safe for now as some jenkins jobs might > need dependencies built with different configurations. > > Note: the necessary disk space for openBSC artifacts of one > matrix-configuration job is ~400 MB (~50 MB per axis). > > Furthermore, each jenkins job takes care about garbage collection on > its own by simply deleting the entire content of its > JOB_NAME-directory inside the ARTIFACT_STORE. Which is, for the record, the reason to have it per-job: we always know which artifacts need to be / we are allowed to clean up. With multiple jobs accessing the same artifact store, GC is not trivial. > The two scripts osmo-{build,artifacts}.sh have been tested [1][2], > shellcheck'ed and pushed to gerrit [3]. nice! > The following actions are pending to enable the use of artifacts > inside contrib/jenkins.sh within each git repository, but can not be > applied by me: > >? - setting ARTIFACT_STORE environment variable for each jenkins slave >? - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user Add to osmo-ci. Could you submit a patch for it? git clone https://gerrit.osmocom.org/osmo-ci >? - adding a new docker volume for the ARTIFACT_STORE to the image We're talking about the docker invocation in the OpenBSC and OpenBSC-gerrit jobs. > But, let's review first. =) I notice there are hashes of various dependent builds in the tar names: libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652_libsmpp34.master.cc0bcd6_openggsn.master.19e19e3.tar.gz I remember that we said to instead have each on its own -- but not saying we have to, just curious. So the semantics are: figure out all of the hashes of all dependencies, as soon as one of them mismatches rebuild all and make a new single tar with all included. Right? Also curious about how a matrix build would do it: would every matrix rebuild the same dependency? (We said that that's fine IIRC) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 6 Date: Thu, 4 May 2017 22:35:12 +0200 From: Neels Hofmeyr To: openbsc at lists.osmocom.org Subject: gerrit: thanks for login link Message-ID: <20170504203512.GA9220 at my.box> Content-Type: text/plain; charset="us-ascii" BTW, the "Sign in with Osmocom" link on the gerrit login page is really nice! It even works as a bookmark. Many Thanks!! (@holger?) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 7 Date: Thu, 4 May 2017 22:49:51 +0200 From: Holger Freyther To: Neels Hofmeyr Cc: openbsc at lists.osmocom.org Subject: Re: gerrit: thanks for login link Message-ID: Content-Type: text/plain; charset=us-ascii > On 4. May 2017, at 22:35, Neels Hofmeyr wrote: > > Many Thanks!! (@holger?) maybe I have a future in frontend development after all ;) ------------------------------ Message: 8 Date: Fri, 5 May 2017 00:31:09 +0200 From: Neels Hofmeyr To: Andr? Boddenberg Cc: OpenBSC Subject: Re: dependency artifacts for faster ??? builds/gerrit-verifications Message-ID: <20170504223109.GA12415 at my.box> Content-Type: text/plain; charset="iso-8859-1" On Thu, May 04, 2017 at 05:52:28PM +0200, Neels Hofmeyr wrote: > On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote: > > The following actions are pending to enable the use of artifacts > > inside contrib/jenkins.sh within each git repository, but can not be > > applied by me: > > > >? - setting ARTIFACT_STORE environment variable for each jenkins slave > >? - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user > > Add to osmo-ci. Could you submit a patch for it? > git clone https://gerrit.osmocom.org/osmo-ci Of course that's https://gerrit.osmocom.org/2465 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 31, Issue 6 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri May 5 07:56:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 5 May 2017 09:56:24 +0200 Subject: OpenBSC Digest, Vol 31, Issue 6 In-Reply-To: <734096548.5184049.1493962751884@mail.yahoo.com> References: <734096548.5184049.1493962751884@mail.yahoo.com> Message-ID: <20170505075624.yzxccfvofxcy7kgt@nataraja> Dear Radiarisainana, On Fri, May 05, 2017 at 05:39:11AM +0000, Radiarisainana Sitraka wrote: > And, what is the different of "nano3G" and the "sysmocell 5000" !? 0) we keep a strict separation between the open source projects and related businesses/companies that provide products and services around it. 1) this mailing list is a list for discussion about the Osmocom open source cellular infrastructure projects, and not a mailing list related to what products which company provides, and what their paraemeters or diffrences are. If you have questions related to a certain vendor, please discuss it with that vendor directly. 2) Please observe the most basic social norms when using mailing lists. * Full-quoting messages is neither useful nor necessary, particularly* not full-quoting an entire message digest. * Always make sure you messages have an useful subject line. "OpenBSC Digest" is not useful subject line * Never "hijack" any thread, but always create a new message for a new topic. * We have summarized the mailing list rules at https://osmocom.org/projects/cellular-infrastructure/wiki/Mailing_List_Rules Thanks for your kind attention. 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 dr.blobb at gmail.com Fri May 5 15:19:35 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Fri, 5 May 2017 17:19:35 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: <20170504223109.GA12415@my.box> References: <20170504155228.GA8279@ass40.sysmocom.de> <20170504223109.GA12415@my.box> Message-ID: Hi Neels, thanks for adding missing details for those who haven't participated in our f2f conversation! > I notice there are hashes of various dependent builds in the tar names: > > libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652_libsmpp34.master.cc0bcd6_openggsn.master.19e19e3.tar.gz > > I remember that we said to instead have each on its own -- but not saying > we have to, just curious. That would be great, but I don't know whether we could simply fetch and inject e.g. "libosmo-netif.master.b4aed1e.tar.gz" to update an artifact which is up-to-date except libosmo-netif, because libosmo-netif depends on libosmo-abis, which depends itself on libosmocore, correct? If correct an artifact for libosmo-netif would need to hold its dependencies in its name as well, because libosmo-netif may didn't change, but its dependencies may did!? Ive created a diagram [1] showing openBSC dependencies and the dependencies of them to illustrate above-stated. As I see, libsmpp34 would be the only openBSC dependency that could be simply injected? Additionally, I created a second diagram [2] that shows a bit of brainstorming. In this thought experiment openBSC depends on the following three "sub-artifacts": - libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652 - libosmocore.master.33e0306_openggsn.master.19e19e3.tar.gz - libsmpp34.master.cc0bcd6 , which then can be extracted before triggering actual openBSC build and/or merging all "sub-artifacts" archives to: - libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652_libsmpp34.master.cc0bcd6_openggsn.master.19e19e3.tar.gz In general, I'd say such improvement is definitely worth to investigate. Furthermore, it might be a good approach to start with libosmocore as a first project that exposes artifact(s) for depending projects e.g. libosmo-abis and openggsn. Such mechanism would be much more elegant as the current, in fact right now all projects are only carrying about their own necessary dependencies and that's probably a bit too selfish ;) Note: *.dot files of diagrams can be accessed by simply replacing 'png' with 'dot' in URLs. > So the semantics are: figure out all of the hashes of all dependencies, as > soon as one of them mismatches rebuild all and make a new single tar with > all included. Right? Yes. > Also curious about how a matrix build would do it: would every matrix > rebuild the same dependency? (We said that that's fine IIRC) Yes, every matrix/axes-combination will build its own artifact for the sake of a simple GC. But at the same time it's probably a good place for further improvements ? la axes-combination share same ARTIFACT_STORE folder, which could be easily achieved by changing line 86 in osmo-build.sh [3] to: $ jobName=$(echo "$JOB_NAME" | cut -d '/' -f1 ...just brainstorming. =) [1] https://blobb.me/osmocom/openBSC_allDepsAndTheirDeps.png [2] https://blobb.me/osmocom/openBSC_smartDeps.png [3] https://gerrit.osmocom.org/#/c/2465/6/scripts/osmo-build.sh From msuraev at sysmocom.de Fri May 5 15:24:31 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 5 May 2017 17:24:31 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: References: <20170504155228.GA8279@ass40.sysmocom.de> <20170504223109.GA12415@my.box> Message-ID: <5546e82d-686a-bafe-54ac-f7416bff799e@sysmocom.de> Out of curiosity: On 05.05.2017 17:19, Andr? Boddenberg wrote: > Ive created a diagram [1] showing openBSC dependencies and the > dependencies of them to illustrate above-stated. > Is this manual work or you're extracting dependency info from configure.ac or debian/? -- Max Suraev 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 nhofmeyr at sysmocom.de Fri May 5 15:28:44 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 5 May 2017 17:28:44 +0200 Subject: PCU broken: PACCH paging omitted Message-ID: <20170505152844.GE2458@my.box> Trying to fix a PCU breakage, I introduced another error, causing paging to be broken. All the details are at: https://osmocom.org/issues/2241 https://gerrit.osmocom.org/2420 I need help: could anyone verify whether the patch is doing the right thing now? Otherwise we will need to revert the whole series of breaking patches: http://git.osmocom.org/osmo-pcu/commit/?id=da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7 "Add counter at BTS level And statistics at TBF/MS level." sivasankari http://git.osmocom.org/osmo-pcu/commit/?id=b78a4a6dfef217c538d45949a6ae725e22a36b05 "fix segfault: check for NULL tbf in sched_select_ctrl_msg()" Neels Hofmeyr Thanks for any help! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dr.blobb at gmail.com Fri May 5 15:48:33 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Fri, 5 May 2017 17:48:33 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: <5546e82d-686a-bafe-54ac-f7416bff799e@sysmocom.de> References: <20170504155228.GA8279@ass40.sysmocom.de> <20170504223109.GA12415@my.box> <5546e82d-686a-bafe-54ac-f7416bff799e@sysmocom.de> Message-ID: > Out of curiosity: > > On 05.05.2017 17:19, Andr? Boddenberg wrote: >> Ive created a diagram [1] showing openBSC dependencies and the >> dependencies of them to illustrate above-stated. >> > Is this manual work or you're extracting dependency info from configure.ac or debian/? It's manually work and actually my first diagram made with dotty (nice tool!). I simply went through openBsc' and its dependencies' contrib/jenkins.sh files to create the diagrams. How would you extract information about dependencies from configure.ac? I would probably curl http://git.osmocom.org/${project}/plain/contrib/jenkins.sh and grep+cut all strings occurring after osmo-build-dep.sh and recursively do the same for all found dependencies. Do you in general think an automated way of creating dotty dependency graph would be nice to have? From msuraev at sysmocom.de Fri May 5 15:58:03 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 5 May 2017 17:58:03 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: References: <20170504155228.GA8279@ass40.sysmocom.de> <20170504223109.GA12415@my.box> <5546e82d-686a-bafe-54ac-f7416bff799e@sysmocom.de> Message-ID: On 05.05.2017 17:48, Andr? Boddenberg wrote: > > How would you extract information about dependencies from configure.ac? PKG_CHECK_MODULES() entries should be good enough. There's probably some autotools trick I don't know which would allow to get those automatically without grepping through. Alternatively one can look in debian/control for Build-Depends entries. Not sure if Debian got any dh_* which could extract this in a nice way. > I would probably curl > http://git.osmocom.org/${project}/plain/contrib/jenkins.sh and > grep+cut all strings occurring after osmo-build-dep.sh and recursively > do the same for all found dependencies. > > Do you in general think an automated way of creating dotty dependency > graph would be nice to have? I wouldn't bother just for dotty. Having dependencies part of jenkins jobs to be autogenerated would be kinda cool but: - not sure if it's not overengineering: dependencies do not change that often - not sure how many false positives/negatives the approaches above give -- Max Suraev 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 axilirator at gmail.com Sat May 6 13:13:51 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 6 May 2017 20:13:51 +0700 Subject: FreeBSD C compiler version Message-ID: Dear all, > @fixeria: re the C compiler used on the FreeBSD build slave: > it is actually, apparently: > > FreeBSD clang version 3.4.1 > 20140512 > x86_64-unknown-freebsd10.3 > > At least that's what a libosmocore ./configure step shows in > its config.log. I would like to start a little discussion about FreeBSD build slave. As it turned out, every new commit is being checked on clang compiler too! It was a bit unexpectedly to me, because we already discussed about this in Gerrit: https://gerrit.osmocom.org/#/c/2100/ > Max: > > Do we officially support anything besides gcc? > > Harald: > > not really, but then it is also nice to be portable. My vote > > would be to merge the current patch under discussion, but open > > a ticket as a reminder that this should be made more portable. > > I suppose mplayer/ffmpeg/fftw or other libs with heavily > > optimized algorithms also have a solution to that. Recently I decided to dig into FreeBSD's world, because one of my changes in Gerrit does build fine on Debian slave, but doesn't on FreeBSD. So, I spent a whole night with my laptop and finally installed and configured FreeBSD first time in my experience. https://gerrit.osmocom.org/#/c/2100/ I am running 11.0 STABLE, and by default it comes with clang as default compiler. There is no GCC installed by default. I tried to build my change with different versions of clang and found the following interesting facts: - Recent clang-4.0 does support the __builtin_cpu_supports call, so runtime CPU detection should work in this case too. I don't know if it works in other versions. So, I suggest to add a new configure.ac task, which would check whether compiler supports this call or not. - Regarding to my change, it builds fine on several tested clang versions: clang-3.4.2, clang-3.9, clang-4.0. And I see two possible reasons, why the build fails on FreeBSD: 1) Version 3.4.1 is pretty dated, and we cat try to upgrade it. 2) Clang compiles the source code in a different way, when some SIMD flags are provided. But target CPU doesn't support some of provided SIMD flags. Now in both OsmoTRX and libosmocore we only check whether compiler supports some SIMD flags, but we don't check whether these flags are supported by current build machine CPU. So, lack of the last check and specific optimization / compilation way of clang may cause the fail. I still need to know supported SIMD features of FreeBSD build machine to confirm or refute this assumption. I also have an idea: what if we could build our projects with several compilers (GCC and clang) and with their several versions (the three latest for example) on Jenkins at the same time? I think, it would be great to keep our projects as portable as possible. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Sat May 6 13:23:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 6 May 2017 15:23:15 +0200 Subject: Undeliverable: PCU broken: PACCH paging omitted In-Reply-To: References: <20170505152844.GE2458@my.box> Message-ID: <20170506132315.GH2458@my.box> On Fri, May 05, 2017 at 03:28:48PM +0000, postmaster at Radisyscorp.onmicrosoft.com wrote: > Your message to Sivasankari.Theerthagiri at radisys.com couldn't be delivered. > > Sivasankari.Theerthagiri wasn't found at radisys.com. Dear Radisys, since we are having a problem with a patch from Sivasankari Theerthagiri and since that contact is apparently no longer available, do you have another contact that could help resolve the issue? Thanks! ~N > From: Neels Hofmeyr > To: openbsc at lists.osmocom.org > CC: sivasankari > Subject: PCU broken: PACCH paging omitted > User-Agent: Mutt/1.5.23 (2014-03-12) > > Trying to fix a PCU breakage, I introduced another error, causing paging to be > broken. All the details are at: > https://osmocom.org/issues/2241 > https://gerrit.osmocom.org/2420 > > I need help: could anyone verify whether the patch is doing the right thing > now? Otherwise we will need to revert the whole series of breaking patches: > > http://git.osmocom.org/osmo-pcu/commit/?id=da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7 > "Add counter at BTS level And statistics at TBF/MS level." > sivasankari > > http://git.osmocom.org/osmo-pcu/commit/?id=b78a4a6dfef217c538d45949a6ae725e22a36b05 > "fix segfault: check for NULL tbf in sched_select_ctrl_msg()" > Neels Hofmeyr > > Thanks for any help! > > ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat May 6 14:47:55 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 6 May 2017 16:47:55 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: Message-ID: <20170506144755.GI2458@my.box> On Wed, May 03, 2017 at 06:45:39PM +0700, Vadim Yanitskiy wrote: > Neels, do you still have the same problem with running on osmo-gsm-tester > setup? I just got another chance to test, and indeed now osmo-trx runs fine on our gsm-tester main unit! Thanks! (The next problem is to get the modems to see the osmo-bts-trx network, apparently, but that's a different issue.) ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sun May 7 14:21:33 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 7 May 2017 16:21:33 +0200 Subject: Undeliverable: PCU broken: PACCH paging omitted In-Reply-To: <20170506132315.GH2458@my.box> References: <20170505152844.GE2458@my.box> <20170506132315.GH2458@my.box> Message-ID: <20170507142133.GA2299@my.box> On Sat, May 06, 2017 at 03:23:15PM +0200, Neels Hofmeyr wrote: > On Fri, May 05, 2017 at 03:28:48PM +0000, postmaster at Radisyscorp.onmicrosoft.com wrote: > > Your message to Sivasankari.Theerthagiri at radisys.com couldn't be delivered. > > > > Sivasankari.Theerthagiri wasn't found at radisys.com. For the record, I've received four more "undeliverable" reports, meaning that the following seem to be the remaining valid contacts for Radisys: Saurabh.Sharan at radisys.com arvind.sirsikar at radisys.com Let me know if I'm missing any. Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Mon May 8 08:28:21 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 8 May 2017 10:28:21 +0200 Subject: FreeBSD C compiler version In-Reply-To: References: Message-ID: I'd like to share my opinion after recent experience with OpenGGSN. It's very portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code into horrible mess of ifdefs which is hard to follow and update. On 06.05.2017 15:13, Vadim Yanitskiy wrote: > > > I also have an idea: what if we could build our projects with several > compilers (GCC and clang) and with their several versions (the three > latest for example) on Jenkins at the same time? I think, it would be > great to keep our projects as portable as possible. Personally I don't see any benefit in this - if smth compiles on platform X it doesn't mean it really supports it. We can guess that it does but unless someone actually uses it on platform X on a regular basis, it's more of a handwaving: it can fail at runtime, it can fail due to some obscure configuration or file path differences etc. On the downside - it makes code more complex and harder to follow. I think we should only care about portability to platform X iff there's maintainer who cares about platform X. Someone who's willing to contribute his time (or money) into ensuring that Osmocom stack actually works on it (not just compiles). Otherwise all the efforts spent on making various compiler versions happy are simply wasted. -- Max Suraev 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 huanglin.bupt at gmail.com Mon May 8 10:06:51 2017 From: huanglin.bupt at gmail.com (Lin HUANG) Date: Mon, 8 May 2017 18:06:51 +0800 Subject: nano3G Access Points Authorization In-Reply-To: <20170419133933.GF2390@ass40.sysmocom.de> References: <20170419133933.GF2390@ass40.sysmocom.de> Message-ID: Hi Neels, We followed the instructions in the link you mentioned, and ran 'hnbgw', but nano3G didn't build connection to hnbgw. When we used Wireshark to capture all packets over the PC net interface, we didn't see any packet from nano3G. The connection of our side is: nano3G (192.168.31.165) <--LAN--> router <--WLAN--> Win-PC + Vmware-Ubuntu (hnbgw, 192.168.31.147) I attached the screenshots for you. Could you give some suggestion? What's the problem here? Thanks~ Lin 2017-04-19 21:39 GMT+08:00 Neels Hofmeyr : > > On Tue, Apr 18, 2017 at 11:07:11AM +0800, root@?? wrote: > > Hello, > > > > I want to configure the nano3G Access Points through 8089 port ( nano3G > AP?s configuration web page )?but i don't konw the username and password . > what should i do? > > You can configure it using the dmi console, maybe this information will > help you: > http://osmocom.org/projects/cellular-infrastructure/wiki/ > Configuring_the_ipaccess_nano3G > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dmi.png Type: image/png Size: 24270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hnbgw.png Type: image/png Size: 85313 bytes Desc: not available URL: From laforge at gnumonks.org Mon May 8 09:41:48 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 May 2017 11:41:48 +0200 Subject: FreeBSD C compiler version In-Reply-To: References: Message-ID: <20170508094148.pyulakik6oby5ym4@nataraja> Hi Max, On Mon, May 08, 2017 at 10:28:21AM +0200, Max wrote: > I'd like to share my opinion after recent experience with OpenGGSN. It's very > portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code > into horrible mess of ifdefs which is hard to follow and update. Well, it's not as bad as you put it. But maybe I'm just remembering too much 1990ies Unix aplication code, where that was more or less the standard, you had to care about portability about a lot of platfomrms... > > I also have an idea: what if we could build our projects with several > > compilers (GCC and clang) and with their several versions (the three > > latest for example) on Jenkins at the same time? I think, it would be > > great to keep our projects as portable as possible. > > Personally I don't see any benefit in this - if smth compiles on platform X it > doesn't mean it really supports it. We can guess that it does but unless someone > actually uses it on platform X on a regular basis, it's more of a handwaving: it can > fail at runtime, it can fail due to some obscure configuration or file path > differences etc. This is correct. > On the downside - it makes code more complex and harder to follow. I think we should > only care about portability to platform X iff there's maintainer who cares about > platform X. Someone who's willing to contribute his time (or money) into ensuring > that Osmocom stack actually works on it (not just compiles). Otherwise all the > efforts spent on making various compiler versions happy are simply wasted. I agree, but only in as far as it goes beyond FreeBSD. There's quite some point in supporting builds for FreeBSD, as a) a lot of Osmocom infrastructure is running on FreeBSD itself b) FreeBSD has a more reliable SCTP implementation. With AoIP becoming part of the standard setup between OsmoBSC and OsmoMSC (as well as M3UA based Iu on the 3G side), there is quite some value if users can run Osmo* on FreeBSD and not just on Linux. So I agree with you for cases like Darwin, Solaris, etc. - but not for FreeBSD. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From huanglin.bupt at gmail.com Mon May 8 10:48:07 2017 From: huanglin.bupt at gmail.com (Lin HUANG) Date: Mon, 8 May 2017 18:48:07 +0800 Subject: nano3G Access Points Authorization In-Reply-To: References: <20170419133933.GF2390@ass40.sysmocom.de> Message-ID: Hi Neels, We just re-inputted all the commands. Now it is OK! The last two commands are the key point. Sorry for disturb you. Regards Lin 2017-05-08 18:06 GMT+08:00 Lin HUANG : > Hi Neels, > > We followed the instructions in the link you mentioned, and ran 'hnbgw', > but nano3G didn't build connection to hnbgw. When we used Wireshark to > capture all packets over the PC net interface, we didn't see any packet > from nano3G. > > The connection of our side is: > nano3G (192.168.31.165) <--LAN--> router <--WLAN--> Win-PC + Vmware-Ubuntu > (hnbgw, 192.168.31.147) > > I attached the screenshots for you. Could you give some suggestion? What's > the problem here? > > Thanks~ > Lin > > 2017-04-19 21:39 GMT+08:00 Neels Hofmeyr : > >> >> On Tue, Apr 18, 2017 at 11:07:11AM +0800, root@?? wrote: >> > Hello, >> > >> > I want to configure the nano3G Access Points through 8089 port ( >> nano3G AP?s configuration web page )?but i don't konw the username and >> password . what should i do? >> >> You can configure it using the dmi console, maybe this information will >> help you: >> http://osmocom.org/projects/cellular-infrastructure/wiki/Con >> figuring_the_ipaccess_nano3G >> >> ~N >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: success.png Type: image/png Size: 169455 bytes Desc: not available URL: From laforge at gnumonks.org Mon May 8 10:29:04 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 May 2017 12:29:04 +0200 Subject: nano3G Access Points Authorization In-Reply-To: References: <20170419133933.GF2390@ass40.sysmocom.de> Message-ID: <20170508102904.nxrtovo4gs22rqa2@nataraja> Dear Lin, On Mon, May 08, 2017 at 06:06:51PM +0800, Lin HUANG wrote: > We followed the instructions in the link you mentioned, and ran 'hnbgw', > but nano3G didn't build connection to hnbgw. The instructions on that wiki page relate to the 'accelerate 3G5' users, i.e. who have received a nano3G femtocell from us with a known software version and configuration. If you have a nano3G from a different source, there could be several hundred different parameters in the MIB that might be different. In that case, it might make sense to try to get a full dump of the MIB parametrs via DMI from a working device and compare that line by line with your output. > When we used Wireshark to capture all packets over the PC net > interface, we didn't see any packet from nano3G. If you see no packets at all, I suspect something wrong with your physical network / IP connection. You should at the very least see the DHCP connection, followed by NTP traffic to a public NTP server. If you don't first see successful DHCP and NTP handshake, there's no point to look at Iuh. In that case, your problem seems to be a problem with the nano3G itself, and not an issue with the osmocom software. > I attached the screenshots for you. Could you give some suggestion? What's > the problem here? As a general note: Please copy+paste the text from text consoles into your mails rather than attaching screenshots. Thanks -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Mon May 8 12:24:03 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 8 May 2017 14:24:03 +0200 Subject: nano3G Access Points Authorization In-Reply-To: References: <20170419133933.GF2390@ass40.sysmocom.de> Message-ID: <20170508122403.GB9328@my.box> First off, please absolutely refrain from sending images containing text screenshots. It bloats everyone's mailbox, cannot be commented on easily and is not searchable. About your problem: assuming that you got your nano3G from sysmocom, it should work if you follow the instructions on the wiki completely. It seems you have omitted various dmi commands. http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G#Starting-Operation ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pablo at gnumonks.org Mon May 8 17:11:03 2017 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 8 May 2017 19:11:03 +0200 Subject: FreeBSD C compiler version In-Reply-To: References: Message-ID: <20170508171103.GA27461@salvia> On Mon, May 08, 2017 at 10:28:21AM +0200, Max wrote: > I'd like to share my opinion after recent experience with OpenGGSN. It's very > portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code > into horrible mess of ifdefs which is hard to follow and update. Are you refering to lib getopt? Look, there's a note that says: NOTE: getopt is now part of the C library,... Probably you can kill those getopt.c and getopt1.c files and use #include ? From axilirator at gmail.com Mon May 8 21:09:22 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 9 May 2017 04:09:22 +0700 Subject: FreeBSD C compiler version Message-ID: Hi Max and Harald, As I mentioned above, my suggestion is to keep the source code "as portable as possible", which doesn't mean absolutely portable. I don't suggest to add other UNIX platforms (Darwin, Solaris, etc.) to our portability scope, I suggest to perform checks on the same platforms as we currently do, but additionally to have both Clang and GCC on both slaves. Why Clang? - it's default compiler on FreeBSD (recent distributions); - it has its own big community; - it has growing compatibility with GCC, see: en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility Why different versions? - different distributions provide different versions available out of the box, i.e. some (such as FreeBSD) provide the latest version, while some other provide a bit dated versions; - some things may change in newer versions, e.g. from my recent experience: Clang 4.0 has support of the __builtin_cpu_supports built-in, while older versions don't. I see the only disadvantage of this approach - longer total build time. So, if you guys support this idea, I could do all configuration and installation related work. Also, I'll try to contribute some computing power to Jenkins: there are some servers in my university, which power isn't used anyhow, so they mostly idle all the time. > Recently I decided to dig into FreeBSD's world, because one of my > changes in Gerrit does build fine on Debian slave, but doesn't on > FreeBSD. Here I found the problem. Cite from GCC's documentation page x86-Built-in-Functions.html at gcc.gnu.org: > If you specify command-line switches such as -msse, the compiler > could use the extended instruction sets even if the built-ins > are not used explicitly in the program. For this reason, applications > that perform run-time CPU detection must compile separate files for > each supported architecture, using the appropriate flags. In > particular, the file containing the CPU detection code should be > compiled without these options. Adding SIMD flags to a whole project breaks portability between different CPUs, so I added these flags for viterbi_sse.lo only. Now the problem seems solved. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon May 8 22:15:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 9 May 2017 00:15:12 +0200 Subject: catch-22 VTY error Message-ID: <20170508221512.GA2430@my.box> I'd like to share a VTY config error analysis that has a tricky solution: I started osmo-bsc -c osmo-bsc.cfg with, according to openbsc/doc/examples/osmo-bsc: net [...] bts 0 [...] periodic location update 30 trx 0 [...] and get this error: There is no such command. Error occurred during reading below line: trx 0 what? 'net / bts / trx' is no command?? Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on this branch, I've actually moved the 'periodic location update N' command a level up, from net / bts / periodic to net / periodic (background: assuming that OsmoMSC does not have individual BTS info, we moved some settings up to network level; whether this makes sense for osmo-bsc is a different question, it's just what happens to be on the vlr_3G branch now). So there is no net / bts / periodic command. Why do I get an error for net / bts / trx instead? two reasons: 1. 'trx 0' was the line following the 'periodic' command, 2. since 'periodic' exists one level above, the vty code goes to the parent node automatically. About 2: we tend to indent our VTY config files, but in fact the indentation has no effect whatsoever, it is just eye candy (very useful eye candy). The code in question: If a command does not exist, try 'vty_go_parent()' and see if the command exists there. That's what allows us to omit 'exit' in our config files to go to the parent node explicitly: libosmocore/src/vty/command.c: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { HERE -----> vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } In this case the 'periodic...' command does in fact now exist one level above, so the vty_go_parent() is successful and running that command works. But, the vty config parsing then sits above on the 'network' level, is no longer in 'bts 0' and hence refuses to accept the following bts-level command, in this case 'trx 0'. Confusing! So it's not a bug, it's a feature. But it's a feature we might see quite often if we move the 'periodic' command up to network level and users attempt to use their old config files. Same goes for the 'timezone' command, BTW, so we might want to rename commands, or re-consider moving commands one level up in the first place. Maybe we should leave backward compat catchers in place that print a warning. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue May 9 05:06:27 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 May 2017 07:06:27 +0200 Subject: catch-22 VTY error In-Reply-To: <20170508221512.GA2430@my.box> References: <20170508221512.GA2430@my.box> Message-ID: <20170509050627.iwlfjlhtsekzob7e@nataraja> Hi Neels, On Tue, May 09, 2017 at 12:15:12AM +0200, Neels Hofmeyr wrote: > About 2: we tend to indent our VTY config files, but in fact the indentation > has no effect whatsoever, it is just eye candy (very useful eye candy). Maybe we should change that part, rather than renaming commands for no good reason? We could use the indent level to generate 'virtual node exit' commands... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 9 05:03:42 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 May 2017 07:03:42 +0200 Subject: Jenkins testing against more compiler versions (was Re: FreeBSD C compiler version) In-Reply-To: References: Message-ID: <20170509050342.k6waemehnkot7pez@nataraja> Hi Vadim, On Tue, May 09, 2017 at 04:09:22AM +0700, Vadim Yanitskiy wrote: > As I mentioned above, my suggestion is to keep the source code > "as portable as possible", which doesn't mean absolutely portable. > I suggest to perform checks on the same platforms as we currently do, > but additionally to have both Clang and GCC on both slaves. > [...] > > - different distributions provide different versions available > out of the box, i.e. some (such as FreeBSD) provide the latest > version, while some other provide a bit dated versions; > - some things may change in newer versions, e.g. from my recent > experience: Clang 4.0 has support of the __builtin_cpu_supports > built-in, while older versions don't. I'm not quite sure if I follow your argument here. From my point of view, the importance is that we test build on those platforms/compilers that most of our users actually use. So I would rather argue for testing with (the gcc versions of) various recent releases of popular GNU/Linux distributions or on different CPUs such as ARM, than to introduce a compiler version that isn't even included in latest FreeBSD (11). > I see the only disadvantage of this approach - longer total build > time. So, if you guys support this idea, I could do all configuration > and installation related work. Thanks. I guess the question is if people generally agree that it is useful. I'm not entirely convinced that we should do build testing on more compiler versions. Also, as a compromise proposal: we don't necessarily have to do it as part of the testing of each and every commit. It might be sufficient to do this e.g. once as part of a daily/nightly job which sends e-mails to the author of the commit that broke? > Also, I'll try to contribute some computing power to Jenkins: there > are some servers in my university, which power isn't used anyhow, so > they mostly idle all the time. Thanks for your offer. However, I'm not quite sure if we should do something like that without official permission. Paying for another rented server should generally not be a problem: An AMD Ryzen hexa-core 3.6GHz machine with 32GB RAM and SSD is available for 58.31 EUR per month. > Here I found the problem. [...] > > Adding SIMD flags to a whole project breaks portability between > different CPUs, so I added these flags for viterbi_sse.lo only. > Now the problem seems solved. Yes, that's basically the same error as osmo-trx did with using "-march=native": Using optimization flags of the build CPU and assuming that the CPU you later run on will be the exact same CPU type. That's really only useful on systems like Gentoo where everybody builds everything from source on the very system they run the code on. 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 Tue May 9 08:19:48 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 9 May 2017 15:19:48 +0700 Subject: Jenkins testing against more compiler versions (was Re: FreeBSD C compiler version) In-Reply-To: <20170509050342.k6waemehnkot7pez@nataraja> References: <20170509050342.k6waemehnkot7pez@nataraja> Message-ID: Hi Harald, > I'm not quite sure if I follow your argument here. From my point of > view, the importance is that we test build on those platforms/compilers > that most of our users actually use. So I would rather argue for > testing with (the gcc versions of) various recent releases of popular > GNU/Linux distributions or on different CPUs such as ARM, than to > introduce a compiler version that isn't even included in latest FreeBSD > (11). Thanks for response, your point of view makes sense. > Also, as a compromise proposal: we don't necessarily have to do it as > part of the testing of each and every commit. It might be sufficient to > do this e.g. once as part of a daily/nightly job which sends e-mails to > the author of the commit that broke? Great idea! Let's see, what other developers think about that... With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue May 9 10:46:38 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 9 May 2017 12:46:38 +0200 Subject: catch-22 VTY error In-Reply-To: <20170509050627.iwlfjlhtsekzob7e@nataraja> References: <20170508221512.GA2430@my.box> <20170509050627.iwlfjlhtsekzob7e@nataraja> Message-ID: <20170509104638.GB2411@ass40.sysmocom.de> On Tue, May 09, 2017 at 07:06:27AM +0200, Harald Welte wrote: > Hi Neels, > > On Tue, May 09, 2017 at 12:15:12AM +0200, Neels Hofmeyr wrote: > > About 2: we tend to indent our VTY config files, but in fact the indentation > > has no effect whatsoever, it is just eye candy (very useful eye candy). > > Maybe we should change that part, rather than renaming commands for no > good reason? We could use the indent level to generate 'virtual node > exit' commands... And call it "vtython" from python :) I indeed would prefer that from the implicit exiting. Hoping that most users would anyway have properly indented config files... On the telnet vty, we can so far also issue commands that belong to the parent and end up on the parent level implicitly, which we would also stop with this change; I think that'd be a good thing. The code would be slightly non-trivial, simply counting the number of spaces leading each line, and issue an exit for every decrease is not enough: we need to count the number of de-indentings to exit multiple times e.g. at the end of net/bts/trx. I guess we should count tabs as single indents, but make sure that a config file has only tabs or only spaces, not a mixture? count tabs as eight? disallow tabs altogether? Otherwise we could look at how python solves that and maybe copy their code over to C... which would probably be quite complex. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue May 9 12:47:55 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 9 May 2017 14:47:55 +0200 Subject: osmo-trx version question Message-ID: Hi. Is there a way for osmo-bts-trx to get osmo-trx version programmatically (at runtime)? -- Max Suraev 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 alexander.chemeris at gmail.com Tue May 9 14:01:49 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 9 May 2017 17:01:49 +0300 Subject: osmo-trx version question In-Reply-To: References: Message-ID: Not that I'm aware off. Why do you need that? It can be added. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On May 9, 2017 15:48, "Max" wrote: > Hi. > > Is there a way for osmo-bts-trx to get osmo-trx version programmatically > (at runtime)? > > -- > Max Suraev 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Tue May 9 14:04:30 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 9 May 2017 16:04:30 +0200 Subject: osmo-trx version question In-Reply-To: References: Message-ID: <02d87374-f38d-ba34-808d-17c6dcb78540@sysmocom.de> It's not strictly speaking needed, just think it would be nice to add it as part of the data we report via OML: see https://projects.osmocom.org/issues/1614 for details. On 09.05.2017 16:01, Alexander Chemeris wrote: > Not that I'm aware off. Why do you need that? It can be added. > > Please excuse typos. Written with a touchscreen keyboard. > > -- > Regards, > Alexander Chemeris > CTO/Founder Fairwaves, Inc. > https://fairwaves.co > > On May 9, 2017 15:48, "Max" > wrote: > > Hi. > > Is there a way for osmo-bts-trx to get osmo-trx version programmatically (at > runtime)? > -- Max Suraev 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 mychaela.falconia at gmail.com Tue May 9 15:37:50 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Tue, 9 May 2017 07:37:50 -0800 Subject: Creating GSM Users Association (GSMUA) Message-ID: Hello FreeCalypso and Osmocom communities, I am in the process of creating an informal organisation representing the interests of those members of the GSM universe whose interests are not represented by GSMA etc, and I am inviting you to join me in this venture. I propose that we name our informal organisation GSMUA, standing for GSM Users Association, and my vision for this GSMUA is to be a counter-body (antibody?) to the official GSMA. I just registered the gsmua.org domain name, but there is no website or mailing list set up yet. If someone from the Osmocom camp would like to host the server infrastructure for gsmua.org, I will happily point the DNS to you, otherwise the FreeCalypso family can host it on our server. My vision for GSMUA is to represent the interests of GSM end users (empowered end users who wish to fully own and control all aspects of their user equipment while operating on public mobile networks in a fully spec-compliant manner), small boutique manufacturers of GSM devices (both MS/user equipment and network infrastructure), small community network operators and others whose interests are not represented by GSMA etc, especially in cases where our interests are in direct conflict with the interests of big players such as giant device manufacturers, giant commercial network operators and governments. A key goal of GSMUA is to be project-neutral, that is, every person and every small company belonging to any of the categories listed above (empowered end user, small boutique device manufacturer, small community network operator etc) should be fully welcome regardless of which specific project they are associated with. As of today there are at least two different projects offering GSM MS implementations (OsmocomBB and FreeCalypso) and at least two different projects offering network-side GSM implementations (Osmocom and OpenBTS), and I hope that this number of available alternatives will continue to grow: freedom of choice is always a good thing. But at the present time there exists no neutral soil on which members of different projects with a common interest (GSM networks and devices serving the interests of end users rather than big corporations and governments) and a common enemy (just named) can meet, and this lack of neutral meeting ground is the problem which GSMUA is meant to solve. I also have one practical application for GSMUA in mind already: to manage and legitimize recycling of wasted IMEI number ranges. By the official rules of GSMA etc each different *type* of GSM mobile equipment requires a different TAC, i.e., a range of at least 1 million IMEI numbers. So if a small boutique GSM device manufacturer makes a boutique MS device of which no more than 100 units will ever be made, 999900 IMEI numbers have to be wasted by the official rules. While I don't know of any manufacturer who got a range of 1 million IMEIs and only made 100 devices, we do have examples like Openmoko GTA01/02 and Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that about 15 thousand units were made in total; in the case of Pirelli DP-L10 it appears that the total number produced was somewhere under 100 thousand. In each case a full range of 1 million IMEIs was allocated, and at least 900 thousand numbers out of each range are currently unused and wasted. If a small boutique manufacturer wishes to offer a boutique GSM MS product to the general public and wishes to ship each unit with a world-unique IMEI that stands a good chance of being accepted as valid by common GSM networks, and the product in question does not qualify for IMEI allocation by the official rules (e.g., the product is a development board specifically intended for users to run their own firmware and connect to live public networks with it, taking full personal responsibility for their actions) - the situation I found myself in with my GSM MS development board - I feel that the small boutique manuf in question should be empowered to squat on a small subrange of someone else's IMEI range if it is known beyond reasonable doubt to be wasted and unused. However, this recycling of wasted IMEI number ranges could be better organized and given at least some aura of semi-legitimacy if there were a community body set up to manage it, and this is where my proposed GSMUA can come in. Once we get our GSMUA up and running and assign a group of volunteers to be IMEI recycling managers, any small GSM or 3G+ device manufacturer who needs a small range of IMEI numbers will be able to request one from GSMUA, and we will allocate and assign these small subranges out of whatever wasted range we decide to squat on, ensuring that each requestor gets a different subrange. So these are my ideas, and I would like to see them turn into reality. We are going to need a simple website and a community mailing list at gsmua.org, and for the IMEI recycling service we will need a small group of volunteers to serve as its managers - I and Das Signal from FreeCalypso will be happy to serve on that panel, but it would be nice to also have someone from the Osmocom camp for better neutrality. Bright Blessings, Mychaela Falconia, Mother of FreeCalypso From vmarcusv at gmail.com Tue May 9 16:53:48 2017 From: vmarcusv at gmail.com (Marcus Dias) Date: Tue, 9 May 2017 13:53:48 -0300 Subject: Question about multiplexed GSM signal Message-ID: Dear all, Most BTS code I have, generate only one or two 200 kHz channels, but I need to test a receiver using several (multiplexed) 200 kHz channels, composing approximately 5 MHz of total bandwidth. This should be a "valid" multiplex signal (correct and "decodable" control channel). Can anyone pointout where should I start to put together the software to generate a binary file with such signal? I guess I can inspect the code of a BTS that supports two TRX (two 200 kHz channels) but I would like to double check whether there is a more direct approach. Thanks beforehand, Marcus Dias UFPA - Lasse - LaPS -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Tue May 9 18:41:04 2017 From: tom at tsou.cc (Tom Tsou) Date: Tue, 9 May 2017 11:41:04 -0700 Subject: Question about multiplexed GSM signal In-Reply-To: References: Message-ID: Hi Marcus, On Tue, May 9, 2017 at 9:53 AM, Marcus Dias wrote: > Most BTS code I have, generate only one or two 200 kHz channels, but I need > to test a receiver using several (multiplexed) 200 kHz channels, composing > approximately 5 MHz of total bandwidth. This should be a "valid" multiplex > signal (correct and "decodable" control channel). Can anyone pointout where > should I start to put together the software to generate a binary file with > such signal? I guess I can inspect the code of a BTS that supports two TRX > (two 200 kHz channels) but I would like to double check whether there is a > more direct approach. It sounds like you need a raw IQ sampled binary file at about 5 Msps. Is that correct? There are a variety of methods to achieve this depending on your requirements. You could generate the multiplexed signal live with up to 3 adjacent ARFCN channels (800 kHz separation) with a B200 and osmo-trx with multi-ARFCN enabled. But, it sounds like you just need a test file, so you could post-process an existing single ARFCN signal file in Octave or Matlab to carry multiple versions of the same GSM signal. That may or may not be sufficient depending on your needs. -TT From nhofmeyr at sysmocom.de Thu May 11 12:49:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 11 May 2017 14:49:53 +0200 Subject: libosmocore[master]: doc: fix incorrect return value description References: Message-ID: <20170511124953.GC6617@my.box> On Wed, May 10, 2017 at 12:43:42PM +0000, Max wrote: > To view, visit https://gerrit.osmocom.org/2552 > > Patch Set 1: > > > I guess this could use an entry in 'TODO-RELEASE' to note the fixed API? > > Why? TODO-RELEASE is for keeping track of API/ABI changes so we bump corresponding versions when necessary. Docstring change requires neither API not ABI bump. In my view the API doc describes how the API/ABI *should* behave, and if it mismatches that's like a bug in the API. If we fix that bug, that's interesting for users of the API, right? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Thu May 11 12:54:56 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 11 May 2017 14:54:56 +0200 Subject: libosmocore[master]: doc: fix incorrect return value description In-Reply-To: <20170511124953.GC6617@my.box> References: <20170511124953.GC6617@my.box> Message-ID: On 11.05.2017 14:49, Neels Hofmeyr wrote: > On Wed, May 10, 2017 at 12:43:42PM +0000, Max wrote: >> To view, visit https://gerrit.osmocom.org/2552 >> >> Patch Set 1: >> >>> I guess this could use an entry in 'TODO-RELEASE' to note the fixed API? >> Why? TODO-RELEASE is for keeping track of API/ABI changes so we bump corresponding versions when necessary. Docstring change requires neither API not ABI bump. > In my view the API doc describes how the API/ABI *should* behave, and if it > mismatches that's like a bug in the API. If we fix that bug, that's interesting > for users of the API, right? > Except that it's not - wrong documentation for API is bug in the documentation, not API. It might be interesting for API users but this have nothing to do with (no pun intended) TODO-RELEASE file was never targeted for API users. -- Max Suraev 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 nhofmeyr at sysmocom.de Thu May 11 13:03:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 11 May 2017 15:03:53 +0200 Subject: libosmocore[master]: doc: fix incorrect return value description In-Reply-To: References: <20170511124953.GC6617@my.box> Message-ID: <20170511130353.GF6617@my.box> On Thu, May 11, 2017 at 02:54:56PM +0200, Max wrote: > Except that it's not - wrong documentation for API is bug in the documentation, not > API. It might be interesting for API users but this have nothing to do with (no pun > intended) TODO-RELEASE file was never targeted for API users. I still don't see your point. If not the API, what else do I use of libosmocore? If I implement code, I look at the API doc. If that had an error, it's a significant change towards users, no matter what you intend. I'll stop reiterating the same point over and over now. I wish you were less rigid on this. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From vmarcusv at gmail.com Thu May 11 16:58:07 2017 From: vmarcusv at gmail.com (Marcus Dias) Date: Thu, 11 May 2017 13:58:07 -0300 Subject: Question about multiplexed GSM signal In-Reply-To: References: Message-ID: >It sounds like you need a raw IQ sampled binary file at about 5 Msps. >Is that correct? Thanks a lot for your hints! If my math (sampling theorem) is not wrong, because I need a bandwidth of 5 MHz (assuming only downstream transmission, given I will not use upstream), it would require 5 Msps in case each sample is a complex number or 10 Msps in case the samples are real-valued. >There are a variety of methods to achieve this depending on your >requirements. You could generate the multiplexed signal live with up >to 3 adjacent ARFCN channels (800 kHz separation) with a B200 and >osmo-trx with multi-ARFCN enabled. That is a good starting point. But I would need to increase the number of 200 kHz to reach a total of 5 MHz. >But, it sounds like you just need a test file, so you could >post-process an existing single ARFCN signal file in Octave or Matlab >to carry multiple versions of the same GSM signal. That may or may not >be sufficient depending on your needs. Yes, exactly: just a test file. I am still studying the GSM PHY and I suspect if I simply position the ARFCNs in different frequencies I will end up with an invalid GSM signal (that is, it will not be properly decoded by the Keysight VSA equipment that I have to interface to). Marcus Dias UFPA - Lasse - LaPS 2017-05-09 15:41 GMT-03:00 Tom Tsou : > Hi Marcus, > > On Tue, May 9, 2017 at 9:53 AM, Marcus Dias wrote: > > Most BTS code I have, generate only one or two 200 kHz channels, but I > need > > to test a receiver using several (multiplexed) 200 kHz channels, > composing > > approximately 5 MHz of total bandwidth. This should be a "valid" > multiplex > > signal (correct and "decodable" control channel). Can anyone pointout > where > > should I start to put together the software to generate a binary file > with > > such signal? I guess I can inspect the code of a BTS that supports two > TRX > > (two 200 kHz channels) but I would like to double check whether there is > a > > more direct approach. > > It sounds like you need a raw IQ sampled binary file at about 5 Msps. > Is that correct? > > There are a variety of methods to achieve this depending on your > requirements. You could generate the multiplexed signal live with up > to 3 adjacent ARFCN channels (800 kHz separation) with a B200 and > osmo-trx with multi-ARFCN enabled. > > But, it sounds like you just need a test file, so you could > post-process an existing single ARFCN signal file in Octave or Matlab > to carry multiple versions of the same GSM signal. That may or may not > be sufficient depending on your needs. > > -TT > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu May 11 18:26:55 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 11 May 2017 20:26:55 +0200 Subject: Question about multiplexed GSM signal In-Reply-To: References: Message-ID: Hi, > Yes, exactly: just a test file. I am still studying the GSM PHY and I > suspect if I simply position the ARFCNs in different frequencies I > will end up with an invalid GSM signal (that is, it will not be properly > decoded by the Keysight VSA equipment that I have to interface to). It should work fine. A GSM broadcast channel doesn't include its own frequency, so you can just take it and position it anywhere (as long as it's on an actual possible frequency). In gr-osmosdr the siggen application even has a small hardcoded burst sequence that's "good enough" for the E4406 VSA to lock onto. Cheers, Sylvain From ron.menez at entropysolution.com Fri May 12 03:46:28 2017 From: ron.menez at entropysolution.com (Ron) Date: Fri, 12 May 2017 03:46:28 +0000 Subject: osmo-nitb | subscriber-create-on-demand random Message-ID: Hi All, We are trying to used a specific pool of number (extension) for the "subscriber-create-on-demand? configuration in osmo-nitb. Unfortunately, when we used the range from 9570000000 to 9579999999, it returns a different value upon running ?show running-config?. So we tried to change it from the config file of openbsc.conf. After restarting the osmo-nitb application, different value still shows upon running ?show running-config?. But the supported Min and Max value for the "subscriber-create-on-demand random? is from 1-9999999999. Attached is the config file we used and below is the ?show running-config? value of "subscriber-create-on-demand random" value. nitb subscriber-create-on-demand subscriber-create-on-demand random 980065408 990065407 no assign-tmsi Best Regards, Ron Rylan B. Menez -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.conf Type: application/octet-stream Size: 5517 bytes Desc: openbsc.conf URL: From nhofmeyr at sysmocom.de Fri May 12 12:16:02 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 May 2017 14:16:02 +0200 Subject: osmo-nitb | subscriber-create-on-demand random In-Reply-To: References: Message-ID: <20170512121602.GB28041@my.box> I can reproduce the issue. OpenBSC(config-nitb)# subscriber-create-on-demand random 9570000000 9579999999 OpenBSC(config-nitb)# show running-config [...] nitb subscriber-create-on-demand subscriber-create-on-demand random 980065408 990065407 assign-tmsi Created issue https://osmocom.org/issues/2253 and will take a quick look at the code. Thanks for reporting this! ~N On Fri, May 12, 2017 at 03:46:28AM +0000, Ron wrote: > Hi All, > > We are trying to used a specific pool of number (extension) for the "subscriber-create-on-demand? configuration in osmo-nitb. > > Unfortunately, when we used the range from 9570000000 to 9579999999, it returns a different value upon running ?show running-config?. > > So we tried to change it from the config file of openbsc.conf. After restarting the osmo-nitb application, different value still shows upon running ?show running-config?. > > But the supported Min and Max value for the "subscriber-create-on-demand random? is from 1-9999999999. > > Attached is the config file we used and below is the ?show running-config? value of "subscriber-create-on-demand random" value. > > nitb > subscriber-create-on-demand > subscriber-create-on-demand random 980065408 990065407 > no assign-tmsi > > Best Regards, > > Ron Rylan B. Menez > -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From andreas.mueller at criticallabs.org Sat May 13 13:47:23 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Sat, 13 May 2017 15:47:23 +0200 Subject: Filename for HLR sqlite3 Database in 3G network? Message-ID: <20170513134723.GA604@pocken.who.de> Hallo, when setting up a 3G network with the nano3G the default filename of the HLR according to osmo-hlr is hlr.db (source code: hlr.c), but the run.sh script, which is included in https://osmocom.org/attachments/download/2636/3G-config-example-v5.tar tries to access hlr.sqlite3 (7th line: sqlite3 hlr.sqlite3 "delete from sms"). So, when starting an error message occures: "Error: no such table: sms". greetings, Andreas From andreas.mueller at criticallabs.org Sat May 13 18:48:10 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Sat, 13 May 2017 20:48:10 +0200 Subject: Filename for HLR sqlite3 Database in 3G network? In-Reply-To: <20170513134723.GA604@pocken.who.de> References: <20170513134723.GA604@pocken.who.de> Message-ID: <20170513184810.GA22841@pocken.who.de> Hello, sorry - I saw, that sms table is in sms.db, so the line in run.sh to clean the table should maybe be sqlite3 sms.db "delete from sms" greetings, Andreas On Sat, May 13, 2017 at 03:47:23PM +0200, Andreas Mueller wrote: > Hallo, > > when setting up a 3G network with the nano3G the default filename of the HLR according to osmo-hlr is hlr.db (source code: hlr.c), but the run.sh script, which is included in https://osmocom.org/attachments/download/2636/3G-config-example-v5.tar tries to access hlr.sqlite3 (7th line: sqlite3 hlr.sqlite3 "delete from sms"). So, when starting an error message occures: "Error: no such table: sms". > > greetings, > > Andreas > > From nhofmeyr at sysmocom.de Sat May 13 21:28:52 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 13 May 2017 23:28:52 +0200 Subject: Filename for HLR sqlite3 Database in 3G network? In-Reply-To: <20170513184810.GA22841@pocken.who.de> References: <20170513134723.GA604@pocken.who.de> <20170513184810.GA22841@pocken.who.de> Message-ID: <20170513212852.GA14563@my.box> On Sat, May 13, 2017 at 08:48:10PM +0200, Andreas Mueller wrote: > Hello, > > sorry - I saw, that sms table is in sms.db, so the line in run.sh to clean the table should maybe be > sqlite3 sms.db "delete from sms" Ah, thanks for reporting this. The hlr.sqlite3 is the legacy database from OsmoNITB. In OsmoMSC, this db no longer holds subscriber data, but until we fix the implementation, SMS are still stored in it. Thus it was renamed to sms.db. That said, the run script comes from my personal test setup, where I don't want SMS from a previous test run to re-appear in the next one. So I deleted all SMS from the (then) hlr.sqlite3. That would need to happen in sms.db now, but in that run.sh we shouldn't actually remove SMS, who knows what important messages might be in there :) I commented out the SMS deletion, fixed the db filename and uploaded to redmine. Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From m.saman at cerebrosphere.com Tue May 9 07:56:40 2017 From: m.saman at cerebrosphere.com (Mo Saman) Date: Tue, 9 May 2017 12:26:40 +0430 Subject: [osmo-iuh UNKNOWN] testsuite: 1 2 3 failed Message-ID: <01c901d2c899$ce436340$6aca29c0$@cerebrosphere.com> Hi.. Sending logs as instructed by install script make[5]: Leaving directory '/home/saman/osmo-iuh/src/tests' make check-local make[5]: Entering directory '/home/saman/osmo-iuh/src/tests' /bin/bash './testsuite' ## ---------------------------- ## ## osmo-iuh UNKNOWN test suite. ## ## ---------------------------- ## Regression tests. 1: helpers FAILED (testsuite.at:9) 2: hnbap FAILED (testsuite.at:15) 3: ranap FAILED (testsuite.at:21) ## ------------- ## ## Test results. ## ## ------------- ## ERROR: All 3 tests were run, 3 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## Please send `src/tests/testsuite.log' and all information you think might help: To: Subject: [osmo-iuh UNKNOWN] testsuite: 1 2 3 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `src/tests/testsuite.dir'. Makefile:796: recipe for target 'check-local' failed make[5]: *** [check-local] Error 1 make[5]: Leaving directory '/home/saman/osmo-iuh/src/tests' Makefile:650: recipe for target 'check-am' failed make[4]: *** [check-am] Error 2 make[4]: Leaving directory '/home/saman/osmo-iuh/src/tests' Makefile:623: recipe for target 'check-recursive' failed make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory '/home/saman/osmo-iuh/src' Makefile:772: recipe for target 'check' failed make[2]: *** [check] Error 2 make[2]: Leaving directory '/home/saman/osmo-iuh/src' Makefile:439: recipe for target 'check-recursive' failed make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory '/home/saman/osmo-iuh' Makefile:730: recipe for target 'check' failed make: *** [check] Error 2 Mo Saman Chief Platform Architect +1 202 621 0097 m.saman at cerebrosphere.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.dir.tar.gz Type: application/octet-stream Size: 3253 bytes Desc: not available URL: From serg at tvman.us Tue May 9 19:44:43 2017 From: serg at tvman.us (Serg l) Date: Tue, 9 May 2017 15:44:43 -0400 Subject: Creating GSM Users Association (GSMUA) In-Reply-To: References: Message-ID: Hi Mychaela, You brought up a tricky subject and I definitely would be interested to hear some feedback from someone who dealt with various government bodies in different countries. Website hosting is the easy part :) Thanks, -Serg On Tue, May 9, 2017 at 11:37 AM, Mychaela Falconia < mychaela.falconia at gmail.com> wrote: > Hello FreeCalypso and Osmocom communities, > > I am in the process of creating an informal organisation representing > the interests of those members of the GSM universe whose interests are > not represented by GSMA etc, and I am inviting you to join me in this > venture. I propose that we name our informal organisation GSMUA, > standing for GSM Users Association, and my vision for this GSMUA is to > be a counter-body (antibody?) to the official GSMA. I just registered > the gsmua.org domain name, but there is no website or mailing list set > up yet. If someone from the Osmocom camp would like to host the > server infrastructure for gsmua.org, I will happily point the DNS to > you, otherwise the FreeCalypso family can host it on our server. > > My vision for GSMUA is to represent the interests of GSM end users > (empowered end users who wish to fully own and control all aspects of > their user equipment while operating on public mobile networks in a > fully spec-compliant manner), small boutique manufacturers of GSM > devices (both MS/user equipment and network infrastructure), small > community network operators and others whose interests are not > represented by GSMA etc, especially in cases where our interests are > in direct conflict with the interests of big players such as giant > device manufacturers, giant commercial network operators and > governments. > > A key goal of GSMUA is to be project-neutral, that is, every person > and every small company belonging to any of the categories listed > above (empowered end user, small boutique device manufacturer, small > community network operator etc) should be fully welcome regardless of > which specific project they are associated with. As of today there > are at least two different projects offering GSM MS implementations > (OsmocomBB and FreeCalypso) and at least two different projects > offering network-side GSM implementations (Osmocom and OpenBTS), and I > hope that this number of available alternatives will continue to grow: > freedom of choice is always a good thing. But at the present time > there exists no neutral soil on which members of different projects > with a common interest (GSM networks and devices serving the interests > of end users rather than big corporations and governments) and a > common enemy (just named) can meet, and this lack of neutral meeting > ground is the problem which GSMUA is meant to solve. > > I also have one practical application for GSMUA in mind already: to > manage and legitimize recycling of wasted IMEI number ranges. By the > official rules of GSMA etc each different *type* of GSM mobile > equipment requires a different TAC, i.e., a range of at least 1 million > IMEI numbers. So if a small boutique GSM device manufacturer makes a > boutique MS device of which no more than 100 units will ever be made, > 999900 IMEI numbers have to be wasted by the official rules. While I > don't know of any manufacturer who got a range of 1 million IMEIs and > only made 100 devices, we do have examples like Openmoko GTA01/02 and > Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that > about 15 thousand units were made in total; in the case of Pirelli > DP-L10 it appears that the total number produced was somewhere under > 100 thousand. In each case a full range of 1 million IMEIs was > allocated, and at least 900 thousand numbers out of each range are > currently unused and wasted. > > If a small boutique manufacturer wishes to offer a boutique GSM MS > product to the general public and wishes to ship each unit with a > world-unique IMEI that stands a good chance of being accepted as valid > by common GSM networks, and the product in question does not qualify > for IMEI allocation by the official rules (e.g., the product is a > development board specifically intended for users to run their own > firmware and connect to live public networks with it, taking full > personal responsibility for their actions) - the situation I found > myself in with my GSM MS development board - I feel that the small > boutique manuf in question should be empowered to squat on a small > subrange of someone else's IMEI range if it is known beyond reasonable > doubt to be wasted and unused. > > However, this recycling of wasted IMEI number ranges could be better > organized and given at least some aura of semi-legitimacy if there > were a community body set up to manage it, and this is where my > proposed GSMUA can come in. Once we get our GSMUA up and running and > assign a group of volunteers to be IMEI recycling managers, any small > GSM or 3G+ device manufacturer who needs a small range of IMEI numbers > will be able to request one from GSMUA, and we will allocate and > assign these small subranges out of whatever wasted range we decide to > squat on, ensuring that each requestor gets a different subrange. > > So these are my ideas, and I would like to see them turn into reality. > We are going to need a simple website and a community mailing list at > gsmua.org, and for the IMEI recycling service we will need a small > group of volunteers to serve as its managers - I and Das Signal from > FreeCalypso will be happy to serve on that panel, but it would be nice > to also have someone from the Osmocom camp for better neutrality. > > Bright Blessings, > Mychaela Falconia, > Mother of FreeCalypso > _______________________________________________ > Community mailing list > Community at freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun May 14 11:10:55 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 14 May 2017 19:10:55 +0800 Subject: [osmo-iuh UNKNOWN] testsuite: 1 2 3 failed In-Reply-To: <01c901d2c899$ce436340$6aca29c0$@cerebrosphere.com> References: <01c901d2c899$ce436340$6aca29c0$@cerebrosphere.com> Message-ID: > On 9. May 2017, at 15:56, Mo Saman wrote: > > Hi.. > Sending logs as instructed by install script > The GNU autotest scripts will write a testsuite.log and it is a good idea to read it. Which install script did you follow? +/home/saman/osmo-iuh/src/tests/.libs/lt-test-helpers: error while loading shared libraries: libasn1c.so.0: cannot open shared object file: No such file or directory this means that the dynamic linker will not be able to find the libasn1c.so.0 (e.g. not in the linker library path). holger From andreas.mueller at criticallabs.org Sun May 14 12:03:28 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Sun, 14 May 2017 14:03:28 +0200 Subject: Problems with latest 3G software Message-ID: <20170514120328.GA7545@pocken.who.de> Hello, I had success running an 3G network with the nano3G femtocell and osmocom-software a month ago, but I did not follow the changes which happend during the last 4 weeks. With the latest version of the software from git I am not able to register any phone on the network! The test result of 3 different phones: * iPhone: Can see the 3G network, but cannot join * Samsung S5 duos: Not seeing the network, when searching for providers * Acer Liqid M330: Not able to join the network I did not test the iPhone and S5 on the previous version of the network, but the Acer was running perfectly with it. What I did: * checked out the latest source-code and compiled it with the script osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh after completely removing the old source code [I had to change the script to use "sudo make install", because /usr/local/ is not writable for users on my system] => When I checked the created directories I realized, that "/usr/local/include/openbsc " has a trailing space! * I verifyed, that all needed dependencies mentioned in clone_and_build_osmocom_3g.sh are installed (running debian8 32bit) * verifyed that the initial config of the nano3G [according to http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G] is present * I checked my config-files ggsn.conf, osmo-hlr.cfg, osmo-msc.cfg, mgcp.cfg, osmo-hnbgw.cfg, osmo-sgsn.cfg against those provided by osmocom.org/attachments/download/2669/3G-config-example.tar, but they only differ in ip-addresses and ip-networks due to my local network configuration. * I created a new hlr.db with sqlite3 hlr.db < src/osmo-hlr/sql/hlr.sql sqlite3 hlr.db < own_hlr.sql echo "update auc_3g set sqn = 32 where sqn < 32;" | sqlite3 hlr.db with own_hlr.sql containing the IMSIs and auth-data of the used USIM-cards like: INSERT INTO "subscriber" (id, imsi, msisdn) VALUES(1,'901700000014910','1111'); INSERT INTO "auc_3g" VALUES(1,5,'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx','yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy',NULL,32,5); When running the network and trying to join with different smartphones: => in sgsn.log I can see messages like: ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:699 SUBSCR(901700000014913) Received GSUP message OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:455 SUBSCR(901700000014913) Send authentication info has failed with cause 2, handled as: Permission denied ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:463 SUBSCR(901700000014913) GPRS send auth info req failed, access denied, GMM cause = 'IMSI unknown in HLR' (2) ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:813 SUBSCR(901700000014913) Updating subscriber authentication info => when looking at the RANAP-packages captured from eth0 I can see also "GSM A-I/F DTAP - Attach Reject" "GMM Cause: IMSI unknown in HLR" * I checked, that the IMSIs and auth-data is present in hlr.db => I observed that for one subscriber (the Acer Phone, which was connected to the network with a previous version of the software) the sqn number in auc_3g Table is increased, where the value of other subscribers is still 32 (=initial value) => in hnbgw.log I can only see the IMSI of the acer-phone, but not of the two other phones. So it looks like phones who had joined the network before are seen there, but phones which IMSIs are new to the network do not show up there ESC[0;m20170514014439016 DHNBAP <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014913 cause=1 ESC[0;m20170514014439016 DHNBAP <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014913, tmsi 0x0 => in hlr.log I can also only the the IMSI of the Acer phone (keys changed) when 5 vectors are created: ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:132 901700000014913: No 2G Auth Data ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:213 901700000014913: Calling to generate 5 vectors ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only (2G derived from 3G keys) ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:96 3G: k = kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:99 3G: OP = oooooooooooooooooooooooooooooooo ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn was 32 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:113 vector [0]: rand = rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:137 vector [0]: sqn = 64 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:139 vector [0]: autn = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:140 vector [0]: ck = cccccccccccccccccccccccccccccccc ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:141 vector [0]: ik = iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:142 vector [0]: res = 22222222222222222222222222222222 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:143 vector [0]: res_len = 8 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:147 vector [0]: kc = kckckckckckckck ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:148 vector [0]: sres = resrestes ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 .... I am running the network as non-privileged user (only ggsn with sudo), but this user can write hlr.db. Does this user also need to have write-access to files under /usr/local ? As it looks to me that there is a problem with new USIMs, which have never joined the network: Do the USIMs need special preparation for joining the network? (the USIMs are bought from the sysmocom-shop) has anybody have the same problems or can give me a hint, where to look for an error? Thanks! greetings, Andreas From laforge at gnumonks.org Sun May 14 11:15:06 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 14 May 2017 13:15:06 +0200 Subject: Assigning issues to "Osmocom Developers" Message-ID: <20170514111506.gibfbyixibw5ifmx@nataraja> Dear all, I've seen dozens of tickets in recent weeks being assigned to the group "Osmocom Developers". That group is a really large group of redmine users, quite a number of which don't even work on the GSM/cellular protocol part. Assigning issues to that group has the result that they will show up in *every group members* "My issues" / "My page". And as those issues are not relevant to most people, they will increase the noise ration of important information in that default view. So please think twice before you decide to assign an issue to that group. It should only be done if you think the issue actually deserves such a wide audience. If you don't yet know who will handle a ticket, simply have no assignee. Also, we (at least Holger, Sylvain, Neels and I) can easily create more groups for more specific teams, e.g. an "osmo-gsm-tester developers" group or the like. Thanks for your attention. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Sun May 14 13:04:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 14 May 2017 15:04:11 +0200 Subject: osmo-gsm-manuals DRAFT Message-ID: <20170514130411.GA24995@my.box> In our osmo-gsm-manuals, there are various code listings that one would like to copy-paste from the PDF. That would theoretically work, but practically, the 'DRAFT' watermark in the backdrop confuses the text marking, hence making copy-pasting some text from the manuals very very cumbersome. Though I'm not that sure why we need a 'DRAFT' watermark in an open source manual (it's implicitly a draft), I am fine with having such a marking. But I would like the marking to be less obtrusive. We could experiment with putting a bitmap image in the backdrop instead of text, or even better IMHO would be to put it in the page header next to the version. We could also add a generic "DRAFT" disclaimer near the beginning of each document. (Same goes for the sysmocom internal manuals, for which it isn't so easy to get the asciidoc source to paste from.) Any opinions on this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Sun May 14 13:53:02 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 14 May 2017 15:53:02 +0200 Subject: osmo-gsm-manuals DRAFT In-Reply-To: <20170514130411.GA24995@my.box> References: <20170514130411.GA24995@my.box> Message-ID: <20170514135302.sli3bovlczr4k4pq@nataraja> Hi Neels, I do like the "DRAFT" marking as it is not a set of released manuals for a given version of the software. Having said that, if there's a real benefit from disabling draft marking, please simply go for it. If we ever have a set of "stable" documentation for a given version of the software, we can think on how to properly mark that version on the title pages of the manuals at that time. I don't think it's useful use of our time trying to find other methods that enable DRAFT watermarking. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Sun May 14 18:05:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 14 May 2017 20:05:11 +0200 Subject: osmo-gsm-manuals DRAFT In-Reply-To: <20170514135302.sli3bovlczr4k4pq@nataraja> References: <20170514130411.GA24995@my.box> <20170514135302.sli3bovlczr4k4pq@nataraja> Message-ID: <20170514180511.GB24995@my.box> On Sun, May 14, 2017 at 03:53:02PM +0200, Harald Welte wrote: > I do like the "DRAFT" marking as it is not a set of released manuals for > a given version of the software. > > Having said that, if there's a real benefit from disabling draft > marking, please simply go for it. Playing around for some minutes, I found these snippets: (I did this of course before reading that I shouldn't bother with it) Show "DRAFT" in the document header and drop the watermark: ------------------------- diff --git a/build/Makefile.asciidoc.inc b/build/Makefile.asciidoc.inc index fad91fa..82721ff 100644 --- a/build/Makefile.asciidoc.inc +++ b/build/Makefile.asciidoc.inc @@ -16,15 +16,15 @@ ASCIIDOCSTYLE ?= $(BUILDDIR)/custom-dblatex.sty cleanfiles += $(ASCIIDOCPDFS) ASCIIDOC_OPTS := -f $(BUILDDIR)/mscgen-filter.conf -f $(BUILDDIR)/diag-filter.conf -f $(BUILDDIR)/docinfo-releaseinfo.conf -DBLATEX_OPTS := -s $(ASCIIDOCSTYLE) -P draft.mode=yes +DBLATEX_OPTS := -s $(ASCIIDOCSTYLE) -P draft.mode=yes -P draft.watermark=0 ifeq (,$(BUILD_RELEASE)) - DBLATEX_OPTS += -P draft.watermark=1 + REVNUMBER := DRAFT $(GIT_VERSION) else - DBLATEX_OPTS += -P draft.watermark=0 + REVNUMBER := $(GIT_VERSION) endif -A2X_OPTS := -L --asciidoc-opts="$(ASCIIDOC_OPTS)" --dblatex-opts="$(DBLATEX_OPTS)" -a docinfo -a revnumber="$(GIT_VERSION)" -a revdate="$(GIT_DATE)" +A2X_OPTS := -L --asciidoc-opts="$(ASCIIDOC_OPTS)" --dblatex-opts="$(DBLATEX_OPTS)" -a docinfo -a revnumber="$(REVNUMBER)" -a revdate="$(GIT_DATE)" all: $(ASCIIDOCPDFS) ------------------------- I also found a bit of code to put a "DRAFT" on only the first page, but I find it impossibly hard to figure out how to switch this snippet on and off depending on the 'make BUILD_RELEASE=?' option. So if we don't need it to be toggle-able, we can use it as-is. Otherwise, if someone has some dblatex magic or a nifty trick to make these two lines conditional, that would give us the conditional 'DRAFT' watermark on only the first page: ------------------------- diff --git a/build/custom-dblatex.sty b/build/custom-dblatex.sty index 66cf9a1..6d1b49d 100644 --- a/build/custom-dblatex.sty +++ b/build/custom-dblatex.sty @@ -19,6 +19,10 @@ \usepackage{alltt} \usepackage{upquote} +% "DRAFT" on first page +\definecolor{LtGrey}{rgb}{0.8,0.8,0.8} +\AddToShipoutPicture*{ \AtTextCenter{ \makebox(0,0)[c]{\resizebox{\textwidth}{!}{ \rotatebox{45}{\textsf{\textbf{\color{LtGrey}DRAFT}}}}} } } + \def\Company{sysmocom - s.f.m.c. GmbH} \def\DBKcover{ ------------------------- That's enough dblatex for me now, asciidoc is so much easier to understand. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pespin at sysmocom.de Sun May 14 21:47:58 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 14 May 2017 23:47:58 +0200 Subject: Assigning issues to "Osmocom Developers" In-Reply-To: <20170514111506.gibfbyixibw5ifmx@nataraja> References: <20170514111506.gibfbyixibw5ifmx@nataraja> Message-ID: On 14/05/17 13:15, Harald Welte wrote: > Also, we (at least Holger, Sylvain, Neels and I) can easily create more > groups for more specific teams, e.g. an "osmo-gsm-tester developers" > group or the like. Indeed having one group for osmo-gsm-tester would be a good idea. -- - 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 ron.menez at entropysolution.com Mon May 15 05:40:01 2017 From: ron.menez at entropysolution.com (Ron) Date: Mon, 15 May 2017 05:40:01 +0000 Subject: SMS to SIP-Message Support Message-ID: Hi All, We are looking for a way to route all SMS to freeswitch to convert it to SIP-Message. The reason behind this is a better control and additional VAS for SMS transactions. The forum that we had stumble upon is dated four years ago (http://openbsc.osmocom.narkive.com/9hGGHzZP/help-with-asterisk-setup-to-stop-openbsc-registering-handsets) and it seems that it was not yet supported by OSMO-NITB by that time. Not sure if there is already an existing document regarding this case but, can anyone confirm if this is doable and help us on how to do it? We are using the following: OS: Ubuntu 16.10 OSMO Elements: osmo-nitb osmo-sip-connector osmo-bts-trx osmo-trx Ettus SDR Best Regards, Ron Rylan B. Menez -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon May 15 06:40:20 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 May 2017 08:40:20 +0200 Subject: SMS to SIP-Message Support In-Reply-To: References: Message-ID: <20170515064020.2libl5eupywatf5e@nataraja> Hi Ron, OsmoNITB uses SMPP 3.4 as external interface for handling SMS. You can route all SMS via SMPP and thus bypass all internal SMS handling/queueing inside OsmoNITB. You will need external software implementing the SMPP ESME role in order to interface with OsmoNITB. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Mon May 15 09:09:10 2017 From: ron.menez at entropysolution.com (Ron) Date: Mon, 15 May 2017 09:09:10 +0000 Subject: SMS to SIP-Message Support In-Reply-To: <20170515064020.2libl5eupywatf5e@nataraja> References: <20170515064020.2libl5eupywatf5e@nataraja> Message-ID: <26CF79E1-F3FB-4F69-8DE1-4BD619A2BCE1@entropysolution.com> Thanks for the information Harald. We?ll try this as well. BR, Ron Menez ron.menez at entropysolution.com > On May 15, 2017, at 2:40 PM, Harald Welte wrote: > > Hi Ron, > > OsmoNITB uses SMPP 3.4 as external interface for handling SMS. You can > route all SMS via SMPP and thus bypass all internal SMS > handling/queueing inside OsmoNITB. > > You will need external software implementing the SMPP ESME role in order > to interface with OsmoNITB. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Mon May 15 09:35:35 2017 From: ron.menez at entropysolution.com (Ron) Date: Mon, 15 May 2017 09:35:35 +0000 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR Message-ID: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> Hi All, Is there the an equivalent configuration from OpenBTS? Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS to the devices when they attached to an open registration network. What we are trying to do is replicate most of the features from OpenBTS and migrate it to OSMO. Another feature we are looking for is a trigger to an external server for every LUR of devices. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon May 15 10:01:06 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 15 May 2017 18:01:06 +0800 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> Message-ID: <96422F21-B5DF-4D16-B99A-094392F43391@freyther.de> > On 15. May 2017, at 17:35, Ron wrote: > > Hi All, > > Is there the an equivalent configuration from OpenBTS? Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS to the devices when they attached to an open registration network. > > What we are trying to do is replicate most of the features from OpenBTS and migrate it to OSMO. > > Another feature we are looking for is a trigger to an external server for every LUR of devices. One option is SMPP. An ALERT_NOTIFICATION will be sent on attach and detach to all ESMES. Depending on ESME config this can be done by IMSI or MSISDN. If you are quick enough with the SMPP call you might even use the same radio channel. A second option: You could ship your own "HLR" (either based on the C HLR or the OpenCellular python implementation). Then you will be notified for UpdateLocation and can schedule your SMS. holger From laforge at gnumonks.org Mon May 15 11:07:49 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 May 2017 13:07:49 +0200 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> Message-ID: <20170515110749.p65gm7sie3d6wg6h@nataraja> Hi Ron, On Mon, May 15, 2017 at 09:35:35AM +0000, Ron wrote: > Is there the an equivalent configuration from OpenBTS? > Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS > to the devices when they attached to an open registration network. This doesn't exist, sorry. We highly discourate the use of an open network. It's highly insecure and will likely interfere with users of other cellular networks in the vicinity. > Another feature we are looking for is a trigger to an external server > for every LUR of devices. We once again do this on the SMPP interface. The idea is that an external SMSC / ESME can then send any pending SMS based on the location update trigger. You can use that to send your welcome SMS, too. You'd have to keep some kind of history/cache of all IMSIs that you've already seen to prevent re-sending the welcome SMS on every LU. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Mon May 15 11:26:16 2017 From: keith at rhizomatica.org (Keith) Date: Mon, 15 May 2017 13:26:16 +0200 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> Message-ID: On 15/05/2017 11:35, Ron wrote: > > Another feature we are looking for is a trigger to an external server > for every LUR of devices. Hi Ron, You will find a very basic implementation of that here: https://github.com/Rhizomatica/rccn/blob/master/rccn/smpp.py You could even use that same python-smpplib that is used there to generate your "welcome" message, it would be no more than a few lines of python. You'll need this version as it has support for the alert_notification PDU: https://github.com/asdfuser/python-smpplib k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon May 15 16:07:31 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 May 2017 18:07:31 +0200 Subject: Assigning issues to "Osmocom Developers" In-Reply-To: <20170514111506.gibfbyixibw5ifmx@nataraja> References: <20170514111506.gibfbyixibw5ifmx@nataraja> Message-ID: <20170515160731.GA11723@my.box> On Sun, May 14, 2017 at 01:15:06PM +0200, Harald Welte wrote: > So please think twice before you decide to assign an issue to that > group. It should only be done if you think the issue actually deserves > such a wide audience. Ah, so far I had understood your previous remarks (long time ago) that issues should never have an empty assignee so that we won't forget about them; the osmo-gsm-tester group is indeed a good solution. Thanks for adding it. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 15 16:35:28 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 May 2017 18:35:28 +0200 Subject: Problems with latest 3G software In-Reply-To: <20170514120328.GA7545@pocken.who.de> References: <20170514120328.GA7545@pocken.who.de> Message-ID: <20170515163528.GD11723@my.box> Thanks for reporting! I will give the scripts another spin and see if I can reproduce/fix the problems you're seeing. Will respond in detail later... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.huemer at xx.vu Mon May 15 19:39:57 2017 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 15 May 2017 21:39:57 +0200 Subject: Proposal: Usage of stow in jenkins build scripts Message-ID: <20170515193957.GA2859@yade.chaostreff.at> Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-_CFLAGS-and-_LIBS.patch Type: text/x-diff Size: 1589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 15 19:52:05 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 May 2017 21:52:05 +0200 Subject: Problems with latest 3G software In-Reply-To: <20170514120328.GA7545@pocken.who.de> References: <20170514120328.GA7545@pocken.who.de> Message-ID: <20170515195205.GE11723@my.box> On Sun, May 14, 2017 at 02:03:28PM +0200, Andreas Mueller wrote: > Hello, > > I had success running an 3G network with the nano3G femtocell and osmocom-software a month ago, but I did not follow the changes which happend during the last 4 weeks. > With the latest version of the software from git I am not able to register any phone on the network! I just cleared my system of osmocom and ran the script https://osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh and using the 3G-config-example.tar to verify. In summary, all works as expected for me! I found an error in the instructions to add an entry to the hlr.db (we've added another column which was missing in the example and on the wiki). And I've seen the sporadic failure of data service which I reported a while back in https://osmocom.org/issues/1977 . I fixed the doc errors, also tweaked a bit, and this time around enclosed the clone_and_build_osmocom_3g.sh in the 3G-config-example.tar. Uploaded on the wiki. Since all works for me, let me try to see what went wrong for you: > The test result of 3 different phones: > * iPhone: Can see the 3G network, but cannot join > * Samsung S5 duos: Not seeing the network, when searching for providers > * Acer Liqid M330: Not able to join the network I usually use a Samsung S4mini. Note that our nano3G is on US band, some devices may only have EU band. Note that when a phone was once subscribed, the SIM card remembers the name it sends out. Before that, the MCC+MNC codes may be interpreted from an internal list kept in the SIM card. For me, I usually see the network as '90198' (i.e. MCC+MNC), and when first subscribed, that instead becomes 'OsmoMSC' (as from osmo-msc.cfg). > What I did: > * checked out the latest source-code and compiled it with the script osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh after completely removing the old source code > [I had to change the script to use "sudo make install", because /usr/local/ is not writable for users on my system] I added a hint to adjust the prefix in the new version. I usually just do 'sudo chown -R $USER /usr/local' since it's anyway only me writing to that location. Saves the trouble of setting LD_LIBRARY_PATH and PATH env. > => When I checked the created directories I realized, that "/usr/local/include/openbsc " has a trailing space! Not related to 3G, but hey, that's right! What the hell! Fixed in https://gerrit.osmocom.org/2649 (though I'd have expected openbsc to live in osmocom/ ...) > * I verifyed, that all needed dependencies mentioned in clone_and_build_osmocom_3g.sh are installed (running debian8 32bit) I'm running 64bit ... I dearly hope that that is not an issue! > * verifyed that the initial config of the nano3G [according to http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G] is present Yes, I also used that 1:1 now. > * I checked my config-files ggsn.conf, osmo-hlr.cfg, osmo-msc.cfg, mgcp.cfg, osmo-hnbgw.cfg, osmo-sgsn.cfg against those provided by osmocom.org/attachments/download/2669/3G-config-example.tar, but they only differ in ip-addresses and ip-networks due to my local network configuration. The IP addresses in the example are conveniently exactly those that I'm using on my computer. I trust that you understand those, if in doubt attach your configs so I can take a look. > * I created a new hlr.db with > sqlite3 hlr.db < src/osmo-hlr/sql/hlr.sql > sqlite3 hlr.db < own_hlr.sql yes > echo "update auc_3g set sqn = 32 where sqn < 32;" | sqlite3 hlr.db ^ This is no longer needed, but not harmful either. It was actually a missing software feature because I had a far too simplistic understanding of how SQNs work. I just realized that it was still on the wiki page, removed that part now. > with own_hlr.sql containing the IMSIs and auth-data of the used USIM-cards like: > INSERT INTO "subscriber" (id, imsi, msisdn) VALUES(1,'901700000014910','1111'); > INSERT INTO "auc_3g" VALUES(1,5,'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx','yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy',NULL,32,5); (This auc_3g line needed fixing in the example.) Hold on, you're actually entering an OP and not an OPC? Are you sure that's correct? The 'yyy...' is in the OP column. With sysmoUSIM I usually use the OPC column instead, i.e. 'xxx', NULL, 'yyy'. The fixed example uses explicit column names: sqlite> insert into auc_3g (subscriber_id, algo_id_3g, k, opc) values (2342, 5, '0102030405060708090a0b0c0d0e0f00', 'f0e0d0c0b0a090807060504030201000'); > When running the network and trying to join with different smartphones: > > => in sgsn.log I can see messages like: > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:699 SUBSCR(901700000014913) Received GSUP message OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:455 SUBSCR(901700000014913) Send authentication info has failed with cause 2, handled as: Permission denied > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:463 SUBSCR(901700000014913) GPRS send auth info req failed, access denied, GMM cause = 'IMSI unknown in HLR' (2) > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:813 SUBSCR(901700000014913) Updating subscriber authentication info IMSI unknown in HLR is maybe some unrelated phone trying to camp on your network? OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR means that no auth tuples were obtained from the HLR. Also take a look at the osmo-hlr log? > => when looking at the RANAP-packages captured from eth0 I can see also "GSM A-I/F DTAP - Attach Reject" "GMM Cause: IMSI unknown in HLR" > > * I checked, that the IMSIs and auth-data is present in hlr.db > > => I observed that for one subscriber (the Acer Phone, which was connected to the network with a previous version of the software) the sqn number in auc_3g Table is increased, where the value of other subscribers is still 32 (=initial value) Looks like this gets auth tuples generated, but something fails later on. Hard to say from the distance. > => in hnbgw.log I can only see the IMSI of the acer-phone, but not of the two other phones. So it looks like phones who had joined the network before are seen there, but phones which IMSIs are new to the network do not show up there Are you sure you have allowed those IMSIs access to the nano3G on the dmi? that "open access" would allow all. > ESC[0;m20170514014439016 DHNBAP <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014913 cause=1 > ESC[0;m20170514014439016 DHNBAP <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014913, tmsi 0x0 > > => in hlr.log I can also only the the IMSI of the Acer phone (keys changed) when 5 vectors are created: > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:132 901700000014913: No 2G Auth Data > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:213 901700000014913: Calling to generate 5 vectors > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only (2G derived from 3G keys) > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:96 3G: k = kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:99 3G: OP = oooooooooooooooooooooooooooooooo (again, I typically use OPC with sysmoUSIM) > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn was 32 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:113 vector [0]: rand = rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:137 vector [0]: sqn = 64 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:139 vector [0]: autn = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:140 vector [0]: ck = cccccccccccccccccccccccccccccccc > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:141 vector [0]: ik = iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:142 vector [0]: res = 22222222222222222222222222222222 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:143 vector [0]: res_len = 8 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:147 vector [0]: kc = kckckckckckckck > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:148 vector [0]: sres = resrestes > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 > .... > > I am running the network as non-privileged user (only ggsn with sudo), but this user can write hlr.db. That should be fine. > Does this user also need to have write-access to files under /usr/local ? No. > As it looks to me that there is a problem with new USIMs, which have never joined the network: Do the USIMs need special preparation for joining the network? (the USIMs are bought from the sysmocom-shop) Try using OPC instead! Let us know of your progress... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 15 20:18:03 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 May 2017 22:18:03 +0200 Subject: Proposal: Usage of stow in jenkins build scripts In-Reply-To: <20170515193957.GA2859@yade.chaostreff.at> References: <20170515193957.GA2859@yade.chaostreff.at> Message-ID: <20170515201803.GB7018@my.box> The attached patch below indeed looks like errors in our build. Can you please push this as a patch to gerrit? And you are meaning to say: if we used stow in our jenkins builds, we would catch these errors and fail builds if new ones are introduced, right? What role exactly does stow play here -- do I get the same when I install to separate '--prefix'es and then add all those prefixes to the PKG_CONFIG_PATH and LD_LIBRARY_PATH? The jenkins build scripts for each project are included in the contrib/ dir of each git tree, using scripts found in the osmo-ci.git (also on gerrit). Feel free to go ahead and submit patches that use stow, e.g. for the openbsc.git build to begin with. If it improves our build by catching CFLAGS omissions I'll happily merge it. I can also install packages that you need for this on the build slaves. ~N On Mon, May 15, 2017 at 09:39:57PM +0200, Alexander Huemer wrote: > From e9fc0ed9c7b6c1acc70714f703983708f5d8a1ee Mon Sep 17 00:00:00 2001 > From: Alexander Huemer > Date: Mon, 15 May 2017 20:42:47 +0200 > Subject: [PATCH] Add missing _CFLAGS and _LIBS > > These missing pieces go unnoticed if dependencies are not installed in > distinct directories. > > Change-Id: If8d57b72f63d79cc0d8efba7466c6ec177207cbb > --- > openbsc/src/utils/Makefile.am | 3 +++ > openbsc/tests/sndcp_xid/Makefile.am | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am > index 9c3837a36..26494e13d 100644 > --- a/openbsc/src/utils/Makefile.am > +++ b/openbsc/src/utils/Makefile.am > @@ -109,6 +109,7 @@ osmo_meas_pcap2db_LDADD = \ > osmo_meas_pcap2db_CFLAGS = \ > $(LIBOSMOCORE_CFLAGS) \ > $(LIBOSMOGSM_CFLAGS) \ > + $(LIBOSMOABIS_CFLAGS) \ > $(NULL) > > osmo_meas_udp2db_SOURCES = \ > @@ -125,6 +126,7 @@ osmo_meas_udp2db_LDADD = \ > osmo_meas_udp2db_CFLAGS = \ > $(LIBOSMOCORE_CFLAGS) \ > $(LIBOSMOGSM_CFLAGS) \ > + $(LIBOSMOABIS_CFLAGS) \ > $(NULL) > > meas_json_SOURCES = \ > @@ -140,5 +142,6 @@ meas_json_LDADD = \ > meas_json_CFLAGS = \ > $(LIBOSMOCORE_CFLAGS) \ > $(LIBOSMOGSM_CFLAGS) \ > + $(LIBOSMOABIS_CFLAGS) \ > $(NULL) > > diff --git a/openbsc/tests/sndcp_xid/Makefile.am b/openbsc/tests/sndcp_xid/Makefile.am > index 99b9d1a4f..d09c41b28 100644 > --- a/openbsc/tests/sndcp_xid/Makefile.am > +++ b/openbsc/tests/sndcp_xid/Makefile.am > @@ -15,6 +15,7 @@ sndcp_xid_test_LDADD = \ > $(LIBOSMOGB_LIBS) \ > $(LIBCARES_LIBS) \ > $(LIBCRYPTO_LIBS) \ > - -lgtp -lrt -lm > + $(LIBGTP_LIBS) \ > + -lrt -lm > > > -- > 2.11.0 > -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.huemer at xx.vu Mon May 15 20:25:18 2017 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 15 May 2017 22:25:18 +0200 Subject: Proposal: Usage of stow in jenkins build scripts In-Reply-To: <20170515201803.GB7018@my.box> References: <20170515193957.GA2859@yade.chaostreff.at> <20170515201803.GB7018@my.box> Message-ID: <20170515202518.GB2859@yade.chaostreff.at> Hi! On Mon, May 15, 2017 at 10:18:03PM +0200, Neels Hofmeyr wrote: > The attached patch below indeed looks like errors in our build. Can you please > push this as a patch to gerrit? Will do. > And you are meaning to say: if we used stow in our jenkins builds, we would > catch these errors and fail builds if new ones are introduced, right? That is the intention, yes, although stow is a convenience layer, not strictly required. > What role exactly does stow play here -- do I get the same when I install to > separate '--prefix'es and then add all those prefixes to the PKG_CONFIG_PATH > and LD_LIBRARY_PATH? Yes, the effect would be the same. Stow just makes all of that much more convenient and straight-forward, as you end up with just one location where (symlinks to) libs and so forth have to be searched. stow takes care of that. > The jenkins build scripts for each project are included in the contrib/ dir of > each git tree, using scripts found in the osmo-ci.git (also on gerrit). Feel > free to go ahead and submit patches that use stow, e.g. for the openbsc.git > build to begin with. If it improves our build by catching CFLAGS omissions I'll > happily merge it. I can also install packages that you need for this on the > build slaves. I will take a look into that as well. > On Mon, May 15, 2017 at 09:39:57PM +0200, Alexander Huemer wrote: > > From e9fc0ed9c7b6c1acc70714f703983708f5d8a1ee Mon Sep 17 00:00:00 2001 > > From: Alexander Huemer > > Date: Mon, 15 May 2017 20:42:47 +0200 > > Subject: [PATCH] Add missing _CFLAGS and _LIBS > > > > These missing pieces go unnoticed if dependencies are not installed in > > distinct directories. > > > > Change-Id: If8d57b72f63d79cc0d8efba7466c6ec177207cbb > > --- > > openbsc/src/utils/Makefile.am | 3 +++ > > openbsc/tests/sndcp_xid/Makefile.am | 3 ++- > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am > > index 9c3837a36..26494e13d 100644 > > --- a/openbsc/src/utils/Makefile.am > > +++ b/openbsc/src/utils/Makefile.am > > @@ -109,6 +109,7 @@ osmo_meas_pcap2db_LDADD = \ > > osmo_meas_pcap2db_CFLAGS = \ > > $(LIBOSMOCORE_CFLAGS) \ > > $(LIBOSMOGSM_CFLAGS) \ > > + $(LIBOSMOABIS_CFLAGS) \ > > $(NULL) > > > > osmo_meas_udp2db_SOURCES = \ > > @@ -125,6 +126,7 @@ osmo_meas_udp2db_LDADD = \ > > osmo_meas_udp2db_CFLAGS = \ > > $(LIBOSMOCORE_CFLAGS) \ > > $(LIBOSMOGSM_CFLAGS) \ > > + $(LIBOSMOABIS_CFLAGS) \ > > $(NULL) > > > > meas_json_SOURCES = \ > > @@ -140,5 +142,6 @@ meas_json_LDADD = \ > > meas_json_CFLAGS = \ > > $(LIBOSMOCORE_CFLAGS) \ > > $(LIBOSMOGSM_CFLAGS) \ > > + $(LIBOSMOABIS_CFLAGS) \ > > $(NULL) > > > > diff --git a/openbsc/tests/sndcp_xid/Makefile.am b/openbsc/tests/sndcp_xid/Makefile.am > > index 99b9d1a4f..d09c41b28 100644 > > --- a/openbsc/tests/sndcp_xid/Makefile.am > > +++ b/openbsc/tests/sndcp_xid/Makefile.am > > @@ -15,6 +15,7 @@ sndcp_xid_test_LDADD = \ > > $(LIBOSMOGB_LIBS) \ > > $(LIBCARES_LIBS) \ > > $(LIBCRYPTO_LIBS) \ > > - -lgtp -lrt -lm > > + $(LIBGTP_LIBS) \ > > + -lrt -lm > > > > > > -- > > 2.11.0 > > > > > > > -- > - Neels Hofmeyr http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ron.menez at entropysolution.com Tue May 16 01:50:48 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 16 May 2017 01:50:48 +0000 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: <20170515110749.p65gm7sie3d6wg6h@nataraja> References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> <20170515110749.p65gm7sie3d6wg6h@nataraja> Message-ID: Thanks for this info Harald. We?ll try to check the SMPP interface approach. Best Regard, Ron Menez ron.menez at entropysolution.com On May 15, 2017, at 7:07 PM, Harald Welte > wrote: Hi Ron, On Mon, May 15, 2017 at 09:35:35AM +0000, Ron wrote: Is there the an equivalent configuration from OpenBTS? Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS to the devices when they attached to an open registration network. This doesn't exist, sorry. We highly discourate the use of an open network. It's highly insecure and will likely interfere with users of other cellular networks in the vicinity. Another feature we are looking for is a trigger to an external server for every LUR of devices. We once again do this on the SMPP interface. The idea is that an external SMSC / ESME can then send any pending SMS based on the location update trigger. You can use that to send your welcome SMS, too. You'd have to keep some kind of history/cache of all IMSIs that you've already seen to prevent re-sending the welcome SMS on every LU. -- - Harald Welte > http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Tue May 16 01:51:58 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 16 May 2017 01:51:58 +0000 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: <96422F21-B5DF-4D16-B99A-094392F43391@freyther.de> References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> <96422F21-B5DF-4D16-B99A-094392F43391@freyther.de> Message-ID: <3AB2B57A-F0E5-472B-B868-59F266787C18@entropysolution.com> Thanks for the info Holger. We?ll try to explore the second option. Best Regard, Ron Menez ron.menez at entropysolution.com On May 15, 2017, at 6:01 PM, Holger Freyther > wrote: On 15. May 2017, at 17:35, Ron > wrote: Hi All, Is there the an equivalent configuration from OpenBTS? Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS to the devices when they attached to an open registration network. What we are trying to do is replicate most of the features from OpenBTS and migrate it to OSMO. Another feature we are looking for is a trigger to an external server for every LUR of devices. One option is SMPP. An ALERT_NOTIFICATION will be sent on attach and detach to all ESMES. Depending on ESME config this can be done by IMSI or MSISDN. If you are quick enough with the SMPP call you might even use the same radio channel. A second option: You could ship your own "HLR" (either based on the C HLR or the OpenCellular python implementation). Then you will be notified for UpdateLocation and can schedule your SMS. holger -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Tue May 16 01:53:14 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 16 May 2017 01:53:14 +0000 Subject: Welcome Message Upon first Connect / Trigger to External Server for LUR In-Reply-To: References: <307268C0-154F-4AE6-B887-6C5B5EDD37F5@entropysolution.com> Message-ID: <63497D09-808B-4264-A663-CB8374A2BE62@entropysolution.com> Thank you for the info Keith. Best Regard, Ron Menez ron.menez at entropysolution.com On May 15, 2017, at 7:26 PM, Keith > wrote: On 15/05/2017 11:35, Ron wrote: Another feature we are looking for is a trigger to an external server for every LUR of devices. Hi Ron, You will find a very basic implementation of that here: https://github.com/Rhizomatica/rccn/blob/master/rccn/smpp.py You could even use that same python-smpplib that is used there to generate your "welcome" message, it would be no more than a few lines of python. You'll need this version as it has support for the alert_notification PDU: https://github.com/asdfuser/python-smpplib k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue May 16 16:27:08 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 May 2017 18:27:08 +0200 Subject: libosmocore embedded build Message-ID: <20170516162708.fimenn7qgsehu5pp@nataraja> Dear all, when we originally moved a lot of generic code from OpenBSC to libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded' build of libosmocore, which can use [most of] the library code also in deeply embedded, OS-less 'bare metal' microcontroller environments. The ability to build libosmocore this way has been broken for many years, but I've fixed that in recent libosmocore master. Below command works for me [tm]: ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" What we'd need now is: 1) make sure embedded builds continue to work by building libosmocore for embedded as part of the jenkins setup (using gcc-arm-none-eabi debian package). Any volunteers? 2) start to use this embedded build from simtrace2 firmware, osmocom-bb and the upcoming fimrware for the RFDN[1]. So far, * osmocom-bb uses an old clone of libosmocore, * simtrace2 is using some copy+pasted fork of some libosmocore files * rfdn is using some copy+pasted fork of some libosmocore files The above is no longer required. 3) consider if we can shrink the resource requirements of some libosmocore parts. One issue coming up are the static buffers in osmo_hexdump[] or the like. If your total processor RAM is 8k or 16k, then spending 4k on the buffer for hex-dumping is indeed a bit excessive. Any help is appreciated, particularly on the jenkins side. Regards, Harald [1] (1:8 splitter-combiner with adjustible step attenuators, part of the osmo-gsm-tester setup we're building at sysmocom). Code will be released as soon as the hardware is validated. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 16 16:38:29 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 May 2017 18:38:29 +0200 Subject: m3ua and sua testing as part of jenkins? Message-ID: <20170516163829.wigobqkdftgdxe3a@nataraja> Dear all, for some time, I've been wanting to have an easy way to run m3ua-testtool and sua-testtool as part of our regular regression testing setup. After some very disappointing trials using docker (see my blog), I managed to make this work using the 'unshare' program (part of util-linux). The key regquirement basically is: * create a network namespace * configure some netdevice / ip adresses in it * run the software under test (osmo-stp in this case) * run the test suite * tear down everything Initially I tried to do this using 'ip netns', but the problem is that you normally require root permissions to configure the netdevice inside the new namespace. And being root is of course difficult if you think of a jenkins build slave. However, 'unshare' offers the ability to map your real UID to root inside the namespace. At that point, everything can be done as non-root. The resulting scripts are in libosmo-sccp/contrib/test: "run-in-ns.sh" is a simple wrapper around unshare, so you have to call something like ./run-in-ns.sh ./test-m3ua.sh In order to use the m3ua-testtool, you will need to * install guile * clone + build + install https://github.com/nplab/guile-sctp * clone + build m3ua-testtool and sua-testtool from git.osmocom.org, no installation of this require. I would appreciate feedback from others trying to reproduce the above setup on their machine[s]. All tests should be GREEN/PASS. If anyone knowns how to integrate this with jenkins for libosmo-sccp,I think it would be great to have this as part of our testing of gerrit patches. I'm not so sure if it makes sense to try to integrate this with "make check", as it is not a unit test (and it would only work on Linux). I'm planning to use the saee "run-in-ns.sh" approach for my SCCP level tests implemented in TTCN-3/Titan. One further idea is if it make sense to report the test reuslts in a more friendly way. Right now it's deailed osmo-stp logs interspersed with output from the tester. Mayb there's some more information we can feed back into jenkins? Again, I have very little understanding of jenkins. 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 laforge at gnumonks.org Tue May 16 17:05:54 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 May 2017 19:05:54 +0200 Subject: TTCN-3 / Eclipse Titan for SIGTRAN testing Message-ID: <20170516170554.6jrey47l2xnoykj7@nataraja> Hi all, some of you have heard me talk about my first steps in TTCN-3 and Eclipse Titan for testing of libosmo-sccp SIGTRAN code. Ericsson has thankfully agreed to release their M3UA and SCCP code (called "protocol emulation"). I received an advance copy to get started. Now, they have officially released it at: git://git.eclipse.org/gitroot/titan/titan.ProtocolEmulations.SCCP.git git://git.eclipse.org/gitroot/titan/titan.ProtocolEmulations.M3UA.git git://git.eclipse.org/gitroot/titan/titan.TestPorts.MTP3.git Using my earlier version of that code, I was able to craft some test cases for connectionless and connection-oriented SCCP (as shown on OsmoDevCon). I will now need to port that code onto the officially released git repositories above, and after that I'll of course release that on osmocom.org. 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 dr.blobb at gmail.com Wed May 17 09:47:55 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Wed, 17 May 2017 11:47:55 +0200 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: <20170516163829.wigobqkdftgdxe3a@nataraja> References: <20170516163829.wigobqkdftgdxe3a@nataraja> Message-ID: Hi all, I've tried to run the tests on my machine, but didn't succeed and need some help to do so. >> The resulting scripts are in libosmo-sccp/contrib/test: >> "run-in-ns.sh" is a simple wrapper around unshare, >> so you have to call something like >> ./run-in-ns.sh ./test-m3ua.sh I could not find mentioned script in current master branch (872c6b2a8e309ca6739ef295f1fc468c189e4ec9) [1]. >> clone + build m3ua-testtool and sua-testtool from git.osmocom.org, >> no installation of this require. I could not find {m3ua,su}-testtool on git.osmocom.org [2][3], so I cloned them from https://github.com/nplab/. Is this correct? >> One further idea is if it make sense to report the test reuslts in a >> more friendly way. Right now it's deailed osmo-stp logs interspersed >> with output from the tester. Mayb there's some more information we can >> feed back into jenkins? Again, I have very little understanding of >> jenkins. Once I had to visual PowerShell unit tests in Jenkins and back then we converted the output/testlog to a JUnit XML report as these reports are beautiful visualised. Moreover those reports would introduce the third build status "UNSTABLE" in case of a failed test. I will try to create such testlog_2_xml_report script to visualise osmocom testlog and will let you know about my try. Regards, Andr? [1] http://git.osmocom.org/libosmo-sccp/tree/contrib?id=872c6b2a8e309ca6739ef295f1fc468c189e4ec9 [2] http://git.osmocom.org/?q=sua-testtool [3] http://git.osmocom.org/?q=m3ua-testtool From dr.blobb at gmail.com Wed May 17 09:51:02 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Wed, 17 May 2017 11:51:02 +0200 Subject: libosmocore embedded build In-Reply-To: <20170516162708.fimenn7qgsehu5pp@nataraja> References: <20170516162708.fimenn7qgsehu5pp@nataraja> Message-ID: Hi all, >> 1) make sure embedded builds continue to work by building libosmocore >> for embedded as part of the jenkins setup (using gcc-arm-none-eabi >> debian package). Any volunteers? Here, I'd like to do this. Afaics we need some modifications in libosmocore/contrib/jenkins.sh or an additional libosmocore/contrib/jenkins-arm-none-eabi.sh script to build the arm-none-eabi flavor. Any preferences? I have sufficient permission to create a test job on Jenkins. to verify that the build slave (gcc-arm-none-eabi) can build libosmocore with changed ./configure invokation. In case of missing dependencies on the build slave I'd reach out do you. But before starting, I need some clarification about the changed arguments of ./configure invokation, because: >> Below command works for me [tm]: >> ./configure --prefix=/usr/local/arm-none-eabi \ >> --host=arm-none-eabi \ >> --enable-embedded \ >> --disable-shared \ >> CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" does only succeed when adding "--enable-static" to the arguments. Can I simply add "--enable-static" or is my build environment not sane? If not how can I fix it? Regards, Andr? From laforge at gnumonks.org Wed May 17 14:03:05 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 17 May 2017 15:03:05 +0100 Subject: libosmocore embedded build In-Reply-To: References: <20170516162708.fimenn7qgsehu5pp@nataraja> Message-ID: <20170517140305.iaoflv4pczt3o6a4@nataraja> Hi Andre, On Wed, May 17, 2017 at 11:51:02AM +0200, Andr? Boddenberg wrote: > >> 1) make sure embedded builds continue to work by building libosmocore > >> for embedded as part of the jenkins setup (using gcc-arm-none-eabi > >> debian package). Any volunteers? > > Here, I'd like to do this. great! > Afaics we need some modifications in libosmocore/contrib/jenkins.sh or > an additional libosmocore/contrib/jenkins-arm-none-eabi.sh script to > build the arm-none-eabi flavor. Any preferences? I don't know anything about the jenkins setup, so I defer here to the people more familiar with it. > I have sufficient permission to create a test job on Jenkins. to > verify that the build slave (gcc-arm-none-eabi) can > build libosmocore with changed ./configure invokation. In case of > missing dependencies on the build slave I'd reach out do you. sure, thanks. > But before starting, I need some clarification about the changed > arguments of ./configure invokation, because: > > >> Below command works for me [tm]: > >> ./configure --prefix=/usr/local/arm-none-eabi \ > >> --host=arm-none-eabi \ > >> --enable-embedded \ > >> --disable-shared \ > >> CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" > > does only succeed when adding "--enable-static" to the arguments. '--enable-static' will just enable the linking/generation of a static library. It will not disable the dynamic library and do any of the other things. > Can I simply add "--enable-static" or is my build environment not > sane? If not how can I fix it? Ah, I think now I understand. You're saying that the above command quoted from my mail only works if you _also_ add --enable-static? This is interesting, but yes you can simply add it. We could also change the configure.ac to add the --disable-shared and --enable-static automatically when using '--enable-embedded'. We coul dalso do the same for the CFLAGS, as they should be the same for whatever embedded microcontroller one would want to build for. The --host and --prefix should not have any default values, though, and should always be specified by the caller. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed May 17 13:59:02 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 17 May 2017 14:59:02 +0100 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: References: <20170516163829.wigobqkdftgdxe3a@nataraja> Message-ID: <20170517135902.codb6gbkvjndmpif@nataraja> Hi Andre, thanks for looking into this! On Wed, May 17, 2017 at 11:47:55AM +0200, Andr? Boddenberg wrote: > Hi all, > > I've tried to run the tests on my machine, but didn't succeed and need > some help to do so. > > >> The resulting scripts are in libosmo-sccp/contrib/test: > >> "run-in-ns.sh" is a simple wrapper around unshare, > >> so you have to call something like > >> ./run-in-ns.sh ./test-m3ua.sh > > I could not find mentioned script in current master branch > (872c6b2a8e309ca6739ef295f1fc468c189e4ec9) [1]. thanks for pointing this out. I forgot to submit https://gerrit.osmocom.org/#/c/2611/ - which has just been done. > >> no installation of this require. > > I could not find {m3ua,su}-testtool on git.osmocom.org [2][3], they are not yet listed on the index, but you should be able to clone them via git://git.osmocom.org/nplab/m3ua-testtool and git://git.osmocom.org/nplab/sua-testtool already. I just tried, works for me [tm]. > so I cloned them from https://github.com/nplab/. Is this correct? no, this is not correct, sorry. > I will try to create such testlog_2_xml_report script to visualise > osmocom testlog and will let you know about my try. ok. For the m3ua/sua testtool, the 'runm3uatest' program already contains some custom colorized output, you might simply be able to patch that to generate something useful to jenkins? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed May 17 16:06:02 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 17 May 2017 18:06:02 +0200 Subject: libosmocore embedded build In-Reply-To: <20170516162708.fimenn7qgsehu5pp@nataraja> References: <20170516162708.fimenn7qgsehu5pp@nataraja> Message-ID: <20170517160602.GA21386@my.box> On Tue, May 16, 2017 at 06:27:08PM +0200, Harald Welte wrote: > 1) make sure embedded builds continue to work by building libosmocore > for embedded as part of the jenkins setup (using gcc-arm-none-eabi > debian package). Any volunteers? For the jenkins side, it's probably easiest for me to add it, unless Holger jumps in. About the cross-compile, do we have a doc or readme that describes it? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed May 17 16:15:59 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 17 May 2017 18:15:59 +0200 Subject: libosmocore embedded build In-Reply-To: References: <20170516162708.fimenn7qgsehu5pp@nataraja> Message-ID: <20170517161559.GC21386@my.box> On Wed, May 17, 2017 at 11:51:02AM +0200, Andr? Boddenberg wrote: > Hi all, > > >> 1) make sure embedded builds continue to work by building libosmocore > >> for embedded as part of the jenkins setup (using gcc-arm-none-eabi > >> debian package). Any volunteers? > > Here, I'd like to do this. Afaics we need some modifications in oof, I replied before reading the rest of the thread. Andr?, please go ahead, I have enough on my todo list. Let me know of anything that needs to be installed or configured in our jenkins! (BTW, I kind of lost track of the status on our builds re-using previous build artifacts, feel free to bump on that... would be nice to get this into "production") ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed May 17 16:18:40 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 17 May 2017 18:18:40 +0200 Subject: libosmocore embedded build In-Reply-To: <20170517140305.iaoflv4pczt3o6a4@nataraja> References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> Message-ID: <20170517161840.GD21386@my.box> On Wed, May 17, 2017 at 03:03:05PM +0100, Harald Welte wrote: > > Afaics we need some modifications in libosmocore/contrib/jenkins.sh or > > an additional libosmocore/contrib/jenkins-arm-none-eabi.sh script to > > build the arm-none-eabi flavor. Any preferences? Let's have a separate script. We can then decide per-job or per-build-slave which parts we'd like to build. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed May 17 22:16:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 18 May 2017 00:16:12 +0200 Subject: A over IP / osmo-gsm-tester / aoip branch Message-ID: <20170517221612.GB4431@my.box> Since our A-interface efforts are slowly shaping out, I am adding a build of OsmoMSC that is capable of A over IP to our osmo-gsm-tester setup. For that purpose, I created the branch 'aoip' by glorifying my branch that combines pmaier's AoIP branches (for OsmoBSC and for OsmoMSC) to be the one that osmo-gsm-tester will build the AoIP binaries from. This will converge with vlr_3G and ultimately will become the new master branch(es) of our planned new osmo-bsc and osmo-msc git repositories. Overview of current "root level" branches: master: active 2G development vlr_2G: OsmoNITB capable of external HLR and UMTS authentication vlr_3G: OsmoMSC that can do 3G with an hNodeB, but no 2G aoip: OsmoMSC that has 3G disabled but can do 2G over A-interface with a separate OsmoBSC. The reason why 3G is disabled there is the early code state; vlr_3G and aoip will soon become identical. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dr.blobb at gmail.com Thu May 18 09:46:52 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Thu, 18 May 2017 11:46:52 +0200 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: <20170517135902.codb6gbkvjndmpif@nataraja> References: <20170516163829.wigobqkdftgdxe3a@nataraja> <20170517135902.codb6gbkvjndmpif@nataraja> Message-ID: Hi Harald, >> they are not yet listed on the index, but you should be able to clone >> them via git://git.osmocom.org/nplab/m3ua-testtool and >> git://git.osmocom.org/nplab/sua-testtool already. I just tried, works >> for me [tm]. Thanks, works for me too. Now I can see the test output, although tests are failing. Probably "culprit" is line 29 in test-m3ua.sh: Line29 => $STP_DIR/osmo-stp -c $STP_CONFIG & Error=> ./test-m3ua.sh: 29: ./test-m3ua.sh: ../..//stp/osmo-stp: not found Can you please help me to fix this issue? >> ok. For the m3ua/sua testtool, the 'runm3uatest' program already >> contains some custom colorized output, you might simply be able to patch >> that to generate something useful to jenkins? That was my first approach, but I didn't manage to pipe the colorized output to a file. Any ideas? So I (temporarily) changed following line in run-all-sgp-tests.sh: $ (./runm3uatest -d . -t $timeout $testcase > /dev/tty) >& /dev/null to $ ./runm3uatest -d . -t $timeout $testcase Then executing $ ./run-in-ns.sh ./test-m3ua.sh 2>&1 | tee m3ua-test-report.plain gives a very verbose output, which is saved to a "m3ua-test-report.plain" for XML generation after all tests have been run. At this point I got the feeling that a more verbose output could also be more helpful in a Jenkins job than prompting the summary, which is probably more suited for builds run by a developer.(?) What is your general opinion about the verboseness of the Jenkins log and the XML report? Here is how a XML report looks like when we would simply evaluate the "test output summary": This XML snippet represent the current state after my hands on yesterday: Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. FAILED ...... I personally always prefer when Jenkins provides some information about the failure rather than only pointing out that something failed and referring to the console log. Something else, can I may request a failing test or information how to change one to let it fail? :) Without such test case it's hard to test the script, which shall produce the XML report. Regards, Andr? From dr.blobb at gmail.com Thu May 18 10:08:08 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Thu, 18 May 2017 12:08:08 +0200 Subject: libosmocore embedded build In-Reply-To: <20170517161840.GD21386@my.box> References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> <20170517161840.GD21386@my.box> Message-ID: Hi all, a test job for the libosmocore arm-none-eabi build is created [1]. Another multi-configuration axis (arch) has been added and a combination filter has been applied to not run arm builds on FreeBSD. Do we actually want to cross-compile on FreeBSD as well? The arm build does not succeed (yet) [2]. Can someone else may have a quick look at log [2] to point me in the right direction? Afaics build dependencies are available but the compilation itself fails. OT: the debian8_amd64 build [3] publishes XML test results. :) Regards, Andr? [1] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/ [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch=arm-none-eabi,label=linux_amd64_debian8/10/console [3] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch=amd64,label=linux_amd64_debian8/ From dr.blobb at gmail.com Thu May 18 14:12:39 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Thu, 18 May 2017 16:12:39 +0200 Subject: dependency artifacts for faster builds/gerrit-verifications In-Reply-To: References: <20170504155228.GA8279@ass40.sysmocom.de> <20170504223109.GA12415@my.box> <5546e82d-686a-bafe-54ac-f7416bff799e@sysmocom.de> Message-ID: Hi Neels, I'd like to reanimate this thread. The gerrit review is still pending [1]. Once it's through, we can start enabling the "(re)builds using artifacts"-feature for OpenBSC and other build jobs. Regards, Andr? [1] https://gerrit.osmocom.org/#/c/2465/ From dr.blobb at gmail.com Thu May 18 14:44:15 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Thu, 18 May 2017 16:44:15 +0200 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: References: <20170516163829.wigobqkdftgdxe3a@nataraja> <20170517135902.codb6gbkvjndmpif@nataraja> Message-ID: Hi, > Thanks, works for me too. Now I can see the test output, although > tests are failing. Probably "culprit" is line 29 in test-m3ua.sh: > > Line29 => $STP_DIR/osmo-stp -c $STP_CONFIG & > > Error=> ./test-m3ua.sh: 29: ./test-m3ua.sh: ../..//stp/osmo-stp: not found I've fixed this by properly building libosomo-sccp (using ./contrib/jenkins.sh). Please excuse impatience. Regards, Andr? From craig_comstock at yahoo.com Thu May 18 15:42:01 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 18 May 2017 15:42:01 +0000 (UTC) Subject: libosmocore embedded build References: <523878719.609260.1495122121893.ref@mail.yahoo.com> Message-ID: <523878719.609260.1495122121893@mail.yahoo.com> > Can someone else may have a > quick look at log [2] to point me in the > right direction? Afaics build dependencies are > available but the > compilation itself > fails. > [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch=arm-none-eabi,label=linux_amd64_debian8/10/console Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the make of timer_test fails and doesn't log somehow? I"m not sure. craig at z500:~/libosmocore/tests$ vi timer/timer_test. timer_test.c timer_test.ok craig at z500:~/libosmocore/tests$ vi timer/timer_test.c craig at z500:~/libosmocore/tests$ make check-am make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test make[1]: Entering directory '/home/craig/libosmocore/tests' CC timer/timer_test.o In file included from timer/timer_test.c:31:0: ../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory #include ^ compilation terminated. Makefile:1336: recipe for target 'timer/timer_test.o' failed make[1]: *** [timer/timer_test.o] Error 1 make[1]: Leaving directory '/home/craig/libosmocore/tests' Makefile:1529: recipe for target 'check-am' failed make: *** [check-am] Error 2 From laforge at gnumonks.org Thu May 18 10:50:48 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 May 2017 11:50:48 +0100 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: References: <20170516163829.wigobqkdftgdxe3a@nataraja> <20170517135902.codb6gbkvjndmpif@nataraja> Message-ID: <20170518105048.f6i43hqejsvig6wq@nataraja> Hi Andre, On Thu, May 18, 2017 at 11:46:52AM +0200, Andr? Boddenberg wrote: > >> they are not yet listed on the index, but you should be able to clone > >> them via git://git.osmocom.org/nplab/m3ua-testtool and > >> git://git.osmocom.org/nplab/sua-testtool already. I just tried, works > >> for me [tm]. > > Thanks, works for me too. Now I can see the test output, although > tests are failing. Probably "culprit" is line 29 in test-m3ua.sh: > > Line29 => $STP_DIR/osmo-stp -c $STP_CONFIG & > > Error=> ./test-m3ua.sh: 29: ./test-m3ua.sh: ../..//stp/osmo-stp: not found > > Can you please help me to fix this issue? you are not starting the script from within contrib/test, or didn't build osmo-stp as part of libosmo-sccp? > What is your general opinion about the verboseness of the Jenkins log > and the XML report? I think it would be useful to have a summay at first sight (at top of the log?) and then the details at the end or after another click? > I personally always prefer when Jenkins provides some information > about the failure rather than only pointing out that something failed > and referring to the console log. yes, the question is how can we get both the summary and the detailed log. > Something else, can I may request a failing test or information how to > change one to let it fail? :) Just change the configuration in the m3ua-param-testtool.scm i.e. to a different IP address or port number ('tester-addr', 'tester-port'; will make all tests fail) or to a different point code ('tester-pc'; will make some tests fail) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu May 18 10:54:01 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 May 2017 11:54:01 +0100 Subject: libosmocore embedded build In-Reply-To: References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> <20170517161840.GD21386@my.box> Message-ID: <20170518105401.y5qrxx6fytvlkmm7@nataraja> Hi Andre! On Thu, May 18, 2017 at 12:08:08PM +0200, Andr? Boddenberg wrote: > a test job for the libosmocore arm-none-eabi build is created [1]. > Another multi-configuration axis (arch) has been added and a > combination filter has been applied to not run arm builds on FreeBSD. great. > Do we actually want to cross-compile on FreeBSD as well? no. > The arm build does not succeed (yet) [2]. > > Can someone else may have a quick look at log [2] to point me in the > right direction? Afaics build dependencies are available but the > compilation itself fails. The build completes, but 'make check' fails. I think 'make check' does only make sense for host builds, but not for embedded. We cannot execute the test cases anyway, even if we were able to build them. I cannot fix it right now in the autoconf (i.e. do nothing for 'make check'), so feel free to disable 'make check' in the build script as an interim workaround. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu May 18 18:24:30 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 May 2017 19:24:30 +0100 Subject: OsmocomBB compile testing / Re: libosmocore embedded build In-Reply-To: References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> <20170517161840.GD21386@my.box> Message-ID: <20170518182430.g6jtc3ib54hwnhuy@nataraja> Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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 craig_comstock at yahoo.com Thu May 18 18:48:06 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 18 May 2017 18:48:06 +0000 (UTC) Subject: OsmocomBB compile testing / Re: libosmocore embedded build References: <678000730.767348.1495133286217.ref@mail.yahoo.com> Message-ID: <678000730.767348.1495133286217@mail.yahoo.com> I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose). Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development. -Craig -------------------------------------------- On Thu, 5/18/17, Harald Welte wrote: Subject: OsmocomBB compile testing / Re: libosmocore embedded build To: "Andr? Boddenberg" Cc: baseband-devel at lists.osmocom.org, "OpenBSC" , "Vadim Yanitskiy" Date: Thursday, May 18, 2017, 1:24 PM Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB.? They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB.? The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts.? That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master.? However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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 dr.blobb at gmail.com Fri May 19 09:57:45 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Fri, 19 May 2017 11:57:45 +0200 Subject: libosmocore embedded build In-Reply-To: <20170518105401.y5qrxx6fytvlkmm7@nataraja> References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> <20170517161840.GD21386@my.box> <20170518105401.y5qrxx6fytvlkmm7@nataraja> Message-ID: Hi Harald, thanks a lot for your clarification. The "make check" and "make distcheck"[1] have been disabled as an interim workaround. Now, all multi-configuration axes (FreeBSD_amd64, debian8_amd64, arm-none-eabi) are successful. [2] If the build job is "sane" for everyone(?), I'd push the jenkins-arm-none-eabi.sh build script to gerrit for review and apply changes to libosmocore and libosmocore_gerrit job after a successful patch submission. Does everyone agree? Regards, Andr? [1] http://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch=arm-none-eabi,label=linux_amd64_debian8/12/console [2] http://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/ From alexander.huemer at xx.vu Fri May 19 12:09:13 2017 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Fri, 19 May 2017 14:09:13 +0200 Subject: Proposal: Usage of stow in jenkins build scripts In-Reply-To: <20170515202518.GB2859@yade.chaostreff.at> References: <20170515193957.GA2859@yade.chaostreff.at> <20170515201803.GB7018@my.box> <20170515202518.GB2859@yade.chaostreff.at> Message-ID: <20170519120913.GA12444@yade.chaostreff.at> Hi! On Mon, May 15, 2017 at 10:25:18PM +0200, Alexander Huemer wrote: > On Mon, May 15, 2017 at 10:18:03PM +0200, Neels Hofmeyr wrote: > > The attached patch below indeed looks like errors in our build. Can you please > > push this as a patch to gerrit? > > Will do. I just pushed patch set 2 to gerrit. Patch set 1 got Code-Review+2 and Verified+1. Patch set 2 got a broken pipe for --enable-smpp --enable-iu, not sure if that is really caused by the patch. > > And you are meaning to say: if we used stow in our jenkins builds, we would > > catch these errors and fail builds if new ones are introduced, right? > > That is the intention, yes, although stow is a convenience layer, not > strictly required. > > > What role exactly does stow play here -- do I get the same when I install to > > separate '--prefix'es and then add all those prefixes to the PKG_CONFIG_PATH > > and LD_LIBRARY_PATH? > > Yes, the effect would be the same. Stow just makes all of that much more > convenient and straight-forward, as you end up with just one location > where (symlinks to) libs and so forth have to be searched. stow takes > care of that. > > > The jenkins build scripts for each project are included in the contrib/ dir of > > each git tree, using scripts found in the osmo-ci.git (also on gerrit). Feel > > free to go ahead and submit patches that use stow, e.g. for the openbsc.git > > build to begin with. If it improves our build by catching CFLAGS omissions I'll > > happily merge it. I can also install packages that you need for this on the > > build slaves. > > I will take a look into that as well. I created a patch for osmo-ci, but cannot do a $ git push gerrit HEAD:refs/for/master Lack of permissions? For now the patch is attached to this email. On my local machine the following worked then: $ cd ~/src/telco/osmo/openbsc $ MAKE=make PARALLEL_MAKE="-j$(nproc)" \ PATH="$PATH:$HOME/src/telco/osmo/osmo-ci/scripts" ./contrib/jenkins.sh [...] make[1]: Leaving directory '/home/blackbit/src/telco/osmo/openbsc/openbsc/openbsc-0.15.0.770-71124-dirty/_build/sub' if test -d "openbsc-0.15.0.770-71124-dirty"; then find "openbsc-0.15.0.770-71124-dirty" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "openbsc-0.15.0.770-71124-dirty" || { sleep 5 && rm -rf "openbsc-0.15.0.770-71124-dirty"; }; else :; fi ================================================================ openbsc-0.15.0.770-71124-dirty archives ready for distribution: openbsc-0.15.0.770-71124-dirty.tar.gz openbsc-0.15.0.770-71124-dirty.tar.bz2 ================================================================ $ ls deps/install/stow/ libosmo-abis libosmocore libosmo-netif libosmo-sccp libsmpp34 openggsn $ Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-stow-for-dependency-management.patch Type: text/x-diff Size: 777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gerardfly9 at gmail.com Sat May 20 05:28:56 2017 From: gerardfly9 at gmail.com (Gerard Lawrence Pinto) Date: Fri, 19 May 2017 22:28:56 -0700 Subject: Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB Message-ID: Greetings, Congrats on OsmoCon 2017! I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in Osmocom. I would like to contribute some code snippets with your acceptance. To begin with I have committed: I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap * (Has both implementations in Python and C + Tested voice with gsm-fr with gsm audio file - works great). - Some of which can be committed to mncc-python? (In order to support MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB - I'm not sure, the relevance of this contribution to this repo? Reason: 1. Solves some mailing list questions: Some questions on mailing list are pertaining sending voice from PC to phone and receive. 2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented, we can use these snippets and send audio with gsm-efr sample, instead of connecting to LCR (Am I correct?) *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC, ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = 456. So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => l1ctl_rx_traffic_req *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) if num > 4 dropping traffic frame. (114 x 4) The code above indicates if queue has any (114 x 4) bits drop the incoming voice request. So I faced the issue of voice packets getting dropped, but that was just twice/thrice and then it did not give me any trouble (I'm not sure how it got fixed), I could hear *clear* voice gsm-fr on the called party cell phone. *My Question is*: If I happened to send voice packets 33 bytes really fast. There should be some kind of buffer rather than a check (Code) and drop frame? - OR this case can never happen? My apologies, if my understanding is incorrect, I just tried to reverse engg. from code and GSM codec available online! II) osmo-sim-auth with added other SIM related API's (still needs code clean up, SIM response check, code re-usable, README.md etc,) * https://github.com/GerardPinto/osmo-sim-auth * - I did check out PySIM (I think I can add some code to the existing repository, with your permission). Could you please let me know if my osmo-sim-auth repo? If it is correct to combine with PySIM, with the changes done below? Files modified: 1. SIM.py - Added more API's. 2. osmo-sim-auth.py - Options parser. Thanks, Gerard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Sat May 20 10:08:47 2017 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 20 May 2017 12:08:47 +0200 Subject: Proposal: Usage of stow in jenkins build scripts In-Reply-To: <20170519120913.GA12444@yade.chaostreff.at> References: <20170515193957.GA2859@yade.chaostreff.at> <20170515201803.GB7018@my.box> <20170515202518.GB2859@yade.chaostreff.at> <20170519120913.GA12444@yade.chaostreff.at> Message-ID: <20170520100847.GA4327@yade.chaostreff.at> Hi! On Fri, May 19, 2017 at 02:09:13PM +0200, Alexander Huemer wrote: > On Mon, May 15, 2017 at 10:25:18PM +0200, Alexander Huemer wrote: > > On Mon, May 15, 2017 at 10:18:03PM +0200, Neels Hofmeyr wrote: > > > > > > The jenkins build scripts for each project are included in the > > > contrib/ dir of > > > each git tree, using scripts found in the osmo-ci.git (also on gerrit). Feel > > > free to go ahead and submit patches that use stow, e.g. for the openbsc.git > > > build to begin with. If it improves our build by catching CFLAGS omissions I'll > > > happily merge it. I can also install packages that you need for this on the > > > build slaves. > > > > I will take a look into that as well. > > I created a patch for osmo-ci, but cannot do a > $ git push gerrit HEAD:refs/for/master > Lack of permissions? > For now the patch is attached to this email. > On my local machine the following worked then: My bad, there was an error in my git config. I now pushed the patch to gerrit as 2691[1], the change for openbsc is 2652[2]. Kind regards, -Alex [1] https://gerrit.osmocom.org/2691 [2] https://gerrit.osmocom.org/2652 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dr.blobb at gmail.com Tue May 23 17:20:08 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Tue, 23 May 2017 19:20:08 +0200 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: <20170518105048.f6i43hqejsvig6wq@nataraja> References: <20170516163829.wigobqkdftgdxe3a@nataraja> <20170517135902.codb6gbkvjndmpif@nataraja> <20170518105048.f6i43hqejsvig6wq@nataraja> Message-ID: Hi Harald, Thanks for your input on "how to let tests fail"! Before speaking about the publishing of XML reports on Jenkins, I'd like to make a small infrastructure-detour after reading your blog post. Long story short, here's a Dockerfile (attached) capable of running tests on top of a compiled (via ./contrib/jenkins.sh) libosmo-sctp repository. Only one container is used and IPs can be created on loopback interface in fact of using "--add-cap=NET_ADMIN", which imo is a mighty feature - able of pushing docker beyond its proposed use cases. After building the Dockerfile execute following "line" inside compiled libosmo-sctp repo: docker run -it --rm --cap-add=NET_ADMIN \ -v $(pwd):/workdir/libosmo-sctp \ ./test-m3ua.sh 2>&1 | tee result.plain Note: result.plain will be saved in directory where docker run is executed. In other words the pipe wraps docker command - not command executed within docker. Imho this is what we need in order to: "... execute the entire testsuite e.g. during jenkins test without having IP address or port number conflicts. It could even run multiple times in parallel on one buildhost, verifying different patches as part of the continuous integration setup." [1]. Moreover, we could also split up tests and execute them in separate containers inside the same job, allowing us to cut down the verification time of each patch set. Does the container work for you, too? What do you think about such approach in general? Furthermore I wrote a protopy-ish script (attached) able to parse "result.plain" (generated by above stated docker command) and create a valid JUnit XML report, which then can be parsed and visualized by Jenkins. A test job [2] has been created showing how such a "publishing" looks like. One simply clicks on "Latest Test Result" and sees a list of all failures. Each failure can be expanded to see the "Stacktrace:/Backtrace:". Furthermore, the first line of such a "Stacktrace" specifies whether it is a "pure" failure or a timeout. The console log of a jenkins job using mentioned Dockerfile and script (create_xml_report.sh) would first hold the verbose log of the docker command. Then a summary would follow as an result of executing create_xml_report.sh. Thus giving full details as well as a summary inside the console log. (Although the summary would use multiple lines per test case -> less beautiful) In addition I'd like to mention the possibility of saving duration of each test case inside XML report. This could enable performance statistics!? What do you think about such approach of creating and publishing XML reports in general? Please note that create_xml_report.sh still needs a clean up, but at the same time I thought it's already worth sharing my hands-on results. Furthermore, feel free to request more details on specific topics e.g. JUnit XML reports, Jenkins, Docker (tried to keep mail crisp). Best Regards, Andr? [1] http://laforge.gnumonks.org/blog/20170503-docker-overhyped/ [2] https://jenkins.blobb.me/job/check_xml_report/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Dockerfile Type: application/octet-stream Size: 2040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: create_xml_report.sh Type: application/x-sh Size: 1774 bytes Desc: not available URL: From emily.mcmilin at gmail.com Wed May 24 01:48:45 2017 From: emily.mcmilin at gmail.com (emily mcmilin) Date: Tue, 23 May 2017 18:48:45 -0700 Subject: how to use the CTRL interface to set TRAPs. Message-ID: Hi all, I have some uncertainty about how to use the CTRL interface to set TRAPs. In the OsmoBSC user manual (for example), the example provided doesn't specify an option to set for the 'var' I might be particularly interested in monitoring: `$ ./bsc_control.py -d localhost -m` Is this the default to monitor all? Can I go about narrowing this? Also, I don't feel like I quite understand the TRAP portion of "Table 2: Variables available over control interface" in the OsmoBSC user manual: For example, the 'name' column seems to generally indicate the 'var' that one would pass in a GET/SET command, so I'm assuming the 'name' associated with the TRAP-enabled rows has the same significance. But these 'names' have no real meaning to me in terms of my experience with VTY, for example 'notification'. I have tried to look toward the osmo-nitb unit tests for inspiration, as there is fantastic coverage for GET/SET, out haven't seen similar for TRAP. Can someone please point me in the right direction? Thanks, Emily From msuraev at sysmocom.de Wed May 24 08:14:04 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 24 May 2017 10:14:04 +0200 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: References: Message-ID: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> Hi. Comments/answers are inline. On 24.05.2017 03:48, emily mcmilin wrote: > In the OsmoBSC user manual (for example), the example provided doesn't > specify an option to set for the 'var' I might be particularly > interested in monitoring: > `$ ./bsc_control.py -d localhost -m` > > Is this the default to monitor all? Can I go about narrowing this? We don't have pub/sub mechanism - the volume of TRAP messages is rather low so there's been no need for added complexity so far. The receiver just get all possible TRAP messages and takes care of filtering those she's not interested in. > > Also, I don't feel like I quite understand the TRAP portion of "Table > 2: Variables available over control interface" in the OsmoBSC user > manual: Think of it this way: if you want to get certain variable, than you send GET command and receive response back with the variable name and value (see chapter ?13 in OsmoBSC User Manual). If that variable is marked as Trap = Yes in Table 2 chapter ?6, than you can get the same response without issuing explicit GET command - you connect in monitor mode to CTRL interface and receive message with variable name and value when it's changed. > For example, the 'name' column seems to generally indicate the 'var' > that one would pass in a GET/SET command, so I'm assuming the 'name' > associated with the TRAP-enabled rows has the same significance. But > these 'names' have no real meaning to me in terms of my experience > with VTY, for example 'notification'. There's no 1:1 correspondence between CTRL and VTY, both ways: there might be variables available only via vty and variables available only via ctrl. > > I have tried to look toward the osmo-nitb unit tests for inspiration, > as there is fantastic coverage for GET/SET, out haven't seen similar > for TRAP. > > Can someone please point me in the right direction? The easiest way to quickstart would be to compile OsmoBSC ("./configure --enable-osmo-bsc" in OpenBSC repo) and than start it (./openbsc/src/osmo-bsc/osmo-bsc -c ~/.config/osmocom/osmo-bsc.cfg) and start OsmoBTS (./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts.cfg). After that you can play with ctrl interface using GET (./bsc_control.py -d localhost -g bts_connection_status) and TRAP (./bsc_control.py -d localhost -m) messages. That way you don't even have to have functional network - all you've got to do is to make sure that "ip.access unit-id" parameter matches in both BSC and BTS config. The TRAP would be generated when OML connection between BSC and BTS is established/dropped, even in the absence of actual MSC and TRX. -- Max Suraev 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 dr.blobb at gmail.com Wed May 24 12:59:22 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Wed, 24 May 2017 14:59:22 +0200 Subject: OsmocomBB compile testing / Re: libosmocore embedded build In-Reply-To: <20170518182430.g6jtc3ib54hwnhuy@nataraja> References: <20170516162708.fimenn7qgsehu5pp@nataraja> <20170517140305.iaoflv4pczt3o6a4@nataraja> <20170517161840.GD21386@my.box> <20170518182430.g6jtc3ib54hwnhuy@nataraja> Message-ID: Hi Harald, > To resolve this, we should also start to have a jenkins compile testing > job for OsmocomBB. The "host" (PC) part of the code is built against > regular libosmocore, just like e.g. openbsc or osmo-bts. That should be > possible even so far, and it might make sense to start with that. Probably done [1][2], although I disabled following line to let OsmocomBB build succeed: libosmocore/contrib/verify_value_string_arrays_are_terminated.py $(find . -name "*.[hc]") Is it okay to disable this verification? Regards, Andr? [1] https://gerrit.osmocom.org/#/c/2726/ [2] https://jenkins.osmocom.org/jenkins/view/Jenkins-Gerrit/job/osmocomBB-gerrit/ From ron.menez at entropysolution.com Wed May 24 14:33:16 2017 From: ron.menez at entropysolution.com (Ron) Date: Wed, 24 May 2017 14:33:16 +0000 Subject: Half Rate Codec (GSM-HR-08) Message-ID: <4AAF7E90-8ACB-4B14-8C58-9BB312B095AA@entropysolution.com> Hi All, We are having ?INCOMPATIBLE_DESTINATION? error in Freeswitch using the half rate configuration of each timeslots in NITB. Our setup have 1 OSMO-NITB (with OSMO-BTS-TRX, OSMO-TRX, and OSMO-SIP-CONNECTOR) and 2 Freeswitch. One of the Freeswitch is local in the server while the other Freeswitch is at the cloud. Using the Full Rate Configuration of each timeslots, we do not encounter the ?INCOMPATIBLE_DESTINATION? error and we successfully connected 2 phone calls. Upon using the Half Rate Configuration, "INCOMPATIBLE_DESTINATION? error occurs. We played around the codecs of Freeswitch but unfortunately, we were not able to complete the call. It always disconnects the call immediately after the MT answers. Does anyone tried this kind of setup before? What equivalent codec does the ?default-codec tch/h hr? or GSM-HR-08 as seen in Freeswitch? OS: Ubuntu 16.10 OSMO Elements: OSMO-TRX OSMO-BTS-TRX OSMO-NITB OSMO-SIP-CONNECTOR SDR: Ettus B210 Softswitch: Freeswitch (Version 1.6) Attached are the config files used for OSMO Elements. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.conf Type: application/octet-stream Size: 5594 bytes Desc: openbsc.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 1994 bytes Desc: osmo-bts.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-sip-connector.cfg Type: application/octet-stream Size: 1065 bytes Desc: osmo-sip-connector.cfg URL: From laforge at gnumonks.org Wed May 24 15:07:13 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 24 May 2017 17:07:13 +0200 Subject: Half Rate Codec (GSM-HR-08) In-Reply-To: <4AAF7E90-8ACB-4B14-8C58-9BB312B095AA@entropysolution.com> References: <4AAF7E90-8ACB-4B14-8C58-9BB312B095AA@entropysolution.com> Message-ID: <20170524150713.bcl7nzv7fs53mtcn@nataraja> Hi Ron, did you verify that your sowtswitch actually supports encoding/decoding of the GSM HR Codec? You must make sure that all involved parties understand the same codec. https://wiki.freeswitch.org/wiki/Codecs doesn't list anything but full rate and AMR. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Wed May 24 15:34:51 2017 From: ron.menez at entropysolution.com (Ron) Date: Wed, 24 May 2017 15:34:51 +0000 Subject: Half Rate Codec (GSM-HR-08) In-Reply-To: <20170524150713.bcl7nzv7fs53mtcn@nataraja> References: <4AAF7E90-8ACB-4B14-8C58-9BB312B095AA@entropysolution.com> <20170524150713.bcl7nzv7fs53mtcn@nataraja> Message-ID: <85CD71F3-0B46-4652-A262-97177CFD7CFC@entropysolution.com> Thanks for the confirmation Harald. It seems that is the case. Best Regard, Ron Menez ron.menez at entropysolution.com On May 24, 2017, at 11:07 PM, Harald Welte > wrote: Hi Ron, did you verify that your sowtswitch actually supports encoding/decoding of the GSM HR Codec? You must make sure that all involved parties understand the same codec. https://wiki.freeswitch.org/wiki/Codecs doesn't list anything but full rate and AMR. -- - Harald Welte > http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From emily.mcmilin at gmail.com Wed May 24 19:07:00 2017 From: emily.mcmilin at gmail.com (emily mcmilin) Date: Wed, 24 May 2017 12:07:00 -0700 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> Message-ID: Hi Max, Thanks for the quick feedback. Comments inline On Wed, May 24, 2017 at 1:14 AM, Max wrote: > > The easiest way to quickstart would be to compile OsmoBSC ("./configure > --enable-osmo-bsc" in OpenBSC repo) and than start it > (./openbsc/src/osmo-bsc/osmo-bsc -c ~/.config/osmocom/osmo-bsc.cfg) and start OsmoBTS > (./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts.cfg). After that you > can play with ctrl interface using GET (./bsc_control.py -d localhost -g > bts_connection_status) and TRAP (./bsc_control.py -d localhost -m) messages. > (Note that in this case I am using the SysmoBTS HW, hence osmo-bts-trx is not running, and my version of bsc_control.py insists on host/port.) I am able to use GET vars as expected, for example: `$ python ~/openbsc/openbsc/contrib/bsc_control.py -g bts.0.oml-connection-state -d localhost -p 4249 Got message: GET_REPLY 9194480470313757573 bts.0.oml-connection-state connected` However, I am not able to issue the specific GET for "bts_connection_status" that you used in your example: `$ python ~/openbsc/openbsc/contrib/bsc_control.py -g bts_connection_status -d localhost -p 4249 Got message: ERROR 6533531211354498498 Command not found` Are these two .*connection.* commands synonymous in function, or am I missing something? (Note there are other examples of seeming mismatch between the command in the manual and the command that I can run, ie: 'net.btsN.trxM.arfcn' in Table 2 referenced before vs 'bts.0.trx.0.arfcn' in my use case -- note the difference in . pattern -- which I assume to be a non-issue, but would love further clarity on.) However, speaking to TRAP calls specifically, in both cases, I get a non-response from CLI (initially meeting my expectations, but it remains non-responsive despite issuing the GET .*connection.* commands noted above in another terminal, thus my confusion): `$ python ~/openbsc/openbsc/contrib/bsc_control.py -m bts_connection_status -d localhost -p 4249 ^C $ python ~/openbsc/openbsc/contrib/bsc_control.py -m bts.0.oml-connection-state -d localhost -p 4249 ^C ` Thanks, Emily From msuraev at sysmocom.de Fri May 26 16:36:51 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 26 May 2017 18:36:51 +0200 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> Message-ID: <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> Further clarifications are inline. On 24.05.2017 21:07, emily mcmilin wrote: > > (Note that in this case I am using the SysmoBTS HW, hence osmo-bts-trx > is not running, and my version of bsc_control.py insists on > host/port.) Not a problem at all - the TRAP message is generated when BTS (any) connects to or disconnects from BSC. The particular BTS type should not matter. The ports could be looked up in libosmocore's include/osmocom/ctrl/ports.h in addition to corresponding user manuals. In case of OsmoBSC the ctrl port is 4249 (same as NITB) see Table 7 in Appendix A of OsmoBSC user manual. That's also the port used by bsc_control.py by default. Also the port is reported upon startup: ... 20170526183514003 DLCTRL <0025> control_if.c:787 CTRL at 127.0.0.1 4249 ... > > I am able to use GET vars as expected, for example: > `$ python ~/openbsc/openbsc/contrib/bsc_control.py -g > bts.0.oml-connection-state -d localhost -p 4249 > Got message: GET_REPLY 9194480470313757573 > bts.0.oml-connection-state connected` > > However, I am not able to issue the specific GET for > "bts_connection_status" that you used in your example: > `$ python ~/openbsc/openbsc/contrib/bsc_control.py -g > bts_connection_status -d localhost -p 4249 > Got message: ERROR 6533531211354498498 Command not found` That's very odd - I'm unable to reproduce this: ./bsc_control.py -g bts_connection_status -d localhost Got message: GET_REPLY 7587255856797935347 bts_connection_status disconnected Could it be the case that you're running NITB instead of OsmoBSC? Please provide all the commands you're using to start everything (not only python scripts). Also, please make sure that no osmo* is started automatically by .service or .sh scripts. > Are these two .*connection.* commands synonymous in function, or am I > missing something? > > (Note there are other examples of seeming mismatch between the command > in the manual and the command that I can run, ie: > 'net.btsN.trxM.arfcn' in Table 2 referenced before vs > 'bts.0.trx.0.arfcn' in my use case -- note the difference in . pattern > -- which I assume to be a non-issue, but would love further clarity > on.) > > However, speaking to TRAP calls specifically, in both cases, I get a > non-response from CLI (initially meeting my expectations, but it > remains non-responsive despite issuing the GET .*connection.* commands > noted above in another terminal, thus my confusion): > `$ python ~/openbsc/openbsc/contrib/bsc_control.py -m > bts_connection_status -d localhost -p 4249 > ^C > > $ python ~/openbsc/openbsc/contrib/bsc_control.py -m > bts.0.oml-connection-state -d localhost -p 4249 > ^C > ` The trigger for TRAP is not GET request - those are orthogonal. The event which causes the TRAP to be generated is the (dis)connection of BTS from/to BSC. So the test sequence would look as follows: 1. Start OsmoBSC - `$ ./src/osmo-bsc/osmo-bsc -c ~/.config/osmocom/osmo-bsc.cfg` 2. Start bsc_control.py in monitor mode - `$ ./bsc_control.py -d localhost -m` 3. Start OsmoBTS `$ systemctl start sysmobts` 4. Stop OsmoBTS `$ ^c` The last 2 actions should generated TRAPs. Note that: * the config files for BSC and BTS should match (same unit-id etc) * the connection between BTS and BSC have to succeed (see the stderr/logs and wireshark traces for OML [tcp port 3002 or tcp port 3003]) -- Max Suraev 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 msuraev at sysmocom.de Fri May 26 16:40:17 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 26 May 2017 18:40:17 +0200 Subject: Illegal instruction error Message-ID: Hi. It seems like some of the recent changes to libosmocore cased following build failures: [ 216s] +/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 28875 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test See https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmocore/xUbuntu_16.10/x86_64 Could you please have a look as to what's causing it? I'm also puzzled by the build failing on 16.10 only. Versions 16.04 and 17.04 seems to be fine. -- Max Suraev 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 emily.mcmilin at gmail.com Fri May 26 17:13:07 2017 From: emily.mcmilin at gmail.com (emily mcmilin) Date: Fri, 26 May 2017 10:13:07 -0700 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> Message-ID: Hi Max, > Could it be the case that you're running NITB instead of OsmoBSC? Please provide all > the commands you're using to start everything (not only python scripts). Also, please > make sure that no osmo* is started automatically by .service or .sh scripts. I am running osmo-nitb, and it my preference to continue to do so. Will that be a problem? > The trigger for TRAP is not GET request - those are orthogonal. The event which > causes the TRAP to be generated is the (dis)connection of BTS from/to BSC. ... > * the config files for BSC and BTS should match (same unit-id etc) I have confidence that there is proper communication between my BTS and BSC, because when I SET arfcn (as in the example below) and then powerup/down my SysmoBTS, the arfcn does properly update (as verified on a sig analyzer). $ python ~/openbsc/openbsc/contrib/bsc_control.py -s bts.0.trx.0.arfcn 148 -d localhost -p 4249 However, issuing the command to TRAP oml connection state (example below), traps no message when I powerup/down the SysmoBTS: $ python ~/openbsc/openbsc/contrib/bsc_control.py -m bts.0.oml-connection-state -d localhost -p 4249 Would you expect a TRAP command to captured in the immediately above example? Thanks, Emily From msuraev at sysmocom.de Fri May 26 17:36:19 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 26 May 2017 19:36:19 +0200 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> Message-ID: <0c0285c3-f2da-7692-3335-ceadea27cbdc@sysmocom.de> Hi. On 26.05.2017 19:13, emily mcmilin wrote: > I am running osmo-nitb, and it my preference to continue to do so. > Will that be a problem? Not really, but in this case you'll have to use ctrl variables from corresponding user manual. In case of osmo-nitb there's no bts_connection_status. You can use, for example, net.0.bsc.N.notification-rejection-v1 to get TRAP message when phone is rejected. Simply try to connect to your network using sim card which is not allowed and you should receive TRAP with that sim IMSI. > > I have confidence that there is proper communication between my BTS > and BSC, because when I SET arfcn (as in the example below) and then > powerup/down my SysmoBTS, the arfcn does properly update (as verified > on a sig analyzer). > > $ python ~/openbsc/openbsc/contrib/bsc_control.py -s bts.0.trx.0.arfcn > 148 -d localhost -p 4249 > > However, issuing the command to TRAP oml connection state (example > below), traps no message when I powerup/down the SysmoBTS: > > $ python ~/openbsc/openbsc/contrib/bsc_control.py -m > bts.0.oml-connection-state -d localhost -p 4249 > > Would you expect a TRAP command to captured in the immediately above example? No, that won't work because there's simply no trap in osmo-nitb which is generated for BTS (dis)connection. Also, there's no need to specify which variable you're expecting as a TRAP - this'll be ignored and you'll get the TRAP for all variables anyway. You've got to check "Control interface" chapter of user manual for whatever program you're using. I've used OsmoBSC just as a quickstart example, if you're using anything else, than you've got to check for variable names in the manual with "Trap=Yes" (if any) and use them. The variables are program-specific: those which are available in osmo-bsc might be absent in osmo-nitb and vice versa. In case of NITB I suggest to use net.0.bsc.N.notification-rejection-v1 where N is the number you've used in your NITB config for bts entry (use 0 if unsure). Also, let me stress again orthogonality of SET/GET operation to TRAP messages. If there's variable which could GET it doesn't mean there's corresponding TRAP. It works other way around too - if theres a TRAP with given name it does not mean that there's variable with the same name which you could GET. It might be, it might be not - that's why we've got to consult the manual which have separate columns for Access (RW means Read/Write - both SET and GET are possible, RO means ReadOnly - only GET is possible, etc) and Trap. Of course we can add TRAP filtering to bsc_control.py as well as bts_connection_status to osmo-nitb if necessary but I think it's a subject of a separate discussion. -- Max Suraev 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 Fri May 26 20:59:41 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 26 May 2017 22:59:41 +0200 Subject: osmo-trx: Generating frame sync output on GPIO? Message-ID: <20170526205941.3oaulnmva73toz3v@nataraja> Hi all, I was wondering if it is possible to generate a TDMA frame sync output on a GPIO line of a USRP device (and/or any other SDR supported by osmo-trx). This way it would be much easier to do e.g. BER testing by using a pure waveform/pattern generator for the "MS side". Such devices (Like an E4433B) can only generate the uplink bursts with pseudo-random sequence, but they don't have any receiver, so they're not able to receive the downlink from the BTS in order to lock on the TDMA frame and transmit the uplink in sync to that. There are of course specialized devices (CMU-300, ...) or hardware options that add such receivers for synchronization on the signal generators, equipment side, but why go there if there would be an easy way to generate some kind of a frame sync output. I would appreciate to know even if there's a way to introduce such "synchronous GPIO toggles" or the like in the command stream to UHD devices. If that existed, it should be rather simple to insert those whenever a new burst for TS0 is sent. A rather computationally (and bandwidth) expensive other option might be to use the second RF output to generate such a signal, but I was hoping not having to abuse the 2nd channel for that ;) 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 Sat May 27 06:55:24 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 27 May 2017 09:55:24 +0300 Subject: Illegal instruction error In-Reply-To: References: Message-ID: Hey, > Could you please have a look as to what's causing it? Sure. But I need to know more information. As I can see: > #define HAVE_AVX2 > #define HAVE_SSE3 > #define HAVE_SSE4_1 The build machine's compiler supports all SIMD features we use. > #define HAVE___BUILTIN_CPU_SUPPORTS 1 And realtime SIMD detection should work fine too. Could you please provide at least: 1) cat /proc/cpuinfo 2) compiler version Thanks! With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Sat May 27 17:40:25 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 27 May 2017 19:40:25 +0200 Subject: redmine search for issues problem Message-ID: <20170527174025.GB1882@my.box> Just noticed, in redmine, it's best to search without any projects selected, even if they are the parent of some others you intend to search in: - go to osmocom.org - enter 'AoverIP' in the search field (do not select a particular project). - find 5 issues, they are from projects OsmoMSC and OsmoBSC. versus: - select 'Cellular Infrastructure', next to the search field at 'Jump to a Project' - enter 'AoverIP' in the search field. - Find no issues at all. Why? OsmoMSC and OsmoBSC are both subprojects of Cellular Infrastructure. ... good to know. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat May 27 18:43:25 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 27 May 2017 20:43:25 +0200 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> Message-ID: <20170527184325.GD1882@my.box> On Fri, May 26, 2017 at 06:36:51PM +0200, Max wrote: > The ports could be looked up in libosmocore's include/osmocom/ctrl/ports.h in > addition to corresponding user manuals. http://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers and osmo-gsm-manuals, besides two separate headers for vty and ctrl. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From axilirator at gmail.com Sun May 28 08:15:59 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 28 May 2017 15:15:59 +0700 Subject: Illegal instruction error In-Reply-To: References: Message-ID: > Could you please provide at least: I was managed to replicate the problem. gcc version 6.2.0 20161005 Let me some time to figure out. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun May 28 11:45:35 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 28 May 2017 18:45:35 +0700 Subject: Illegal instruction error In-Reply-To: References: Message-ID: Hi Max, Please see: https://gerrit.osmocom.org/#/c/2760/ This change should fix the issue. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun May 28 20:10:15 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 28 May 2017 22:10:15 +0200 Subject: gapk jenkins integration Message-ID: <20170528201015.rrrqfjjoa4whtzcm@nataraja> Dear all, gapk (the GSM Audio Pocket Knife) now has tests that can be executed in order to determine if encoding and decoding from/to most supported formats still work "most" as the file source can only read codecs with fixed block size, so AMR cannot be tested yet. It would be great if somebody[tm] would jump in to add this to jenkins, so new commits can be tested against this. Thanks in advance! The test is not integrated with autotest, I wasn't sure if it makes sense. Probably yes, to unify with other projects? In either case, after a successful 'make', you should be able to do a (cd test && ./test_all_formats.sh) and get some meaningful output as well as a status code (1 = error, 0 = success). Patches for autotest integration or any other step towards CI integration is much appreciated. I'm planning to disable direct git commit and move patch submissions to gerrit soon, too (to get the benefit of pre-merge patch verification). I'll also be working on some usage examples on gapk in the redmine wiki and/or included with the tool. By now you can use it as a RTP sink to transcode an RTP stream and play it back on your sound card via ALSA, which is very useful, particularly in combination with a patch that will enable you to issue a MDCX from the BSC VTY, requesting the BTS to redirect the RTP stream e.g. to that gapk RTP sink. 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 nhofmeyr at sysmocom.de Sun May 28 23:12:29 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 01:12:29 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester Message-ID: <20170528231229.GI1882@my.box> > commit b4999b60d48bcbb5aa575973d068e07ab672e095 > Author: Philipp Maier > Date: Wed Oct 26 15:19:41 2016 +0200 > > pcu_sock: add basic pcu interface support > > Adds a basic version of a pcu socket interface, similar > to the one that can be found in osmo-bts. > > Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2 This commit adds PCU sockets to OsmoNITB, but these are not configurable, which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB processes all write to /tmp/pcu_bts, their paths needs to be configurable. Also they seem to not be cleaned up when the process exits. I now see failures of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears when a different user attempts to start an OsmoNITB, i.e. I had a successful run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU socket file should be cleaned up on exit?? The third point is that I don't understand why the OsmoNITB or the OsmoBSC need PCU sockets. The commit log does not explain that unfortunately. I would like this commit to be reverted until the location is configurable, so that the osmo-gsm-tester can continue to run across several users. (and several NITBs at once, which we're not using yet, but in principle could want to.) I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Mon May 29 07:51:43 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 09:51:43 +0200 Subject: Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB In-Reply-To: References: Message-ID: <20170529075143.4nsf3hmq6dilsbzv@nataraja> Hi Gerard, sorry for the delayed response, sometimes there are simply too many tasks and mails to handle :/ On Fri, May 19, 2017 at 10:28:56PM -0700, Gerard Lawrence Pinto wrote: > Congrats on OsmoCon 2017! thanks! > I have been working with OsmocomBB, osmo-sim-auth, mncc-python > projects in Osmocom. great. The important part is now to make sure those changes don't live somewhere out there but to think how they can be merged mainline! > To begin with I have committed: > I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap > * (Has both > implementations in Python and C + Tested voice with gsm-fr with gsm audio > file - works great). > - Some of which can be committed to mncc-python? (In order to support > MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB > - I'm not sure, the relevance of this contribution to this repo? MNCC should be virtually the same, whether on OsmocomBB or on OsmoNITB (or now OsmoMSC). Let's avoid having different implementations and different repositories. At least regarding the python code, please submit your changes to mncc-python We generally try to avoid fragmentation of code but want to have one implementation of a given functionality within the project. So what's needed is the knowledge of what exactly is missing or needs modification/improvement in mncc-python, not another implementation with unclear status on what are advantages/disadvantages of either of them. So I suggest we move the existing mncc-python repository into gerrit, and then you can submit whatever you think is missing in mncc-python? How does that sound? A general suggestion (independent of Osmocom): Please always put license information in your code. Otherwise it is not clear if anyone is able to use it (and under what terms). > *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() > 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC, > ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = > 456. > So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => > l1ctl_rx_traffic_req > *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) > if num > 4 dropping traffic frame. (114 x 4) > The code above indicates if queue has any (114 x 4) bits drop the incoming > voice request. Well, GSM is a TDMA system and everything has to happen with regard to the TDMA clock as defined by the BTS (clock master). So you cannot send voice frames faster than the TDMA clock is transmitting them. > *My Question is*: If I happened to send voice packets 33 bytes really fast. > There should be some kind of buffer rather than a check (Code) and drop > frame? - OR this case can never happen? The way how to properly solve this (normally) is that Layer1 is sending something like "ready to send (RTS) indications" to Layer2, and Layer2 then knows it has to send another frame. This way, the timing is defined by L1. However, as there is latency between L1 and L2 (serial line, operating system scheduling, ...) there actually needs to be a bit of a buffer or an "advancement" of the RTS indications to compensate for that. L1CTL doesn't have this so far, but it would of course be appreciated if somebody would make it more robust and contribute related patches. Please also keep future osmocom-bb related questions to the baseband-devel list, thanks! > II) osmo-sim-auth with added other SIM related API's (still needs code > clean up, SIM response check, code re-usable, README.md etc,) > * https://github.com/GerardPinto/osmo-sim-auth > * > - I did check out PySIM (I think I can add some code to the existing > repository, with your permission). If you work on existing code, then please properly clone the original repository and then add your patches on top of it. That way one can browse the commit log and clearly look ad individual patches. I'm unable to figure out what you did by looking at your repository, as you appear to have imported an unknown version of osmo-sim-auth without cloning the original repository and keeping history. > Could you please let me know if my osmo-sim-auth repo? If it is correct to > combine with PySIM, with the changes done below? I'm happy to review it once there is a repo based on the original one with change sets to review. We can also move osmo-sim-auth to gerrit so you can submit your patches there. But in order to do that, you would also have to do a proper clone of the original repo and implement your changes as commits on top. 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 laforge at gnumonks.org Mon May 29 08:14:07 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 10:14:07 +0200 Subject: Creating GSM Users Association (GSMUA) In-Reply-To: References: Message-ID: <20170529081407.deqbb2gdycpcf7uf@nataraja> Hi Mychaela, sorry for the late response. I think there is a legitimate need (for decades!) to represent the users at entities like GSMA or (much more importantly) the 3GPP and ETSI. 3GPP (and lesser extent ETSI) is where the relevant specifiations are written. Such an user representation would have a role to * identify where (new) specifications infringe on users rights * make sure the industry at least hears about what's in the best interest of users before they discard all of that and implement whatever they want anyway * Raise public awareness about new proposals for specifications that are particularly problematic from a user point of view, therby assert pressure on the standardizations body before it is too late (spec finalied). The areas that I can think of are mostly related to privacy, data protection, and general "digital rights". However, doing the above is fundamentally a lobbying organization, and requires significant funding, starting from membership fees to the relevant standard bodies, to paying for all the related travel expenses to attend the relevant meetings, and people with lots of time on their hands to read the respective draft standards, etc. I think it would be great to do something here, but I think we as the "super technical, ultra nerdy" people working on Free Software (and harwere) in the telecom sphere are typically not in posession of the right skillset to do so. It's much more about social skills than about technical skills. Regarding your proposal: It seems like a contradiction in terms to me if you establish something called an 'user association' while your interest is (at least partially) to represent "boutique manufacturers" regarding IMEI allocations. That's not really of the interest of a *user*. I think the least concern of a user is how and where a manufacturer gets his IMEI allocated. Yes, I agree there is something that can be done regarding TAC allocation (like IEEE OUI / MAC address allocation or USB vid/pid allocation). But that's not a topic for users. 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 laforge at gnumonks.org Mon May 29 08:24:13 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 10:24:13 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester In-Reply-To: <20170528231229.GI1882@my.box> References: <20170528231229.GI1882@my.box> Message-ID: <20170529082413.wasobczfz637g6xt@nataraja> Hi Neels, On Mon, May 29, 2017 at 01:12:29AM +0200, Neels Hofmeyr wrote: > > commit b4999b60d48bcbb5aa575973d068e07ab672e095 > > Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2 > > This commit adds PCU sockets to OsmoNITB, but these are not configurable, > which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB > processes all write to /tmp/pcu_bts, their paths needs to be configurable. This is a pity, sorry about missing that. I think the BSC-side PCU socket has started at a time where even the OsmoBTS PCU socket was not configurable yet. But the history of course doesn't help here. It's sad that we only see this now - for a patch that has been in gerrit for review since March :/ > Also they seem to not be cleaned up when the process exits. I now see failures > of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears > when a different user attempts to start an OsmoNITB, i.e. I had a successful > run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU > socket file should be cleaned up on exit?? not sure if we do that for mncc and the other sockets. I would try to follow what's done there. In a crash you cannot reliably clean them up anyway, so in general one must live with that. > The third point is that I don't understand why the OsmoNITB or the OsmoBSC need > PCU sockets. The commit log does not explain that unfortunately. In classic GSM networks the PCU was always co-located with the BSC. It's only nanoBTS and OsmoBTS that put the PCU with the BTS (which was more or less required or strongly implied by the fact there's no TDM but an IP link on Abis). So if we want to support GPRS/EGPRS for classic BTSs with proprietary BTSs-side code, we ned to have support for co-locating OsmoPCU with OsmoBSC (or NITB, but that will die soon anyway). To the PCU this is fully transparent, i.e. the PCU should not care whether it attaches to the pcu_sock of a BTS (in the OsmoBTS case) or to that of a BSC. The protocol is the same. > I would like this commit to be reverted until the location is configurable, so > that the osmo-gsm-tester can continue to run across several users. (and several > NITBs at once, which we're not using yet, but in principle could want to.) There are a long series of follow-up commits merged which would all need to be reverted (otherwise there are clashes and fall-out). So I think the more realistic approach is to simply make the socket path configurable, possibly even share some of the setup/cleanup code with mncc_sock? I have plenty of other Osmocom TODOs on my list for this Sunday, but will try to look at it tonight. Cannot make promises, though. > I have a ticket for this in the OsmoGSMTester project, we may need to move it > to a different parent project or create a new ticket: > https://osmocom.org/issues/2293 I think it's an issue with libbsc, so it should go to the OpenBSC project in the libbsc category? 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 laforge at gnumonks.org Mon May 29 12:00:56 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 14:00:56 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester In-Reply-To: <20170529082413.wasobczfz637g6xt@nataraja> References: <20170528231229.GI1882@my.box> <20170529082413.wasobczfz637g6xt@nataraja> Message-ID: <20170529120056.eekhcy642smdj5qu@nataraja> Hi Neels, See https://gerrit.osmocom.org/#/c/2777/ which is merged now. @Phillip + Lynxis: Please note this will affect your configurations with RBS2000. you'll have to explicitly add the related config file line when you update beyond that patch! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon May 29 12:32:16 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 14:32:16 +0200 Subject: m3ua and sua testing as part of jenkins? In-Reply-To: References: <20170516163829.wigobqkdftgdxe3a@nataraja> <20170517135902.codb6gbkvjndmpif@nataraja> <20170518105048.f6i43hqejsvig6wq@nataraja> Message-ID: <20170529123216.w6r5g3tfggjz3fqt@nataraja> Hi Andre, On Tue, May 23, 2017 at 07:20:08PM +0200, Andr? Boddenberg wrote: > Long story short, here's a Dockerfile (attached) capable of running > tests on top of a compiled (via ./contrib/jenkins.sh) libosmo-sctp > repository. Only one container is used and IPs can be created on > loopback interface in fact of using "--add-cap=NET_ADMIN", which imo > is a mighty feature - able of pushing docker beyond its proposed use > cases. > > After building the Dockerfile execute following "line" inside compiled > libosmo-sctp repo: > > docker run -it --rm --cap-add=NET_ADMIN \ > -v $(pwd):/workdir/libosmo-sctp \ > ./test-m3ua.sh 2>&1 | tee result.plain # docker run -it --rm --cap-add=NET_ADMIN -v $(pwd):/workdir/libosmo-sctp 16e576fa31f9 ./test-m3ua.sh 2>&1 | tee result.plain Test m3ua-sgp-aspsm-v-001 /workdir/libosmo-sctp/stp/.libs/osmo-stp: error while loading shared libraries: libosmovty.so.3: cannot open shared object file: No such file or directory I guess there's a ldconfig missing somewhere? How are you actually building the code if there's no libosmovty installed from source in your Dockerfile? BTW: should we add your Docker file to the collection of Dockerfiles in http://git.osmocom.org/docker-playground/ ? > Does the container work for you, too? unfortunately not, see above :/ > What do you think about such approach in general? I'd like to play with it, but first have to get it to work. In general, I don't really care too much *how* the tests are excecuted, just as long as it is based on technology that works well and is present on our buildhosts/jenkins. What was wrong with my simple 'unshare' based script? > A test job [2] has been created showing how such a "publishing" looks > like. One simply clicks on "Latest Test Result" and sees a list of all > failures. looks great! > Each failure can be expanded to see the > "Stacktrace:/Backtrace:". Furthermore, the first line of such a > "Stacktrace" specifies whether it is a "pure" failure or a timeout. interesting > In addition I'd like to mention the possibility of saving duration of > each test case inside XML report. This could enable performance > statistics!? yes, but I don't think it is of much use, as the build hosts might be doing all kinds of other things in parallel? > What do you think about such approach of creating and publishing XML > reports in general? Looks fine to me. Maybe there's even a simple/straightforward way to do that for the gnu autotest based unit tests we have in the various osmocom projects? > Please note that create_xml_report.sh still needs a clean up, but at > the same time I thought it's already worth sharing my hands-on > results. Furthermore, feel free to request more details on specific > topics e.g. JUnit XML reports, Jenkins, Docker (tried to keep mail > crisp). wouldn't it make sense to simply replace the 'runm3uatest' executor and the shell script that repeatedly executes it with something that generates the required XML directly? It could be a python script directly, doing away with the C program that does nothing but executing a guile interpreter ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon May 29 12:42:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 14:42:38 +0200 Subject: OsmocomBB compile testing / Re: libosmocore embedded build In-Reply-To: <678000730.767348.1495133286217@mail.yahoo.com> References: <678000730.767348.1495133286217.ref@mail.yahoo.com> <678000730.767348.1495133286217@mail.yahoo.com> Message-ID: <20170529124238.6aloft3r4qz5wmxo@nataraja> Hi Craig, On Thu, May 18, 2017 at 06:48:06PM +0000, Craig Comstock wrote: > I was thinking about how to setup an automated real device test for > the repo and/or PRs especially. I have devices and cables, just was > thinking about how to automate the re-loading of firmware (via an > interface to the power button I suppose). I think there has been some work by Peter and/or Kevin (Cc) on setting up OsmocomBB phones with a power supply (emulating a battery) and using some serial handshake line (next to the UART) to simulate power button presses in the past. Peter? Kevin? It would be great if you'd be willing to set up such as system, document it and then integate it. I think you don't even need your own base setation. Simple test cases for OsmocomBB could include: * running bcch_scan and check that certain (known strong) cells in the neigbhorhood are found * trying to register to a given network using unknwon/expired IMSI and confirming that the channel is established and a LU REJECT is received With such a test rig we could then automatically test every new libosmocore and osmcoom-bb commit to verify that it still performs basic receive and even basic rx+tx functionality. > Any work ongoing on this front? I don't think there's much happening in OsmocomBB for many years, sadly. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon May 29 13:29:49 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 15:29:49 +0200 Subject: Voice audio testing in osmo-gsm-tester Message-ID: <20170529132949.z57kio2ozhaehtg2@nataraja> Dear all, osmo-gsm-tester is currently capable of setting up an entire network with one or more BTSs, Modems, NITB, etc. and test signaling + SMS. Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel. Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144014v140000p.pdf) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101293v080600p.pdf) before. The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop. So if we can activate that loop-back functionality from the Osmocom stack, we could test if we get back the same voice data that we send in downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS). 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 msuraev at sysmocom.de Mon May 29 16:00:11 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 29 May 2017 18:00:11 +0200 Subject: static builds in jenkins Message-ID: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> Hi. Most (if not all) of Osmocom libraries can be built for static linking. With the addition of https://gerrit.osmocom.org/#/c/2748/ we can leverage this to also build static OpenBSC which comes in handy while testing from time to time. Would be nice to add this option to jenkins as well (for OpenBSC as well as all the libraries). What do you think? -- Max Suraev 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 Mon May 29 16:47:15 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 18:47:15 +0200 Subject: static builds in jenkins In-Reply-To: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> References: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> Message-ID: <20170529164715.6urn2dmzsuvjnwhw@nataraja> Hi Max, I also saw your patch in gerrit, but I was wondering ... why? Where's the use case, except higher build times and larger binaries? Is it worth spending time on this? 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 msuraev at sysmocom.de Mon May 29 17:46:56 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 29 May 2017 19:46:56 +0200 Subject: static builds in jenkins In-Reply-To: <20170529164715.6urn2dmzsuvjnwhw@nataraja> References: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> <20170529164715.6urn2dmzsuvjnwhw@nataraja> Message-ID: <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> Well, in my case I wanted to quickly test on a remote host without build environment (internal ref. - gbproxy issue). It turned out that it doesn't work - way too different hosts (libc, compiler etc). As for general use-case - I'm not sure. Hence, this email to start the discussion. 29.05.2017 18:47, Harald Welte ?????: > I also saw your patch in gerrit, but I was wondering ... why? Where's > the use case, except higher build times and larger binaries? Is it > worth spending time on this? -- Max Suraev 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 Directors: Holger Freyther, Harald Welte From laforge at gnumonks.org Mon May 29 18:14:19 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 May 2017 20:14:19 +0200 Subject: static builds in jenkins In-Reply-To: <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> References: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> <20170529164715.6urn2dmzsuvjnwhw@nataraja> <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> Message-ID: <20170529181419.pl5wkatb5jooplp2@nataraja> On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote: > Well, in my case I wanted to quickly test on a remote host without build environment > (internal ref. - gbproxy issue). It turned out that it doesn't work - way too > different hosts (libc, compiler etc). ah, thanks for the clarification. Now it actually makes more sense. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon May 29 18:36:47 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 29 May 2017 21:36:47 +0300 Subject: static builds in jenkins In-Reply-To: <20170529181419.pl5wkatb5jooplp2@nataraja> References: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> <20170529164715.6urn2dmzsuvjnwhw@nataraja> <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> <20170529181419.pl5wkatb5jooplp2@nataraja> Message-ID: (sorry for top posting, but I remember otherwise you have issues reading HTML quotation) We originally created these patches when developing changes touching both libosmocore and osmo-nitb. So that instead of reinstalling a whole bunch of Debs every time we would want to test something, we could just drop a single binary, test it and switch back to whatever is running there normally. There is a few other use cases when we found this option very handy. Once merged, we would probably use it for deployment as well. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On May 29, 2017 9:15 PM, "Harald Welte" wrote: > On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote: > > Well, in my case I wanted to quickly test on a remote host without build > environment > > (internal ref. - gbproxy issue). It turned out that it doesn't work - > way too > > different hosts (libc, compiler etc). > > ah, thanks for the clarification. Now it actually makes more sense. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Mon May 29 18:47:21 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Mon, 29 May 2017 13:47:21 -0500 Subject: OsmocomBB compile testing / Re: libosmocore embedded build In-Reply-To: <20170529124238.6aloft3r4qz5wmxo@nataraja> References: <678000730.767348.1495133286217.ref@mail.yahoo.com> <678000730.767348.1495133286217@mail.yahoo.com> <20170529124238.6aloft3r4qz5wmxo@nataraja> Message-ID: <84BD1A94-3BAB-4DB0-851F-7FD2877A37C4@yahoo.com> I have two c139s wired up for JTAG and many others I can fiddle with. I'll give it a shot! Craig On May 29, 2017 7:42:38 AM CDT, Harald Welte wrote: >Hi Craig, > >On Thu, May 18, 2017 at 06:48:06PM +0000, Craig Comstock wrote: > >> I was thinking about how to setup an automated real device test for >> the repo and/or PRs especially. I have devices and cables, just was >> thinking about how to automate the re-loading of firmware (via an >> interface to the power button I suppose). > >I think there has been some work by Peter and/or Kevin (Cc) on setting >up OsmocomBB phones with a power supply (emulating a battery) and using >some serial handshake line (next to the UART) to simulate power button >presses in the past. Peter? Kevin? > >It would be great if you'd be willing to set up such as system, >document >it and then integate it. > >I think you don't even need your own base setation. Simple test cases >for OsmocomBB could include: > >* running bcch_scan and check that certain (known strong) cells in the > neigbhorhood are found > >* trying to register to a given network using unknwon/expired IMSI and > confirming that the channel is established and a LU REJECT is received > >With such a test rig we could then automatically test every new >libosmocore and osmcoom-bb commit to verify that it still performs >basic >receive and even basic rx+tx functionality. > >> Any work ongoing on this front? > >I don't think there's much happening in OsmocomBB for many years, >sadly. > >-- >- Harald Welte >http://laforge.gnumonks.org/ >============================================================================ >"Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon May 29 19:26:07 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 21:26:07 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester In-Reply-To: <20170529082413.wasobczfz637g6xt@nataraja> References: <20170528231229.GI1882@my.box> <20170529082413.wasobczfz637g6xt@nataraja> Message-ID: <20170529192607.GC1863@my.box> On Mon, May 29, 2017 at 10:24:13AM +0200, Harald Welte wrote: > It's sad that we only see this now - for a patch that has been in gerrit > for review since March :/ Well yea, also kind of normal to miss some things every now and then. On the up-side, the osmo-gsm-tester is starting to give us useful feedback ;) > > socket file should be cleaned up on exit?? > > not sure if we do that for mncc and the other sockets. I would try to > follow what's done there. In a crash you cannot reliably clean them up > anyway, so in general one must live with that. ok. As soon as the path for the sockets is configurable, the osmo-gsm-tester will be fine. > In classic GSM networks the PCU was always co-located with the BSC. [...] Ah ok, I understand now. All I know is Osmocom, so the classic way is new to me :) > > I would like this commit to be reverted until the location is configurable, so > There are a long series of follow-up commits merged which would all need [...] It's ok, I can also write up a patch; though I'm not sure what you mean with sharing code with mncc_sock yet. I could try to figure that out, unless you're faster than me anyway. It's not super high prio, because so far the tester is running only one {BSC, NITB} at a time, and as long as we clean up after manual runs with a different user things should continue to work for the time being. > > I have a ticket for this in the OsmoGSMTester project, we may need to move it > > to a different parent project or create a new ticket: > > https://osmocom.org/issues/2293 > > I think it's an issue with libbsc, so it should go to the OpenBSC > project in the libbsc category? Agreed. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 29 19:59:49 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 21:59:49 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester In-Reply-To: <20170529120056.eekhcy642smdj5qu@nataraja> References: <20170528231229.GI1882@my.box> <20170529082413.wasobczfz637g6xt@nataraja> <20170529120056.eekhcy642smdj5qu@nataraja> Message-ID: <20170529195949.GG1863@my.box> On Mon, May 29, 2017 at 02:00:56PM +0200, Harald Welte wrote: > Hi Neels, > > See https://gerrit.osmocom.org/#/c/2777/ which is merged now. Excellent! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 29 20:11:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 22:11:15 +0200 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <20170529132949.z57kio2ozhaehtg2@nataraja> References: <20170529132949.z57kio2ozhaehtg2@nataraja> Message-ID: <20170529201115.GH1863@my.box> On Mon, May 29, 2017 at 03:29:49PM +0200, Harald Welte wrote: > Voice testing has always been on the wishlist, but further down on the > TODO list. One issue here is that > > a) many modems don't do voice at all (data-only modems for laptops) > b) some modems expose voice only as analog audio (difficult to interface, > would require custom hardware next to the modem, e.g. using USB > soundcard, calibrate the levels, ...) > c) some modems expose the voice as PCM bus. Similarly, would require > some external codec chip and/or USB soundcard or the like, plus a > custom circuit > d) some modems expose voice as "GSM codec frames over UART" or other > highty proprietary formats > e) some modems expose voice as USB audio device. Most convenient, but > only found in some Qualcomm LE based devices such as Sierra Wireless > or Quectel. For the record, Harald already knows this: Another issue is that we don't have a modem yet for which ofono offers even the possibility of initiating a call. It would be nice to at first have the voice signalling to begin with. > simpler: Every phone is supposed to include a voice loop-back mode. In Hah interesting feat! I wonder whether it is sending the exact RTP packets back. This way we can certainly play around with the RF attenuation and see whether voice frames got dropped and so forth. Sounds like we would initiate a single-leg call from the MSC with the modem in loopback mode. But we could maybe also still call one modem from the other, and tell one of them to go in loopback mode? Anyhow, sounds quite interesting. > The idea is that one puts a special "Test SIM" (as specified in TS > 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this > context) into the phone, and then sends some specific commands on Layer3 > to activate the loop. Hopefully we can tell the sysmoUSIM to do this, and thus still use all other features like authentication? > downlink (minus some occasional bit error, but those should be super low > given we're operating omso-gsm-tester over coaxial cabling between MS and > BTS). Unless we do want to turn up the attenuation and see how, say, handovers go. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 29 20:18:42 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 22:18:42 +0200 Subject: static builds in jenkins In-Reply-To: <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> References: <834ffce8-6963-8d37-c349-25f0afb63406@sysmocom.de> <20170529164715.6urn2dmzsuvjnwhw@nataraja> <44fcc95b-f6f9-d32a-f5e7-1f591ec27e4c@sysmocom.de> Message-ID: <20170529201842.GI1863@my.box> On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote: > Well, in my case I wanted to quickly test on a remote host without build environment > (internal ref. - gbproxy issue). It turned out that it doesn't work - way too > different hosts (libc, compiler etc). > > As for general use-case - I'm not sure. Hence, this email to start the discussion. Could also make sense for the osmo-gsm-tester. So far we are building all the osmo libraries and actually copy them over to the main unit as well, meaning we need to set an LD_LIBRARY_PATH when launching a binary. But it is a bit of a "gamble", or, say, uncertainty whether the remaining dependencies on the main unit match the build server. If we built one single static binary and send it to the main unit, it would probably be more certain to work as intended at build time? So far I have a ticket to drop static libraries from the build artifacts. Instead we could drop all libraries (dynamic and static) and only send the readily linked static binary. http://osmocom.org/issues/2303 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mychaela.falconia at gmail.com Mon May 29 20:21:38 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 29 May 2017 12:21:38 -0800 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <20170529132949.z57kio2ozhaehtg2@nataraja> References: <20170529132949.z57kio2ozhaehtg2@nataraja> Message-ID: On 5/29/17, Harald Welte wrote: > d) some modems expose voice as "GSM codec frames over UART" You got me curious here: are there any modems out there other than FreeCalypso that offer the quoted special feature? Someone actually paid me to add this special feature to FreeCalypso a little over a year ago, so I reason that it must be sufficiently non-standard that they couldn't find a commercial off-the-shelf modem that can do this feat. M~ From nhofmeyr at sysmocom.de Mon May 29 20:21:25 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 22:21:25 +0200 Subject: PCU socket in OsmoNITB breaks osmo-gsm-tester In-Reply-To: <20170529192607.GC1863@my.box> References: <20170528231229.GI1882@my.box> <20170529082413.wasobczfz637g6xt@nataraja> <20170529192607.GC1863@my.box> Message-ID: <20170529202125.GJ1863@my.box> On Mon, May 29, 2017 at 09:26:07PM +0200, Neels Hofmeyr wrote: > It's ok, I can also write up a patch; though I'm not sure what you mean with (This mail was written without internet and sent later, in case you're confused about the ordering of my messages) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon May 29 21:57:02 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 May 2017 23:57:02 +0200 Subject: osmo-gsm-tester successfully runs {NITB, AoverIP} x {sysmoBTS, B210} Message-ID: <20170529215702.GA3872@my.box> Just now I obtained a successful test run of the osmo-gsm-tester with these combinations: OsmoNITB with sysmoBTS OsmoNITB with osmo-bts-trx (Ettus B210) OsmoMSC + OsmoBSC (AoverIP) with sysmoBTS OsmoMSC + OsmoBSC (AoverIP) with osmo-bts-trx (Ettus B210) http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/214/ yay! :) All of these are now enabled by default. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue May 30 00:27:16 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 May 2017 02:27:16 +0200 Subject: osmo-gsm-tester successfully runs {NITB, AoverIP} x {sysmoBTS, B210} In-Reply-To: <20170529215702.GA3872@my.box> References: <20170529215702.GA3872@my.box> Message-ID: <20170530002716.7vhhutuvrzbmwr7k@nataraja> Hi Neels, On Mon, May 29, 2017 at 11:57:02PM +0200, Neels Hofmeyr wrote: > Just now I obtained a successful test run of the osmo-gsm-tester with these > combinations: > > OsmoNITB with sysmoBTS > OsmoNITB with osmo-bts-trx (Ettus B210) > OsmoMSC + OsmoBSC (AoverIP) with sysmoBTS > OsmoMSC + OsmoBSC (AoverIP) with osmo-bts-trx (Ettus B210) this is great news, and I hope we are getting stable, reproducible results for this. Might it make sense to simply let the tester run repeating and repeating the same test with the same software over and over again to see if it really is reproducible? In any case, I think next to extending this to more BTS hardware options, there are the following next steps: * replicate the development setup on the 1U enclosed production setup * use the production setup for the official jenkins job * extend test coverage to go beyond the current very basic tests cases. Would you agree? I think a long time once did quite some brainstorming on the kind of testing that I'd love to see. Let me see if I can dig that out somewhere again. I think there's quite a bit that can be tested even without voice, purely on the signaling plane. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 30 00:23:08 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 May 2017 02:23:08 +0200 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: References: <20170529132949.z57kio2ozhaehtg2@nataraja> Message-ID: <20170530002308.oyro5tzrhg5yebw3@nataraja> Hi Mychaela, On Mon, May 29, 2017 at 12:21:38PM -0800, Mychaela Falconia wrote: > On 5/29/17, Harald Welte wrote: > > d) some modems expose voice as "GSM codec frames over UART" > > You got me curious here: are there any modems out there other than > FreeCalypso that offer the quoted special feature? Someone actually > paid me to add this special feature to FreeCalypso a little over a > year ago, so I reason that it must be sufficiently non-standard that > they couldn't find a commercial off-the-shelf modem that can do this > feat. I've definitely seen this in commercial modems. If I remember correctly, it was the Gemalto EHS-6, which can disable the GPS uart and re-cycle that UART for the audio frames. It might also have been a Quectel UC-20. Now that I think more about it, I think it was the UC-20. -- - 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 Tue May 30 01:32:24 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 30 May 2017 09:32:24 +0800 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <20170530002308.oyro5tzrhg5yebw3@nataraja> References: <20170529132949.z57kio2ozhaehtg2@nataraja> <20170530002308.oyro5tzrhg5yebw3@nataraja> Message-ID: <48565DE2-85A8-4DB4-9E3F-E11AEA5F1BF7@freyther.de> > On 30. May 2017, at 08:23, Harald Welte wrote: > > Hi Mychaela, > > > If I remember correctly, it was the Gemalto EHS-6, which can disable the > GPS uart and re-cycle that UART for the audio frames. It might also > have been a Quectel UC-20. Now that I think more about it, I think it > was the UC-20. Yes UC-20, with 40ms (according to the documentation not 20ms!) of audio at a time. I have used gstreamer with the filebin to send audio and cat+ audacity to receive it. holger From mychaela.falconia at gmail.com Tue May 30 01:43:57 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 29 May 2017 17:43:57 -0800 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <48565DE2-85A8-4DB4-9E3F-E11AEA5F1BF7@freyther.de> References: <20170529132949.z57kio2ozhaehtg2@nataraja> <20170530002308.oyro5tzrhg5yebw3@nataraja> <48565DE2-85A8-4DB4-9E3F-E11AEA5F1BF7@freyther.de> Message-ID: Holger Freyther wrote: > Yes UC-20, with 40ms (according to the documentation not 20ms!) of audio > at a time. I have used gstreamer with the filebin to send audio and cat+ > audacity to receive it. What exactly are the bits which you send and receive every 40 ms? Do you get two 260-bit GSM 06.10 codec frames every 40 ms, with the ability to send your own arbitrary bits into the TCH uplink, including the possibility of passing non-speech data over voice TCH if the network does TFO as in GSM 02.53? The latter is what the Calypso DSP allows. M~ From holger at freyther.de Tue May 30 04:00:21 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 30 May 2017 12:00:21 +0800 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: References: <20170529132949.z57kio2ozhaehtg2@nataraja> <20170530002308.oyro5tzrhg5yebw3@nataraja> <48565DE2-85A8-4DB4-9E3F-E11AEA5F1BF7@freyther.de> Message-ID: <3A906ED7-C9F9-4838-B9B0-47F00AD4367D@freyther.de> > On 30. May 2017, at 09:43, Mychaela Falconia wrote: > > Holger Freyther wrote: Hi > What exactly are the bits which you send and receive every 40 ms? Do > you get two 260-bit GSM 06.10 codec frames every 40 ms, with the > ability to send your own arbitrary bits into the TCH uplink, including > the possibility of passing non-speech data over voice TCH if the > network does TFO as in GSM 02.53? The latter is what the Calypso DSP > allows. It is alaw. I assume the Qualcomm DSP will do the transcoding but I didn't look/trace the implementation (and the UC20 doesn't run Linux). E.g. I used this to play a sine wave on a connected call. gst-launch-1.0 audiotestsrc wave=sine ! audioconvert ! audioresample ! audio/x-raw, rate=8000, channels=1, format=S16LE ! filesink location=/dev/ttyUSB1 sync=true From gerardfly9 at gmail.com Wed May 31 03:53:56 2017 From: gerardfly9 at gmail.com (Gerard Lawrence Pinto) Date: Tue, 30 May 2017 20:53:56 -0700 Subject: Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB In-Reply-To: <20170529075143.4nsf3hmq6dilsbzv@nataraja> References: <20170529075143.4nsf3hmq6dilsbzv@nataraja> Message-ID: Hi Harald, No problem. I totally understand thanks for the reply! > So I suggest we move the existing mncc-python repository into gerrit, > and then you can submit whatever you think is missing in mncc-python? Yes, please thanks! As far as I remember there was just 1 issue when I used mncc-python with OsmocomBB on real network. I can confirm this again and push the fix there if it still exists. So you can verify it accordingly. > A general suggestion (independent of Osmocom): Please always put license > information in your code. Ok I wasn't aware of this protocol. I read and understood that I need to include GNU PL and cite if a 3rd party library is used (also check its license conditions) If I'm contributing to an existing then keep the original license intact (also check its conditions) > If you work on existing code, then please properly clone the original > repository and then add your patches on top of it. Yes, my apologies I did clone from git. However I must have messed up. > The way how to properly solve this (normally) is that Layer1 is sending something like "ready to send (RTS) indications" to Layer2 > L1CTL doesn't have this so far, > Please also keep future osmocom-bb related questions to the baseband-devel list, thanks! Very interesting reply, thanks! Sure baseband-devel list, I was thinking the same that it should have been there, so other developers would be aware of it. > I'm happy to review it once there is a repo based on the original one > with change sets to review. We can also move osmo-sim-auth to gerrit so > you can submit your patches there. Yes, please thank you! Sorry about not maintaining history. I have just added other SIM card related API's like fetch - IMSI, LAI, ICCID write LOCI etc. (A full fledged sim reader/writer of a SIM card) Let us keep it in osmo-sim-auth for now. If it is accepted by Osmocom, then later can be merged with Pysim with a different executable? (Although it was built for programmable SIM card - agreed) We can discuss! Thanks, Gerard On Mon, May 29, 2017 at 12:51 AM, Harald Welte wrote: > Hi Gerard, > > sorry for the delayed response, sometimes there are simply too many > tasks and mails to handle :/ > > On Fri, May 19, 2017 at 10:28:56PM -0700, Gerard Lawrence Pinto wrote: > > Congrats on OsmoCon 2017! > > thanks! > > > I have been working with OsmocomBB, osmo-sim-auth, mncc-python > > projects in Osmocom. > > great. The important part is now to make sure those changes don't live > somewhere out there but to think how they can be merged mainline! > > > To begin with I have committed: > > I) MNCC with OsmocomBB - *https://github.com/ > GerardPinto/call-control-mncc-sap > > * (Has both > > implementations in Python and C + Tested voice with gsm-fr with gsm audio > > file - works great). > > - Some of which can be committed to mncc-python? (In order to support > > MNCC with OsmocomBB too) Although, Harald told me it was built for > OpenNITB > > - I'm not sure, the relevance of this contribution to this repo? > > MNCC should be virtually the same, whether on OsmocomBB or on OsmoNITB > (or now OsmoMSC). Let's avoid having different implementations and > different repositories. At least regarding the python code, please > submit your changes to mncc-python > > We generally try to avoid fragmentation of code but want to have one > implementation of a given functionality within the project. So what's > needed is the knowledge of what exactly is missing or needs > modification/improvement in mncc-python, not another implementation with > unclear status on what are advantages/disadvantages of either of them. > > So I suggest we move the existing mncc-python repository into gerrit, > and then you can submit whatever you think is missing in mncc-python? > How does that sound? > > A general suggestion (independent of Osmocom): Please always put license > information in your code. Otherwise it is not clear if anyone is able > to use it (and under what terms). > > > *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() > > 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The > DAC, > > ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = > > 456. > > So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => > > l1ctl_rx_traffic_req > > *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) > > if num > 4 dropping traffic frame. (114 x 4) > > The code above indicates if queue has any (114 x 4) bits drop the > incoming > > voice request. > > Well, GSM is a TDMA system and everything has to happen with regard to > the TDMA clock as defined by the BTS (clock master). So you cannot > send voice frames faster than the TDMA clock is transmitting them. > > > *My Question is*: If I happened to send voice packets 33 bytes really > fast. > > There should be some kind of buffer rather than a check (Code) and drop > > frame? - OR this case can never happen? > > The way how to properly solve this (normally) is that Layer1 is sending > something like "ready to send (RTS) indications" to Layer2, and Layer2 > then knows it has to send another frame. This way, the timing is > defined by L1. However, as there is latency between L1 and L2 (serial > line, operating system scheduling, ...) there actually needs to be a bit > of a buffer or an "advancement" of the RTS indications to compensate for > that. > > L1CTL doesn't have this so far, but it would of course be appreciated if > somebody would make it more robust and contribute related patches. > > Please also keep future osmocom-bb related questions to the > baseband-devel list, thanks! > > > II) osmo-sim-auth with added other SIM related API's (still needs code > > clean up, SIM response check, code re-usable, README.md etc,) > > * https://github.com/GerardPinto/osmo-sim-auth > > * > > - I did check out PySIM (I think I can add some code to the existing > > repository, with your permission). > > If you work on existing code, then please properly clone the original > repository and then add your patches on top of it. That way one can > browse the commit log and clearly look ad individual patches. I'm > unable to figure out what you did by looking at your repository, as you > appear to have imported an unknown version of osmo-sim-auth without > cloning the original repository and keeping history. > > > Could you please let me know if my osmo-sim-auth repo? If it is correct > to > > combine with PySIM, with the changes done below? > > I'm happy to review it once there is a repo based on the original one > with change sets to review. We can also move osmo-sim-auth to gerrit so > you can submit your patches there. But in order to do that, you would > also have to do a proper clone of the original repo and implement your > changes as commits on top. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Wed May 31 11:06:56 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 31 May 2017 13:06:56 +0200 Subject: osmo-trx rx gain question Message-ID: <0da14f35-4106-735e-d486-280996190ad4@sysmocom.de> Hi. While testing latest osmo-trx in multi-trx mode I've noticed following errors: sudo chrt -r 99 ./Transceiver52M/osmo-trx -c 2 -x -m linux; GNU C++ version 6.2.0 20161005; Boost_106100; UHD_003.009.006-release opening configuration table from path :memory: Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 2 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Disabled Reference............... External C0 Filler Table......... Disabled Multi-Carrier........... Enabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Detected Device: B210 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 16.000000 MHz... -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 51.200000 MHz... -- Actually got clock rate 51.200000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B200/B210 4 SPS Multi-ARFCN -- Transceiver active with 2 channel(s) NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:243:start: Starting the transceiver NOTICE 139729930749696 12:59:48.0 Transceiver.cpp:794:driveControl: Changing TSC from 7 to 7 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ... This doesn't seem to have any visible effect but still makes me wonder what's going on here? If this is indeed critical error than what exactly is broken and how to test it? If it's smth which could be safely ignored than why it's reported with alert priority? Any help clarifying it would be appreciated. -- Max Suraev 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 tom at tsou.cc Wed May 31 18:13:07 2017 From: tom at tsou.cc (Tom Tsou) Date: Wed, 31 May 2017 11:13:07 -0700 Subject: osmo-trx rx gain question In-Reply-To: <0da14f35-4106-735e-d486-280996190ad4@sysmocom.de> References: <0da14f35-4106-735e-d486-280996190ad4@sysmocom.de> Message-ID: On Wed, May 31, 2017 at 4:06 AM, Max wrote: > ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent > channel 1 The error comes up because in MCBTS there is only one physical channel - as in one hardware RF gain element. So the receive gain on channel 0 is effectively a global setting for all ARFCN channels; gain on each ARFCN cannot be set independently. Note that the transmit side behaves differently. The same gain effect exists for all channels, but there is no warning. Instead, the gain control command is sent to the device regardless of which ARFCN is selected. Perhaps we should make the Tx and Rx gain behavior consistent. I'm open to suggestions. -TT From laforge at gnumonks.org Wed May 31 19:35:17 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 May 2017 21:35:17 +0200 Subject: osmo-trx rx gain question In-Reply-To: References: <0da14f35-4106-735e-d486-280996190ad4@sysmocom.de> Message-ID: <20170531193517.7ddq4abqwip3kwc3@nataraja> Hi Tom, In osmo-bts, we have the notion of a "phy link" and a "phy instance". A PHY Link defines some kind of logical or physical interfae to a given PHY layer implementation. This can be some kind of shared memory device (sysmobts, litecell15), or a ethernet device (octbts). The PHY Instance is a logical instance serving one ARFCN within the PHY Link. AFAIR, for osmo-bts-trx, we moved the attenuation/gain parameters at some point into the "instance" so that there can be separate parameters for each of the two TRX. If I understand you correctly, osmo-trx has two modes of multi-trx operation: a) two soft ARFCN in one RF dac/adc-rx/tx chain in the SDR b) two sets of single-TRX, each on a separate dac/adc-rx/tx chain in the SDR Correct? In that case, the problem is that 'a' and 'b' would differ in terms of where the parameters should be put. In 'a' it should be global parameters for the entire 'PHY Link', in 'b' it shold be per 'PHY Instance'. The only obvious logical way to resolve this would be to move the parameters to the 'PHY Link'. 'a' would then have one PHY link with two PHY instances (shared params), and 'b' would have two PHY links which one instance each (separate params). The question is then how the separate TRX are exposed on the UDP-protocol between osmo-trx and osmo-bts-trx. I haven't yet looked at that part of the code [or forgot, sorry]. 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 laforge at gnumonks.org Wed May 31 20:27:48 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 May 2017 22:27:48 +0200 Subject: Message Sequence Charts on A / SCCPlite / 3GPP AoIP Message-ID: <20170531202748.lvmsoeb3hsqqojmu@nataraja> Dear all, today I put together some message sequence charges on the different A interface configurations. This should serve to establish some kind of "common understanding" about what is different in terms of a) classic A interface (E1 on Abis and A) b) Old OsmoBSC with Abis/IP and SCCPlite+MGCP on A c) New OsmoBSC with Abis/IP and 3GPP AoIP d) New OsmoBSC with Abis/E1 and 3GPP AoIP (extended MGW) The document is in gerrit review, but you can also find a rendered version of the current draft at http://people.osmocom.org/laforge/tmp/aoip-mgw-options.pdf Please let me know if your understanding of the different protocol/options is different. I'll continue to work on the document and add some more textual explanation. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)