From laforge at gnumonks.org Sat Apr 1 09:45:17 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 1 Apr 2017 11:45:17 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? Message-ID: <20170401094517.5fstmuftbe457izq@nataraja> Dear all, [Despite today being April 1st, this is not an april fool's joke] ever since the start of the Osmocom project, we have adopted pretty much 1:1 the Linux Kernel coding style. Having a uniform coding style all over the project is important for readability, and from my point of view it doesn't really matter too much which style it is, as long as it is uniform accross the projects. I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines. 80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code. What do people generally think here? 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 k at rhizomatica.org Sat Apr 1 10:30:48 2017 From: k at rhizomatica.org (k at rhizomatica.org) Date: Sat, 1 Apr 2017 12:30:48 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170401094517.5fstmuftbe457izq@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: <68502fb0-d240-6f1d-b999-de75ca407fd0@rhizomatica.org> On 01/04/2017 11:45, Harald Welte wrote: > 80 characters is still > nice here and there, but maybe something like 100, 120 or even 130 might > actually make the code more readable and permit us to use slightly > longer identifiers without having to wrap every second statement in the > code. > > What do people generally think here? Not that I'm coding much on Osmo, well it says RFC.. :-) I have recently been making at attempt to clean up some python coding style using pylint and I have been wincing a little at the "standard" default of a line width of 79, although some arguments in favour do make sense. My terminal is generally 120 -140 characters wide. I also use Sublime Text which usually displays 110 the way I have it. You mentioned something recently about why would anyone read code in a web browser, I find myself browsing code more and more on sites such as github, rather than getting a local copy, via clone or download and extract etc. - I had a conversation recently about how we tend more to lookup quick reminders of things on the web, even though there are local manpages. need to get offline more.. :) Anyway, github site handles 120 chars fine. I guess any issue might be more with gerrit. k/ From nhofmeyr at sysmocom.de Sat Apr 1 12:43:45 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 1 Apr 2017 14:43:45 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170401094517.5fstmuftbe457izq@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: <20170401124345.GA1809@my.box> On Sat, Apr 01, 2017 at 11:45:17AM +0200, Harald Welte wrote: > I'm still fine with the Linux kernel coding style for most parts, but I > think we could consider allowing longer lines. The vim indenting rules help a great deal with breaking up lines[1], but particularly when strings or function argument definitions are involved, it's still annoying. There is no actual reason to choose 80 chars anymore. With the osmo-gsm-tester code I'm working on these days, I find myself not strictly enforcing the 80 characters rule, because it's annoying more than helping. Just checked, the default way my terminals are arranged and configured ends up in 105 characters of line width (two terminals side-by-side in a tiling wm, with a font roughly ten times the size that Harald uses). When I scale down one font size, I can fit 119... but... My purely self-centered vote would be 100 chars -- or 105 ;) I guess even if we allow 120, most lines would stay within 100? A post some time last year pointed at a ruleset using 120. With debug log output lines I would gladly allow "any" line width, though. Following the category and level is a nice and descriptive string, which almost always needs to be broken up without really serving code readability. > What do people generally think here? +1 ("+20") ~N [1] ~/.vimrc: if has("autocmd") augroup ccmds autocmd! autocmd FileType c set cin isk=a-z,A-Z,48-57,_ cino=>1s,e0,f0,{0,}0,=1s,t0,+1s,c3,(0,u0,\ 0,:0 autocmd FileType cpp set cin isk=a-z,A-Z,48-57,_ cino=>1s,e0,f0,{0,}0,=1s,t0,+1s,c3,(0,u0,\ 0,:0 augroup END endif " useful: 'visual'-select a long line and hit gw -------------- 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 Sat Apr 1 12:54:17 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 1 Apr 2017 15:54:17 +0300 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170401094517.5fstmuftbe457izq@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: I completely support extension of the line with. 80 characters limit is very annoying these days. 120 is a good number. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On Apr 1, 2017 12:45, "Harald Welte" wrote: > Dear all, > > [Despite today being April 1st, this is not an april fool's joke] > > ever since the start of the Osmocom project, we have adopted pretty much > 1:1 the Linux Kernel coding style. > > Having a uniform coding style all over the project is important for > readability, and from my point of view it doesn't really matter too much > which style it is, as long as it is uniform accross the projects. > > I'm still fine with the Linux kernel coding style for most parts, but I > think we could consider allowing longer lines. 80 characters is still > nice here and there, but maybe something like 100, 120 or even 130 might > actually make the code more readable and permit us to use slightly > longer identifiers without having to wrap every second statement in the > code. > > What do people generally think here? > > 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 andreas.mueller at criticallabs.org Mon Apr 3 05:50:32 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Mon, 3 Apr 2017 07:50:32 +0200 Subject: UMTS-Stick on nano3G? Message-ID: <20170403055032.GA3216@pocken.who.de> Hello, I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and pppd to connect to a nano3G for getting an IP/Internet-connection via UMTS/HSDPA. The setup is mainly as described on http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G. When using an android-Smartphone with the same configuration of the ggsn and the other components the IP/Internet-connection is working. After pppd is started from wvdial it receives his local IP-address from the "net 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by pppd as a default value: ... --> local IP address 192.168.99.5 --> pppd: ???[7f] --> remote IP address 10.64.64.64 --> pppd: ???[7f] --> primary DNS address 8.8.8.8 --> pppd: ???[7f] ..which results in an unusable ppp0-device: ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 Has anybody successfully used an UMTS-Stick with ggsn? How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote IP address"? Are there special options for pppd which I have to use? thanks and greetings, Andreas From laforge at gnumonks.org Mon Apr 3 06:18:12 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 3 Apr 2017 08:18:12 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <20170403055032.GA3216@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> Message-ID: <20170403061812.v456lxcbztlzdzid@nataraja> Hi Andreas, first of all congratulations to get the setup running and to reproduce the current status of the Osmocom 3G support. On Mon, Apr 03, 2017 at 07:50:32AM +0200, Andreas Mueller wrote: > After pppd is started from wvdial it receives his local IP-address > from the "net 192.168.99.0/24" parameter of ggsn.conf and also the > configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by > pppd as a default value: This is very odd. Please include a protocol trace of the Iuh interface. -- - 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 Apr 3 08:25:50 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 3 Apr 2017 10:25:50 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170401094517.5fstmuftbe457izq@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> Hell yeah! The 120 would be a dream come true :) I use emacs to visibly mark current 80 chars limit and it's about 1/3 screen estate on my rather old monitor. On a related note: have anyone tried to use https://www.gnu.org/software/indent/manual/indent.html already to make more formal specification of what Osmocom coding style is? On 01.04.2017 11:45, Harald Welte wrote: > > What do people generally think here? > -- 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 246tnt at gmail.com Mon Apr 3 08:27:44 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 3 Apr 2017 10:27:44 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: +1. I'm fine with either 100 or 120. Cheers, Sylvain From pmaier at sysmocom.de Mon Apr 3 08:35:46 2017 From: pmaier at sysmocom.de (Philipp Maier) Date: Mon, 3 Apr 2017 10:35:46 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> References: <20170401094517.5fstmuftbe457izq@nataraja> <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> Message-ID: <58E20962.4070901@sysmocom.de> Hi folks, > The 120 would be a dream come true :) To be honest, I feel very uncomfortable with changing the coding style. This would make the existing code look like a mess. If we really break with the 80 lines limit, we should only do it for new projects. Since the 80 characters have a historical background, the new policy should have a historical background too. I would suggest to use 132 columns (DECwriter II) regards, Philipp -- Philipp Maier 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 Mon Apr 3 08:39:59 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 3 Apr 2017 10:39:59 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <58E20962.4070901@sysmocom.de> References: <20170401094517.5fstmuftbe457izq@nataraja> <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> <58E20962.4070901@sysmocom.de> Message-ID: <6c1703fd-c378-ddd5-21dd-a47719966380@sysmocom.de> That would only be true if all the code would have complied with the current policy of 80 chars. In reality it's not the case - in almost any given file you can find exceptions hanging beyond 80 limit. So the code is already mess in this regard. On 03.04.2017 10:35, Philipp Maier wrote: > Hi folks, > >> The 120 would be a dream come true :) > > To be honest, I feel very uncomfortable with changing the coding > style. This would make the existing code look like a mess. -- 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 Mon Apr 3 12:03:52 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 3 Apr 2017 14:03:52 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> References: <20170401094517.5fstmuftbe457izq@nataraja> <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> Message-ID: <20170403120352.GA1451@ass40.sysmocom.de> I like the notion of historical context... http://kleinekatze.de/lai9wiK4/DECWriterII.jpg ;) Still I would prefer 120 or less for practical reasons. I assume none of us is using a DEC Writer to hack on Osmocom? :) ~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 Apr 3 12:10:58 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 3 Apr 2017 14:10:58 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <20170403055032.GA3216@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> Message-ID: <20170403121058.GB1451@ass40.sysmocom.de> On Mon, Apr 03, 2017 at 07:50:32AM +0200, Andreas Mueller wrote: > After pppd is started from wvdial it receives his local IP-address from the "net 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by pppd as a default value: > > ... > --> local IP address 192.168.99.5 > --> pppd: ???[7f] > --> remote IP address 10.64.64.64 > --> pppd: ???[7f] > --> primary DNS address 8.8.8.8 > --> pppd: ???[7f] I know a whole while back we tried unsuccessfully to use an UMTS "stick" to test data services, but never got it to work. We saw the same: smart phone works fine, UMTS stick fails to establish data. You might be onto the reason there, would be great if you could help us resolve this! > Has anybody successfully used an UMTS-Stick with ggsn? > How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote IP address"? > Are there special options for pppd which I have to use? I don't really know and would have to look into it in detail. It would be great if you could try to understand what's going on from traces and/or openggsn code and/or openbsc code... Maybe we somehow send the wrong or incomplete configuration and maybe smart phones have some magic to work around it, which UMTS sticks don't? ~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 Apr 3 12:34:48 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 3 Apr 2017 14:34:48 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> References: <20170401094517.5fstmuftbe457izq@nataraja> <94be7144-6997-97e1-9482-961ccf23b588@sysmocom.de> Message-ID: <20170403123448.GC1451@ass40.sysmocom.de> On Mon, Apr 03, 2017 at 10:25:50AM +0200, Max wrote: > Hell yeah! > > The 120 would be a dream come true :) > > I use emacs to visibly mark current 80 chars limit and it's about 1/3 screen > estate on my rather old monitor. > > On a related note: have anyone tried to use > https://www.gnu.org/software/indent/manual/indent.html already to make more > formal specification of what Osmocom coding style is? Could be nice to have this in the light of: http://programmer.97things.oreilly.com/wiki/index.php/Automate_Your_Coding_Standard We would have a bunch of cosmetic commits to once apply a consistent style everywhere from 'indent', and we'd probably have an amount of bikesheds until we agree on a specific 'indent' configuration. From then on we would have a guaranteed fixed coding style. But we'll probably also have to do many more patch edits from breaking the style in gerrit submissions, and it would also erase the comfort of being able to let a cosmetic issue slip by. 'indent' is only useful if all code already adheres to its style (otherwise it adds numerous unrelated cosmetic changes). Would have been nice, but not sure if it's worth the added effort to introduce it now... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From aschultz at tpip.net Mon Apr 3 13:29:56 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Mon, 3 Apr 2017 15:29:56 +0200 (CEST) Subject: UMTS-Stick on nano3G? In-Reply-To: <20170403055032.GA3216@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> Message-ID: <1097441106.721065.1491226196405.JavaMail.zimbra@tpip.net> Hi Andreas, Could you provide a pcap of the Create PDP Request and Response exchange between SGSN and GGSN? Regards Andreas ----- On Apr 3, 2017, at 7:50 AM, Andreas Mueller andreas.mueller at criticallabs.org wrote: > Hello, > > I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and > pppd to connect to a nano3G for getting an IP/Internet-connection via > UMTS/HSDPA. > The setup is mainly as described on > http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G. > > When using an android-Smartphone with the same configuration of the ggsn and the > other components the IP/Internet-connection is working. > > After pppd is started from wvdial it receives his local IP-address from the "net > 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but > no remote-IP, so 10.64.64.64 is used by pppd as a default value: > > ... > --> local IP address 192.168.99.5 > --> pppd: ???[7f] > --> remote IP address 10.64.64.64 > --> pppd: ???[7f] > --> primary DNS address 8.8.8.8 > --> pppd: ???[7f] > > ..which results in an unusable ppp0-device: > ppp0 Link encap:Point-to-Point Protocol > inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > > Has anybody successfully used an UMTS-Stick with ggsn? > How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote > IP address"? > Are there special options for pppd which I have to use? > > > thanks and greetings, > > Andreas From ron.menez at entropysolution.com Tue Apr 4 05:11:10 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 4 Apr 2017 05:11:10 +0000 Subject: osmo-bts Installation Issue Message-ID: <87C7FE3E-DBE1-4342-864C-718390E70168@entropysolution.com> Hi All, Requesting your help regarding the case that we had encountered during the installation of osmo-bts using UBUNTU 14.04 as OS. Without using the 201509-fairwaves-rebase, the installation go past through. Unfortunately, there is no ?osmo-bts-trx? executable. Below are the steps we followed for the installation of osmo-bts. cd /opt/osmo/src/ git clone git://git.osmocom.org/osmo-bts cd osmo-bts autoreconf -fi ./configure make -j5 make check make install We tried using the 201509-fairwaves-rebase, but unfortunately the installation stops and an error was encountered during the ?make? process. Below are the installation steps and error encountered: cd /opt/osmo/src/ git clone git://git.osmocom.org/osmo-bts cd osmo-bts git checkout 201509-fairwaves-rebase autoreconf -fi ./configure --enable-trx make Error encountered: make[2]: Entering directory `/opt/osmo/src/osmo-bts/src' Making all in common make[3]: Entering directory `/opt/osmo/src/osmo-bts/src/common' CC gsm_data_shared.o CC sysinfo.o CC logging.o CC abis.o abis.c: In function ?abis_open?: abis.c:233:25: warning: assignment discards ?const? qualifier from pointer target type [enabled by default] bts_dev_info.unit_name = model_name; ^ abis.c:236:25: warning: assignment discards ?const? qualifier from pointer target type [enabled by default] bts_dev_info.location2 = model_name; ^ CC oml.o oml.c:46:30: error: conflicting type qualifiers for ?abis_nm_att_tlvdef_ipa? static struct tlv_definition abis_nm_att_tlvdef_ipa = { ^ In file included from oml.c:33:0: /usr/local/include/osmocom/gsm/abis_nm.h:37:36: note: previous declaration of ?abis_nm_att_tlvdef_ipa? was here extern const struct tlv_definition abis_nm_att_tlvdef_ipa; ^ oml.c:373:6: error: nested redefinition of ?enum abis_nm_t200_idx? enum abis_nm_t200_idx { ^ oml.c:373:6: error: redeclaration of ?enum abis_nm_t200_idx? In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:647:6: note: originally defined here enum abis_nm_t200_idx { ^ oml.c:374:2: error: redeclaration of enumerator ?T200_SDCCH? T200_SDCCH = 0, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:648:2: note: previous definition of ?T200_SDCCH? was here T200_SDCCH = 0, ^ oml.c:375:2: error: redeclaration of enumerator ?T200_FACCH_F? T200_FACCH_F = 1, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:649:2: note: previous definition of ?T200_FACCH_F? was here T200_FACCH_F = 1, ^ oml.c:376:2: error: redeclaration of enumerator ?T200_FACCH_H? T200_FACCH_H = 2, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:650:2: note: previous definition of ?T200_FACCH_H? was here T200_FACCH_H = 2, ^ oml.c:377:2: error: redeclaration of enumerator ?T200_SACCH_TCH_SAPI0? T200_SACCH_TCH_SAPI0 = 3, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:651:2: note: previous definition of ?T200_SACCH_TCH_SAPI0? was here T200_SACCH_TCH_SAPI0 = 3, ^ oml.c:378:2: error: redeclaration of enumerator ?T200_SACCH_SDCCH? T200_SACCH_SDCCH = 4, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:652:2: note: previous definition of ?T200_SACCH_SDCCH? was here T200_SACCH_SDCCH = 4, ^ oml.c:379:2: error: redeclaration of enumerator ?T200_SDCCH_SAPI3? T200_SDCCH_SAPI3 = 5, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:653:2: note: previous definition of ?T200_SDCCH_SAPI3? was here T200_SDCCH_SAPI3 = 5, ^ oml.c:380:2: error: redeclaration of enumerator ?T200_SACCH_TCH_SAPI3? T200_SACCH_TCH_SAPI3 = 6 ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:654:2: note: previous definition of ?T200_SACCH_TCH_SAPI3? was here T200_SACCH_TCH_SAPI3 = 6 ^ make[3]: *** [oml.o] Error 1 make[3]: Leaving directory `/opt/osmo/src/osmo-bts/src/common' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/osmo/src/osmo-bts/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/osmo/src/osmo-bts' make: *** [all] Error 2 We followed the installation process from the URLs below: https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_family https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source 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. -------------- 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 laforge at gnumonks.org Tue Apr 4 06:30:58 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 4 Apr 2017 08:30:58 +0200 Subject: osmo-bts Installation Issue In-Reply-To: <87C7FE3E-DBE1-4342-864C-718390E70168@entropysolution.com> References: <87C7FE3E-DBE1-4342-864C-718390E70168@entropysolution.com> Message-ID: <20170404063058.3krtxuhs2ynv2j6m@nataraja> Hi Ron, my first question is: Why are you rebuilding from source and not using a more recent Ubuntu version for which there are official osmocom nightly packages available? But unrelated to that: On Tue, Apr 04, 2017 at 05:11:10AM +0000, Ron wrote: > cd /opt/osmo/src/ > git clone git://git.osmocom.org/osmo-bts > cd osmo-bts > autoreconf -fi > ./configure I think you are missing --enable-trx > We tried using the 201509-fairwaves-rebase, but unfortunately the installation stops and an error was encountered during the ?make? process. Below are the installation steps and error encountered: I don't think there's much point in useing some old branches unless you also use all the libraries that were current at that time. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas.mueller at criticallabs.org Tue Apr 4 08:03:45 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Tue, 4 Apr 2017 10:03:45 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <1097441106.721065.1491226196405.JavaMail.zimbra@tpip.net> References: <20170403055032.GA3216@pocken.who.de> <1097441106.721065.1491226196405.JavaMail.zimbra@tpip.net> Message-ID: <20170404080345.GA16893@pocken.who.de> Hallo, unfortunately I have very limited time during the next days, but I can do further testing on friday and will provide you with the pcap- and logfiles. greetings, Andreas On Mon, Apr 03, 2017 at 03:29:56PM +0200, Andreas Schultz wrote: > Hi Andreas, > > Could you provide a pcap of the Create PDP Request and Response exchange between > SGSN and GGSN? > > Regards > Andreas > > ----- On Apr 3, 2017, at 7:50 AM, Andreas Mueller andreas.mueller at criticallabs.org wrote: > > > Hello, > > > > I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and > > pppd to connect to a nano3G for getting an IP/Internet-connection via > > UMTS/HSDPA. > > The setup is mainly as described on > > http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G. > > > > When using an android-Smartphone with the same configuration of the ggsn and the > > other components the IP/Internet-connection is working. > > > > After pppd is started from wvdial it receives his local IP-address from the "net > > 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but > > no remote-IP, so 10.64.64.64 is used by pppd as a default value: > > > > ... > > --> local IP address 192.168.99.5 > > --> pppd: ???[7f] > > --> remote IP address 10.64.64.64 > > --> pppd: ???[7f] > > --> primary DNS address 8.8.8.8 > > --> pppd: ???[7f] > > > > ..which results in an unusable ppp0-device: > > ppp0 Link encap:Point-to-Point Protocol > > inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255 > > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > > > > > Has anybody successfully used an UMTS-Stick with ggsn? > > How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote > > IP address"? > > Are there special options for pppd which I have to use? > > > > > > thanks and greetings, > > > > Andreas From ron.menez at entropysolution.com Tue Apr 4 07:52:17 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 4 Apr 2017 07:52:17 +0000 Subject: osmo-bts Installation Issue In-Reply-To: <20170404063058.3krtxuhs2ynv2j6m@nataraja> References: <87C7FE3E-DBE1-4342-864C-718390E70168@entropysolution.com> <20170404063058.3krtxuhs2ynv2j6m@nataraja> Message-ID: Thanks Harald for the immediate reply. We successfully installed the osmo-bts from source using the --enable-trx and we?ll also try the recent Ubuntu version installation of osmocom. Thank you for your support. 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 4, 2017, at 2:30 PM, Harald Welte > wrote: Hi Ron, my first question is: Why are you rebuilding from source and not using a more recent Ubuntu version for which there are official osmocom nightly packages available? But unrelated to that: On Tue, Apr 04, 2017 at 05:11:10AM +0000, Ron wrote: cd /opt/osmo/src/ git clone git://git.osmocom.org/osmo-bts cd osmo-bts autoreconf -fi ./configure I think you are missing --enable-trx We tried using the 201509-fairwaves-rebase, but unfortunately the installation stops and an error was encountered during the ?make? process. Below are the installation steps and error encountered: I don't think there's much point in useing some old branches unless you also use all the libraries that were current at that time. -- - 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: -------------- 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 nhofmeyr at sysmocom.de Tue Apr 4 09:16:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 4 Apr 2017 11:16:12 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <20170404080345.GA16893@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> <1097441106.721065.1491226196405.JavaMail.zimbra@tpip.net> <20170404080345.GA16893@pocken.who.de> Message-ID: <20170404091612.GA1812@ass40.sysmocom.de> On Tue, Apr 04, 2017 at 10:03:45AM +0200, Andreas Mueller wrote: > Hallo, > > unfortunately I have very limited time during the next days, but I can do further testing on friday and will provide you with the pcap- and logfiles. Sure, take your time, no problem at all. ~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 Apr 5 12:26:03 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Apr 2017 14:26:03 +0200 Subject: DBus usage Message-ID: <20170405122603.GB3035@my.box> Hi Pau (and maybe others), here is a test script that showcases how I'd like to use DBus in the osmo-gsm-tester: use pydbus and keep the glib main loop in a thread (to handle DBus signals only). It sounds ambitious but the test program actually works. Would be great to hear your opinion on it: http://git.osmocom.org/osmo-gsm-tester/tree/selftest/dbus_test/ofono_client.py?h=neels The same thing cosmetically rearranged as module stub: http://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/dbus_client.py?h=neels Thanks! ~N Related: OS#1980 https://osmocom.org/issues/1980 -- - 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 Apr 5 12:43:24 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Apr 2017 14:43:24 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170401094517.5fstmuftbe457izq@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> Message-ID: <20170405124324.GC3035@my.box> On Sat, Apr 01, 2017 at 11:45:17AM +0200, Harald Welte wrote: > [Despite today being April 1st, this is not an april fool's joke] > nice here and there, but maybe something like 100, 120 or even 130 might It sounds to me like most opinions converge around 120. The collected opinions from this thread: "My terminal is generally 120 -140 characters wide. I also use Sublime Text which usually displays 110 the way I have it." "github site handles 120 chars fine" "I can fit 119" "A post some time last year pointed at a ruleset using 120." "120 is a good number." "I'm fine with either 100 or 120." "The 120 would be a dream come true" "I feel very uncomfortable with changing the coding style." and "the new policy should have a historical background too. I would suggest to use 132 columns (DECwriter II)" If we were a democracy the vote would be 120, but more African would be to reach unanimous agreement: would anyone like to comment on / veto the choice of changing the maximum permitted line width to 120 in the Osmocom projects? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From christophe.devine at ssi.gouv.fr Wed Apr 5 14:23:32 2017 From: christophe.devine at ssi.gouv.fr (Devine Christophe) Date: Wed, 5 Apr 2017 16:23:32 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170405124324.GC3035@my.box> References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> Message-ID: <58E4FDE4.9080302@ssi.gouv.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Neels, As for me a maximum of 120 chars per line is perfect, more however would be problematic on my work laptop which has a 1366x768 resolution. On a side note I've discovered Qt Creator is able to handle autotools projects, for instance this makes it very convenient to follow function calls (even across projects), or to discover who calls a particular function. It also provides a number of interesting features such as clang static analysis. By default however the relevant plugin is disabled, and must be enabled in Help->About plugins. Then for each project the top-level Makefile.am can be opened; I also recommend to restore the session on startup (File->Sessing Manager), and setting up a shortcut to define the current project (Tools->Options->Keyboard->SetStartup). - -cd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJY5P3kAAoJECrKWTqY+zzatB4H/iR7Fy4TFB28yQDgpwp/rgVf 4Z41rzzH9gwlLbsEtKSVOWygLULpsZ0xXUlJw/x59I5u3xQIPEk3d6eP6s3v5XNM DmaX/grTksKhNfOBtE2UDCh3SjPbUU5eDxsYocEhCvJxt3Rmd3MzCKBHfgumR9Ev /jBhKiSRyi/T4yO14sKEYiRivQ48x7cECsvI0O6xnQ9mqx0/HhRy9XtaQfz7sg9z tmbmgyJWTgyJaNsACJyQTiE9J7DZRyVKCVnhHRBisGroTT8I8G/pLV44NQqDlubv ouZ/KjB88s67KWjjPOQWIUi2KC9du3JjUHk9yMfTRtsGks+E/oBymqOQuhD3eE4= =lbux -----END PGP SIGNATURE----- From laforge at gnumonks.org Wed Apr 5 14:43:09 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Apr 2017 16:43:09 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170405124324.GC3035@my.box> References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> Message-ID: <20170405144309.3oc3lre7dozchhzu@nataraja> Dear all, for egoistical reasons I'm in favor of a limit of 100 to 106 characters only. Otherwise I can no longer fit three terminal windows next to each other on a (these day standard minimum display width) of 1920, which would be a major step back in terms of being able to look at multiple source files simultaneously. -- - 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 Apr 5 16:26:07 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Apr 2017 18:26:07 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170405144309.3oc3lre7dozchhzu@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> <20170405144309.3oc3lre7dozchhzu@nataraja> Message-ID: <20170405162607.GF3035@my.box> On Wed, Apr 05, 2017 at 04:43:09PM +0200, Harald Welte wrote: > Dear all, > > for egoistical reasons I'm in favor of a limit of 100 to 106 characters > only. Otherwise I can no longer fit three terminal windows next to each > other on a (these day standard minimum display width) of 1920, which > would be a major step back in terms of being able to look at multiple > source files simultaneously. Having the occasional bleed to a second line is not an option? I was hoping that all are fine with 120 to conclude this :) I've gotten used to a smaller font already and now have 119 chars of line estate in my two terminals alongside. If we go for ~106 I can go back to a larger font (where the i-dot is more than a single pixel) ... 106 is a kind of odd number to pick, but it's nearer to 120 than 100. Personally, I'm fine with odd numbers for good reasons. We could have 100 as the public "rule" to reduce the wtf-factor and use 106 as unwritten hard limit to reject patches on. So then, asking again: Would anyone veto/dislike an absolute max line width of 106 for all Osmocom projects? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tom at tsou.cc Wed Apr 5 17:59:59 2017 From: tom at tsou.cc (Tom Tsou) Date: Wed, 5 Apr 2017 10:59:59 -0700 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170405144309.3oc3lre7dozchhzu@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> <20170405144309.3oc3lre7dozchhzu@nataraja> Message-ID: On Wed, Apr 5, 2017 at 7:43 AM, Harald Welte wrote: > for egoistical reasons I'm in favor of a limit of 100 to 106 characters > only. Otherwise I can no longer fit three terminal windows next to each > other on a (these day standard minimum display width) of 1920, which > would be a major step back in terms of being able to look at multiple > source files simultaneously. With similar considerations, my maximum is 120 characters coming from two terminal windows at display width of 1920. If one cannot fit two windows of code side-by-side at such a resolution, then readability has suffered. -TT From laforge at gnumonks.org Wed Apr 5 18:54:31 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Apr 2017 20:54:31 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> <20170405144309.3oc3lre7dozchhzu@nataraja> Message-ID: <20170405185431.x4dcs2aepkdvumza@nataraja> Ok guys, let's go for 120 characters and have e-mails with more productive contents on this list again. I don't think there is a problem with old code following the old line length. After all, we're not changing anything but permittedline length. It's not really evena "style" change (like whether or not to have curly braces on new lines or on the same line). Also, general common sense applies: We do not accept patches that change the style from old to new line length. We merely write new code with longer lines, and [may] change those lines that we are editing in patches. I'll update the wiki accordingly. 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 pablo at gnumonks.org Thu Apr 6 15:35:38 2017 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 6 Apr 2017 17:35:38 +0200 Subject: [RFC] Coding Style: Longer Line Lengths? In-Reply-To: <20170405144309.3oc3lre7dozchhzu@nataraja> References: <20170401094517.5fstmuftbe457izq@nataraja> <20170405124324.GC3035@my.box> <20170405144309.3oc3lre7dozchhzu@nataraja> Message-ID: <20170406153517.GA4466@salvia> On Wed, Apr 05, 2017 at 04:43:09PM +0200, Harald Welte wrote: > Dear all, > > for egoistical reasons I'm in favor of a limit of 100 to 106 characters > only. Otherwise I can no longer fit three terminal windows next to each > other on a (these day standard minimum display width) of 1920, which > would be a major step back in terms of being able to look at multiple > source files simultaneously. If you update this, I would prefer 100 or so too. Unless you use very long function names, the only reason that I've seen for people to go over that boundary is a symptom of low quality code. I don't think asking for this is egoistical, it's a technical reason. Long lines are quality metric on code. From andreas.mueller at criticallabs.org Fri Apr 7 17:52:15 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Fri, 7 Apr 2017 19:52:15 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <20170403055032.GA3216@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> Message-ID: <20170407175215.GA31390@pocken.who.de> Hello, today the UMTS-USB-stick established a successfull IP-connection on the first attempt, but further attempts failed. When comparing packet-dumps of a successful and a failed connection-attempt and looking and the RANAP and GTP-packages I saw, that on the failed connection-attempts the UMTS-Stick is not authorized and on the successful attempt at first a location-update is made and then the authentification, which succeeds. Adding the command "AT+CREG" to wvdial.conf seems to solve the problem. Then I can see an "Routing Area Update Request" which is rejected then the authorization happens (Attach, Identity, Authentication) and the IP-connection is successfully established! Here is a working wvdial.conf for the huawei E1823: [Dialer Defaults] Init1 = AT^U2DIAG=0 Init2 = AT+CREG Init3 = ATZ Init4 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Init5 = AT+CGDCONT=1,"IP","web.blubb.xy" Modem Type = Analog Modem Baud = 9600 New PPPD = yes Modem = /dev/ttyUSB0 Stupid mode = 1 ISDN = 0 Phone = *99# Password = none Username = none It takes very long (>30 seconds) until ppp0 receives the IP-config but afterwards it is working with 6625 kBit/s down- and 580kBit/s upstream. greetings, Andreas From jsteiger at sysmocom.de Fri Apr 7 18:07:18 2017 From: jsteiger at sysmocom.de (Joachim Steiger) Date: Fri, 7 Apr 2017 20:07:18 +0200 Subject: weekly test report (w14 2017) Message-ID: <6271bc78-a512-7198-7671-684a431930f8@sysmocom.de> Hi, this is the BTS test report for week14 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G Most test cases have passed: sysmobts and nanobts worked without issue. the only one failing were with the octbts: the issues there were reliability of establishing a voicecall and or gprs. only every 2nd or 3rd attempt works. on the 3 TCH/H, 3 PDCH config gprs was not working at all with the ettus B200 everything worked but gprs seemed extremely slow or lossy. i could only view small testpages, big graphics do not load. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: bf7976c0b0076410ad1bd67061dd18d0f33a7f43 libosmocore: ff20641d9e3bb4373f9577c3382df1480ace4e91 libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: 2d92162a6b6720d72129bee1bcbef353b0fd0aa6 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: 6031734f448c6308d67b1ee464a13d60b33cd843 sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger 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: Harald Welte From laforge at gnumonks.org Sun Apr 9 19:38:29 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 Apr 2017 21:38:29 +0200 Subject: gerrit trouble "Change is New" Message-ID: <20170409193829.atlse55a5thg64ot@nataraja> I want to merge the patchset from my libosmo-sccp sigtran branch to master, but gerrit doesn't allow me to. I've re-pushed the patch set already multiple times, the last time also doing a minor cosmetic change to the commit log message of the first patch in the series (https://gerrit.osmocom.org/#/c/2191/). gerrit refuses to merge even that very first patch in the series with "change is new". What should I do to get this merged? -- - 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 Apr 10 06:49:58 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 Apr 2017 08:49:58 +0200 Subject: jenkins / Re: gerrit trouble "Change is New" In-Reply-To: <20170409193829.atlse55a5thg64ot@nataraja> References: <20170409193829.atlse55a5thg64ot@nataraja> Message-ID: <20170410064958.ldnmscafjhlpzwoq@nataraja> Hi all, it now gets even more mysterious: Some patches have failed in the most recent re-upload. See for example https://gerrit.osmocom.org/#/c/2215/5 which links to Gerrit http://jenkins.osmocom.org/jenkins/job/libosmo-sccp-gerrit/311/ but then that link is dead. Does anyone know what's happening here? Why is gerrit loosing information about t given build? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Apr 10 07:26:16 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 10 Apr 2017 15:26:16 +0800 Subject: jenkins / Re: gerrit trouble "Change is New" In-Reply-To: <20170410064958.ldnmscafjhlpzwoq@nataraja> References: <20170409193829.atlse55a5thg64ot@nataraja> <20170410064958.ldnmscafjhlpzwoq@nataraja> Message-ID: <31A9C282-B556-4BBA-B2C0-AFD46BBD5207@freyther.de> > On 10. Apr 2017, at 14:49, Harald Welte wrote: > > Hi all, Hey! > it now gets even more mysterious: I don't have an answer for the "Change is New" but this problem is "easy" to understand. > http://jenkins.osmocom.org/jenkins/job/libosmo-sccp-gerrit/311/ > but then that link is dead. > > Does anyone know what's happening here? Why is gerrit loosing > information about t given build? Jenkins is configured to only keep build logs for X days or Y amount of builds. In the libosmo-sccp-gerrit case X and Y are 30. Given from where I come from I am for putting a limit to the disk space used by build logs but 30 is obviously too small. I am changing it to 30 days and 120 logs for all gerrit logs. holger From laforge at gnumonks.org Mon Apr 10 09:57:36 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 Apr 2017 11:57:36 +0200 Subject: gerrit trouble "Change is New" In-Reply-To: <20170409193829.atlse55a5thg64ot@nataraja> References: <20170409193829.atlse55a5thg64ot@nataraja> Message-ID: <20170410095736.5d7g7f3yjuokg6yy@nataraja> Hi again, On Sun, Apr 09, 2017 at 09:38:29PM +0200, Harald Welte wrote: > I want to merge the patchset from my libosmo-sccp sigtran branch to > master, but gerrit doesn't allow me to. > > I've re-pushed the patch set already multiple times, the last time also > doing a minor cosmetic change to the commit log message of the first > patch in the series (https://gerrit.osmocom.org/#/c/2191/). > > gerrit refuses to merge even that very first patch in the series with > "change is new". It seems one neds to do a change in the actual source code as a work-around. I introduced an extra space somewhere in a comment, and the error is now gone. Not nice :/ I've hit again in this problem with https://gerrit.osmocom.org/#/c/2211/6 in my series, which I have now also re-submitted with a one-byte 'additional space'. Let's see if I can reproduce the result of above work-around. I hope we won't have to have introduce extra "gerrit spaces" in all our new code :/ 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 Apr 10 10:38:36 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 10 Apr 2017 12:38:36 +0200 Subject: gerrit trouble "Change is New" In-Reply-To: <20170410095736.5d7g7f3yjuokg6yy@nataraja> References: <20170409193829.atlse55a5thg64ot@nataraja> <20170410095736.5d7g7f3yjuokg6yy@nataraja> Message-ID: <7f706b7f-f759-3493-2c0f-b660096c2878@sysmocom.de> On 10.04.2017 11:57, Harald Welte wrote: > > I hope we won't have to have introduce extra "gerrit spaces" in all our > new code :/ > In case of patch series another workaround would be to re-arrange the sequence of patches bringing another patch to the "top" of the series. It's not much more meaningful than "gerrit spaces" but might be quicker/easier (at least that's the case with Emacs' magit :) -- 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 ron.menez at entropysolution.com Tue Apr 11 06:03:20 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 11 Apr 2017 06:03:20 +0000 Subject: Running osmo-trx and osmo-bts-trx Shows Errors Message-ID: Hi, We just finished installing the following osmo elements using Ubuntu 14.04 and the procedures from this link: https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_family https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source * libosmocore * libosmo-abis * libosmo-netif * openggsn * libosmo-sccp * openbsc * osmo-pcu * osmo-trx * osmo-bts We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx. We also installed the UHD driver of Ettus B2xx series using both ?apt-get install? process and binary process as well using this link: https://files.ettus.com/manual/page_install.html https://files.ettus.com/manual/page_build_guide.html But still, the same errors were received. Errors received: # osmo-trx [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-128-g379f922d 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 osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE # osmo-bts-trx -c /etc/osmo-bts.cfg ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading below line: fn-advance 20 Failed to parse the config file: '/etc/osmo-bts.cfg? What seems to cause this errors? What logs do we need to check? 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. -------------- 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 jsteiger at sysmocom.de Tue Apr 11 09:14:43 2017 From: jsteiger at sysmocom.de (Joachim Steiger) Date: Tue, 11 Apr 2017 11:14:43 +0200 Subject: Running osmo-trx and osmo-bts-trx Shows Errors In-Reply-To: References: Message-ID: <84ed027f-1d3b-fa28-f9fc-6d5e0dece066@sysmocom.de> hi, On 04/11/2017 08:03 AM, Ron wrote: [...] > We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx. > > We also installed the UHD driver of Ettus B2xx series using both ?apt-get install? process and binary process as well using this link: > https://files.ettus.com/manual/page_install.html > https://files.ettus.com/manual/page_build_guide.html > > But still, the same errors were received. [...] > osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE this points to some issue between the UHD libs, its headers and your build. did you compile osmo-trx/osmo-bts-trx yourself or did you use packages for installing it? > # osmo-bts-trx -c /etc/osmo-bts.cfg > ((*)) > | > / \ OsmoBTS > There is no such command. > Error occurred during reading below line: > fn-advance 20 > > Failed to parse the config file: '/etc/osmo-bts.cfg? this points to a problem with the config. could you paste(bin) it somewhere? kind regards -- - Joachim Steiger 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: Harald Welte From ron.menez at entropysolution.com Tue Apr 11 14:45:02 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 11 Apr 2017 14:45:02 +0000 Subject: Running osmo-trx and osmo-bts-trx Shows Errors In-Reply-To: <84ed027f-1d3b-fa28-f9fc-6d5e0dece066@sysmocom.de> References: <84ed027f-1d3b-fa28-f9fc-6d5e0dece066@sysmocom.de> Message-ID: <0B70DBC9-7B8B-4056-B76F-519583A2D7B9@entropysolution.com> Hi Joachim, Thank you for your immediate response. The osmo-trx and osmo-bts-trx was compiled. All checking has no errors received during compilation. The config file is taken from the URL below: https://osmocom.org/attachments/download/1919/osmo-bts.cfg Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:918bc6f0-c470-4b0d-bae8-dc0e389fd6f9 at apcprd06.prod.outlook.com] 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 11, 2017, at 5:14 PM, Joachim Steiger > wrote: hi, On 04/11/2017 08:03 AM, Ron wrote: [...] We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx. We also installed the UHD driver of Ettus B2xx series using both ?apt-get install? process and binary process as well using this link: https://files.ettus.com/manual/page_install.html https://files.ettus.com/manual/page_build_guide.html But still, the same errors were received. [...] osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE this points to some issue between the UHD libs, its headers and your build. did you compile osmo-trx/osmo-bts-trx yourself or did you use packages for installing it? # osmo-bts-trx -c /etc/osmo-bts.cfg ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading below line: fn-advance 20 Failed to parse the config file: '/etc/osmo-bts.cfg? this points to a problem with the config. could you paste(bin) it somewhere? kind regards -- - Joachim Steiger > 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: Harald Welte -------------- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 1414 bytes Desc: osmo-bts.cfg URL: From keith at rhizomatica.org Wed Apr 12 12:15:41 2017 From: keith at rhizomatica.org (Keith Whyte) Date: Wed, 12 Apr 2017 14:15:41 +0200 Subject: Running osmo-trx and osmo-bts-trx Shows Errors In-Reply-To: References: Message-ID: <97f7db37-afec-0edc-749b-262a03c5ae55@rhizomatica.org> On 11/04/17 08:03, Ron wrote: > > > # *osmo-bts-trx -c /etc/osmo-bts.cfg* > ((*)) > | > / \ OsmoBTS > There is no such command. > Error occurred during reading below line: > fn-advance 20 > > Failed to parse the config file: '/etc/osmo-bts.cfg? > > What seems to cause this errors? Hi Ron, the config file attached to this page https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_family is well out of date for the current osmo-bts Please try this: http://git.osmocom.org/osmo-bts/tree/doc/examples/trx/osmo-bts.cfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From changizy at icloud.com Wed Apr 12 11:57:52 2017 From: changizy at icloud.com (Bizhan Changizi) Date: Wed, 12 Apr 2017 16:27:52 +0430 Subject: OpenBSC Message-ID: <958F9884-3A75-4039-8E49-F1E861DA6F06@icloud.com> Dear Sipos Csaba Hi firstly my english languages is not good, and excuse me. i find Your contact info from blow link. http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html dear Sips i need to help to run OsmoNITB but i have a problem when compile the source. but i can?t resolve it, can you help me to to run OpenBSC plz, tnx. Problem : CC abis_om2000_vty.o CC abis_rsl.o CC bsc_rll.o CC paging.o CC bts_ericsson_rbs2000.o CC bts_ipaccess_nanobts.o In file included from bts_ipaccess_nanobts.c:39:0: /usr/local/include/osmocom/abis/ipaccess.h:7:8: error: redefinition of ?struct ipaccess_unit? struct ipaccess_unit { ^ In file included from bts_ipaccess_nanobts.c:38:0: /usr/local/include/osmocom/gsm/ipa.h:11:8: note: originally defined here struct ipaccess_unit { ^ make[3]: *** [bts_ipaccess_nanobts.o] Error 1 make[3]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src/libbsc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc' make: *** [all] Error 2 telecom at OpenBCS:~/osmo/src/osmonitb$ best regurds -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Apr 12 13:10:59 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Apr 2017 15:10:59 +0200 Subject: Running osmo-trx and osmo-bts-trx Shows Errors In-Reply-To: <97f7db37-afec-0edc-749b-262a03c5ae55@rhizomatica.org> References: <97f7db37-afec-0edc-749b-262a03c5ae55@rhizomatica.org> Message-ID: <20170412131059.x6s2zckbro34afv5@nataraja> On Wed, Apr 12, 2017 at 02:15:41PM +0200, Keith Whyte wrote: > Hi Ron, the config file attached to this page > https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_family > is well out of date for the current osmo-bts > > Please try this: > http://git.osmocom.org/osmo-bts/tree/doc/examples/trx/osmo-bts.cfg I've replaced it. I think in general it would be great if somebody could go through the wiki and remove such attachments (where possible) and simply reference the most current example config file from the respective git repository. Thanks! -- - 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 Sun Apr 16 17:40:44 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Apr 2017 19:40:44 +0200 Subject: Control interface introspection of FSMs Message-ID: <20170416174044.cehr246dma4kwqzt@nataraja> Good News, everyone [tm] Some may have already played with it: The osmo_fsm's already have gained a VTY interface (see http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time ago, which is nice for manual debugging and the like. However, for automatic testing one would normally want to do something like the following: 1) send a packet to the implementation under test (IUT) 2) then check if a given FSM has been created, a state has changed, a timer is running, etc. 3) go to '1' for the next packet, or wait for a timeout and then re-check, ... I've just introduced a generic CTRL interface for programmatic access to osmo_fsm. See https://gerrit.osmocom.org/#/c/2377 for details. The general idea is that you can send a CTRL command like GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is the identity of the instance (e.g. the IMSI of a subscriber in the VLR code). So in OsmoMSC, something like GET 1 fsm.vlr_lu_fsm.id.901700123456789.state would return the string name of the state for the location update FSM of the given IMSI, e.g. "VLR_ULA_S_WAIT_LU_COMPL_STANDALONE" I presume Neels will like this. Could be used from osmo-gsm-tester to not just do "black box testing" from MS to MS or MS to MNCC, but to actually verify individual states/transitions on all osmo_fsm enabled elements. It's of course questionable if an end-to-end test should care, but I can think of all kinds of other testing (particularly of my new SIGTRAN work) where it is absolutely useful. Once the above-mentioned patches are merged, applications with a control inteface will have this functionality enabled automatically. I think this makes osmo_fsm even more useful. I can imagine use cases not only related to testing, but also use cases of e.g. user interfaces or visualization. Regards, Harald p.s.: In German we say "self praise stinks", but I really think osmo_fsm is one of the best things happening to the Osmocom cellular projects in recent years. Now we just need to convert more code to use it. -- - 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 Sun Apr 16 17:27:07 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Apr 2017 19:27:07 +0200 Subject: Control Interface related testing Message-ID: <20170416172707.qgzngxiyat4lexaz@nataraja> Dear all, I have just submitted some patches which allow test cases to use the Control Interface internally, without binding to a TCP port. See https://gerrit.osmocom.org/#/c/2375/ and https://gerrit.osmocom.org/#/c/2376/ Using this, one can now write unit tests for control commands, without having to go for a multi-process setup with an external control client connected to the control TCP port (which is not easily possible in CI as the port might be used by another test case, ...) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From robert.steve07 at gmail.com Mon Apr 17 13:18:41 2017 From: robert.steve07 at gmail.com (robert) Date: Mon, 17 Apr 2017 16:18:41 +0300 Subject: OpenBSC TCH/H Message-ID: <43941858-CF6D-4640-B097-A4E51D5E2F31@gmail.com> Hello, I have set all the traffic channels to TCH/H and started the BTS but I was not able to perform a call. Is there something else that should be done ? Best regards, From laforge at gnumonks.org Mon Apr 17 14:07:57 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 17 Apr 2017 16:07:57 +0200 Subject: OpenBSC TCH/H In-Reply-To: <43941858-CF6D-4640-B097-A4E51D5E2F31@gmail.com> References: <43941858-CF6D-4640-B097-A4E51D5E2F31@gmail.com> Message-ID: <20170417140757.nur65hvuzhryhnfw@nataraja> On Mon, Apr 17, 2017 at 04:18:41PM +0300, robert wrote: > I have set all the traffic channels to TCH/H and started the BTS but I > was not able to perform a call. How does your setup look like? What kind of BTS? What is your codec configuration? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From root at spriteking.com Tue Apr 18 03:07:11 2017 From: root at spriteking.com (=?utf-8?B?cm9vdEDpm6rnoqc=?=) Date: Tue, 18 Apr 2017 11:07:11 +0800 Subject: nano3G Access Points Authorization Message-ID: 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? http://www.ipaccess.com/uploads/wysiwyg_editor/files/2017/S8_S16-Datasheet-v1.0.pdf Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Apr 19 10:59:30 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Apr 2017 12:59:30 +0200 Subject: UMTS-Stick on nano3G? In-Reply-To: <20170407175215.GA31390@pocken.who.de> References: <20170403055032.GA3216@pocken.who.de> <20170407175215.GA31390@pocken.who.de> Message-ID: <20170419105930.GA2390@ass40.sysmocom.de> I won't have time for some days, but this looks like someone should verify this. I'm still wondering why a "Routing Area Update Request" is rejected, so some clarification could also be good... And we should incorporate this information on our wiki; I see that it is mentioned on https://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5_--_andreas but at least when this is verified/clarified we should incorporate it in https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G Many thanks so far, Andreas! I also noticed from your Accelerate3g5 page that the getting started guide lacks the creation of the hlr.db. I added this to the main guide now (but used the new default db name of 'hlr.db'). ~N On Fri, Apr 07, 2017 at 07:52:15PM +0200, Andreas Mueller wrote: > Hello, > > today the UMTS-USB-stick established a successfull IP-connection on the first attempt, but further attempts failed. When comparing packet-dumps of a successful and a failed connection-attempt and looking and the RANAP and GTP-packages I saw, that on the failed connection-attempts the UMTS-Stick is not authorized and on the successful attempt at first a location-update is made and then the authentification, which succeeds. > Adding the command "AT+CREG" to wvdial.conf seems to solve the problem. Then I can see an "Routing Area Update Request" which is rejected then the authorization happens (Attach, Identity, Authentication) and the IP-connection is successfully established! > > Here is a working wvdial.conf for the huawei E1823: > > [Dialer Defaults] > Init1 = AT^U2DIAG=0 > Init2 = AT+CREG > Init3 = ATZ > Init4 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 > Init5 = AT+CGDCONT=1,"IP","web.blubb.xy" > Modem Type = Analog Modem > Baud = 9600 > New PPPD = yes > Modem = /dev/ttyUSB0 > Stupid mode = 1 > ISDN = 0 > Phone = *99# > Password = none > Username = none > > It takes very long (>30 seconds) until ppp0 receives the IP-config but afterwards it is working with 6625 kBit/s down- and 580kBit/s upstream. > > greetings, > > Andreas > -- - 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 Apr 19 11:30:05 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Apr 2017 13:30:05 +0200 Subject: gerrit trouble "Change is New" In-Reply-To: <20170409193829.atlse55a5thg64ot@nataraja> References: <20170409193829.atlse55a5thg64ot@nataraja> Message-ID: <20170419113005.GB2390@ass40.sysmocom.de> On Sun, Apr 09, 2017 at 09:38:29PM +0200, Harald Welte wrote: > I want to merge the patchset from my libosmo-sccp sigtran branch to > master, but gerrit doesn't allow me to. > > I've re-pushed the patch set already multiple times, the last time also > doing a minor cosmetic change to the commit log message of the first > patch in the series (https://gerrit.osmocom.org/#/c/2191/). > > gerrit refuses to merge even that very first patch in the series with > "change is new". I've had this problem for a very long time and have mailed here about it. Basically if you have a private branch based on current 'master', gerrit will fail to merge the same patches. As soon as 'master' has moved on so that your private branch is based on an older revision than master HEAD, the merge will work again. Because I have the admin rights to do so, I usually do a manual push to master instead. See also http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Merge-patch-to-master and https://bugs.chromium.org/p/gerrit/issues/detail?id=4158 which unfortunately hasn't concluded in a solution --- or so I thought! There has been activity on this ticket since I last looked at it, it seems they've actually fixed the problem in 2.12.6, yay! I will upgrade gerrit one of these days... ~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 Apr 19 11:59:03 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Apr 2017 13:59:03 +0200 Subject: OpenBSC In-Reply-To: <958F9884-3A75-4039-8E49-F1E861DA6F06@icloud.com> References: <958F9884-3A75-4039-8E49-F1E861DA6F06@icloud.com> Message-ID: <20170419115903.GD2390@ass40.sysmocom.de> Hi, you could try to use the nightly packages instead of building from source. Otherwise: is it possible that your checkout of libosmo-abis is really old? It seems that struct ipaccess_unit was moved to libosmocore in august 2014. Clear your system of all osmocom installations, 'git pull' all your git repositories to current master (or create entirely new clones to be sure) and rebuild from scratch. BTW, please don't address generic questions to individuals on this list, just mail to this list. ~N On Wed, Apr 12, 2017 at 04:27:52PM +0430, Bizhan Changizi wrote: > Dear Sipos Csaba > > Hi > firstly my english languages is not good, and excuse me. > i find Your contact info from blow link. > > http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html > > dear Sips i need to help to run OsmoNITB but i have a problem when compile the source. > but i can?t resolve it, can you help me to to run OpenBSC plz, tnx. > > Problem : > CC abis_om2000_vty.o > CC abis_rsl.o > CC bsc_rll.o > CC paging.o > CC bts_ericsson_rbs2000.o > CC bts_ipaccess_nanobts.o > In file included from bts_ipaccess_nanobts.c:39:0: > /usr/local/include/osmocom/abis/ipaccess.h:7:8: error: redefinition of ?struct ipaccess_unit? > struct ipaccess_unit { > ^ > In file included from bts_ipaccess_nanobts.c:38:0: > /usr/local/include/osmocom/gsm/ipa.h:11:8: note: originally defined here > struct ipaccess_unit { > ^ > make[3]: *** [bts_ipaccess_nanobts.o] Error 1 > make[3]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src/libbsc' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc' > make: *** [all] Error 2 > telecom at OpenBCS:~/osmo/src/osmonitb$ > > > best regurds -- - 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 Apr 19 12:14:33 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Apr 2017 14:14:33 +0200 Subject: Control interface introspection of FSMs In-Reply-To: <20170416174044.cehr246dma4kwqzt@nataraja> References: <20170416174044.cehr246dma4kwqzt@nataraja> Message-ID: <20170419121433.GE2390@ass40.sysmocom.de> On Sun, Apr 16, 2017 at 07:40:44PM +0200, Harald Welte wrote: > Good News, everyone [tm] > > Some may have already played with it: The osmo_fsm's already have gained > a VTY interface (see > http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time > ago, which is nice for manual debugging and the like. > > However, for automatic testing one would normally want to do something > like the following: > 1) send a packet to the implementation under test (IUT) > 2) then check if a given FSM has been created, a state has changed, > a timer is running, etc. > 3) go to '1' for the next packet, or wait for a timeout and then > re-check, ... > > I've just introduced a generic CTRL interface for programmatic access to > osmo_fsm. See https://gerrit.osmocom.org/#/c/2377 for details. > > The general idea is that you can send a CTRL command like > > GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state > GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer > GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name > GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump > > Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is > the identity of the instance (e.g. the IMSI of a subscriber in the VLR > code). > > So in OsmoMSC, something like > > GET 1 fsm.vlr_lu_fsm.id.901700123456789.state Nice! Could become useful once we move to OsmoMSC on the gsm tester (so far still the old/aging OsmoNITB without a VLR is run there). Currently the tester uses ctrl subscriber-list-active to verify attached-ness. Notably, FSMs like this one (vlr_lu_fsm) exist for a very limited amount of time. Once a LU is through (success or failure), the FSM instance is deallocated. A vlr_lu_fsm or parq_fsm will be active while an authentication is ongoing, e.g. if the OsmoHLR has not replied with an auth tuple yet. But during normal operation, FSMs will be gone quite quickly. The longest living one is the conn_fsm, it exists while a subscriber connection is active, so it may make sense to query it while a voice call is active. But it could be hard for a test case to catch even the conn_fsm before it is gone for things like sending an SMS or running a USSD. When a subscriber is attached but has no active connections, there are no FSM instances in the VLR, only a flag set in the vlr_subscriber struct. And furthermore, the FSM's id isn't always clear: it will use the mobile identity that came with the first request -- if e.g. a LU came in by previously known TMSI, and then the TMSI gets reallocated, the FSM will still use the old TMSI as identification. I had plans to update the id once things become known, also to improve log readability, but so far it's just using the first identity that comes up. ~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 Apr 19 13:39:33 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Apr 2017 15:39:33 +0200 Subject: nano3G Access Points Authorization In-Reply-To: References: Message-ID: <20170419133933.GF2390@ass40.sysmocom.de> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From renxianyuanqi at gmail.com Thu Apr 20 02:57:00 2017 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Thu, 20 Apr 2017 10:57:00 +0800 Subject: nano3G Access Points Authorization In-Reply-To: <20170419133933.GF2390@ass40.sysmocom.de> References: <20170419133933.GF2390@ass40.sysmocom.de> Message-ID: find the htpasswd passwdfile,method? 1.log in ip.access nano via ssh; 2.cd /var/www 3.ls -lah after that you can see .htpasswd 4.cat .htpasswd nano-admin:SO0umw******* femto-admin:gRWqmP****** developer:.QIQ0J******* new problem now: i don't the Encryption Algorithm,Still can?t certification pass. 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: From snehasish.cse at LIVE.COM Sat Apr 22 20:18:00 2017 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Sat, 22 Apr 2017 20:18:00 +0000 Subject: openbsc 3G supoort with octasic phy Message-ID: Hi I just wanted to know has anyone tried to use openbsc 3G with octasic 3G phy. BR Snehasish -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Apr 23 10:53:40 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 23 Apr 2017 12:53:40 +0200 Subject: openbsc 3G supoort with octasic phy In-Reply-To: References: Message-ID: <20170423105340.yngxh72q5vczl2wd@nataraja> Hi Snehasish, On Sat, Apr 22, 2017 at 08:18:00PM +0000, Snehasish Kar wrote: > I just wanted to know has anyone tried to use openbsc 3G with octasic 3G phy. This will not work. Osmocom has implemented the MSC, SGSN and HNB-GW components and expects an Iuh interface. Octasic provides a PHY interface. So you're missing the RLC/MAC and RRC protocol implementations in between, the RNC functionality and the eNodeB-side Iuh implementation. So basically a very large gap in between. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Apr 23 11:04:56 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 23 Apr 2017 13:04:56 +0200 Subject: Using repo to make 'regular' releases Message-ID: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> Hi, for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR). I could envision we have: * A simple build shell script to build/install everything * A script to update (and tag) the default.xml to make new releases available. How to use it (if repo is installed): repo init -u git://git.osmocom.org/osmocom-cellular-manifest repo sync ./build_all.sh --prefix=/opt/cellular aand on a new release repo sync ./build_all.sh ... ideas? comments? holger default.xml: From holger at freyther.de Sun Apr 23 11:06:29 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 23 Apr 2017 13:06:29 +0200 Subject: gerrit trouble "Change is New" In-Reply-To: <20170419113005.GB2390@ass40.sysmocom.de> References: <20170409193829.atlse55a5thg64ot@nataraja> <20170419113005.GB2390@ass40.sysmocom.de> Message-ID: > On 19. Apr 2017, at 13:30, Neels Hofmeyr wrote: > > --- or so I thought! There has been activity on this ticket since I last > looked at it, it seems they've actually fixed the problem in 2.12.6, yay! > > I will upgrade gerrit one of these days... the upgrade occurred yesterday. Please have a look at how it behaves. holger From nhofmeyr at sysmocom.de Sun Apr 23 12:54:21 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 23 Apr 2017 14:54:21 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> Message-ID: <20170423125421.GB2738@my.box> On Sun, Apr 23, 2017 at 01:04:56PM +0200, Holger Freyther wrote: > Hi, > > for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR). > > I could envision we have: > > * A simple build shell script to build/install everything > * A script to update (and tag) the default.xml to make new releases available. I like the central handle on dependencies, but I don't really like XML. Why not use the git submodules approach? Can't submodules tag specific revisions? ~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 Sun Apr 23 12:59:42 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 23 Apr 2017 14:59:42 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170423125421.GB2738@my.box> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423125421.GB2738@my.box> Message-ID: > On 23. Apr 2017, at 14:54, Neels Hofmeyr wrote: > > I like the central handle on dependencies, but I don't really like XML. Why not > use the git submodules approach? Can't submodules tag specific revisions? I have just seen repo used for Android and the Qualcomm MD9615 (Quectel EC2x) and it seemed to do quite well to clone/checkout/copy and later sync/update it. git submodule will probably work equally well. holger From laforge at gnumonks.org Sun Apr 23 13:02:48 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 23 Apr 2017 15:02:48 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> Message-ID: <20170423130248.bjzo6u2w73rlxi7q@nataraja> Hi Holger, On Sun, Apr 23, 2017 at 01:04:56PM +0200, Holger Freyther wrote: > for the topic of making "releases" I wondered if we want to explore > using "repo" to tie the different Osmocom repositories into a single > "release". Below is an example "default.xml" that would make up a > release. The default.xml would be maintained in a git repository that > we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR). I would still suggest that the "release" tags should also be made in all the individual repositories. Otherwise, while looking at git history in an individual repository during development/review, it is not obvious which patches are in which release or not. So having the specific 'git commit' IDs into repo and bypassing release tags inside the individual git repositories, you are taking this information out of the individual repositories. I don't generally think that's a good idea. So if at all, I believe 'repo' should refer to tags inside the inidvidual repositories [not sure at possible], or the repository-individual tags should be auto-generated in the same process when generating a new xml file in repo. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Apr 23 18:38:28 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 23 Apr 2017 20:38:28 +0200 Subject: FSM for lchan release handling -- release indication after SACCH deactivation timeout Message-ID: Good Evening, this is a bit of speculation but Keith showed me a trace with some network delay that makes a case for using FSM for the lchan itself. It seems the following can happen: * LU REJECT * Start Channel Release ** Send RR Release to the MS ** Deactivate SACCH ** Start Timer ... network transmission issues... at least 5s * SACCH deactivate timeout ** Start error release procedure.. ... * LATE RELEASE INDICATION arrives triggering other release procedure? So with a proper FSM we would have transitioned into the error path and would just ignore the RELEASE INDICATION. The question is if someone has budget to do a FSM transition here? I will try to build a simulated testcase for that. The other part that seems to happen (and I don't understand yet): * Allocating a lchan before it is fully freed?! * The BTS sending us RF Channel Releasse ACK twice cheers holger From snehasish.cse at LIVE.COM Mon Apr 24 05:16:57 2017 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Mon, 24 Apr 2017 05:16:57 +0000 Subject: openbsc 3G supoort with octasic phy In-Reply-To: <20170423105340.yngxh72q5vczl2wd@nataraja> References: , <20170423105340.yngxh72q5vczl2wd@nataraja> Message-ID: Hi, As per the API provided by Octasic we can handle the RLC/MAC and RRC protocols. So can you please help me with setting up a roadmap in interfacing octasic phy with openbsc3G. Also if we are able to create the interface, do we require programmable sims for testing or it we can be done with sims of any provider. BR Snehasish ________________________________ From: Harald Welte Sent: Sunday, April 23, 2017 4:23:40 PM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: openbsc 3G supoort with octasic phy Hi Snehasish, On Sat, Apr 22, 2017 at 08:18:00PM +0000, Snehasish Kar wrote: > I just wanted to know has anyone tried to use openbsc 3G with octasic 3G phy. This will not work. Osmocom has implemented the MSC, SGSN and HNB-GW components and expects an Iuh interface. Octasic provides a PHY interface. So you're missing the RLC/MAC and RRC protocol implementations in between, the RNC functionality and the eNodeB-side Iuh implementation. So basically a very large gap in between. -- - 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 pespin at sysmocom.de Mon Apr 24 09:32:23 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 24 Apr 2017 11:32:23 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423125421.GB2738@my.box> Message-ID: <52389db8-e96d-02eb-1499-76c7e53a0b68@sysmocom.de> Hi, > >> I like the central handle on dependencies, but I don't really like XML. Why not >> use the git submodules approach? Can't submodules tag specific revisions? > > I have just seen repo used for Android and the Qualcomm MD9615 (Quectel EC2x) and it seemed to do quite well to clone/checkout/copy and later sync/update it. git submodule will probably work equally well. I like the idea. I think repo is going to work better for this kind of stuff and also given the amount of git repositories we are handling. I would also use branches/tags inside the repo repository. For instance, branch "master" is mapped to all master branches from all git repositories, then branch "version1" points to specific versions or revisions. This way it can be used both for building/testing development + releases. It can be great too to use this repo repository to easily switch all git repositories to a given development branch. For instance, if we want to test 3g nowadays, we need to set most git repositories to branch "master, then repository A to branch X, repository B to branch Y, etc. By using repo, you just create a new branch "3G" modifying the xml to point to your git repository specific branch (default=>master, A=>X, B=>Y), and then everybody can easily test it by switching the repo repo to "3g" branch, then calling repo sync + build_all.sh What about using a Makefile instead of a build_all.sh script? We can ten perhaps paralelize some autoconf building between repositories which have no depndencies to speedup build/test time. -- - 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 holger at freyther.de Mon Apr 24 09:45:34 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 24 Apr 2017 11:45:34 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170423130248.bjzo6u2w73rlxi7q@nataraja> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423130248.bjzo6u2w73rlxi7q@nataraja> Message-ID: <95995AFE-6FF2-4A8F-B2AE-060351D98ADE@freyther.de> > On 23. Apr 2017, at 15:02, Harald Welte wrote: > > Hi Holger, > > I would still suggest that the "release" tags should also be made in all > the individual repositories. Otherwise, while looking at git history in > an individual repository during development/review, it is not obvious > which patches are in which release or not. I would like to be lazy but if the have pending SO_VERSION bumps we need to make a proper release (bump the version, update the debian package). Maybe to make it a bit more easy drop a version scheme like v1.2.3 and have a strictly monotonic increasing number like used for systemd/udev (and then still have v123.X for minor releases) or the date approach I mentioned before. > So if at all, I believe 'repo' should refer to tags inside the > inidvidual repositories [not sure at possible], or the > repository-individual tags should be auto-generated in the same process > when generating a new xml file in repo. If we go for date as version number we should be able to automate most of it and assist where manual work is needed (e.g. work on the TODO-RELEASE). holger From laforge at gnumonks.org Mon Apr 24 11:26:20 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 24 Apr 2017 13:26:20 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <95995AFE-6FF2-4A8F-B2AE-060351D98ADE@freyther.de> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423130248.bjzo6u2w73rlxi7q@nataraja> <95995AFE-6FF2-4A8F-B2AE-060351D98ADE@freyther.de> Message-ID: <20170424112620.sw43e75s2yyotfmm@nataraja> Hi Holger, On Mon, Apr 24, 2017 at 11:45:34AM +0200, Holger Freyther wrote: > > I would still suggest that the "release" tags should also be made in all > > the individual repositories. Otherwise, while looking at git history in > > an individual repository during development/review, it is not obvious > > which patches are in which release or not. > > I would like to be lazy but if the have pending SO_VERSION bumps we need > to make a proper release (bump the version, update the debian package). > Maybe to make it a bit more easy drop a version scheme like v1.2.3 and > have a strictly monotonic increasing number like used for systemd/udev > (and then still have v123.X for minor releases) or the date approach I > mentioned before. I don't mind what structure the actual version numbers take. > > So if at all, I believe 'repo' should refer to tags inside the > > inidvidual repositories [not sure at possible], or the > > repository-individual tags should be auto-generated in the same process > > when generating a new xml file in repo. > > If we go for date as version number we should be able to automate most > of it and assist where manual work is needed (e.g. work on the TODO-RELEASE). As indicated, the important part for me is to have tags in the individual repositories, and then use those tagged versions in the repo manifest. Beyond that, I'm open to whatever you guys think makes sense. -- - 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 Apr 24 12:28:09 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Apr 2017 14:28:09 +0200 Subject: osmocom-bb moved to gerrit Message-ID: <20170424122809.GA1050@my.box> The osmocom-bb git repository has now moved to gerrit. For patch submission to osmocom-bb, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit ~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 Tue Apr 25 06:21:41 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 25 Apr 2017 08:21:41 +0200 Subject: Video Recordings of OsmoCon 2017 Message-ID: <20170425062141.j2syfk6zyttlmv7w@nataraja> Hi all, the Osmocom Conference 2017 last week was an overwhelming success. We received lots of positive feedback from all sides. Thanks to all the speakers, to the attendees as well as to the anonymous sponsor of the travel grant funds. It is my great pleasure that due to the great support by C3VOC (The CCC Video Operation Center), we have full recordings of all talks given at OsmoCon 2017. You can find the videos on the C3VOC site at https://media.ccc.de/search/?q=osmocon They are also linked individually from the OsmoCon 2017 homepage at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017 I hope the video recordings will be of help for everyone who could not make it to the event in person. We will also be collecting the slides and put them up on the wiki during the next few days. Please don't hesitate to raise any feedback and/or questions. Technical feedback/questions regarding Osmocom software / projects should be addressed to the appropriate mailing lists, such as openbsc at lists.osmocom.org. Feedback to the organizers should be sent to osmocon2017 at sysmocom.de. Looking forward to the next OsmoCon, which we'll expect to be spanning ore than just a single day. 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 Tue Apr 25 11:37:04 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 25 Apr 2017 13:37:04 +0200 Subject: gerrit trouble "Change is New" In-Reply-To: References: <20170409193829.atlse55a5thg64ot@nataraja> <20170419113005.GB2390@ass40.sysmocom.de> Message-ID: <20170425113704.GC1753@ass40.sysmocom.de> On Sun, Apr 23, 2017 at 01:06:29PM +0200, Holger Freyther wrote: > > > On 19. Apr 2017, at 13:30, Neels Hofmeyr wrote: > > > > --- or so I thought! There has been activity on this ticket since I last > > looked at it, it seems they've actually fixed the problem in 2.12.6, yay! > > > > I will upgrade gerrit one of these days... > > > the upgrade occurred yesterday. Please have a look at how it behaves. I tested with the sandbox https://gerrit.osmocom.org/2402 and it seems to work now! Thanks!! Excellent, I've been looking forward to this for a long time :) ~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 Apr 25 11:45:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 25 Apr 2017 13:45:35 +0200 Subject: openbsc 3G supoort with octasic phy In-Reply-To: References: <20170423105340.yngxh72q5vczl2wd@nataraja> Message-ID: <20170425114535.GD1753@ass40.sysmocom.de> On Mon, Apr 24, 2017 at 05:16:57AM +0000, Snehasish Kar wrote: > Hi, > > > As per the API provided by Octasic we can handle the RLC/MAC and RRC protocols. So can you please help me with setting up a roadmap in interfacing octasic phy with openbsc3G. Also if we are able to create the interface, do we require programmable sims for testing or it we can be done with sims of any provider. Unless you have an RNC and the eNodeB-side Iuh, Osmocom 3G will not work for you. Apart from that you can use any USIM when you know its Ki and OP/C secrets and as long as the USIM uses the stock Milenage algorithm. ~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 Apr 25 13:40:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 25 Apr 2017 15:40:15 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170424112620.sw43e75s2yyotfmm@nataraja> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423130248.bjzo6u2w73rlxi7q@nataraja> <95995AFE-6FF2-4A8F-B2AE-060351D98ADE@freyther.de> <20170424112620.sw43e75s2yyotfmm@nataraja> Message-ID: <20170425134015.GE1753@ass40.sysmocom.de> Let me comment as well as recap the things discussed on OsmoDevCon: On Mon, Apr 24, 2017 at 01:26:20PM +0200, Harald Welte wrote: > I don't mind what structure the actual version numbers take. At OsmoDevCon as one of the very last items, we basically agreed for year+month style version numbering, and that we should not use just "Osmocom" for it, since Osmocom is much more than our core network + BSC (etc) infrastructure. The name floating around so far has been "Osmocom-Cellular". This makes a name and version scheme of e.g.: Osmocom-Cellular 17.04 Just now I notice that this would actually blur/confuse with the name of Open Cellular at least when abbreviated. Or maybe that's a good thing? Also Osmocom-BB is technically also part of "Cellular" but will not be part of what we plan to wrap in a release. (The plan is not to include *all* of the osmocom repositories in a release, right?) It occured to me that "osmo-net" or "osmo-network" or "OsmocomNetwork" (explicitly without the 'core') could be a good name for releases. What do you think about that? For example, we can call the releases: "osmocom-net-17.04" "osmocom-net-17.07" etc. In a separate discussion, we've also been looking for a name to replace "openbsc.git", to combine the MSC+BSC+SGSN+MGCPGW realms. The conclusion of *that* name discussion so far has been that we will instead try to split up into many smaller repositories: one for the MSC, one for the BSC, one for the SGSN... Does the Osmocom-Network name fit this? We should not use the name for both: the release also includes libosmocore, libosmo-*, osmo-bts, osmo-iuh, osmo-hlr, while the repository would have only been for MSC+BSC+SGSN+MGCPGW. So I would use the "Network" name for the release, and I would still go for separation of openbsc.git into smaller entities. To be contained in a release, RFC: libosmocore/ libosmo-abis/ libosmo-netif/ libosmo-sccp/ libsmpp34/ openggsn/ openbsc/ --> split as osmo-msc/ osmo-sgsn/? osmo-ps/? osmo-bsc/ osmo-hlr/ osmo-iuh/ osmo-bts/ osmo-pcu/ osmo-trx/ osmo-python-tests/ asn1c/ libasn1c/ sysmo-bts/layer1-api/ octphy-2g-headers/ osmo-gsm-manuals/ (Any additions or removals to this list?) What if a release turns out to contain a critical bug? The simplest way we would "resolve" that for now is to tell the users to revert to a release that works and wait for the next regular release. Nevertheless, it would be good to have a versioning scheme that allows for future changes in the release schedule without breaking the naming conventions. If we would like to tag several releases within a month, we could append a minor version like "osmocom-net-17.07.2". Should we add a ".0" by default? "osmocom-net-17.04.0"? Should we drop the leading zero from the month? "osmocom-net-17.4.0"? My personal choice for release names converges to: osmocom-net-17.6.0 osmocom-net-17.9.0 osmocom-net-17.12.0 osmocom-net-17.12.1 <-- critical bugfix release ("backed by funding") osmocom-net-18.3.0 Please comment on the naming -- the time window for permitted bike sheds is still open now. I suggest that we follow a regular release schedule of: at the beginning of March, June, September and December. (so that we don't need to roll a release during/right after the festive season, i.e. not on 1st January) More details on releases: We will so far provide simple tagging of an otherwise arbitrary state of the master branches -- the aim is merely to provide a common handle to users to be able to talk about the same "version" of our software, to allow using the same software state without the need to pass individual git hashes around. That means: - we will *not* maintain older releases with backports, - we will *not* do any special verifications of the working state of release X beyond the common sensical checks. - We *will* require a release to pass all stock 'make check' and 'make distcheck' (as we do for all our patches), - *and* we will require the osmo-gsm-tester setup to be in production before commencing releases (I'm on it), so that - we will require a release to pass the osmo-gsm-tester physical tests. If anyone is interested in maintenance of older releases or more extensive release management, you are a) free to do so and/or b) request such, backed by appropriate funding (for a longer term, probably). Our releases will be scheduled every three months for the time being. The individual git repositries will remain separate, and each will have their own version (maintained in signed git tags to be used for compatibility checks in autoconf). The release name should also be tagged in each of the individual git repositories (without interfering with 'git describe', i.e. non-signed non-annotated git tags, best prefixed by "release_" or "release/" to allow looking it up automatically?). The combined release repository (be it by repos or by git submodules) shall reference those release tags instead of individual commit hashes (basically to make sure we do have such tags in place). Upon invoking 'osmo-foo --version', we would ideally output both the individual 'git describe' version as well as the larger release version sort of like ? osmo-msc --version OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0) What if it's from a bleeding edge master, i.e. most-recent-release-tag != HEAD? ? osmo-msc --version OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0-dev) Or maybe rather a scheme combining both? like: OsmoMSC version 17.6.0-0.15.0.735-1759 Though the library version used for autoconf checks should not contain the release name -- so I would personally opt to keep these entirely separate, meaning that we would add a separate variable to the config.h (like $RELEASE) determined by a separate script. Loosely related and still open is the question of a scheme to effect version bumps of the individual projects. I had at some point started to do a tagged version bump for each API addition to e.g. libosmocore, but that was a lot of overhead (including adjusting configure.ac of dependent projects). It was somewhat agreed that we would collect significant API changes in the TODO_RELEASE text file and bump a version tag whenever a "new release (TM)" would be made ... but we never defined when we would do that nor how exactly. So, added bonus would be to resolve this question along with this discussion, alas it might blow up the bikeshed permutations... Naive question to clarify: if we have overall release tags, why exactly do we need individual release numbers for each subproject -- and then decide on a process to facilitate that need; I'm blanked out on its use at the moment. It seems to me we could completely replace individual project versions with the overall release ("17.6.0"), *if* we accept that non-changing projects would have several versions tagging exactly the same code state. The other way would be to bump the individual projects' versions upon each overall release, iff they have changes (at all? to their API?) since the last release. This would mean way more release work than just glorifying a given state of the master branch, but would make a lot of sense in the logic of a release process. The effort should hopefully be fine to do every 3 months, only. Your thoughts are welcome. Actual example implementations would also be welcome to provide a basis to work on. All in all we have agreed on various guidelines/facts but have not completely got a fix on the process and all the details yet. Please provide your feedback, and/but let's decide soon. ~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 Tue Apr 25 21:38:58 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 25 Apr 2017 23:38:58 +0200 Subject: openbsc 3G supoort with octasic phy In-Reply-To: References: <20170423105340.yngxh72q5vczl2wd@nataraja> Message-ID: <20170425213858.xe6foeptio4nv3hu@nataraja> Hi Snehasish, On Mon, Apr 24, 2017 at 05:16:57AM +0000, Snehasish Kar wrote: > As per the API provided by Octasic we can handle the RLC/MAC and RRC > protocols. This is probably not the right mailing list to discuss the features of a particular proprietary PHY/BTS implementation of a given vendor. But to the best of my knowledge - and that to my contacts inside Octasic R&D - they only provide the PHY interface and do not provide any RLC/MAC/RRC/RLC. > So can you please help me with setting up a roadmap in > interfacing octasic phy with openbsc3G. Your "RNC" part will need to implement an Iuh interface as specified by 3GPP. There's not really anything else to say about this. In case you are actually impleemnting that part, it would be great if you could follow our example and release it as Open Source. After all, this is about collaborative development that lives by contributions. > Also if we are able to create the interface, do we require > programmable sims for testing or it we can be done with sims of any > provider. This is a question completely unrelated to Osmocom, but something very fundamental about UMTS. The short answer is: You need to use your own SIM Cards. They don't need to be programmable, but you need the K/OPC programmed into them. 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 Apr 25 21:34:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 25 Apr 2017 23:34:45 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170425134015.GE1753@ass40.sysmocom.de> 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> Message-ID: <20170425213445.rv66lbdsqtffty5w@nataraja> Hi neels, On Tue, Apr 25, 2017 at 03:40:15PM +0200, Neels Hofmeyr wrote: > Let me comment as well as recap the things discussed on OsmoDevCon: thanks. > At OsmoDevCon as one of the very last items, we basically agreed for > year+month style version numbering, and that we should not use just > "Osmocom" for it, since Osmocom is much more than our core network > + BSC (etc) infrastructure. correct. > The name floating around so far has been "Osmocom-Cellular". > This makes a name and version scheme of e.g.: Alternatives: Osmocom-CellNet Osmo-CellNet or something like that. > Osmocom-Cellular 17.04 > > Just now I notice that this would actually blur/confuse with the name of > Open Cellular at least when abbreviated. Or maybe that's a good thing? I don't really think there's much confusion. But OsmoCellNet or variants of it would be OCN and thus not easily confused? > Also Osmocom-BB is technically also part of "Cellular" but will not be > part of what we plan to wrap in a release. (The plan is not to include > *all* of the osmocom repositories in a release, right?) No, OsmocomBB would not be part of it. CellNet might improve upon that, as most people probably would not intuitively consider the phone part of the network. An alternative is of course OsmoPLMN... but then, who knows what that is ;) > It occured to me that "osmo-net" or "osmo-network" or "OsmocomNetwork" > (explicitly without the 'core') could be a good name for releases. > What do you think about that? there are many types of network, and i think anything that narrows it further down to terrestrial cellular networks, possibly even hinting at 3GPP standards, would be useful IMHO. > In a separate discussion, we've also been looking for a name to replace > "openbsc.git", to combine the MSC+BSC+SGSN+MGCPGW realms. The conclusion > of *that* name discussion so far has been that we will instead try to > split up into many smaller repositories: one for the MSC, one for the BSC, > one for the SGSN... Does the Osmocom-Network name fit this? We should not > use the name for both: the release also includes libosmocore, libosmo-*, > osmo-bts, osmo-iuh, osmo-hlr, while the repository would have only been > for MSC+BSC+SGSN+MGCPGW. So I would use the "Network" name for the > release, and I would still go for separation of openbsc.git into smaller > entities. Correct. Osmocom-Network / OsmoCellNet includes also things like OsmoBTS and OsmoPCU, as well as any of the current programs of openbsc.git, osmo-hlr.git, etc. > To be contained in a release, RFC: > > libosmocore/ > libosmo-abis/ > libosmo-netif/ > libosmo-sccp/ > libsmpp34/ > openggsn/ > openbsc/ --> split as > osmo-msc/ > osmo-sgsn/? osmo-ps/? > osmo-bsc/ > osmo-hlr/ > osmo-iuh/ > osmo-bts/ > osmo-pcu/ > osmo-trx/ > > osmo-python-tests/ > > asn1c/ not sure if you need the asn1c as part of the release, given that the asn1c-generated code could be part of it, too? > (Any additions or removals to this list?) Not that I know of right now, but I guess we'll find out as we go ahead. > Nevertheless, it would be good to have a versioning scheme that allows for > future changes in the release schedule without breaking the naming > conventions. If we would like to tag several releases within a month, we > could append a minor version like "osmocom-net-17.07.2". Should we add a > ".0" by default? "osmocom-net-17.04.0"? Should we drop the leading zero > from the month? "osmocom-net-17.4.0"? I would keep the '0', simply because it seems more common in year.month based schemes like that of ubuntu. It's 16.04 and not 16.4. > I suggest that we follow a regular release schedule of: at the beginning > of March, June, September and December. (so that we don't need to roll a > release during/right after the festive season, i.e. not on 1st January) Sounds good. > - We *will* require a release to pass all stock 'make check' and 'make > distcheck' (as we do for all our patches), > - *and* we will require the osmo-gsm-tester setup to be in production > before commencing releases (I'm on it), so that > - we will require a release to pass the osmo-gsm-tester physical tests. ACK. > The individual git repositries will remain separate, and each will have > their own version (maintained in signed git tags to be used for > compatibility checks in autoconf). ACK. > Upon invoking 'osmo-foo --version', we would ideally output both the > individual 'git describe' version as well as the larger release version > sort of like ACK. > What if it's from a bleeding edge master, i.e. > most-recent-release-tag != HEAD? > > ? osmo-msc --version > OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0-dev) > > Or maybe rather a scheme combining both? like: > OsmoMSC version 17.6.0-0.15.0.735-1759 > > Though the library version used for autoconf checks should not contain the > release name -- so I would personally opt to keep these entirely separate, > meaning that we would add a separate variable to the config.h (like > $RELEASE) determined by a separate script. yes, makes most sense. PACKAGE_RELEASE along with the existing PACKAGE_VERSION > It seems to me we could completely replace individual project versions > with the overall release ("17.6.0"), *if* we accept that non-changing > projects would have several versions tagging exactly the same code > state. So far I really don't like that idea. It just feels wrong, somehow. I cannot really explain it. > The other way would be to bump the individual projects' versions upon each > overall release, iff they have changes (at all? to their API?) since the > last release. This would mean way more release work than just glorifying > a given state of the master branch, but would make a lot of sense in the > logic of a release process. The effort should hopefully be fine to do > every 3 months, only. Yes, I think at every time we make a release, we go through the TODO-RELEASE file and change the libversion accordingly, ... 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 pespin at sysmocom.de Wed Apr 26 08:07:08 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 26 Apr 2017 10:07:08 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170425213445.rv66lbdsqtffty5w@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> Message-ID: <2620b761-f3ad-b850-95f8-41640d97a358@sysmocom.de> Hi, > >> The name floating around so far has been "Osmocom-Cellular". >> This makes a name and version scheme of e.g.: > > Alternatives: > Osmocom-CellNet > Osmo-CellNet > I agree with Harald, adding the "net" part makes sense if we want to keep osmocombb out of it, "cellnet" sounds good. Not sure if adding a reference to "Infrastructure" could also make sense, such as "Osmo-CellInfra" or "Osmo-CellInfraNet". >> It was somewhat agreed that we would collect significant API >> changes in the TODO_RELEASE text file and bump a version tag whenever >> a "new release (TM)" would be made ... but we never defined when we >> would do that nor how exactly. As it may be difficult or tedious to sync/fetch the changes from different project repositories, we could have a wiki page with a list of new added features for each release, and when new stuff is pushed into a given project they could add an entry in the changelist for that project for the next release. > >> It seems to me we could completely replace individual project versions >> with the overall release ("17.6.0"), *if* we accept that non-changing >> projects would have several versions tagging exactly the same code >> state. > > So far I really don't like that idea. It just feels wrong, somehow. I > cannot really explain it. I have to say I'm not particularly against this idea from Neels. It would simplify a lot naming of the versions of all projects. -- - 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 msuraev at sysmocom.de Wed Apr 26 08:13:37 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 26 Apr 2017 10:13:37 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <2620b761-f3ad-b850-95f8-41640d97a358@sysmocom.de> 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> Message-ID: <2a5e5e8b-8b49-7d29-8c6b-bfc20313d878@sysmocom.de> I think it's really bad idea to have different versions pointing to the same commit: * it's extra headache for testing - we either have to figure out "duplicate" versions to avoid useless work or do meaningless testing * if while making point fix we forget about this duplicity we might end-up with 17.04.1 and 17.06.1 diverged while 17.04 and 17.06 were the same thing for particular component * it makes it impossible to mark any component-specific changes between global releases On 26.04.2017 10:07, Pau Espin Pedrol wrote: > >>> It seems to me we could completely replace individual project versions >>> with the overall release ("17.6.0"), *if* we accept that non-changing >>> projects would have several versions tagging exactly the same code >>> state. >> >> So far I really don't like that idea. It just feels wrong, somehow. I >> cannot really explain it. > > I have to say I'm not particularly against this idea from Neels. It would simplify > a lot naming of the versions of all projects. > > -- 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 Apr 26 13:13:06 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Wed, 26 Apr 2017 15:13:06 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <52389db8-e96d-02eb-1499-76c7e53a0b68@sysmocom.de> References: <8C24A1F9-7A5C-4535-87FB-368CB57AEDFC@freyther.de> <20170423125421.GB2738@my.box> <52389db8-e96d-02eb-1499-76c7e53a0b68@sysmocom.de> Message-ID: Hi, > I like the idea. I think repo is going to work better for this kind of stuff > and also given the amount of git repositories we are handling. Imho repo is the better choice compared to git submodule, which I so far only used in quite basic no-dependency projects to "bind"one common-ci repo. > I would also use branches/tags inside the repo repository. For instance, > branch "master" is mapped to all master branches from all git repositories, > then branch "version1" points to specific versions or revisions. This way it > can be used both for building/testing development + releases. I made a spike/hands-on [1] last night to get a better understanding of repo, because I so far only consumed/used it. The created "repo" clones all necessary repositories for the accelerate3g5 CN stack, but the default.xml manifest already holds all Osmocom-CellNet repositories mentioned in this thread. So one can already switch between "default" and "accelerate3g5" project as well as add new projects. My understanding is that we need branches/tags to use repo for several Osmocom-CellNet projects (not optional). That's why I created "accelerate3g5" branch where release (candidate) tags of actual git repositories can be tested and tagged as release (candidate) within the "accelerate3g5" repo branch. The tested/verified state within the accelerate3g5 branch will be then merged to the master and tagged as a release to detach its state from HEAD. > ...and then everybody can easily test it by switching the repo > repo to "3g" branch, then calling repo sync + build_all.sh Inspired by your post I added a script to build the accelerate3g5 CN stack to the repo repository, so one can build the entire stack with 3 lines: $ repo init -u https://github.com/blobbsen/repo-handson -m accelerate3g5.xml $ repo sync $ .repo/manifests/build_accelerate3g5.sh Note: should work on FreeBSD too (gmake/make topic) Probably worth discussing is the topic whether mentioned build script should live in the repo repository or in osmo-ci (if we agree to add osmo-ci)? Although, osmo-ci sounds like a good place I like the fact one can put those build scripts also in the repo repository itself. Perhaps an osmo-repo helper script, which holds some handy shortcuts ? la switchToProject, switchToBranch, because to switch branches or project one basically uses the three above mentioned lines again (cumbersome). > What about using a Makefile instead of a build_all.sh script? We can ten > perhaps paralelize some autoconf building between repositories which have no > depndencies to speedup build/test time. Interesting idea! :) What do you think about [1] in general? Cheers, Andr? [1] https://github.com/blobbsen/repo-handson From msuraev at sysmocom.de Wed Apr 26 13:52:29 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 26 Apr 2017 15:52:29 +0200 Subject: Thoughts on a next generation MIB/VTY replacement In-Reply-To: <20170309010823.pxefxd5ik2vre76p@nataraja> References: <20170309010823.pxefxd5ik2vre76p@nataraja> Message-ID: <0e7fe449-54c5-6c88-095e-d9cc0d311cbd@sysmocom.de> Hi. A little follow-up on this topic after OsmoDevCon. I've stumbled upon following project http://www.clicon.org/ >From a quick glance over their tutorial at http://www.clicon.org/clicon_tutorial.pdf it seems to fulfill almost all the properties discussed at OsmoDevCon: * autogeneration of cli and conf from single source * transactions support * both human-oriented cli and machine-oriented protocol from a single source Added bonus is that it's available under GPL (dual-license actually): https://github.com/clicon/clicon The only downside I see so far (besides the sheer amount of work for migration) is that this project is not widely used (yet?). Another thing I have not understood without digging further is how to apply some configs/commands in runtime without restarting the backend (OsmoBSC, OsmoMSC etc). All-in-all it seems like smth definitely worth looking into. -- 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 Wed Apr 26 14:07:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 26 Apr 2017 16:07:15 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <2a5e5e8b-8b49-7d29-8c6b-bfc20313d878@sysmocom.de> 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> Message-ID: <20170426140715.GA518@my.box> Looks like the opinions are converging quickly, very good. It's almost time to cast this into the release wiki page. On Tue, Apr 25, 2017 at 11:34:45PM +0200, Harald Welte wrote: > Osmocom-CellNet > Osmo-CellNet > > It occured to me that "osmo-net" or "osmo-network" or "OsmocomNetwork" > > there are many types of network, and i think anything that narrows it > further down to terrestrial cellular networks, possibly even hinting at > 3GPP standards, would be useful IMHO. +1 for CellNet with bike shed on word separation: Let's avoid mixed dash plus camel case. OsmocomCellNet osmocom-cell-net We tend to use the CamelCase in manuals and for project names, and the dashed version for git repositories. We also tend to use only "Osmo": OsmoCellNet osmo-cell-net I like shorter names (as long as they are still concise). OTOH it could make sense to mark the overall release with the full "Osmocom" instead, because it's not just a specific program. Personally I would be fine with either one: osmo-cell-net / OsmoCellNet or osmocom-cell-net / OsmocomCellNet { naming so far: git repos / osmo-gsm-manuals / redmine project name libosmocore / libosmocore / libosmocore openbsc / OsmoNITB / OsmoNITB openbsc / OsmoSGSN / OsmoSGSN osmo-hlr / OsmoHLR / OsmoHLR osmo-gsm-tester / OsmoGSMTester / OsmoGSMTester openbsc will soon become: osmo-msc / OsmoMSC / OsmoMSC osmo-ps (?) / OsmoSGSN / OsmoSGSN ... } > > To be contained in a release, RFC: > > > > libosmocore/ > > libosmo-abis/ > > libosmo-netif/ > > libosmo-sccp/ > > libsmpp34/ > > openggsn/ > > openbsc/ --> split as > > osmo-msc/ > > osmo-sgsn/? osmo-ps/? > > osmo-bsc/ > > osmo-hlr/ > > osmo-iuh/ > > osmo-bts/ > > osmo-pcu/ > > osmo-trx/ > > > > osmo-python-tests/ > > > > asn1c/ > > not sure if you need the asn1c as part of the release, given that the > asn1c-generated code could be part of it, too? That's right. For completeness sake we could include it, but we don't really expect changes to the asn.1. If the need arises, we can always add asn1c later. libasn1c though will be in the release (for 3G using osmo-iuh). > > (Any additions or removals to this list?) > Not that I know of right now, but I guess we'll find out as we go ahead. ack. > I would keep the '0', simply because it seems more common in year.month > based schemes like that of ubuntu. It's 16.04 and not 16.4. ok, fine with me. > > I suggest that we follow a regular release schedule of: at the beginning > > of March, June, September and December. (so that we don't need to roll a > > release during/right after the festive season, i.e. not on 1st January) > > Sounds good. > > > - We *will* require a release to pass all stock 'make check' and 'make > > distcheck' (as we do for all our patches), > > - *and* we will require the osmo-gsm-tester setup to be in production > > before commencing releases (I'm on it), so that > > - we will require a release to pass the osmo-gsm-tester physical tests. > > ACK. > > > The individual git repositries will remain separate, and each will have > > their own version (maintained in signed git tags to be used for > > compatibility checks in autoconf). > > ACK. > > > Upon invoking 'osmo-foo --version', we would ideally output both the > > individual 'git describe' version as well as the larger release version > > sort of like > > ACK. > > > What if it's from a bleeding edge master, i.e. > > most-recent-release-tag != HEAD? > > > > ? osmo-msc --version > > OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0-dev) > > > > Or maybe rather a scheme combining both? like: > > OsmoMSC version 17.6.0-0.15.0.735-1759 > > > > Though the library version used for autoconf checks should not contain the > > release name -- so I would personally opt to keep these entirely separate, > > meaning that we would add a separate variable to the config.h (like > > $RELEASE) determined by a separate script. > > yes, makes most sense. PACKAGE_RELEASE along with the existing > PACKAGE_VERSION > > > It seems to me we could completely replace individual project versions > > with the overall release ("17.6.0"), *if* we accept that non-changing > > projects would have several versions tagging exactly the same code > > state. > > So far I really don't like that idea. It just feels wrong, somehow. I > cannot really explain it. So far I notice that it feels wrong because it doesn't really match the semantics 1:1; now Max has found clear terms for the feeling: > I think it's really bad idea to have different versions pointing to the same commit: > * it's extra headache for testing - we either have to figure out "duplicate" versions > to avoid useless work or do meaningless testing > * if while making point fix we forget about this duplicity we might end-up with > 17.04.1 and 17.06.1 diverged while 17.04 and 17.06 were the same thing for particular > component > * it makes it impossible to mark any component-specific changes between global releases An intermediate version tag of a subproject would interfere with the OsmoCellNet release numbers also used in other subprojects as well as the overall release, a minefield for various confusions. > > The other way would be to [...] > every time we make a release, we go through the > TODO-RELEASE file and change the libversion accordingly, ... +1 pespin wrote: > As it may be difficult or tedious to sync/fetch the changes from different > project repositories, we could have a wiki page with a list of new added > features for each release, and when new stuff is pushed into a given project > they could add an entry in the changelist for that project for the next > release. I think we should stay with the TODO-RELEASE files in each subproject -- it is in the same place where the changes get committed and allows including these in feature branches. We need to bump individual project versions anyway for a release, so we need to look at each individual TODO-RELEASE file anyway. We could/should even scriptify the release process as much as possible, e.g. from the osmo-cell-net overall repository, which could fetch the separate TODO-RELEASE contents automatically. ~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 Apr 26 15:56:54 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 26 Apr 2017 17:56:54 +0200 Subject: osmo-stp / nightly builds Message-ID: <20170426155654.GC518@my.box> Just asked holger: the osmo-stp build from cellmgr in the nightly debian packages can be switched off. Since you've been fixing debian these days, could you do that one as well? Hopefully we will have no more failures then. (...except on the new ubuntu 17.04 of course, no idea what's up with that. Not sure who added it and who will resolve those, or whether that's already done?) 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 laforge at gnumonks.org Wed Apr 26 22:35:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 27 Apr 2017 00:35:38 +0200 Subject: Using repo to make 'regular' releases In-Reply-To: <20170426140715.GA518@my.box> 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> Message-ID: <20170426223538.pwcdr5k6atogocft@nataraja> Hi Neels, On Wed, Apr 26, 2017 at 04:07:15PM +0200, Neels Hofmeyr wrote: > We tend to use the CamelCase in manuals and for project names, and the dashed > version for git repositories. We also tend to use only "Osmo": actually, it's mostly the dashed version for the executables, and then the git repo follows that. > OsmoCellNet > osmo-cell-net > > I like shorter names (as long as they are still concise). OTOH it could make > sense to mark the overall release with the full "Osmocom" instead, because it's > not just a specific program. I also like the shorter names. However, we already have the Osmocom trademark in US and EU, and it might make sense to reflect that in naming, should the need ever arise to defend against a copycat or some other misrepresentation of the project and/or its software. > Personally I would be fine with either one: > > osmo-cell-net / OsmoCellNet > > or > > osmocom-cell-net / OsmocomCellNet my vote goes for the latter, due to above reasoning. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From junaid.uppal at outlook.com Wed Apr 26 12:14:44 2017 From: junaid.uppal at outlook.com (Junaid Saeed Uppal) Date: Wed, 26 Apr 2017 12:14:44 +0000 Subject: ip.access nano3G Help Message-ID: Hi, I am trying to setup the 3G Project and have bought a used nano3G BTS (S8 - Model 237A) . The problem i am facing is that the telnet port is not open. I have tried to reset the device using the pin-hole reset button as per documentation but it still doesn't open up the ports and still tries to lookup operator's NTP and tries to establish a IPSEC tunnel. Any pointers on how i can reset this so that I can get it to work with the project? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Apr 27 07:30:17 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 27 Apr 2017 09:30:17 +0200 Subject: ip.access nano3G Help In-Reply-To: References: Message-ID: <20170427073017.exazvnmjcmm3woyc@nataraja> Hi Junaid, On Wed, Apr 26, 2017 at 12:14:44PM +0000, Junaid Saeed Uppal wrote: > I am trying to setup the 3G Project and have bought a used nano3G BTS (S8 - Model 237A) . > > The problem i am facing is that the telnet port is not open. I have > tried to reset the device using the pin-hole reset button as per > documentation but it still doesn't open up the ports and still tries > to lookup operator's NTP and tries to establish a IPSEC tunnel. The problem you're facing is that you might have bought the device, but you still don't "own" it. Femtocells are unfortunately often quite locked down. > Any pointers on how i can reset this so that I can get it to work with the project? I'm not sure if we are able to help with that, sorry. -- - 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 Thu Apr 27 08:26:50 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 27 Apr 2017 10:26:50 +0200 Subject: osmo-stp / nightly builds In-Reply-To: <20170426155654.GC518@my.box> References: <20170426155654.GC518@my.box> Message-ID: On 26.04.2017 17:56, Neels Hofmeyr wrote: > Just asked holger: the osmo-stp build from cellmgr in the nightly debian > packages can be switched off. Since you've been fixing debian these days, could > you do that one as well? Hopefully we will have no more failures then. There's no option to "switch off" package - at least I don't see it. I can delete it though if that's ok. > (...except on the new ubuntu 17.04 of course, no idea what's up with that. Not > sure who added it and who will resolve those, or whether that's already done?) I've added it - this helped to highlight couple of bugs in packaging. Fixes are in gerrit already. -- 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 holger at freyther.de Thu Apr 27 08:34:58 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 27 Apr 2017 10:34:58 +0200 Subject: osmo-stp / nightly builds In-Reply-To: References: <20170426155654.GC518@my.box> Message-ID: <464A83BF-385D-4C9B-8027-24CA16C50BD1@freyther.de> > On 27. Apr 2017, at 10:26, Max wrote: > > On 26.04.2017 17:56, Neels Hofmeyr wrote: >> Just asked holger: the osmo-stp build from cellmgr in the nightly debian >> packages can be switched off. Since you've been fixing debian these days, could >> you do that one as well? Hopefully we will have no more failures then. > > There's no option to "switch off" package - at least I don't see it. I can delete it > though if that's ok. per project you can set repositories and per package you can block some of them From ron.menez at entropysolution.com Thu Apr 27 09:06:08 2017 From: ron.menez at entropysolution.com (Ron) Date: Thu, 27 Apr 2017 09:06:08 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) Message-ID: Hi All, Upon running "osmo-bts-trx -c osmo-bts.cfg? while "osmo-nitb -C -c openbsc.conf -T -P -m? and ?osmo-trx? are running, the following error shows and also shuts down ?osmo-trx? osmo-bts-trx error: root at entropy:~/osmocom_files# osmo-bts-trx -c osmo-bts.cfg ((*)) | / \ OsmoBTS <0017> control_if.c:725 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:95 telnet at 127.0.0.1 4241 <0012> input/ipaccess.c:885 enabling ipaccess BTS mode, OML connecting to 192.168.1.129:3002 <000b> trx_if.c:584 Open transceiver for phy0.0 <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:706 received ID get <0001> oml.c:475 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:844 ADM state already was Unlocked <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:706 received ID get <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <000b> trx_if.c:187 No response from transceiver for phy0.0 <0009> pcu_sock.c:848 PCU socket connected to external PCU <0001> oml.c:72 Reporting FAILURE to BSC: 0.3.20170425 <0000> rsl.c:624 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <0007> l1sap.c:413 Invalid condition detected: Frame difference is > 1! <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=4,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=5,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=6,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=7,ss=0) not sending REL ACK Shutdown timer expired osmo-trx logs: NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:243:start: Starting the transceiver Illegal instruction (core dumped) osmo-nitb logs: Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3002 Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3003 Thu Apr 27 16:50:43 2017 <0004> bsc_init.c:288 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 885 using MCC=1 MNC=1 LAC=1 CID=1 BSIC=63 BTS 0 reported connected PCU version 0.3.20170425 Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:241 Sign link vanished, dead socket Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:69 Forcing socket shutdown with no signal link set Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 1 0x7f5f48820070 Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 2 0x7f5f48820070 ^Csignal 2 received Also attached the configuration files used. What seems causes the issue? OS: Ubuntu 16.04 SDR: B210 Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:bbb8aa9b-ea08-431b-bb55-8cc77a18e169 at apcprd06.prod.outlook.com] 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. -------------- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 628 bytes Desc: osmo-bts.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.conf Type: application/octet-stream Size: 4216 bytes Desc: openbsc.conf URL: From msuraev at sysmocom.de Thu Apr 27 10:08:27 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 27 Apr 2017 12:08:27 +0200 Subject: osmo-stp / nightly builds In-Reply-To: <464A83BF-385D-4C9B-8027-24CA16C50BD1@freyther.de> References: <20170426155654.GC518@my.box> <464A83BF-385D-4C9B-8027-24CA16C50BD1@freyther.de> Message-ID: <080c943e-8116-f346-9aee-214e9f293092@sysmocom.de> Thanks, disabled all via repositories tab. It gave me 500 Internal error before - seems like OBS is overloaded ATM. On 27.04.2017 10:34, Holger Freyther wrote: >> On 27. Apr 2017, at 10:26, Max wrote: >> >> On 26.04.2017 17:56, Neels Hofmeyr wrote: >>> Just asked holger: the osmo-stp build from cellmgr in the nightly debian >>> packages can be switched off. Since you've been fixing debian these days, could >>> you do that one as well? Hopefully we will have no more failures then. >> There's no option to "switch off" package - at least I don't see it. I can delete it >> though if that's ok. > > per project you can set repositories and per package you can block some of them > > -- 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 junaid.uppal at outlook.com Thu Apr 27 04:03:56 2017 From: junaid.uppal at outlook.com (Junaid Saeed Uppal) Date: Thu, 27 Apr 2017 04:03:56 +0000 Subject: nano3G S8 Help Message-ID: ##Resending again as the previous message didn't make it to the list. Hi, I am trying to setup the 3G Project and have bought a used nano3G BTS (S8 - Model 237A) . The problem i am facing is that the telnet port is not open. I have tried to reset the device using the pin-hole reset button as per documentation but it still doesn't reset or open up the ports and still tries to lookup operator's NTP and tries to establish a IPSEC tunnel. Any pointers on how i can reset this so that I can get it to work with the project? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Thu Apr 27 16:42:26 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 27 Apr 2017 18:42:26 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: References: Message-ID: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> > On 27. Apr 2017, at 11:06, Ron wrote: > > NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 > > NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:243:start: Starting the transceiver > > Illegal instruction (core dumped) > So osmo-trx quits because it asked the CPU to execute something that is either no instruction or not supported by your CPU. Are you using the binary packages? holger From ron.menez at entropysolution.com Thu Apr 27 18:10:53 2017 From: ron.menez at entropysolution.com (Ron) Date: Thu, 27 Apr 2017 18:10:53 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> Message-ID: <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> Hi Holger, Thank you for your immediate response. We are using the nightly package for this. Thank you. 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 28, 2017, at 12:42 AM, Holger Freyther > wrote: On 27. Apr 2017, at 11:06, Ron > wrote: NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:243:start: Starting the transceiver Illegal instruction (core dumped) So osmo-trx quits because it asked the CPU to execute something that is either no instruction or not supported by your CPU. Are you using the binary packages? 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 Thu Apr 27 19:12:08 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 27 Apr 2017 21:12:08 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> Message-ID: <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> > On 27. Apr 2017, at 20:10, Ron wrote: > > Hi Holger, > > Thank you for your immediate response. > > We are using the nightly package for this. Could you send us your output of cat /proc/cpuinfo as well. The issue is most likely that while building the package it was optimized for a CPU instruction set not supported by your system. There are some patches pending review[1] to improve/solve this situation. holger [1] https://gerrit.osmocom.org/#/c/2100/ From ron.menez at entropysolution.com Fri Apr 28 01:44:50 2017 From: ron.menez at entropysolution.com (Ron) Date: Fri, 28 Apr 2017 01:44:50 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> References: <542E63FF-CFB7-4884-A1F0-BF616FFF92EC@freyther.de> <61AFCDFE-272C-4CD8-86B3-DAA7B701C78E@entropysolution.com> <527EBB8D-6F83-4467-9B2A-57CB172CFF88@freyther.de> Message-ID: <90CC6794-CCF6-4251-B3E9-EB501C9C6340@entropysolution.com> Hi Holger, Below is the output for the cat /proc/cpuinfo: root at entropy:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3473.539 cache size : 6144 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3461.656 cache size : 6144 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3487.859 cache size : 6144 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3334.093 cache size : 6144 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3444.085 cache size : 6144 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3433.320 cache size : 6144 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 6 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3344.960 cache size : 6144 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0x8a cpu MHz : 3390.968 cache size : 6144 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes 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 bugs : bogomips : 5184.47 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: 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 28, 2017, at 3:12 AM, Holger Freyther > wrote: On 27. Apr 2017, at 20:10, Ron > wrote: Hi Holger, Thank you for your immediate response. We are using the nightly package for this. Could you send us your output of cat /proc/cpuinfo as well. The issue is most likely that while building the package it was optimized for a CPU instruction set not supported by your system. There are some patches pending review[1] to improve/solve this situation. holger [1] https://gerrit.osmocom.org/#/c/2100/ -------------- 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 Fri Apr 28 21:22:41 2017 From: holger at freyther.de (Holger Freyther) Date: Fri, 28 Apr 2017 23:22:41 +0200 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <90CC6794-CCF6-4251-B3E9-EB501C9C6340@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> Message-ID: <40B6960C-740B-4510-90A7-776C20C79BB0@freyther.de> > 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? From ron.menez at entropysolution.com Sat Apr 29 02:41:57 2017 From: ron.menez at entropysolution.com (Ron) Date: Sat, 29 Apr 2017 02:41:57 +0000 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <40B6960C-740B-4510-90A7-776C20C79BB0@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> Message-ID: 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 [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 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 tom at tsou.cc Sat Apr 29 03:24:00 2017 From: tom at tsou.cc (Tom Tsou) Date: Sat, 29 Apr 2017 11:24:00 +0800 Subject: osmo-bts-trx error / osmo-trx illegal instruction (core dumped) In-Reply-To: <40B6960C-740B-4510-90A7-776C20C79BB0@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> Message-ID: 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. -TT From andreas.mueller at criticallabs.org Sat Apr 29 10:28:10 2017 From: andreas.mueller at criticallabs.org (Andreas Mueller) Date: Sat, 29 Apr 2017 12:28:10 +0200 Subject: nano3G <-> sip-connector <-> asterisk? Message-ID: <20170429102810.GA12407@pocken.who.de> 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. have a nice weekend, Andreas From axilirator at gmail.com Sat Apr 29 14:09:57 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 29 Apr 2017 21:09:57 +0700 Subject: autoreconf: "header not found" in generated source Message-ID: Hi all, I am currently working on https://gerrit.osmocom.org/#/c/2075/ The problem is that the conv.h should be shared between several source code files, and it works fine for all of them, excepting the gsm0503_test_vectors.c, which will be generated automatically by the utils/conv_gen.py in the next commit. The header is currently included this way: #include "conv.h" And building in separate directory fails: CC conv/gsm0503_test_vectors.o conv/gsm0503_test_vectors.c:25:18: fatal error: conv.h: No such file or directory #include "conv.h" ^ compilation terminated. This is why I tried to move this header to the global include directory. According to received feedback from Harald and Sylvain, this approach isn't good and I need to find another one. Any suggestions how to make the conv/gsm0503_test_vectors.c able "to see" the conv.h header? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Apr 30 07:47:04 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 30 Apr 2017 09:47:04 +0200 Subject: autoreconf: "header not found" in generated source In-Reply-To: References: Message-ID: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> > On 29. Apr 2017, at 16:09, Vadim Yanitskiy wrote: > > Hi all, > > Hi! > conv/gsm0503_test_vectors.c:25:18: fatal error: > conv.h: No such file or directory > #include "conv.h" > ^ > compilation terminated. > > This is why I tried to move this header to the global include > directory. According to received feedback from Harald and > Sylvain, this approach isn't good and I need to find another one. > > Any suggestions how to make the conv/gsm0503_test_vectors.c > able "to see" the conv.h header? I didn't see this error in the jenkins log. But two things are likely: * gsm0503_test_vectors.c is compiled before the header is generated (though unlikely here) * build dir != src dir. So the "conv.h" is not in the srcdir but the builddir? holger From axilirator at gmail.com Sun Apr 30 08:02:58 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 30 Apr 2017 15:02:58 +0700 Subject: autoreconf: "header not found" in generated source In-Reply-To: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> Message-ID: Thanks for response! I didn't see this error in the jenkins log. But two things are likely: > > * gsm0503_test_vectors.c is compiled before the header is generated > (though unlikely here) > > * build dir != src dir. So the "conv.h" is not in the srcdir but the > builddir? It seems, I already found one solution. You're right, "build dir != src dir" was the problem, so I added this: conv_conv_gsm0503_test_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I$(top_srcdir)/tests/conv And now everything is fine! With best regards, Vadim Yanitskiy. 2017-04-30 14:47 GMT+07:00 Holger Freyther : > > > On 29. Apr 2017, at 16:09, Vadim Yanitskiy wrote: > > > > Hi all, > > > > > > Hi! > > > conv/gsm0503_test_vectors.c:25:18: fatal error: > > conv.h: No such file or directory > > #include "conv.h" > > ^ > > compilation terminated. > > > > This is why I tried to move this header to the global include > > directory. According to received feedback from Harald and > > Sylvain, this approach isn't good and I need to find another one. > > > > Any suggestions how to make the conv/gsm0503_test_vectors.c > > able "to see" the conv.h header? > > I didn't see this error in the jenkins log. But two things are likely: > > * gsm0503_test_vectors.c is compiled before the header is generated > (though unlikely here) > > * build dir != src dir. So the "conv.h" is not in the srcdir but the > builddir? > > holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sitrix at camheds.net Sun Apr 30 11:26:59 2017 From: sitrix at camheds.net (Nikolya) Date: Sun, 30 Apr 2017 14:26:59 +0300 Subject: Accelerate3g5 femto-cell configuration Message-ID: Hello It may not be an appropriate mail-list to ask questions about OsmoBTS inside femto-cell of Accelerate3g5 "promo", but i need some directions. I undestand that i need to build OpenBSC (OpenNITM), so that femto-cell start "working" . But i can't find any documentation regarding how to configure OsmoBTS inside femto-cell . I knew root account password for the cell, but didn't find passwords resting in [root at ip302ff:~#]cat /var/www/.htpasswd nano-admin:SO0umwXJnpBjo femto-admin:gRWqmPZknka4g developer:.QIQ0JPRQ3PKA [root at ip302ff:~#] so i just move this file aside and access http://cell-ip:8089/ cgi-bin/connection_config.cgi . It giving this HTML
$ curl http://cell-ip:8089/cgi-bin/connection_config.cgi



  
  ip.access 3G AP Web-if
  







3G AP

Serial Number:

Sorry - couldn't find '/cgi-bin/connection_config.cgi' page here.
Server name: ip302ff
PathTranslated:
PathInfo:
$
one of the URLs that work is http://cell-ip:8089/cgi-bin/swversion.cgi , which giving
Serial Number:
Firmware Version Information
Flash Contents

Kernel Bank 1:  xc-220.3.0
Kernel Bank 2:  xc-225.2.0
Filesystem Bank 1:      EMPTY
Filesystem Bank 2:      579.26.7
Default Filesystem:     ## Error: "rootdev" not defined sh: 5: unknown
operand sh: 6: unknown operand
Default OS:     ## Error: "kernel_flash_addr" not defined sh: 0x20080000:
unknown operand sh: 0x20280000: unknown operand
Booted version:

Bootloader version:
OS version:     xc-225.2.0 #1 PREEMPT Thu Jul 11 17:54:07 BST 2013
Filesystem version:     579.26.7
Detailed List:

etc
There are open TCP ports on femto-cell ip 22,8089,8090,10002 . One of them 8090, when telnet to it, it providing some "vty"
dmi> help
SYNTAX : help [cmd]|[attribute_id_list]
    where cmd is one of
    quit
    q
    call
    wait
    get
    set
    action
    alarm
    getobj
    restore
    regatt
    deregatt
    regact
    deregact
    dmidata
    endscript
    exitscript
    history
    buildco
    print
    help
dmi>
But it doesn't look like VTY that documented in http://ftp.osmocom.org/docs/latest/osmobts-usermanual.pdf I may need to build linux for femto-cell by myself, but need some help of how to build and write builded image to femto-cell --- WBR Nikolay -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Apr 30 18:21:00 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 30 Apr 2017 20:21:00 +0200 Subject: Accelerate3g5 femto-cell configuration In-Reply-To: References: Message-ID: <20170430182100.tntnwfbmcji7qgzn@nataraja> Hi Nikolya, On Sun, Apr 30, 2017 at 02:26:59PM +0300, Nikolya wrote: > It may not be an appropriate mail-list to ask questions about OsmoBTS inside > femto-cell of Accelerate3g5 "promo", but i need some directions. This list is the right place. > I undestand that i need to build OpenBSC (OpenNITM), so that femto-cell > start "working" . Where have you found any references to OsmoNITB for running a 3G network? Pleaes let us know, because we must make sure that there is no misleading information in our wiki, manuals or other documentation. Please follow the instructions indicated at https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G > But i can't find any documentation regarding how to > configure OsmoBTS inside femto-cell . There is no OsmoBTS on a 3G/3.5G femtocell, as there is no BTS in 3G/3.5G networks. A BTS only exists in 2G/2.5G/2.75G (GSM/GPRS/EDGE). 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 holger at freyther.de Sun Apr 30 19:56:45 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 30 Apr 2017 21:56:45 +0200 Subject: autoreconf: "header not found" in generated source In-Reply-To: References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> Message-ID: > On 30. Apr 2017, at 10:02, Vadim Yanitskiy wrote: > > It seems, I already found one solution. You're right, "build dir != src dir" > was the problem, so I added this: > > conv_conv_gsm0503_test_CPPFLAGS = \ > $(AM_CPPFLAGS) \ > -I$(top_srcdir)/tests/conv > > And now everything is fine! We generate "conv.h" and put it into the source directory? From 10.000 miles aways it sounds a bit odd (at least for checkout from git, make dist would be a different topic). holger From axilirator at gmail.com Sun Apr 30 20:41:03 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 1 May 2017 03:41:03 +0700 Subject: autoreconf: "header not found" in generated source In-Reply-To: References: <950044AF-DC3B-48EF-BDF8-08DDBE2B801D@freyther.de> Message-ID: > 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. 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. Don't you confuse it with the "gsm0503.h", which is exactly generated by the "utils/conv_gen.py"? With best regards, Vadim Yanitskiy. 2017-05-01 2:56 GMT+07:00 Holger Freyther : > > > On 30. Apr 2017, at 10:02, Vadim Yanitskiy wrote: > > > > It seems, I already found one solution. You're right, "build dir != src > dir" > > was the problem, so I added this: > > > > conv_conv_gsm0503_test_CPPFLAGS = \ > > $(AM_CPPFLAGS) \ > > -I$(top_srcdir)/tests/conv > > > > And now everything is fine! > > We generate "conv.h" and put it into the source directory? From 10.000 > miles aways it sounds a bit odd (at least for checkout from git, make dist > would be a different topic). > > holger -------------- next part -------------- An HTML attachment was scrubbed... URL: