From Mrinal.Mishra at radisys.com Thu Dec 1 13:51:32 2016 From: Mrinal.Mishra at radisys.com (Mrinal Mishra) Date: Thu, 1 Dec 2016 13:51:32 +0000 Subject: Dynamic TCH/F_PDCH does not work as TCH/F for CS voice call Message-ID: Hello All, As reported earlier "CS call is not working using TCH/F_PDCH dynamic channel configuration" in URRP B210 board(osmo-trx) . We further checked the commit version using git bisect to find out the exact version from where this functionality is broken . Below is the commit version of BSC : c3f72f63afde926dfc46827d6880055597515fb6 dyn TS: fix: ts_subslots() for TCH/F_PDCH in PDCH mode Thanks and Regards, Mrinal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp.labs at gmx.ch Thu Dec 1 22:07:11 2016 From: rp.labs at gmx.ch (Labs) Date: Thu, 1 Dec 2016 23:07:11 +0100 Subject: RBS 2308 Protocol Error In-Reply-To: <015be423-883f-be92-59d9-341354c90435@gmx.ch> References: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net> <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net> <015be423-883f-be92-59d9-341354c90435@gmx.ch> Message-ID: <91bfe1c3-87df-af46-1cf7-b710a724ceba@gmx.ch> Hello again, I will reply to my own email because I did a mistake. Sorry for any inconvenience. I mismatched the DAHDI conf with another one that had E1 config inside. DAHDI config is fine for T1 link but OpenBSC is still is not clear if timeslot allocation is OK or maybe someone with more experience can share why they are allocated like that. I checked the default config in osmocom-nitb and also the one attached by Caled and it is not clear for me why we have the following arrangement compared to the E/// documentation for BSS: I would re-write Caleb's config as it is the below one for an Unconcentrated LAPD: oml e1 line 0 timeslot 1 sub-slot 0 -->> CF is only found in timeslot 1 trx 0 rf_locked 0 arfcn 512 nominal power 24 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot 1 -->> TRXC is multiplexed only for first TRX. The other RSL/TRXC links for other TRXes use the full timeslot. rsl e1 tei 0 timeslot 0 phys_chan_config BCCH+CCCH --> air timeslot 0 runs BCCH and CCCH hopping enabled 0 e1 line 0 timeslot 1 sub-slot 2 timeslot 1 -->> air timeslot 1 runs a SDCCH8 phys_chan_config SDCCH8 hopping enabled 0 e1 line 0 timeslot 2 sub-slot 3 timeslot 2 -->> subrate 0+1 are spare for 1st TRX in LAPD Unconcentrated mode. At least the E/// docs show the following: PCM TS2(spare/spare/TCH0/TCH1) PCM TS3(TCH2 /TCH3 /TCH4/TCH5) so I interpreted that subrate 0+1 are the spare ones. phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 3 Regards, Razvan On 11/29/16 8:43 PM, Labs wrote: > Hello Caleb, > > > On 11/27/16 9:01 AM, Caleb Pal wrote: >> Good Evening, >> >> With the recent commits for the OM2000 protocol, I figured it was time >> to dust off the RBS2308 and see what would happen. I am using the latest >> version of DAHDI, with a TE122P T1 card. All osmocom software was pulled >> yesterday and installed successfully on a machine running Debian Stable. > Maybe you want to try to switch you DAHDI config from T1 to E1 first > since you use the BSC config with E1. > T1 uses 24 channels and E1 uses 32 channels. > > Second thing is that from what I saw on the wiki and on the Harald's > blog posts the Ericsson RBS units never worked fully and there is still > work to be done. Would be helpful if you have some traces on Abis from a > real Ericsson BSC to see what is going on there. > > Regards, > R. > From sipos.csaba at kvk.uni-obuda.hu Thu Dec 1 22:25:15 2016 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Thu, 1 Dec 2016 23:25:15 +0100 (CET) Subject: RBS 2308 Protocol Error In-Reply-To: <91bfe1c3-87df-af46-1cf7-b710a724ceba@gmx.ch> References: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net> <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net> <015be423-883f-be92-59d9-341354c90435@gmx.ch> <91bfe1c3-87df-af46-1cf7-b710a724ceba@gmx.ch> Message-ID: <309164073.12016550.1480631115705.JavaMail.zimbra@kvk.uni-obuda.hu> Hi, Maybe its not completely related, but my experience with Nokia Site is to use full E1 timeslots (64kbit) for RSL and OML signalling, otherwise it is not working, and this is not a Nokia limitation. Just try using: rsl e1 line 0 timeslot 1 sub-slot full and for the rest: timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 e1 line 0 timeslot 2 sub-slot 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 3 And don't forget to configure the BTS Abis allocation accordingly! Also for DAHDI, you will need to use the correct config with CCS signalling. This is an example for the system.conf for an E1 based BTS: span=1,0,0,ccs,hdb3,crc4 bchan=1-31 Regards, Csaba ----- Eredeti ?zenet ----- Felad?: "Labs" C?mzett: "Caleb Pal" , openbsc at lists.osmocom.org Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. December 1. 23:07:11 T?rgy: Re: RBS 2308 Protocol Error Hello again, I will reply to my own email because I did a mistake. Sorry for any inconvenience. I mismatched the DAHDI conf with another one that had E1 config inside. DAHDI config is fine for T1 link but OpenBSC is still is not clear if timeslot allocation is OK or maybe someone with more experience can share why they are allocated like that. I checked the default config in osmocom-nitb and also the one attached by Caled and it is not clear for me why we have the following arrangement compared to the E/// documentation for BSS: I would re-write Caleb's config as it is the below one for an Unconcentrated LAPD: oml e1 line 0 timeslot 1 sub-slot 0 -->> CF is only found in timeslot 1 trx 0 rf_locked 0 arfcn 512 nominal power 24 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot 1 -->> TRXC is multiplexed only for first TRX. The other RSL/TRXC links for other TRXes use the full timeslot. rsl e1 tei 0 timeslot 0 phys_chan_config BCCH+CCCH --> air timeslot 0 runs BCCH and CCCH hopping enabled 0 e1 line 0 timeslot 1 sub-slot 2 timeslot 1 -->> air timeslot 1 runs a SDCCH8 phys_chan_config SDCCH8 hopping enabled 0 e1 line 0 timeslot 2 sub-slot 3 timeslot 2 -->> subrate 0+1 are spare for 1st TRX in LAPD Unconcentrated mode. At least the E/// docs show the following: PCM TS2(spare/spare/TCH0/TCH1) PCM TS3(TCH2 /TCH3 /TCH4/TCH5) so I interpreted that subrate 0+1 are the spare ones. phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 4 sub-slot 3 Regards, Razvan On 11/29/16 8:43 PM, Labs wrote: > Hello Caleb, > > > On 11/27/16 9:01 AM, Caleb Pal wrote: >> Good Evening, >> >> With the recent commits for the OM2000 protocol, I figured it was time >> to dust off the RBS2308 and see what would happen. I am using the latest >> version of DAHDI, with a TE122P T1 card. All osmocom software was pulled >> yesterday and installed successfully on a machine running Debian Stable. > Maybe you want to try to switch you DAHDI config from T1 to E1 first > since you use the BSC config with E1. > T1 uses 24 channels and E1 uses 32 channels. > > Second thing is that from what I saw on the wiki and on the Harald's > blog posts the Ericsson RBS units never worked fully and there is still > work to be done. Would be helpful if you have some traces on Abis from a > real Ericsson BSC to see what is going on there. > > Regards, > R. > From rp.labs at gmx.ch Thu Dec 1 23:41:55 2016 From: rp.labs at gmx.ch (Labs) Date: Fri, 2 Dec 2016 00:41:55 +0100 Subject: RBS 2308 Protocol Error In-Reply-To: <309164073.12016550.1480631115705.JavaMail.zimbra@kvk.uni-obuda.hu> References: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net> <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net> <015be423-883f-be92-59d9-341354c90435@gmx.ch> <91bfe1c3-87df-af46-1cf7-b710a724ceba@gmx.ch> <309164073.12016550.1480631115705.JavaMail.zimbra@kvk.uni-obuda.hu> Message-ID: Hello Csaba, On 12/1/16 11:25 PM, Sipos Csaba wrote: > Hi, > > Maybe its not completely related, but my experience with Nokia Site is to use full E1 timeslots (64kbit) for RSL and OML signalling, otherwise it is not working, and this is not a Nokia limitation. > Nokia did a different implementation on Abis. I'm hoping to get a Nokia soon and play with it. > Just try using: I can't try it because I don't have a PCM based Ericsson but an IP based one and I really don't know how to make the openbsc.cfg for that one since I couldn't find anything in the wiki for it. I was trying to help Caleb and also understand the OM2000. I worked previously on RAN part with E/// and we integrated this RBSes with real BSCes and according to my notes E/// is not using full PCM timeslots (64kbit) exactly. They have 3 types of LDAP configurations for their Abis to RBS. - Unconcentrated LAPD For E1 they leave the full timeslot 0 free for synchronization and utilize timeslots 1-31. In this mode they use a full timeslot for signaling to TRU (TRXC) and 2 other full timeslots submultiplexed each in 4x 16kbit for voice and data. OML(CF) is not mentioned specifically but it says "TRXC-0 and CF goes together on the same timeslot". The E/// naming TRH (Transceiver Handler) says that is handling all LAPD signaling, signaling BTS to MS and O&M (CF). For T1 lines there is not synchronization timeslot used and sync is done from the overall T1 line so T1 config should start with "timeslot 0". - Concentrated LAPD Recommended for 3 or more TRUs. Here TS0 64kbit is for synchronization in E1 links, TS1 is used as 4x16kbit signaling for the first 4 TRXes, TS2-9 submultiplexed each in 4x16kbit for traffic, TS10 again 4x signaling,etc. For T1 the same but no TS0 so config starts with TS0 for 4x signaling links for the first 4 TRXes. Since in this mode you need also configuration for CON the CF(OML) is added by CON to the same timeslot as the first 4x TRXes that means TS1. - Multiplexed LAPD This is used for small cells and here I made the mistake in my previous mail saying is "Unconcentrated". This type of config multiplexes TRX signaling + CF(OML) + BCCH/CCCH + SDCCH8 in one full 64kbit timeslot and on the second timeslot keeps 2x 16kbit subrates spare. So in the end I am still not sure how the config should look like to have a PCM based RBS working with OpenBSC. > And don't forget to configure the BTS Abis allocation accordingly! > > Also for DAHDI, you will need to use the correct config with CCS signalling. This is an example for the system.conf for an E1 based BTS: > > span=1,0,0,ccs,hdb3,crc4 > bchan=1-31 > Thanks for config. > Regards, > Csaba > Regards, Razvan From nhofmeyr at sysmocom.de Fri Dec 2 01:29:34 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 2 Dec 2016 02:29:34 +0100 Subject: broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE Message-ID: <20161202012934.GB2244@my.box> Heads up, the current openbsc build is broken, as verified by https://jenkins.osmocom.org/jenkins/job/OpenBSC/ This is due to below libosmocore commit, which adds two items to enum chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking the static assert for gsm_network->ctype_by_chreq's size: ../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ?dummyassert_size? is negative osmo_static_assert(sizeof(ctype_by_chreq) == ^ What this patch lacks is * adjustment of ctype_by_chreq[] according to the new additions in libbsc/gsm_04_08_utils.c * same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c * enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h. I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items should be, but to not get distracted from my current task, and since the values don't seem to be used by the current master branches yet, I decided to simply revert the libosmocore commit and leave it up to the original authors to follow up. (No need to mention that those should be merged to libosmocore and openbsc "at the same time" to avoid builds failing.) Thanks and apologies for any inconvenience... ~Neels commit c3c28528de78fd5d50c3a141c2176c0da5dd7075 Refs: 0.9.0-299-gc3c2852 Author: Alexander Couzens AuthorDate: Tue Nov 29 12:42:05 2016 +0100 Commit: Harald Welte CommitDate: Thu Dec 1 15:26:29 2016 +0000 gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE For BSC-located pcu the BSC must understand the PDCH chan request. Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784 --- include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h index 767aa3d..c05b62e 100644 --- a/include/osmocom/gsm/protocol/gsm_04_08.h +++ b/include/osmocom/gsm/protocol/gsm_04_08.h @@ -1456,6 +1456,8 @@ enum chreq_type { CHREQ_T_PAG_R_TCH_F, CHREQ_T_PAG_R_TCH_FH, CHREQ_T_LMU, + CHREQ_T_PDCH_ONE_PHASE, + CHREQ_T_PDCH_TWO_PHASE, CHREQ_T_RESERVED_SDCCH, CHREQ_T_RESERVED_IGNORE, }; -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Dec 2 09:03:31 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Dec 2016 10:03:31 +0100 Subject: broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE In-Reply-To: <20161202012934.GB2244@my.box> References: <20161202012934.GB2244@my.box> Message-ID: <20161202090331.6um4agentssdjquo@nataraja> On Fri, Dec 02, 2016 at 02:29:34AM +0100, Neels Hofmeyr wrote: > Heads up, the current openbsc build is broken, as verified by > https://jenkins.osmocom.org/jenkins/job/OpenBSC/ > > This is due to below libosmocore commit, which adds two items to enum > chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking > the static assert for gsm_network->ctype_by_chreq's size: > > ../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ?dummyassert_size? is negative > osmo_static_assert(sizeof(ctype_by_chreq) == > ^ > > What this patch lacks is > > * adjustment of ctype_by_chreq[] according to the new additions in > libbsc/gsm_04_08_utils.c > * same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c > * enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h. there are related changes in not-yet-pushed commits in openbsc.git, which should be pushed by the team working on this. It's really sad that we have such a chicken-and-egg situation now, where we will introduce a backward-incompatibility, i.e. a newer libosmocore will be source-code incompatible with older openbsc. This is really sad and we should avoid such situations if possible at all. >From that point of view, the static_assert is highly questionable in openbsc.git, because it assumes that an enum is never getting extended in the library :( But of course we cannot change past versions of openbsc.git. But please let's all try to remember this issue and not create one again. -- - 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 Fri Dec 2 08:48:24 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Dec 2016 09:48:24 +0100 Subject: Dynamic TCH/F_PDCH does not work as TCH/F for CS voice call In-Reply-To: References: Message-ID: <20161202084824.hf3mni3vskggenpw@nataraja> Hi Mrinal, On Thu, Dec 01, 2016 at 01:51:32PM +0000, Mrinal Mishra wrote: > As reported earlier ?CS call is not working using TCH/F_PDCH dynamic channel > configuration? in URRP B210 board(osmo-trx) . We further checked the commit > version using git bisect to find out the exact version from where this > functionality is broken . Below is the commit version of BSC : > > c3f72f63afde926dfc46827d6880055597515fb6 is there ar redmine issue about this? If so, please update it with your findings. We want to make sure to collect all bug reports in one place. 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 Fri Dec 2 12:43:40 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 2 Dec 2016 13:43:40 +0100 Subject: broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE In-Reply-To: <20161202090331.6um4agentssdjquo@nataraja> References: <20161202012934.GB2244@my.box> <20161202090331.6um4agentssdjquo@nataraja> Message-ID: <20161202124340.GA1614@my.box> > From that point of view, the static_assert is highly questionable in > openbsc.git I'm glad that we have the assert, otherwise we would be writing past the array's end without noticing now... IMHO the way to update the enum is to have all patches on gerrit and collect +2 on them. Once the libosmocore part is merged, the openbsc one shall follow as soon as possible, unfortunately having to wait for the V+1 first. We could fix one part of this in general with a kind of LAST_ENTRY enum val in the sense of enum vals { VAL1, VAL2, LAST }; struct s { int arr[LAST]; }; (where 's' stands for gsm_network) Then the gsm_network struct size would of course change implicitly, depending on the .h file from libosmocore. But then it's still not possible to use the newly added enum values in the openbsc.git (to extend those other const arrays), so a two-part commit is still needed for this particular patch. --> move the const arrays to libosmocore? What did you have in mind? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Dec 2 12:48:19 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Dec 2016 13:48:19 +0100 Subject: broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE In-Reply-To: <20161202124340.GA1614@my.box> References: <20161202012934.GB2244@my.box> <20161202090331.6um4agentssdjquo@nataraja> <20161202124340.GA1614@my.box> Message-ID: <20161202124819.dubrzai63wwhval7@nataraja> On Fri, Dec 02, 2016 at 01:43:40PM +0100, Neels Hofmeyr wrote: > > From that point of view, the static_assert is highly questionable in > > openbsc.git > > I'm glad that we have the assert, otherwise we would be writing past the > array's end without noticing now... I would rather have code that doesn't have such assumptions in the firstp place, without relying on the fact that an enum of a library doesn't extend in the future. I see the assert more as a hack around code with broken assumption. > What did you have in mind? I don't have the time right now to study the particular code in question, sorry. It will hav to wait for another 10 or 20 other things on my ever growing stack of todo items :/ -- - 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 Fri Dec 2 22:38:27 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Dec 2016 23:38:27 +0100 Subject: libosmocore support for GSMTAP based logging Message-ID: <20161202223827.fgyjpobj6lqd6aw4@nataraja> Dear all, when debugging Osmocom programs, one usually looks at either the pcap trace of one of the many interfaces (Um interface via GSMTAP or OsmocomBB, Abis, Gb, Gp or A interface via ethernet, ...) or at the log files of the various osmocom programs. Sometimes it can be hard to match the two different domains, and it is useful to see in sequence when a certain message was received and what kind of actions this triggered inside e.g. OsmoPCU or OSmoSGSN. One could have used the libosmocore 'syslog' log target for this and then configure the local syslog daemon to log to a remote syslog server via the network. However, as there is another local process and context switches involved, the messages were re-ordered. Also, syslog only receives the fully-formatted log string, and not the meta-data like the log level or sub-system. Hence, the idae of having a GSMTAP based log target was floating around the project for many years. I finally implemented this today. The advantage is that in our single-threaded osmocom programs the GSMTAP messages will leave in-sequence with the protocol messages received or transmitted, and there is only the limited chance of re-ordering by the local network stack and/or intermediate routers. Both shouldn't be much of a concern during local debugging. What do you need to use this? 1) The follwoing three libosmcoore commits from gerrit: https://gerrit.osmocom.org/#/c/1355 https://gerrit.osmocom.org/#/c/1356 https://gerrit.osmocom.org/#/c/1357 2) a "log gsmtap" configuration in your config file (or via vty), similar to how syslog logging is configured: === SNIP === log gsmtap localhost logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice [...] === SNIP === 3) a wireshark with my Change-ID I0de723445e5b5ce0199a4081808111240a9ed047 (can also be found in the laforge/gsmtap-log branch of git://git.osmocom.org/wireshark or http://git.osmocom.org/wireshark/commit/?h=laforge/gsmtap-log&id=3a207894a493598a3047fdfce88e72e3de21f774 I will leave this in review for a few days and then plan to merge it into libosmocore. The wireshark patch will also be submitted at that time. A screenshot is attached for your reference. There is of course no coloring of the lines in wirshark, but you can set various wireshark filters (e.g. on log level, sub-system) and also use colorization rules to e.g. map sub-systems again to colors. 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 -------------- A non-text attachment was scrubbed... Name: gsmtap-log.png Type: image/png Size: 107810 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Dec 5 13:29:14 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Dec 2016 14:29:14 +0100 Subject: Dynamic TCH/F_PDCH does not work as TCH/F for CS voice call In-Reply-To: References: Message-ID: <20161205132914.GA4318@ass40.sysmocom.de> On Thu, Dec 01, 2016 at 01:51:32PM +0000, Mrinal Mishra wrote: > Hello All, > > As reported earlier "CS call is not working using TCH/F_PDCH dynamic channel configuration" in URRP B210 board(osmo-trx) . We further checked the commit version using git bisect to find out the exact version from where this functionality is broken . Below is the commit version of BSC : > > > c3f72f63afde926dfc46827d6880055597515fb6 I have created an issue for this: https://osmocom.org/issues/1868 and also posted a short answer there. Please "watch" (subscribe to) this issue on the osmocom.org redmine to be in the loop for further updates. Thanks! ~Neels -- - 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 Mon Dec 5 15:17:27 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Dec 2016 16:17:27 +0100 Subject: osmo-trx binary can't be moved between "same" CPUs Message-ID: <20161205151727.GA2223@ass40.sysmocom.de> Hi osmo-trx folks, I'd like to draw your attention to https://osmocom.org/issues/1869 -- "osmo-trx binary cannot be moved to similar CPU" Has anyone seen this before and/or is up to the task of fixing it? Thanks! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.chemeris at gmail.com Mon Dec 5 15:33:32 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 5 Dec 2016 18:33:32 +0300 Subject: osmo-trx binary can't be moved between "same" CPUs In-Reply-To: <20161205151727.GA2223@ass40.sysmocom.de> References: <20161205151727.GA2223@ass40.sysmocom.de> Message-ID: The second CPU is missing sse4_1/2. So if you want to build on a CPU with SSE4, but run on a CPU without it - use a hack like the one we're using to build for Atom (older versions don't have SSE4). http://cgit.osmocom.org/osmo-trx/commit/?h=fairwaves/master&id=e1501c24cd4325644c92ecbf13a7e5fe87ed64aa You can find an original thread where we discussed it with Holger and my suggestion was to include this patch by default, so that DEB builds can run on any recent hardware. On Mon, Dec 5, 2016 at 6:17 PM, Neels Hofmeyr wrote: > Hi osmo-trx folks, > > I'd like to draw your attention to https://osmocom.org/issues/1869 -- > "osmo-trx binary cannot be moved to similar CPU" > > Has anyone seen this before and/or is up to the task of fixing it? > > Thanks! > > ~N > > -- > - Neels Hofmeyr http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Gesch?ftsf?hrer / Managing Directors: Harald Welte -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From nhofmeyr at sysmocom.de Mon Dec 5 16:26:49 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Dec 2016 17:26:49 +0100 Subject: osmo-trx binary can't be moved between "same" CPUs In-Reply-To: References: <20161205151727.GA2223@ass40.sysmocom.de> Message-ID: <20161205162649.GB6493@ass40.sysmocom.de> Please add this as comment to issue #1869? :) Thx! ~N On Mon, Dec 05, 2016 at 06:33:32PM +0300, Alexander Chemeris wrote: > The second CPU is missing sse4_1/2. > > So if you want to build on a CPU with SSE4, but run on a CPU without > it - use a hack like the one we're using to build for Atom (older > versions don't have SSE4). > http://cgit.osmocom.org/osmo-trx/commit/?h=fairwaves/master&id=e1501c24cd4325644c92ecbf13a7e5fe87ed64aa > > You can find an original thread where we discussed it with Holger and > my suggestion was to include this patch by default, so that DEB builds > can run on any recent hardware. > > On Mon, Dec 5, 2016 at 6:17 PM, Neels Hofmeyr wrote: > > Hi osmo-trx folks, > > > > I'd like to draw your attention to https://osmocom.org/issues/1869 -- > > "osmo-trx binary cannot be moved to similar CPU" > > > > Has anyone seen this before and/or is up to the task of fixing it? > > > > Thanks! > > > > ~N > > > > -- > > - Neels Hofmeyr http://www.sysmocom.de/ > > ======================================================================= > > * sysmocom - systems for mobile communications GmbH > > * Alt-Moabit 93 > > * 10559 Berlin, Germany > > * Sitz / Registered office: Berlin, HRB 134158 B > > * Gesch?ftsf?hrer / Managing Directors: Harald Welte > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves, Inc. > https://fairwaves.co -- - 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 kristian.martens at ng4t.com Mon Dec 5 18:01:36 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Mon, 5 Dec 2016 19:01:36 +0100 Subject: MGCP logging Message-ID: Dear all, I have switched on logging to file and have set the log level to "debug" for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot find any output in the log file related to MGCP if I get an error. Is there a trick to make the MGCP module more verbose? Thanks, Kristian From laforge at gnumonks.org Mon Dec 5 20:30:09 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Dec 2016 21:30:09 +0100 Subject: MGCP logging In-Reply-To: References: Message-ID: <20161205203009.lwlimnx7j6drjmzt@nataraja> Hi Kristian, On Mon, Dec 05, 2016 at 07:01:36PM +0100, Kristian Martens wrote: > I have switched on logging to file and have set the log level to "debug" > for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot > find any output in the log file related to MGCP if I get an error. Is > there a trick to make the MGCP module more verbose? it would be helpful if you could attach your config file, so we can check it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kristian.martens at ng4t.com Tue Dec 6 07:53:46 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Tue, 6 Dec 2016 08:53:46 +0100 Subject: MGCP logging In-Reply-To: <20161205203009.lwlimnx7j6drjmzt@nataraja> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> Message-ID: <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> Hi Harald, thank you for your answer. Please find attached the config. files. Regards, Kristian Am 05.12.2016 um 21:30 schrieb Harald Welte: > Hi Kristian, > > On Mon, Dec 05, 2016 at 07:01:36PM +0100, Kristian Martens wrote: >> I have switched on logging to file and have set the log level to "debug" >> for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot >> find any output in the log file related to MGCP if I get an error. Is >> there a trick to make the MGCP module more verbose? > it would be helpful if you could attach your config file, so we can > check it. > -------------- next part -------------- ! ! OsmoBSC (0.14.0+gitrAUTOINC+57ee780789-dirty) configuration saved from vty !! password foo ! log file /home/root/bsc1.log logging filter all 1 logging color 1 logging print category 0 logging timestamp 1 logging level all everything logging level rll notice logging level cc notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc debug logging level mgcp debug logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns debug logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 262 mobile network code 79 short name ng4T-BSC-0 long name ng4T-BSC-0 auth policy closed location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 0 timer t3141 0 dtx-used 0 subscriber-keep-in-ram 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 ip.access unit_id 1234 0 oml ip.access stream_id 255 line 0 neighbor-list mode manual-si5 neighbor-list add arfcn 100 neighbor-list add arfcn 200 si5 neighbor-list add arfcn 10 si5 neighbor-list add arfcn 20 codec-support fr gprs mode gprs gprs routing area 0 gprs network-control-order nc0 gprs cell bvci 20 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 149 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 20 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 192.168.17.101 gprs nsvc 1 nsvci 0 gprs nsvc 1 local udp port 0 gprs nsvc 1 remote udp port 0 gprs nsvc 1 remote ip 0.0.0.0 no force-combined-si trx 0 rf_locked 0 arfcn 871 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 ip.access rtp-base 4000 timeout-ping 20 timeout-pong 5 no timeout-ping advanced no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text codec-list fr1 fr2 dest 192.168.17.100 6666 0 type normal allow-emergency allow amr-config 12_2k allowed amr-config 10_2k allowed amr-config 7_95k allowed amr-config 7_40k allowed amr-config 6_70k allowed amr-config 5_90k allowed amr-config 5_15k allowed amr-config 4_75k forbidden bsc mid-call-timeout 0 no missing-msc-text -------------- next part -------------- ! ! OpenBSC MGCP (0.14.0+gitrAUTOINC+57ee780789-dirty) configuration saved from vty !! password foo ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice logging level cc notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp debug logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice ! line vty no login ! mgcp bts ip 172.16.252.43 bind ip 192.168.17.105 bind port 2427 rtp bts-base 4000 rtp net-base 16000 rtp ip-dscp 0 rtp keep-alive once no rtcp-omit no rtp-patch sdp audio-payload number 98 sdp audio-payload name AMR/8000 sdp audio-payload send-ptime sdp audio-payload send-name loop 1 number endpoints 31 allow-transcoding rtp transcoder-base 0 transcoder-remote-base 4000 osmux off trunk 1 sdp audio-payload number 126 sdp audio-payload name AMR/8000 sdp audio-payload send-ptime sdp audio-payload send-name rtp keep-alive once loop 0 no rtcp-omit no rtp-patch allow-transcoding From laforge at gnumonks.org Tue Dec 6 10:16:59 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Dec 2016 11:16:59 +0100 Subject: MGCP logging In-Reply-To: <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> Message-ID: <20161206101659.ac5hdbyy5pulppqx@nataraja> Hi Kristian, the log file looks fine. All "DMGCP" log lines, especially from openbsc/src/libmgcp/*.c should now be visible. The big question now is: Does your MSC actually issue MGCP towards the BSC? Do you get answers from the BSC (i.e. any sign of the BSC processing them) but still you see no related log output? 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 Dec 6 12:10:07 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Dec 2016 13:10:07 +0100 Subject: MGCP logging In-Reply-To: <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> Message-ID: <20161206121007.GA1345@my.box> BTW, this is what my mgcp.cfg looks like to give me lots of log output on the console: log stderr logging print extended-timestamp 1 logging level all debug logging filter all 1 mgcp [...] ~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 Tue Dec 6 12:26:17 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Dec 2016 13:26:17 +0100 Subject: MGCP logging In-Reply-To: <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> Message-ID: <2FBAF4CB-E1F2-41C9-84C3-6ED88BF9B916@freyther.de> > On 06 Dec 2016, at 08:53, Kristian Martens wrote: > > Hi Harald, Hi! > thank you for your answer. Please find attached the config. files. osmo-bsc_mcgp only "recently" gained transcoding and doesn't support conversion from all codecs to all. Your BSC config seems to either select fr1 or fr2 for a call and your MGCP config claims these endpoints are AMR (and you are looping the audio). It seems a bit like a mismatch. osmo-bsc_mgcp doesn't support mixed codec support (mostly because BSC and MGCP MGW do not communicate with each other). regards holger From kristian.martens at ng4t.com Tue Dec 6 13:16:27 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Tue, 6 Dec 2016 14:16:27 +0100 Subject: MGCP logging In-Reply-To: <20161206101659.ac5hdbyy5pulppqx@nataraja> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> Message-ID: Hi Harald, thank you for your answer. Yes, the call agent requests a new connection to the MGW. And it gets an answer. Mostly it fails, and suddenly, one time, it was OK and I wanted to find out the reason for this strange behaviour (see attached pcap). I also wanted to have the log output inside the specific log file. So do I need to specify the log file section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg? Could this be the reason why I do not find MGCP log messages in it? Thanks, Kristian Am 06.12.2016 um 11:16 schrieb Harald Welte: > Hi Kristian, > > the log file looks fine. All "DMGCP" log lines, especially from > openbsc/src/libmgcp/*.c should now be visible. > > The big question now is: Does your MSC actually issue MGCP towards the > BSC? Do you get answers from the BSC (i.e. any sign of the BSC > processing them) but still you see no related log output? > > Regards, > Harald -- *Kristian Martens* Software Engineer Office: +49 30 65218529 / ng4T GmbH Siemensdamm 50 13629 Berlin Germany www.ng4t.com / Berlin-Charlottenburg, HRB 123546 Gesch?ftsf?hrer Dr. Andreas Kallmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sysmo_fail_ok_mgcp.pcapng Type: application/octet-stream Size: 9932 bytes Desc: not available URL: From holger at freyther.de Tue Dec 6 14:01:34 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Dec 2016 15:01:34 +0100 Subject: MGCP logging In-Reply-To: References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> Message-ID: > On 06 Dec 2016, at 14:16, Kristian Martens wrote: > > Hi Harald, Hey! > thank you for your answer. Yes, the call agent requests a new connection to the MGW. And it gets an answer. Mostly it fails, and suddenly, one time, it was OK and I wanted to find out the reason for this strange behaviour (see attached pcap). I also wanted to have the log output inside the specific log file. So do I need to specify the log file section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg? Could this be the reason why I do not find MGCP log messages in it? in contrib/mgcp_server.py we have a small python piece to send CRCX/MDCX/DLCX to the GW. I have not tried to replay your message but you could modify the utility. Just looking at the trace I see that a dynamic payload type is used but it is not mapped to an audio codec. This is problematic and might be the origin of your issue. Our SDP code is not great but I think it started to understand codec name to payloadtype mapping. The other fun thing is that it starts to accept it. For replayed messages it should have a cached (the last) result. Was there any other message in between? holger From msuraev at sysmocom.de Tue Dec 6 15:37:43 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 6 Dec 2016 16:37:43 +0100 Subject: osmo-trx debian nightly builds fail due to uhd requirement In-Reply-To: References: <20161128074529.7o2lp74dbt4lomwv@nataraja> Message-ID: Is there ppa with stable uhd version for ubuntu 16.10? On 29.11.2016 06:32, Tom Tsou wrote: > Hi Harald, > > On Sun, Nov 27, 2016 at 11:45 PM, Harald Welte wrote: >> as osmo-trx has recently introduced a dependency on a super-recent >> version of UHD (as opposed to what regular stable distributions ship), >> the nightly debian builds are broken for both Debian 8.0 and Ubuntu >> 14.04: >> https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx > I bumped the UHD version dependency to 3.9.x because older versions of > UHD are no longer maintained and osmo-trx was already dependent on > 3.9.x for certain functionality (mainly multi-trx and improved > timing). Build-time version checks were also causing user confusion. > > I understand the unwanted effects and dislike the idea of forcing > users to move to more recent versions, however, Ettus Research does > not recommend building against the shipping 3.5 and 3.7 UHD versions > in Ubuntu 14.04 and Debian 8.0 respectively. > >> b) submitting a suitable uhd package version that can be build in the >> osmoco nightly OBS repository > Recommended UHD versions are found in Debian 8.0 Backports and Ubuntu > 14.04 Ettus Research PPA. > > https://packages.debian.org/jessie-backports/libuhd-dev > https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts > > -TT -- 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 radiarisainanasitraka at yahoo.fr Tue Dec 6 19:17:58 2016 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Tue, 6 Dec 2016 19:17:58 +0000 (UTC) Subject: osmo-iuh-3G_2016_09 References: <1126753876.1194404.1481051878505.ref@mail.yahoo.com> Message-ID: <1126753876.1194404.1481051878505@mail.yahoo.com> Hello, I would also ask if the osmo-iuh-3G_2016_09 support the new sfr-femto tha sfr sold now (for 90 euro) or it's not available only for le old sfr femto !?Is it possible also for the new femtocell vodafone signal secure 3 !? (and if it's possible I would like to konw how to find Tx-Rx-GND for this femto) Thanks for helping chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 7 11:59:20 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Dec 2016 12:59:20 +0100 Subject: osmo-iuh-3G_2016_09 In-Reply-To: <1126753876.1194404.1481051878505@mail.yahoo.com> References: <1126753876.1194404.1481051878505.ref@mail.yahoo.com> <1126753876.1194404.1481051878505@mail.yahoo.com> Message-ID: <20161207115920.gj4glhvkkgfupzk4@nataraja> Dear Radiarisainana, On Tue, Dec 06, 2016 at 07:17:58PM +0000, Radiarisainana Sitraka wrote: > I would also ask if the osmo-iuh-3G_2016_09 I recommend to use the latest version of all branches, not some tag in the repo. > support the new sfr-femto tha sfr sold now (for 90 euro) or it's not > available only for le old sfr femto !?Is it possible also for the new > femtocell vodafone signal secure 3 !? (and if it's possible I would > like to konw how to find Tx-Rx-GND for this femto) You will need a 3G femtocell / small cell where you can access the Iuh interface. That's all we can say. We have no access to and no information about the femtocells that various operators may be selling to customers, sorry. If you obtained the femtocell from an operator, that operator will normally make sure that this femtocell will always only talk to their network, and not to any other core network (like your own using osmo-iuh). This is a very strange situation, as in most cases you buy (And pay for) a device, but then the control over that device is still with a third party. It's like buying a car, and then the car manufacturer can decide which roads you can drive on :/ Welcome to the brave new world. 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 Wed Dec 7 12:16:19 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Dec 2016 13:16:19 +0100 Subject: MGCP logging In-Reply-To: References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> Message-ID: <20161207121619.GA1262@my.box> On Tue, Dec 06, 2016 at 02:16:27PM +0100, Kristian Martens wrote: > inside the specific log file. So do I need to specify the log file > section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg? Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to put that logging config in the osmo-bsc_mgcp.cfg file. ~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 Dec 7 12:38:14 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Dec 2016 13:38:14 +0100 Subject: MGCP logging In-Reply-To: <20161207121619.GA1262@my.box> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> Message-ID: <20161207123814.y2jaxf7oeohre76x@nataraja> Hi Neels, On Wed, Dec 07, 2016 at 01:16:19PM +0100, Neels Hofmeyr wrote: > Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not > read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to > put that logging config in the osmo-bsc_mgcp.cfg file. both files were attached to a mail earlier in the threads and had mgcp debug logging enabled. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kristian.martens at ng4t.com Wed Dec 7 13:03:49 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Wed, 7 Dec 2016 14:03:49 +0100 Subject: MGCP logging In-Reply-To: <20161207123814.y2jaxf7oeohre76x@nataraja> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> Message-ID: <5b543830-042d-53da-821a-13b8a6d98fa4@ng4t.com> All, thank you for your answers. I wasn't aware that the logging is specified for each module separately. I inserted the file logging into ..-mgcp.cfg and now I can find all information needed. Cheers, Kristian Am 07.12.2016 um 13:38 schrieb Harald Welte: > Hi Neels, > > On Wed, Dec 07, 2016 at 01:16:19PM +0100, Neels Hofmeyr wrote: > >> Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not >> read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to >> put that logging config in the osmo-bsc_mgcp.cfg file. > both files were attached to a mail earlier in the threads and had mgcp > debug logging enabled. > -- *Kristian Martens* Software Engineer Office: +49 30 65218529 / ng4T GmbH Siemensdamm 50 13629 Berlin Germany www.ng4t.com / Berlin-Charlottenburg, HRB 123546 Gesch?ftsf?hrer Dr. Andreas Kallmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.martens at ng4t.com Wed Dec 7 16:52:15 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Wed, 7 Dec 2016 17:52:15 +0100 Subject: Paging not answered in m2m call In-Reply-To: <20161207123814.y2jaxf7oeohre76x@nataraja> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> Message-ID: <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> Hello, two UEs (A and B) are successfully registered in a network. Now A tries to call B. B is paged by the core via A interface but the sysmoBSC/BTS does not seem to page the UE (or UE does not answer paging). What could be the reason for this behaviour? How could the problem be debugged? Please find the attached pcap for your reference. Thanks, Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: m2m_call_fails.pcapng Type: application/octet-stream Size: 12820 bytes Desc: not available URL: From holger at freyther.de Wed Dec 7 17:13:10 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Dec 2016 18:13:10 +0100 Subject: Paging not answered in m2m call In-Reply-To: <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> Message-ID: > On 07 Dec 2016, at 17:52, Kristian Martens wrote: > > Hello, Hi! > two UEs (A and B) are successfully registered in a network. Now A tries > to call B. B is paged by the core via A interface but the sysmoBSC/BTS > does not seem to page the UE (or UE does not answer paging). What could > be the reason for this behaviour? How could the problem be debugged? > Please find the attached pcap for your reference. nice MNC! The P-TMSI doesn't really look that random but it might be an index into an internal data structure? So on A this looks right. The LAI is 262-79-1 and this is where you are paging. In general it might be: * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ handling the location area identifier. You could trace the RSL protocol and see if a paging command is being sent (periodically) to the BTS? * The MS still has a radio channel open. I notice that clear command is being sent so this is unlikely to be the case. Also IMSI seems to be match.. maybe the MS still calculates the paging group wrongly? That is far fetched though. holger From kristian.martens at ng4t.com Wed Dec 7 17:41:08 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Wed, 7 Dec 2016 18:41:08 +0100 Subject: Paging not answered in m2m call In-Reply-To: References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> Message-ID: <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> Hi, I have captured a trace. Can you find something out? Thanks, Kristian Am 07.12.2016 um 18:13 schrieb Holger Freyther: >> On 07 Dec 2016, at 17:52, Kristian Martens wrote: >> >> Hello, > Hi! > >> two UEs (A and B) are successfully registered in a network. Now A tries >> to call B. B is paged by the core via A interface but the sysmoBSC/BTS >> does not seem to page the UE (or UE does not answer paging). What could >> be the reason for this behaviour? How could the problem be debugged? >> Please find the attached pcap for your reference. > > nice MNC! The P-TMSI doesn't really look that random but it might be an > index into an internal data structure? > > So on A this looks right. The LAI is 262-79-1 and this is where you are > paging. In general it might be: > > * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ > handling the location area identifier. You could trace the RSL protocol > and see if a paging command is being sent (periodically) to the BTS? > > * The MS still has a radio channel open. I notice that clear command is > being sent so this is unlikely to be the case. Also IMSI seems to be > match.. maybe the MS still calculates the paging group wrongly? That is > far fetched though. > > > holger -------------- next part -------------- A non-text attachment was scrubbed... Name: 20161207_nopaging.pcap Type: application/octet-stream Size: 26302 bytes Desc: not available URL: From holger at freyther.de Wed Dec 7 17:44:35 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Dec 2016 18:44:35 +0100 Subject: Paging not answered in m2m call In-Reply-To: <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> Message-ID: <4C6FE746-97F1-4A49-8AEB-36300FEDADF5@freyther.de> > On 07 Dec 2016, at 18:41, Kristian Martens wrote: > > Hi, > > I have captured a trace. Can you find something out? > do you see a paging command in that trace? Do you perhaps have: LOGP(DMSC, LOGL_ERROR, "Unsupported Cell Identifier List: %s\n", osmo_hexdump(data, data_length)); in the logs? cheers holger From kristian.martens at ng4t.com Wed Dec 7 18:03:06 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Wed, 7 Dec 2016 19:03:06 +0100 Subject: Paging not answered in m2m call In-Reply-To: <4C6FE746-97F1-4A49-8AEB-36300FEDADF5@freyther.de> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> <4C6FE746-97F1-4A49-8AEB-36300FEDADF5@freyther.de> Message-ID: <031bef27-a38a-3c00-fad4-45e4aa1e7a32@ng4t.com> Thank you, yes, I can see Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00 How can this list be setup in the BSC? Thanks, Kristian Am 07.12.2016 um 18:44 schrieb Holger Freyther: >> On 07 Dec 2016, at 18:41, Kristian Martens wrote: >> >> Hi, >> >> I have captured a trace. Can you find something out? >> > do you see a paging command in that trace? Do you perhaps have: > > LOGP(DMSC, LOGL_ERROR, "Unsupported Cell Identifier List: %s\n", osmo_hexdump(data, data_length)); > > in the logs? > > > cheers > holger > -- *Kristian Martens* Software Engineer Office: +49 30 65218529 / ng4T GmbH Siemensdamm 50 13629 Berlin Germany www.ng4t.com / Berlin-Charlottenburg, HRB 123546 Gesch?ftsf?hrer Dr. Andreas Kallmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Dec 7 18:04:48 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Dec 2016 19:04:48 +0100 Subject: Paging not answered in m2m call In-Reply-To: <031bef27-a38a-3c00-fad4-45e4aa1e7a32@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> <4C6FE746-97F1-4A49-8AEB-36300FEDADF5@freyther.de> <031bef27-a38a-3c00-fad4-45e4aa1e7a32@ng4t.com> Message-ID: > On 07 Dec 2016, at 19:03, Kristian Martens wrote: > > Thank you, yes, I can see Hi! > Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING > Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00 > > How can this list be setup in the BSC? So far none of my customers used that paging mode and before implementing something that might or might not be correct, I decided to put an error in it so it can be added in the future. a.) Add mode for it and send a patch b.) Ask someone to implement this mode? c.) Switch to the one "supported" have a nice evening holger From kristian.martens at ng4t.com Wed Dec 7 18:08:29 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Wed, 7 Dec 2016 19:08:29 +0100 Subject: Paging not answered in m2m call In-Reply-To: References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> <9a4bcc68-e884-0f48-8a26-989b7edf5bca@ng4t.com> <4C6FE746-97F1-4A49-8AEB-36300FEDADF5@freyther.de> <031bef27-a38a-3c00-fad4-45e4aa1e7a32@ng4t.com> Message-ID: <341e3d0b-48e8-d013-aca9-12079e0a0932@ng4t.com> Hi, OK, so which paging mode would be supported? E.g. just for LAI? Regards, Kristian Am 07.12.2016 um 19:04 schrieb Holger Freyther: >> On 07 Dec 2016, at 19:03, Kristian Martens wrote: >> >> Thank you, yes, I can see > Hi! > > >> Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING >> Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00 >> >> How can this list be setup in the BSC? > > So far none of my customers used that paging mode and before implementing > something that might or might not be correct, I decided to put an error in > it so it can be added in the future. > > a.) Add mode for it and send a patch > b.) Ask someone to implement this mode? > c.) Switch to the one "supported" > > have a nice evening > > holger -- *Kristian Martens* Software Engineer Office: +49 30 65218529 / ng4T GmbH Siemensdamm 50 13629 Berlin Germany www.ng4t.com / Berlin-Charlottenburg, HRB 123546 Gesch?ftsf?hrer Dr. Andreas Kallmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 7 18:51:39 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Dec 2016 19:51:39 +0100 Subject: Paging not answered in m2m call In-Reply-To: <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> References: <20161205203009.lwlimnx7j6drjmzt@nataraja> <94b4cd54-64b9-813f-237e-4e25613c335c@ng4t.com> <20161206101659.ac5hdbyy5pulppqx@nataraja> <20161207121619.GA1262@my.box> <20161207123814.y2jaxf7oeohre76x@nataraja> <86191d29-a64c-67d1-9208-b798d75bef42@ng4t.com> Message-ID: <20161207185139.3ibmp2efvgrp2czs@nataraja> Hi Kristian, On Wed, Dec 07, 2016 at 05:52:15PM +0100, Kristian Martens wrote: > two UEs (A and B) are successfully registered in a network. Now A tries > to call B. B is paged by the core via A interface but the sysmoBSC/BTS > does not seem to page the UE (or UE does not answer paging). What could > be the reason for this behaviour? How could the problem be debugged? > Please find the attached pcap for your reference. Most important is to find out what is actually happening on the air interface vs. the Abis interface. If you have an air-interface protocol tracer, or are familiar with OsmocomBB, or you have a phone with Qualcomm DIAG + QXDM, or a Sagem OT phone, etc. you could get a protocol trace of the phone side. This is the most reliable method to know what arrives at the phone or not. Next best to that, you can enable GSMTAP generation in osmo-bts, which I believe is sufficiently documented in the manual. Using that, particulary for the PCH L1 SAPI, you will get a 'pseudo air interface trace' consisting of anything that the BTS hands to the PHY for transmission. -- - 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 Dec 7 23:10:31 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 8 Dec 2016 00:10:31 +0100 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: <20161130031419.GA9871@my.box> References: <20161130031419.GA9871@my.box> Message-ID: <20161207231031.GB30277@my.box> TbfTest still fails for the sanitizer build: https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/382/console Aravind, can you find out the cause? You seem to be the most recent contributor to the TbfTest. Thanks! ~N On Wed, Nov 30, 2016 at 04:14:19AM +0100, Neels Hofmeyr wrote: > Dear authors of Tbf, > > can you make sense of this build failure? > https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/373/console > > It shows that the expected stderr output of the TbfTest deviates, > and the test exits prematurely. > > interesting output: > > +tbf_dl.cpp:766:65: runtime error: load of value 32767, which is not a valid value for type 'egprs_puncturing_values' > > -- got ack for BSN=1258 > -- got ack for BSN=1259 > -- got ack for BSN=1260 > +- got NACK for BSN=1258 > +- got NACK for BSN=1259 > +- got NACK for BSN=1260 > > To help reproducing it, find below the jenkins script that runs this sanitizer > build. > > Thanks for any patches that could fix our sanitizer build! > > ~Neels > > > > #!/bin/sh > > set -ex > > export BUILDDIR=$PWD/build/ > export PKG_CONFIG_PATH=$BUILDDIR/lib/pkgconfig > export LD_LIBRARY_PATH=$BUILDDIR/lib/ > export PATH="$PATH:$HOME/osmo-ci/scripts" > > build() { > RET=$PWD > git clone git://git.osmocom.org/$1 source/$1 > cd source/$1 > git checkout -b build-branch origin/$2 > cd $3 > autoreconf --install --force > ./configure --prefix=$BUILDDIR $4 > make check CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" ASAN_OPTIONS="detect_leaks=0" UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \ > || cat-testlogs.sh > make install CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" > cd $RET > } > > rm -rf $BUILDDIR > rm -rf source > mkdir -p source > mkdir -p $BUILDDIR/include/sysmocom/femtobts > > git clone git://git.sysmocom.de/sysmo-bts/layer1-api.git source/layer1-api/ > cp source/layer1-api/include/* $BUILDDIR/include/sysmocom/femtobts/ > > build libosmocore $LIBOSMOCORE_BRANCH ./ > build libosmo-abis $LIBOSMOABIS_BRANCH ./ > build libosmo-netif $LIBOSMONETIF_BRANCH ./ > build libosmo-sccp $LIBOSMOSCCP_BRANCH ./ > # gcc ice's > #build libsmpp34 $LIBSMPP_BRANCH > build openggsn $OPENGGSN_BRANCH ./ > build openbsc $OPENBSC_BRANCH ./openbsc "--enable-nat --enable-osmo-bsc --enable-vty-tests --enable-external-tests" > build osmo-pcu $OSMOPCU_BRANCH ./ "--enable-sysmocom-dsp --enable-vty-tests" > build osmo-bts $OSMOBTS_BRANCH ./ "--enable-sysmocom-bts --enable-trx" > > > -- > - 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 -- - 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 raji.oshin at hotmail.com Thu Dec 8 06:17:20 2016 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Thu, 8 Dec 2016 06:17:20 +0000 Subject: OpenBSC Digest, Vol 26, Issue 7 References: 2BmsaaerwUuAKqgyJAPKoQAAAAABDNgZrGmnq8FLgCqoMiQDyqEAAJuoJLM1 Message-ID: anyone know about rbs 2308 is supported yet or not...or still under experimental stage... thanks regards rajitha peiris sri Lanka Sent from my Mi phone On "openbsc-request at lists.osmocom.org" , Dec 7, 2016 11:11 PM wrote: Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: Paging not answered in m2m call (Holger Freyther) 2. Re: Paging not answered in m2m call (Kristian Martens) ---------------------------------------------------------------------- Message: 1 Date: Wed, 7 Dec 2016 18:13:10 +0100 From: Holger Freyther To: Kristian Martens Cc: openbsc at lists.osmocom.org Subject: Re: Paging not answered in m2m call Message-ID: Content-Type: text/plain; charset=us-ascii > On 07 Dec 2016, at 17:52, Kristian Martens wrote: > > Hello, Hi! > two UEs (A and B) are successfully registered in a network. Now A tries > to call B. B is paged by the core via A interface but the sysmoBSC/BTS > does not seem to page the UE (or UE does not answer paging). What could > be the reason for this behaviour? How could the problem be debugged? > Please find the attached pcap for your reference. nice MNC! The P-TMSI doesn't really look that random but it might be an index into an internal data structure? So on A this looks right. The LAI is 262-79-1 and this is where you are paging. In general it might be: * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ handling the location area identifier. You could trace the RSL protocol and see if a paging command is being sent (periodically) to the BTS? * The MS still has a radio channel open. I notice that clear command is being sent so this is unlikely to be the case. Also IMSI seems to be match.. maybe the MS still calculates the paging group wrongly? That is far fetched though. holger ------------------------------ Message: 2 Date: Wed, 7 Dec 2016 18:41:08 +0100 From: Kristian Martens To: Holger Freyther Cc: openbsc at lists.osmocom.org Subject: Re: Paging not answered in m2m call Message-ID: <9a4bcc68-e884-0f48-8a26-989b7edf5bca at ng4t.com> Content-Type: text/plain; charset="utf-8" Hi, I have captured a trace. Can you find something out? Thanks, Kristian Am 07.12.2016 um 18:13 schrieb Holger Freyther: >> On 07 Dec 2016, at 17:52, Kristian Martens wrote: >> >> Hello, > Hi! > >> two UEs (A and B) are successfully registered in a network. Now A tries >> to call B. B is paged by the core via A interface but the sysmoBSC/BTS >> does not seem to page the UE (or UE does not answer paging). What could >> be the reason for this behaviour? How could the problem be debugged? >> Please find the attached pcap for your reference. > > nice MNC! The P-TMSI doesn't really look that random but it might be an > index into an internal data structure? > > So on A this looks right. The LAI is 262-79-1 and this is where you are > paging. In general it might be: > > * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ > handling the location area identifier. You could trace the RSL protocol > and see if a paging command is being sent (periodically) to the BTS? > > * The MS still has a radio channel open. I notice that clear command is > being sent so this is unlikely to be the case. Also IMSI seems to be > match.. maybe the MS still calculates the paging group wrongly? That is > far fetched though. > > > holger -------------- next part -------------- A non-text attachment was scrubbed... Name: 20161207_nopaging.pcap Type: application/octet-stream Size: 26302 bytes Desc: not available URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 26, Issue 7 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arvind.Sirsikar at radisys.com Thu Dec 8 08:48:46 2016 From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar) Date: Thu, 8 Dec 2016 08:48:46 +0000 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: <20161207231031.GB30277@my.box> References: <20161130031419.GA9871@my.box> <20161207231031.GB30277@my.box> Message-ID: Hi Neels, >Aravind, can you find out the cause? You seem to be the most recent contributor >to the TbfTest. Can you please let me know how to reproduce this sanitizer build issue at my local machine? Thanks, Aravind Sirsikar From kristian.martens at ng4t.com Thu Dec 8 10:29:47 2016 From: kristian.martens at ng4t.com (Kristian Martens) Date: Thu, 8 Dec 2016 11:29:47 +0100 Subject: M2M call with no voice Message-ID: <6563f6b7-44ce-186b-357d-876ba348ebb1@ng4t.com> Hello, I got a mobile to mobile call working for signalling only. Two RTP channels are being established successfully. But there are only a few pattern sent over these channels (1 byte 0x23 as UDP payload). Is there a setting I am missing in the configuration files? Please find attached a .zip file with pcap and cfg files. Thanks, Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: sysmobsc_m2m_no_rtp.zip Type: application/x-zip-compressed Size: 28875 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Dec 8 11:30:55 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 8 Dec 2016 12:30:55 +0100 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: References: <20161130031419.GA9871@my.box> <20161207231031.GB30277@my.box> Message-ID: <20161208113055.GA1182@my.box> On Thu, Dec 08, 2016 at 08:48:46AM +0000, Aravind Sirsikar wrote: > Can you please let me know how to reproduce this sanitizer build issue at my local machine? My mail contained the build script of the sanitizer build. https://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html Thanks for taking this on! ~Neels -- - 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 holger at freyther.de Thu Dec 8 12:02:27 2016 From: holger at freyther.de (Holger Freyther) Date: Thu, 8 Dec 2016 13:02:27 +0100 Subject: M2M call with no voice In-Reply-To: <6563f6b7-44ce-186b-357d-876ba348ebb1@ng4t.com> References: <6563f6b7-44ce-186b-357d-876ba348ebb1@ng4t.com> Message-ID: <3821A2A6-5F45-465C-B2E3-E6E6F69DE0BF@freyther.de> > On 08 Dec 2016, at 11:29, Kristian Martens wrote: > > Hello, Hi! > I got a mobile to mobile call working for signalling only. Two RTP > channels are being established successfully. But there are only a few > pattern sent over these channels (1 byte 0x23 as UDP payload). Is there > a setting I am missing in the configuration files? Please find attached > a .zip file with pcap and cfg files. I didn't look at the trace yet but have you seen my comment about the SDP file? <000b> mgcp_protocol.c:830 Got media info via SDP: port 5502, payload 112 (GSM), duration 20, addr 192.168.17.100 <000b> mgcp_transcode.c:170 Checking transcoding: GSM (3) -> GSM (112) Why would one use a dynamic payload type for GSM FR1? I am not sure if the mgcp_mgw is optimized to avoid doing transcoding if input and output codec are the same but use different payload types. I would think it is. The 0x23 UDP payload is to establish a NAT state to be able to send traffic (e.g. ringtone) to a call for a BSC behind a NAT (all traffic will go from network->NAT/Firewall->MGCP MGW) and the only way to know the port is to have the BSC send some data. So in your trace I don't see: * UDP traffic from BTS to bsc_mgcp_mgw * UDP traffic from bsc_mgcp_mgw to 192.168.17.100:5500 * UDP traffic from 192.168.17.100:5500 to ... you get the point. Maybe start looking for where the BTS is sending the traffic to and take it from there? holger From msuraev at sysmocom.de Thu Dec 8 12:51:38 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 8 Dec 2016 13:51:38 +0100 Subject: range1024 encoding question Message-ID: <0febb9b4-6ce9-c821-8c42-559968f774ae@sysmocom.de> Hi. I've stumbled upon situation where range1024 encoding produces weird results - see gerrit #1373 and http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/1515/IU=--disable-iu,MGCP=--enable-mgcp-transcoding,SMPP=--disable-smpp,label=linux_amd64_debian8/console right before "Wrong number of arfcns" Is this because I call it somehow wrong or there's actually a flaw in our implementation? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Dec 8 22:26:32 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 8 Dec 2016 23:26:32 +0100 Subject: range1024 encoding question In-Reply-To: References: <0febb9b4-6ce9-c821-8c42-559968f774ae@sysmocom.de> Message-ID: In which repo it is? I don't know of other users but I might have overlooked smth. 08.12.2016 21:10, Holger Freyther ?????: > > hard to say. Initially I tried to use less storage but we have other range encoding users and testcases for it? E.g. Jacob created property based testing for it. Did you have a look there? > > holger > > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From Arvind.Sirsikar at radisys.com Fri Dec 9 06:57:18 2016 From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar) Date: Fri, 9 Dec 2016 06:57:18 +0000 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: <20161208113055.GA1182@my.box> References: <20161130031419.GA9871@my.box> <20161207231031.GB30277@my.box> <20161208113055.GA1182@my.box> Message-ID: Hi Neels, >https://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html The script you shared, expects arguments $1, $2, $3, $4. Please let me know what are these values. Thanks, Aravind Sirsikar From nhofmeyr at sysmocom.de Fri Dec 9 14:45:17 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Dec 2016 15:45:17 +0100 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: References: <20161130031419.GA9871@my.box> <20161207231031.GB30277@my.box> <20161208113055.GA1182@my.box> Message-ID: <20161209144517.GA1555@my.box> On Fri, Dec 09, 2016 at 06:57:18AM +0000, Aravind Sirsikar wrote: > Hi Neels, > > >https://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html > The script you shared, expects arguments $1, $2, $3, $4. Please let me know what are these values. No, it doesn't :) That's just the internal function expecting $N arguments, they are passed in upon invocation further below. The variables passed in by jenkins are the branch names to build, they are all simply 'master' and AFAICT can simply be omitted as well. I do see that you have submitted a patch that was already merged: https://gerrit.osmocom.org/1398 However, the sanitizer build still shows the same error message, with your patch in: https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/384/console +tbf_dl.cpp:766:65: runtime error: load of value 32766, which is not a valid value for type 'egprs_puncturing_values' Have you actually reproduced the error and fixed it, or have you just taken a shot in the dark with your patch? ;) Anyway, thanks again, I highly appreciate that you're investigating; none of us at sysmocom can possibly fit it in our schedules right now. ~Neels -- - 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 raji.oshin at hotmail.com Sat Dec 10 02:10:40 2016 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Sat, 10 Dec 2016 02:10:40 +0000 Subject: RBS 2308 Message-ID: Hi all... Anyone have success with rbs 2308 ??? If you have any idea pls share ... Thanks Regards Rajitha peiris Sri lanka Sent from my Mi phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Dec 10 15:12:03 2016 From: holger at freyther.de (Holger Freyther) Date: Sat, 10 Dec 2016 16:12:03 +0100 Subject: RBS 2308 In-Reply-To: References: Message-ID: <747F4621-5436-4CC6-903A-885AFD965DD5@freyther.de> > On 10 Dec 2016, at 03:10, Rajitha peiris wrote: > > > Hi all.. Hi! > Anyone have success with rbs 2308 ??? > If you have any idea pls share ... your contribution will be very welcome! Do you think you can still spend time on improving OpenBSC in 2016? regards holger From laforge at gnumonks.org Sat Dec 10 19:11:39 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Dec 2016 20:11:39 +0100 Subject: RFC: OsmoDevCon 2017 planning Message-ID: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc at lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] >From 2012 to 2016 we were running a series of small, invitation-only Osmocom Developer Conferences. Access was intentionally restricted to those community members who have demonstrated an existing track record of contribution to any of the projects under the Osmocom umbrella. This format of a small, tightly knit group of about 20 people has been successful over the years, and I have received a lot of positive feedback from past participants. On the other hand, the Osmocom project has grown in scope and diversity, and some of those projects don't have all that much relationship to each other - except being started by people from within the same group. There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at some point LTE) protocols which is attracting a lot of professional users. And then there's pure community projects like rtl-sdr, OsmocomBB, OsmocomGMR and many other efforts. Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow "standing out" of the othe projects in the context of having a wider user bsae, and in that user base also primarily commercial users. So I'd like to start a discussion on how to possibly change the event format to accomodate the various interests and parties. I definitely don't want to loose the "annual meeting of old friends" atmosphere, while at the same time also opening up to other interested parties. One idea would be to keep OsmoDevCon as-is and have a separate event where non-contributing/developing users / sysadmins / system integrators could also be attending. Another idea would be to split into a 'user day' and 'developer days' format. This is something the netfilter developer workshops have been using for many years, and from my limited insight quite successfully so. The "user day" is more like a traditional tech conference, with a large auditorium and talks oriented towards users / sysadmins / integrators of the software. The "developer days" are the invitation-only part, for known contributing developers only, similar to what we have at OsmoDevCon. Having both events (or both parts of an event) back-to-back has the advantage that a large number of potential speakers for the 'user day' are already present, and they don't have to travel yet another time. One could even structure it further and say we have one user day, one public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon classic', maybe reduced from 4 days to 3 or even 2 days only? What is the general opinion about this? Are there people lurking on this list who would be interested in attending a public 'user day' or even 'developer day' about the Osmocom cellular projects, with presentations and workshops around topics such as running Osmocom based cellular networks? In terms of when/where, I would suggest to keep the tradition of April in Berlin/Germany. But I'm of course very happy if somebody wants to host it some place else... Regards, and looking forward to meeting you [again] in 2017, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Sun Dec 11 01:02:33 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 11 Dec 2016 02:02:33 +0100 Subject: openbsc build was broken due to change in libosmocore: missing doc for 'log gsmtap [HOSTNAME]' Message-ID: <20161211010233.GA4378@my.box> The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item that's missing a doc string, hence breaking the openbsc build (which actually checks the doc strings unlike the libosmocore build job). I pushed the fix I734b22c950242541322e902887bf779c14ba10fd and things should light up "green" (aka blue) again. BTW, in a RL discussion lynxis suggested that it would be good if libosmocore commits were also checked against breaking openbsc. A point against it is that often something in libosmocore is changed and requires a follow-up in openbsc -- if the libosmocore build rejects commits that break openbsc, it would make it impossible to get these changes in. The workaround could be to have a secondary build job that merely comments on gerrit whether the openbsc build still works, without having -V voting powers. Anyway, so far I think it is sufficient to catch these hopefully few cases once the regular master build on jenkins.osmocore.org goes up red, like now. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sun Dec 11 01:20:41 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 11 Dec 2016 02:20:41 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161210191139.rxtzqrdmsifwgi4s@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Message-ID: <20161211012041.GB4378@my.box> On Sat, Dec 10, 2016 at 08:11:39PM +0100, Harald Welte wrote: > One idea would be to keep OsmoDevCon as-is and have a separate event > where non-contributing/developing users / sysadmins / system integrators > could also be attending. Over at Apache Subversion, we used to have parallel users' and developers' events, with conference style talks being held in one room and a hackathon next door for devs only. The advantage is that both happen alongside each other, so all people involved are guaranteed to be present. But the disadvantage was that we devs were drawn to the hacking room, while every hour or so one or two left to next door to hold a talk for the users -- so we'd pretty much never be all just there together to discuss something, with a background ruffle of last-minute slide edits and people leaving and coming back. In the end we went back to having *just* "DevCon" aka hackathon events, because it was more enjoyable and productive for the hackers. With that experience in mind, I think that, *if* we have a users' conference, we should indeed have the events back-to-back ... the "if" probably depending on the users' feedback. And my clear vote would be for Berlin, naturally. Unless ... we could decide to visit Holger in Amsterdam, too ;) ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Sun Dec 11 11:17:33 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Dec 2016 12:17:33 +0100 Subject: OpenBSC Digest, Vol 26, Issue 7 In-Reply-To: References: Message-ID: <20161211111733.slhanckatpbinog6@nataraja> Hi Rajitha, On Thu, Dec 08, 2016 at 06:17:20AM +0000, Rajitha peiris wrote: > anyone know about rbs 2308 is supported yet or not...or still under experimental stage... it was never fully supported, like all other RBS2000 / OM2000 devices. Like support for any BTS model in OpenBSC, it requires an number of people with actual interest in supporting the given device. None of the current developers that I know are working with that device. So if you have an interest in completing RBS2308 support, please join our development efforts. -- - 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 Dec 11 11:21:48 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Dec 2016 12:21:48 +0100 Subject: openbsc build was broken due to change in libosmocore: missing doc for 'log gsmtap [HOSTNAME]' In-Reply-To: <20161211010233.GA4378@my.box> References: <20161211010233.GA4378@my.box> Message-ID: <20161211112148.t3u7p4zi2hwg324e@nataraja> Hi Neels, On Sun, Dec 11, 2016 at 02:02:33AM +0100, Neels Hofmeyr wrote: > The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item > that's missing a doc string, hence breaking the openbsc build (which actually > checks the doc strings unlike the libosmocore build job). Sorry for that. And thanks for the clean-up. > Anyway, so far I think it is sufficient to catch these hopefully few cases once > the regular master build on jenkins.osmocore.org goes up red, like now. yes, still it's sad. I am wondering what else we could do. Maybe include an executable / test case that can verify the documentation strings inside libosmocore itself? I think specifically regarding vty documentation strings, this is not the first time we have seen this problem. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From raji.oshin at hotmail.com Sun Dec 11 13:02:19 2016 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Sun, 11 Dec 2016 13:02:19 +0000 Subject: RBS 2308 References: 2BmsaaerwUuAKqgyJAPKoQAAAAABDNgZrGmnq8FLgCqoMiQDyqEAAJ1bP-g1 Message-ID: hi dear... i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you.... regards rajitha Sent from my Mi phone On Holger Freyther , Dec 10, 2016 8:42 PM wrote: > On 10 Dec 2016, at 03:10, Rajitha peiris wrote: > > > Hi all.. Hi! > Anyone have success with rbs 2308 ??? > If you have any idea pls share ... your contribution will be very welcome! Do you think you can still spend time on improving OpenBSC in 2016? regards holger -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Dec 11 21:02:48 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Dec 2016 22:02:48 +0100 Subject: RBS 2308 In-Reply-To: References: Message-ID: <20161211210248.cfo2joepl3jc35u4@nataraja> Hi Rajitha, On Sun, Dec 11, 2016 at 01:02:19PM +0000, Rajitha peiris wrote: > i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you.... If you run into a specific issue, please always feel free to contact this list. But make sure to include your full config file, openbsc log output and pcap protocol trace. We need sufficient data for any kind of investigation. -- - 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 Dec 12 11:19:59 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Dec 2016 12:19:59 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 In-Reply-To: <20161019071443.ry3dp7offty2umrp@nataraja> References: <20161019071443.ry3dp7offty2umrp@nataraja> Message-ID: <20161212111959.foutxtvzokw346ri@nataraja> Hi Sebastian, as quite some time has passed, I was wondering if you had any follow-up? Have you published your existing progress/code in any publicly accessible repository? Remember: release early, release often :) I would love to see progress here, and if there's something I can help with, let me know. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Dec 12 12:05:05 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 12 Dec 2016 15:05:05 +0300 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161210191139.rxtzqrdmsifwgi4s@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Message-ID: Hi Harald, all, On Sat, Dec 10, 2016 at 10:11 PM, Harald Welte wrote: > Another idea would be to split into a 'user day' and 'developer days' > format. This is something the netfilter developer workshops have been > using for many years, and from my limited insight quite successfully so. > The "user day" is more like a traditional tech conference, with a large > auditorium and talks oriented towards users / sysadmins / integrators of > the software. The "developer days" are the invitation-only part, for > known contributing developers only, similar to what we have at > OsmoDevCon. > > Having both events (or both parts of an event) back-to-back has the > advantage that a large number of potential speakers for the 'user day' > are already present, and they don't have to travel yet another time. It would be great to have a user part at OsmoDevCon and having them back to back is the best option IMHO - exactly for the reasons above. > One could even structure it further and say we have one user day, one > public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon > classic', maybe reduced from 4 days to 3 or even 2 days only? Not sure why public developer part can't be a part of the public user part? Lets just find a good name for it which doesn't contain word "user". :) -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From sebastian.stumpf87 at googlemail.com Mon Dec 12 16:01:45 2016 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Mon, 12 Dec 2016 17:01:45 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 Message-ID: Hi Harald, > why send a private response and not a mail to the mailing list? Sorry, not intended - misclicked on respond instead of respond to all! :) > If you want, I can give you commit access so you can push your private > branches to git.osmocom.org. I just created an account on osmocom.org and logged in to gerrit via osmocom.org/openid (account: BastusIII). As I have never used git-send-email I prefer the commit access. Thank you! I would call the branches stumpf/virt-phy for both osmo-bts and osmocom-bb. With kind regards, Sebastian Am 12.12.2016 15:15 schrieb "Harald Welte" : Hi Sebastian, why send a private response and not a mail to the mailing list? I think they all are interested to read this. On Mon, Dec 12, 2016 at 01:57:05PM +0100, Sebastian Stumpf wrote: > I have not published the Code yet as the vlayer still lacks some basic > functionality. Would you suggest to do so already? yes, by all means. There's a difference between having code in the public for review / improvements by others and submitting it for inclsion into master as it is considered "fixed" If you want, I can give you commit access so you can push your private branches to git.osmocom.org. For that, you would have to create an account on gerrit.osmocom.org (which requires first creating one on osmocom.org) If you prefer to simply send a patchset by git-send-email or to host you git repos on github or any other git hosting site, that's fine, too. -- - 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 laforge at gnumonks.org Mon Dec 12 17:25:36 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Dec 2016 18:25:36 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 In-Reply-To: References: Message-ID: <20161212172536.4i7jfh4xxez2nhqs@nataraja> Hi Sebastian, On Mon, Dec 12, 2016 at 05:01:45PM +0100, Sebastian Stumpf wrote: > I just created an account on osmocom.org and logged in to gerrit via > osmocom.org/openid (account: BastusIII). I just added you to the respective group on gerrit. > As I have never used git-send-email I prefer the commit access. Thank you! > I would call the branches stumpf/virt-phy for both osmo-bts and osmocom-bb. you should be able to push to ssh://$USER at gerrit.osmocom.org:29418/osmo-bts.git branch users/* such as users/stumpf/virt-phy (the users/ part is important!) For OsmocomBB, we are not using Gerrit, so you'll have to mail me your ssh public key to get push access. -- - 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 Dec 12 23:04:00 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Dec 2016 00:04:00 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Message-ID: <20161212230400.f4mostkutiqtojzp@nataraja> Hi Alexander, On Mon, Dec 12, 2016 at 03:05:05PM +0300, Alexander Chemeris wrote: > > Having both events (or both parts of an event) back-to-back has the > > advantage that a large number of potential speakers for the 'user day' > > are already present, and they don't have to travel yet another time. > > It would be great to have a user part at OsmoDevCon and having them > back to back is the best option IMHO - exactly for the reasons above. Happy to see you agree there :) > > One could even structure it further and say we have one user day, one > > public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon > > classic', maybe reduced from 4 days to 3 or even 2 days only? > > Not sure why public developer part can't be a part of the public user > part? Lets just find a good name for it which doesn't contain word > "user". :) Well, the topics are invariably different. A user (aka "operator") cares about configuration + running + monitoring [the software], while a developers care about code architecture, interfaces, testing, etc. In general, there is not much overlap betwene those two groups, particularly not as their respective orgaization gets larger. Hence my proposal to split the two. Of course it could e a "morning/afternoon", a "day 1/day 2" or a "2 tracks in parallel" split. -- - 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 Dec 13 01:11:21 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 02:11:21 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 In-Reply-To: <20161212172536.4i7jfh4xxez2nhqs@nataraja> References: <20161212172536.4i7jfh4xxez2nhqs@nataraja> Message-ID: <20161213011121.GA856@my.box> On Mon, Dec 12, 2016 at 06:25:36PM +0100, Harald Welte wrote: > you should be able to push to > ssh://$USER at gerrit.osmocom.org:29418/osmo-bts.git branch > users/* such as users/stumpf/virt-phy (the users/ part is important!) 'users/' used to be important, but we decided to change that a while back, so that the old branches are still usable and to save some typing in git commands. Do add your own name of choice to group your private branches, though, like 'stumpf/foo'. The policy ATM: once you're accepted as a known user (which you are) you're free to create and mess up branches other than 'master', it's up to your discretion to stay in your own namespace. This policy is subject to change should anyone ever start to abuse others' namespaces, but I don't expect that to happen. We're all very civilized hackers. ~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 sebastian.stumpf87 at googlemail.com Tue Dec 13 10:05:36 2016 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Tue, 13 Dec 2016 11:05:36 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 In-Reply-To: <20161213011121.GA856@my.box> References: <20161212172536.4i7jfh4xxez2nhqs@nataraja> <20161213011121.GA856@my.box> Message-ID: Hi Neels, Harald, On Mon, Dec 12, 2016 at 06:25:36PM +0100, Harald Welte wrote: > I just added you to the respective group on gerrit. Thank you. > For OsmocomBB, we are not using Gerrit, so you'll have to mail me your > ssh public key to get push access. I currently have no access to my public key, just used it on my workplace till now. I'll send it to you on wednesday. And thank you both for the information regarding branching and policy. Kind Regards, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Dec 13 10:36:03 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 11:36:03 +0100 Subject: reduce gerrit mails? Message-ID: <20161213103602.GA2408@ass40.sysmocom.de> Hi Gerrit users, I follow the gerrit mails to get notified of comments and to catch failing builds. The message that a build started or was successful though doesn't help me much, only clutters up space, really. Do you agree? If yes, I would try to silence the "Build started" and "Build successful" messages in our gerrit, if possible without too much effort... ~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 Tue Dec 13 10:48:18 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 13 Dec 2016 11:48:18 +0100 Subject: reduce gerrit mails? In-Reply-To: <20161213103602.GA2408@ass40.sysmocom.de> References: <20161213103602.GA2408@ass40.sysmocom.de> Message-ID: > On 13 Dec 2016, at 11:36, Neels Hofmeyr wrote: > > Hi Gerrit users, > > > > If yes, I would try to silence the "Build started" and "Build successful" > messages in our gerrit, if possible without too much effort... no objection. From nhofmeyr at sysmocom.de Tue Dec 13 12:08:32 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 13:08:32 +0100 Subject: new sanitizer breakage: SIGSEGV in sgsn_create_pdp_ctx() Message-ID: <20161213120832.GA3854@ass40.sysmocom.de> The sanitizer build used to get through to testing the PCU, now it already fails at openbsc's sgsn test. This happens in the recently added test_pdp_deactivation_with_pdp_ctx: http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/388/consoleFull commit 1611df5226199da2bf2fba3d22d93cc1a6c6c777 Commit: Pravin Kumarvel CommitDate: Mon Dec 12 17:20:39 2016 +0530 Support Deactivate PDP Context Request from network https://gerrit.osmocom.org/1262 I can reproduce the segmentation fault locally, but only when the sanitizer is enabled. When stepping up to the failure and checking the parameters, all seems to be in order; immediately when trying to step into sgsn_create_pdp_ctx(), the SIGSEGV is fired. So far the actual failure is not clear to me, I haven't found the 0x02 pointer yet that asan complains about: ==21897==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000002 I found a use-after-free which isn't the cause for above asan failure: gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the local mm is non-NULL but freed. Change the order to: LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); (This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx() from test_pdp_deactivation()) The cause for the asan failure shown above and in jenkins still evades me. But I'm afraid we have to revert the patch. Please run the asan build on this patch and re-submit when the cause is clear. How to asan build has been discussed recently: http://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html ~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 Dec 13 12:41:51 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 13:41:51 +0100 Subject: reduce gerrit mails? In-Reply-To: <20161213103602.GA2408@ass40.sysmocom.de> References: <20161213103602.GA2408@ass40.sysmocom.de> Message-ID: <20161213124151.GA21935@ass40.sysmocom.de> I've found the mailing templates to *modify* what is sent, but no documented way to completely suppress a specific mail. If a template is removed, the default internal template is used. Possibly an empty template results in an empty message to trigger this code: if (body.length() == 0) { // If we have no message body, don't send. return false; } gerrit-server/src/main/java/com/google/gerrit/server/mail/OutgoingEmail.java But the jenkins notifications are apparently only comments like any other users', i.e. we'd need crafty filtering and such :/ Maybe I'll come back to this some other 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 Dec 13 13:08:31 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 14:08:31 +0100 Subject: TbfTest fails sanitizer build, please take a look @tbf-folks In-Reply-To: References: <20161130031419.GA9871@my.box> <20161207231031.GB30277@my.box> Message-ID: <20161213130831.GA22238@ass40.sysmocom.de> Hi Aravind, as said before I appreciate that you attempt to fix the sanitizer build, but unless you will actually reproduce the error on your machine and confirm a fix, we can go on merging random patches of yours indefinitely. Your second patch to fix asan is in, and the second time the very same problem persists: +tbf_dl.cpp:766:65: runtime error: load of value 32766, which is not a valid value for type 'egprs_puncturing_values' I sent the sanitizer build instructions before, but if it helps I can attach my personal asan build script that is able to reproduce the same sanitizer failure. It builds in a subdir 'build-2G' of each git. ~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: build_asan_2G.sh Type: application/x-sh Size: 1496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Dec 13 13:42:00 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 13 Dec 2016 14:42:00 +0100 Subject: new sanitizer breakage: SIGSEGV in sgsn_create_pdp_ctx() In-Reply-To: <20161213120832.GA3854@ass40.sysmocom.de> References: <20161213120832.GA3854@ass40.sysmocom.de> Message-ID: I think this situation will repeat itself over and over again until we make sanitizer tests part of our jenkins setup. On 13.12.2016 13:08, Neels Hofmeyr wrote: > The sanitizer build used to get through to testing the PCU, > now it already fails at openbsc's sgsn test. This happens in the recently added > test_pdp_deactivation_with_pdp_ctx: > > http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/388/consoleFull > > commit 1611df5226199da2bf2fba3d22d93cc1a6c6c777 > Commit: Pravin Kumarvel > CommitDate: Mon Dec 12 17:20:39 2016 +0530 > > Support Deactivate PDP Context Request from network > > https://gerrit.osmocom.org/1262 > > > I can reproduce the segmentation fault locally, but only when the sanitizer is > enabled. When stepping up to the failure and checking the parameters, all seems > to be in order; immediately when trying to step into sgsn_create_pdp_ctx(), the > SIGSEGV is fired. So far the actual failure is not clear to me, I haven't found > the 0x02 pointer yet that asan complains about: > > ==21897==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000002 > > > I found a use-after-free which isn't the cause for above asan failure: > > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > > gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the > local mm is non-NULL but freed. Change the order to: > > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > > (This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx() > from test_pdp_deactivation()) > > > The cause for the asan failure shown above and in jenkins still evades me. But > I'm afraid we have to revert the patch. Please run the asan build on this patch > and re-submit when the cause is clear. > > How to asan build has been discussed recently: > http://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html > > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Tue Dec 13 13:42:51 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 13 Dec 2016 14:42:51 +0100 Subject: reduce gerrit mails? In-Reply-To: <20161213124151.GA21935@ass40.sysmocom.de> References: <20161213103602.GA2408@ass40.sysmocom.de> <20161213124151.GA21935@ass40.sysmocom.de> Message-ID: <721c1f55-cfd0-4a16-38c2-ba8fff0ba05b@sysmocom.de> Maybe we can suppress it inside our smtp server? On 13.12.2016 13:41, Neels Hofmeyr wrote: > I've found the mailing templates to *modify* what is sent, but no documented > way to completely suppress a specific mail. > > If a template is removed, the default internal template is used. Possibly an > empty template results in an empty message to trigger this code: > > if (body.length() == 0) { > // If we have no message body, don't send. > return false; > } > gerrit-server/src/main/java/com/google/gerrit/server/mail/OutgoingEmail.java > > But the jenkins notifications are apparently only comments like any other > users', i.e. we'd need crafty filtering and such :/ > > Maybe I'll come back to this some other time... > > ~N > -- 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 Tue Dec 13 14:20:54 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 15:20:54 +0100 Subject: asan forward -- was: new sanitizer breakage[...] In-Reply-To: References: <20161213120832.GA3854@ass40.sysmocom.de> Message-ID: <20161213142054.GB22238@ass40.sysmocom.de> On Tue, Dec 13, 2016 at 02:42:00PM +0100, Max wrote: > I think this situation will repeat itself over and over again until we make > sanitizer tests part of our jenkins setup. That's why I'm continuously pressing for a clean sanitizer build so that we can finally add it everywhere. And I can use your help, as I said before. The openbsc already builds fine with asan now. So: Max, could you take the libosmocore asan patch a23817622b28cb1969a73ffd36da501eb29b9cd7 and apply the same to openbsc and the various libs openbsc depends on? I won't get around to it anytime soon, and I would appreciate sharing the work load on this. It should be mostly copy-paste work... I will gladly +2, and once we have those in, I can easily add asan builds to the gerrit build jobs. Thanks! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From raji.oshin at hotmail.com Tue Dec 13 14:22:22 2016 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Tue, 13 Dec 2016 14:22:22 +0000 Subject: RBS 2308 References: 2BmsaaerwUuAKqgyJAPKoQAAAAABDNgZrGmnq8FLgCqoMiQDyqEAAJ51OKU1 Message-ID: Hi dear.... i am tired with rbs 2308.... i have purchased nano bts....but i will try to improve that also.... if you have any updates pls letme... On Harald Welte , Dec 12, 2016 2:45 AM wrote: Hi Rajitha, On Sun, Dec 11, 2016 at 01:02:19PM +0000, Rajitha peiris wrote: > i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you.... If you run into a specific issue, please always feel free to contact this list. But make sure to include your full config file, openbsc log output and pcap protocol trace. We need sufficient data for any kind of investigation. -- - 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 nhofmeyr at sysmocom.de Tue Dec 13 14:23:43 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Dec 2016 15:23:43 +0100 Subject: reduce gerrit mails? In-Reply-To: <721c1f55-cfd0-4a16-38c2-ba8fff0ba05b@sysmocom.de> References: <20161213103602.GA2408@ass40.sysmocom.de> <20161213124151.GA21935@ass40.sysmocom.de> <721c1f55-cfd0-4a16-38c2-ba8fff0ba05b@sysmocom.de> Message-ID: <20161213142343.GC22238@ass40.sysmocom.de> On Tue, Dec 13, 2016 at 02:42:51PM +0100, Max wrote: > Maybe we can suppress it inside our smtp server? I also thought about a grep + rm shell script working on my maildir files :P ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Dec 13 17:29:04 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 13 Dec 2016 18:29:04 +0100 Subject: git tagging Message-ID: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> Hi. With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head So the questions are: - how can I add tag '0.9.3' to commit abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 in future? - what's the general guidelines for tagging new versions? Do we go through gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From alexander.chemeris at gmail.com Tue Dec 13 18:37:38 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 13 Dec 2016 21:37:38 +0300 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161212230400.f4mostkutiqtojzp@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <20161212230400.f4mostkutiqtojzp@nataraja> Message-ID: On Dec 13, 2016 2:15 AM, "Harald Welte" wrote: > > One could even structure it further and say we have one user day, one > > public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon > > classic', maybe reduced from 4 days to 3 or even 2 days only? > > Not sure why public developer part can't be a part of the public user > part? Lets just find a good name for it which doesn't contain word > "user". :) Well, the topics are invariably different. A user (aka "operator") cares about configuration + running + monitoring [the software], while a developers care about code architecture, interfaces, testing, etc. In general, there is not much overlap betwene those two groups, particularly not as their respective orgaization gets larger. Hence my proposal to split the two. Of course it could e a "morning/afternoon", a "day 1/day 2" or a "2 tracks in parallel" split On a second thought I do agree. Thank you for further explaining! I personally believe parallel tracks make most sense to save everyone's time, but it's up to organizers to decide, because it puts additional load on them. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Dec 13 23:21:52 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Dec 2016 00:21:52 +0100 Subject: git tagging In-Reply-To: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> References: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> Message-ID: <20161213232152.ooiydclb3gpv2zhb@nataraja> Hi Max, On Tue, Dec 13, 2016 at 06:29:04PM +0100, Max wrote: > With the migration to gerrit the situation around version tagging become > even funnier than before. For example right now in libosmocore v0.9.3 does > not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 > and 0.9.6 are committed in reversed order - see output of > git log --tags --show-notes --decorate | grep 'tag:' | head Thisis indeed odd. The normal procedure should be to push changes via the gerrit review process, and then after code has ended up in master push the related tags on those versions. > So the questions are: > - how can I add tag '0.9.3' to commit > abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore I just did "git tag -s 0.9.3 abc46af90fde9e9435dee5f4f472aec3f68d3353" "git push gerrit 0.9.3" I'm still waiting for this to show up in the public read-only repo on git.osmocom.org, though. > - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 > in future? The question is how did those tags end up in the repository? Was the above procedure used, or did somebody push the tags already while patches were still in review? > - what's the general guidelines for tagging new versions? Do we go through > gerrit or ask responsible person (who?) to do it manually? Or even auto-tag > commit matching certain criteria? I think I mentioned it recently somewehre: We should bump the minor version number each time a new symbol is added to libosmocore, so the code depending on new symbols can require a certian minimum version. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From shaddih at gmail.com Wed Dec 14 06:43:00 2016 From: shaddih at gmail.com (Shaddi Hasan) Date: Tue, 13 Dec 2016 22:43:00 -0800 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <20161212230400.f4mostkutiqtojzp@nataraja> Message-ID: Hi all, First, I think it's great you're considering doing this Harald. It's been exciting to see the user community develop around Osmocom projects, and I would be very interested in attending an in-person gathering. My $0.02 on splitting. I think the premise makes sense, given the very different focuses of the two groups, but I'd encourage if possible not doing parallel tracks. In my experience with other conferences, parallel tracks wind up forcing participants who are interested in both to make difficult decisions, leading to people missing out on things. Doing a temporal split (day 1/2 or morning/afternoon) would be my preference, but of course you and the other developers would be bearing the brunt of the time burden! At risk of bikeshedding, how about "OsmoCon" as a name for the entire event, with OsmoDevCon remaining the usual developer-only portion? Thanks, Shaddi On Tue, Dec 13, 2016 at 10:37 AM, Alexander Chemeris wrote: > > > > > On Dec 13, 2016 2:15 AM, "Harald Welte" wrote: > >> > One could even structure it further and say we have one user day, one >> > public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon >> > classic', maybe reduced from 4 days to 3 or even 2 days only? >> >> Not sure why public developer part can't be a part of the public user >> part? Lets just find a good name for it which doesn't contain word >> "user". :) > > Well, the topics are invariably different. A user (aka "operator") > cares about configuration + running + monitoring [the software], while a > developers care about code architecture, interfaces, testing, etc. > > In general, there is not much overlap betwene those two groups, > particularly not as their respective orgaization gets larger. > > Hence my proposal to split the two. Of course it could e a > "morning/afternoon", a "day 1/day 2" or a "2 tracks in parallel" split > > > On a second thought I do agree. Thank you for further explaining! > > I personally believe parallel tracks make most sense to save everyone's > time, but it's up to organizers to decide, because it puts additional load > on them. > > Please excuse typos. Written with a touchscreen keyboard. > > -- > Regards, > Alexander Chemeris > CEO Fairwaves, Inc. > https://fairwaves.co From msuraev at sysmocom.de Wed Dec 14 09:12:57 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 14 Dec 2016 10:12:57 +0100 Subject: git tagging In-Reply-To: <20161213232152.ooiydclb3gpv2zhb@nataraja> References: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> <20161213232152.ooiydclb3gpv2zhb@nataraja> Message-ID: <159a702e-1f11-ba1c-f5bd-7933f7e36ff4@sysmocom.de> Hi. Can we swap 0.9.5 and 0.9.6 than? I don't think any of the tools like gbp-dch can really accommodate for such an unexpected time flow in git history. On 14.12.2016 00:21, Harald Welte wrote: > Hi Max, > > On Tue, Dec 13, 2016 at 06:29:04PM +0100, Max wrote: > >> With the migration to gerrit the situation around version tagging become >> even funnier than before. For example right now in libosmocore v0.9.3 does >> not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 >> and 0.9.6 are committed in reversed order - see output of >> git log --tags --show-notes --decorate | grep 'tag:' | head > Thisis indeed odd. The normal procedure should be to push changes via > the gerrit review process, and then after code has ended up in master > push the related tags on those versions. > >> So the questions are: >> - how can I add tag '0.9.3' to commit >> abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore > I just did > > "git tag -s 0.9.3 abc46af90fde9e9435dee5f4f472aec3f68d3353" > "git push gerrit 0.9.3" > > I'm still waiting for this to show up in the public read-only repo on > git.osmocom.org, though. > >> - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 >> in future? > The question is how did those tags end up in the repository? Was the > above procedure used, or did somebody push the tags already while > patches were still in review? > >> - what's the general guidelines for tagging new versions? Do we go through >> gerrit or ask responsible person (who?) to do it manually? Or even auto-tag >> commit matching certain criteria? > I think I mentioned it recently somewehre: We should bump the minor > version number each time a new symbol is added to libosmocore, so the > code depending on new symbols can require a certian minimum version. > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Wed Dec 14 09:15:32 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Dec 2016 10:15:32 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <20161212230400.f4mostkutiqtojzp@nataraja> Message-ID: <20161214091532.isxlumqld7gxgwy4@nataraja> Hi Shaddi, On Tue, Dec 13, 2016 at 10:43:00PM -0800, Shaddi Hasan wrote: > First, I think it's great you're considering doing this Harald. It's > been exciting to see the user community develop around Osmocom > projects, and I would be very interested in attending an in-person > gathering. Thanks! I think it is ver useful not only for the respective users (and developers) to gain more input on Osmocom related projects, but also equally interesting for us to get more insight into who actually usees the software in whcih context, with which goals, etc. > My $0.02 on splitting. I think the premise makes sense, given the very > different focuses of the two groups, but I'd encourage if possible not > doing parallel tracks. In my experience with other conferences, > parallel tracks wind up forcing participants who are interested in > both to make difficult decisions, leading to people missing out on > things. Yes, I wasn't advocating parallel tracks, I was merely iterating theoretical options. I think it would be too difficult both venue-wise, as well as speaker-wise, and of course the difficult choices imposed on at least some attendees as you pointed out. > Doing a temporal split (day 1/2 or morning/afternoon) would be > my preference, but of course you and the other developers would be > bearing the brunt of the time burden! I don't see the actual event as the big burden, it's mostly the organizational matters regarding venue, catering, registrations, etc. that I'd expect to consume most of the time. And that luckily can be done at least to a large extent by non-developers. > At risk of bikeshedding, how about "OsmoCon" as a name for the entire > event, with OsmoDevCon remaining the usual developer-only portion? Good point. Unfortunately OSmocomBB already has an 'osmocon' program (the osmocom console program). Though the context should make it hard to mix-up, the programmer in me likes to not overload the global namespace ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sebastian.stumpf87 at googlemail.com Wed Dec 14 10:41:38 2016 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Wed, 14 Dec 2016 11:41:38 +0100 Subject: Osmo-bts/Osmocom-bb virtual layer 1 In-Reply-To: References: <20161212172536.4i7jfh4xxez2nhqs@nataraja> <20161213011121.GA856@my.box> Message-ID: Hi Harald, > For OsmocomBB, we are not using Gerrit, so you'll have to mail me your > ssh public key to get push access. ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBalMlb1Xe6r1qzi26v8AKRnuIQvi3cF0f5Q6C111SyGP+uI2tGhtoKJvsbX0mDAaIyIsU0qBB368P3hrT8RMMdXFB4FQYB+UzZ8F0wwRU4uigDLMkkKkGPhHP3YIpVqZX+1QVpgF3/gLdk0QoCvs/Ly6FHptEI4V6k5URqTzyv/w== sebastian.stumpf It is also attached to this mail. Hope the format is alright :). Kind Regards, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sebastian.stumpf.pub Type: application/vnd.ms-publisher Size: 225 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Dec 14 12:54:55 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Dec 2016 13:54:55 +0100 Subject: git tagging In-Reply-To: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> References: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> Message-ID: <20161214125455.GA7351@my.box> > - how can I add tag '0.9.3' to commit I made those tags recently, I also made a wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release One may need the appropriate pushing powers on gerrit to set a tag? Let me know if I should change access permissions... Could be good to agree whom to allow tagging and some guidelines. Above wiki page would be a good place to document such. > git log --tags --show-notes --decorate | grep 'tag:' | head commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3) In the revision history, 0.9.5 comes before 0.9.6, but 0.9.6 has an earlier commit date. This comes from to the way git does rebases: the commit's date remains the same as the original commit time. Most of our log history has wildly jumping dates. I'm not sure whether we will or should get rid of that. So, my guess is: the way the tags were created doesn't matter. We can't re-order the way they are displayed as long as the two *commits* that are tagged (whenever) keep the same dates: 2016-12-08 17:47 <0.9.6> 2016-12-10 17:01 <0.9.5> I can think of ways to work around it, sort of like $ git log --tags --show-notes --decorate | grep 'tag:' | sort -k 1.54 -r -V | head commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3) (though it would be good to filter on signed tags as well) The most important question: do we have an actual use case where this wrong ordering breaks anything? ~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 Dec 14 13:00:14 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Dec 2016 14:00:14 +0100 Subject: libosmocore[master]: Catch-up with git version tags References: Message-ID: <20161214130014.GB7351@my.box> On Tue, Dec 13, 2016 at 10:58:12PM +0000, Holger Freyther wrote: > Patch Set 1: Code-Review-1 > > The point of TODO-RELEASE is to remember ABI changes. An ABI change requires increasing the version number of the .so files (see the libtool link in Makefile.am for exact rules but we only bump for incompatible versions). Another point here could be that we can't just create a new minor tag without checking this? Does our non-existent policy dictate that an ABI version change should cause a bump in a "middle" version number? i.e. if a commit has been merged that has ABI changes and I want to tag a commit in order to reference it from another project's configure.ac, am I forced to make a bigger version bump than just 0.9.4 -> 0.9.5? All this would be good topics for the next OsmoDevCon... ~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 Dec 14 13:26:19 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Dec 2016 14:26:19 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161214091532.isxlumqld7gxgwy4@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <20161212230400.f4mostkutiqtojzp@nataraja> <20161214091532.isxlumqld7gxgwy4@nataraja> Message-ID: <20161214132619.GD7351@my.box> On Wed, Dec 14, 2016 at 10:15:32AM +0100, Harald Welte wrote: > > At risk of bikeshedding, how about "OsmoCon" as a name for the entire > > event, with OsmoDevCon remaining the usual developer-only portion? > > Good point. Unfortunately OSmocomBB already has an 'osmocon' program > (the osmocom console program). Though the context should make it hard > to mix-up, the programmer in me likes to not overload the global > namespace ;) I really like the name "OsmoCon" as such, and unless people run on FAT OsmoCon and osmocon are different names? :) On the meta meaning side, we're dropping from "Osmocom" the "com" part which means "communication", which is actually the most important part of the conference. OsmocomCon? OsmoComm? as in Osmocom Communication Conference... No idea. OsmoCon still has the nicest ring to it. Interestingly enough, there doesn't seem to be a naming conflict with events on chemical or biological topics (osmosis)... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From 246tnt at gmail.com Wed Dec 14 15:14:16 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 14 Dec 2016 16:14:16 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161210191139.rxtzqrdmsifwgi4s@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Message-ID: Hi, > This format of a small, tightly knit group of about 20 people has been > successful over the years, and I have received a lot of positive > feedback from past participants. Yes, I'm looking forward to it every year :) > Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, > OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow > "standing out" of the othe projects in the context of having a wider > user bsae, and in that user base also primarily commercial users. This seems pretty clear that those project stand out in several ways and could probably benefit from a public event. The reasons why OsmoDevCon is kept invitation-only mostly don't apply to theses. I think dev presentations regarding those could also be in the "user" even, but I'd keep workshop / discussion style events to the invitation only part. > Having both events (or both parts of an event) back-to-back has the > advantage that a large number of potential speakers for the 'user day' > are already present, and they don't have to travel yet another time. Definitely back-to-back, for the reasons you mentioned and I think different venues would also make sense. I'd also do the user part first, so that the dev part includes the weekend. > One could even structure it further and say we have one user day, one > public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon > classic', maybe reduced from 4 days to 3 or even 2 days only? 2 days seems short, especially since the last one of often just a half day with people leaving and from experience most of the 'hands-on' part are often done in the evening after the presentations and I'd have to diminish the time we have for that. > Are there people lurking on this list who would be interested in > attending a public 'user day' or even 'developer day' about the Osmocom > cellular projects, with presentations and workshops around topics such > as running Osmocom based cellular networks? That'd be the first thing to know : How many people would actually be interested to travel and attend a 1 or 2 day event. If it's only people from Berlin, then the usergroup would seem to be enough ? > In terms of when/where, I would suggest to keep the tradition of April > in Berlin/Germany. But I'm of course very happy if somebody wants to > host it some place else... Makes sense to keep it in Berlin IMHO. Cheers, Sylvain From msuraev at sysmocom.de Wed Dec 14 18:03:37 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 14 Dec 2016 19:03:37 +0100 Subject: git tagging In-Reply-To: <20161214125455.GA7351@my.box> References: <89cbfe5a-0dfb-fc27-967a-1897d910e061@sysmocom.de> <20161214125455.GA7351@my.box> Message-ID: I've checked with gbp dch and it seems to work fine - it treats commit log as emacs rather than as git log :) So we don't have to do anything about 0.9.5 and .6, pardon the noise. On 14.12.2016 13:54, Neels Hofmeyr wrote: >> - how can I add tag '0.9.3' to commit > I made those tags recently, I also made a wiki page: > https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release > > One may need the appropriate pushing powers on gerrit to set a tag? > Let me know if I should change access permissions... > Could be good to agree whom to allow tagging and some guidelines. > > Above wiki page would be a good place to document such. > >> git log --tags --show-notes --decorate | grep 'tag:' | head > commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) > commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) > commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) > commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) > commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3) > > In the revision history, 0.9.5 comes before 0.9.6, but 0.9.6 has an earlier > commit date. > > This comes from to the way git does rebases: the commit's date remains the same > as the original commit time. Most of our log history has wildly jumping dates. > I'm not sure whether we will or should get rid of that. > > So, my guess is: the way the tags were created doesn't matter. We can't > re-order the way they are displayed as long as the two *commits* that are > tagged (whenever) keep the same dates: > > 2016-12-08 17:47 <0.9.6> > 2016-12-10 17:01 <0.9.5> > > I can think of ways to work around it, sort of like > > $ git log --tags --show-notes --decorate | grep 'tag:' | sort -k 1.54 -r -V | head > commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) > commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) > commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) > commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) > commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3) > > (though it would be good to filter on signed tags as well) > > The most important question: do we have an actual use case where this wrong > ordering breaks anything? > > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Thu Dec 15 01:13:02 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 15 Dec 2016 02:13:02 +0100 Subject: [nhofmeyr@sysmocom.de: Re: Help required on : Reproducing the issue] Message-ID: <20161215011302.GB1219@my.box> On Wed, Dec 14, 2016 at 02:24:23PM +0000, Pravin Kumaravel Manoharan wrote: > I tried to reproduce the issue mentioned in http://lists.osmocom.org/pipermail/openbsc/2016-December/009966.html . > While running sanitizer script I got an error gcc: error: unrecognized command line option '-fsanitize=undefined' > So, to avoid this I removed the option from CFLAGS+= and CXXFLAGS+= . That's odd, all compilers I've used so far apparently support -fsanitize=address -fsanitize=undefined anyway: > Then I got the following error : > ERROR: Address Sanitizer: heap-use-after-free on address 0x60380000a00c at pc 0x436acf bp 0x7ffc4456d4e0 sp 0x7ffc4456d4d8 > but I didn't get any SIGSEGV in sgsn_create_pdp_ctx(). Have you reversed the order of those two lines I wrote about earlier to fix the use-after-free yet? This is what I wrote: > I found a use-after-free which isn't the cause for above asan failure: > > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > > gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the > local mm is non-NULL but freed. Change the order to: > > LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); > gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); > > (This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx() > from test_pdp_deactivation()) If you do that, do you still get any asan errors? I hope that you'll be able to reproduce the segfault, since it was seen on both our build server as well as my own laptop... ~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 ----- End forwarded message ----- -- - 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 Thu Dec 15 10:43:06 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 15 Dec 2016 11:43:06 +0100 Subject: reduce gerrit mails? In-Reply-To: <20161213142343.GC22238@ass40.sysmocom.de> References: <20161213103602.GA2408@ass40.sysmocom.de> <20161213124151.GA21935@ass40.sysmocom.de> <721c1f55-cfd0-4a16-38c2-ba8fff0ba05b@sysmocom.de> <20161213142343.GC22238@ass40.sysmocom.de> Message-ID: <20161215104306.GA1355@ass40.sysmocom.de> On Tue, Dec 13, 2016 at 03:23:43PM +0100, Neels Hofmeyr wrote: > I also thought about a grep + rm shell script working on my maildir files > :P I have in fact solved my problem locally now, so I won't press this from my side anymore, though I'd be +1 for reducing the mails for everyone. In maildir where each mail is in a separate file: move_to_dropped() { while read f; do # make sure jenkins is the sender if [ -n "$(grep '^From: Jenkins Builder $' "$f")" ]; then echo mv "$f" "$dropped_dir" mv "$f" "$dropped_dir" fi done } rgrep -l '^Build Started http://jenkins.osmocom.org/jenkins/job' "$inbox" | move_to_dropped rgrep -l '^Build Successful $' "$inbox" | move_to_dropped ~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 Fri Dec 16 13:10:43 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Dec 2016 14:10:43 +0100 Subject: libosmocore changes / release process Message-ID: <20161216131043.GA4292@my.box> When I now change pretty much anything in libosmocore that I want to use in e.g. openbsc.git, I would like to bump the minor revision and reference that in other projects' configure.ac. The effort is ok if it entails only tagging a revision and using that elsewhere. However, this has come down to a lengthy process: " cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE) update debian/changelog using "gbp dch" command " https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release#Make-a-Release So, pretty much every commit in libosmocore will be followed by another commit that is adjusting the changelog...? :/ Should we adjust the changelog along with pretty much any change used outside of libosmocore? :/ (probably not, because reverting anything is made cumbersome) Should we rather, like, make a libosmocore release only once a week and somehow track wich other projects need a bump to the required libosmocore version? I think most projects out there make a release tag only every now and then. We could limit to noting the required libosmocore change-id in other projects' commit logs until the next (minor) release is made...? Can we add a fourth level of version that doesn't require a changelog/debian release? So for every small change I make I would tag 0.9.6.1, 0.9.6.2, etc., and at some point we make 0.9.7 along with a changelog adjustment? Thoughts? ~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 msuraev at sysmocom.de Fri Dec 16 13:18:35 2016 From: msuraev at sysmocom.de (Max) Date: Fri, 16 Dec 2016 14:18:35 +0100 Subject: libosmocore changes / release process In-Reply-To: <20161216131043.GA4292@my.box> References: <20161216131043.GA4292@my.box> Message-ID: <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> Hi. I think making new release from libosmocore master just because something in OpenBSC (or other reverse dependency) master requires new functionality is just a waste of efforts. Instead I suggest to make it simple: - recent master version always requires recent master version of all the libraries (libosmo*): it might still work with some earlier version but that just means you're lucky - release version shall require appropriate release version of library This way we only have to make release for libosmo* when we're about to make release of OpenBSC, OsmoBTS etc. which does not happen that often. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Fri Dec 16 15:58:29 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Dec 2016 16:58:29 +0100 Subject: libosmocore changes / release process In-Reply-To: <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> Message-ID: <20161216155829.GA15953@my.box> Sounds good, but how do we keep track which libosmocore version a dependent project requires? When I add foo to libosmocore and use foo in openbsc, I will definitely forget which needs which by the time a release is made... Write down required bumps in TODO-RELEASE of libosmocore? ~N On Fri, Dec 16, 2016 at 02:18:35PM +0100, Max wrote: > Hi. > > I think making new release from libosmocore master just because something in > OpenBSC (or other reverse dependency) master requires new functionality is > just a waste of efforts. Instead I suggest to make it simple: > > - recent master version always requires recent master version of all the > libraries (libosmo*): it might still work with some earlier version but that > just means you're lucky > > - release version shall require appropriate release version of library > > This way we only have to make release for libosmo* when we're about to make > release of OpenBSC, OsmoBTS etc. which does not happen that often. > > -- > 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 > -- - 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 msuraev at sysmocom.de Fri Dec 16 16:04:32 2016 From: msuraev at sysmocom.de (Max) Date: Fri, 16 Dec 2016 17:04:32 +0100 Subject: libosmocore changes / release process In-Reply-To: <20161216155829.GA15953@my.box> References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> <20161216155829.GA15953@my.box> Message-ID: <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> I'd say write in both: - TODO-RELEASE in OpenBSC/OsmoBTS/whatever: "bump libosmo-X with change Y before release" - TODO-RELEASE in libosmo-*: "change Y: blah-blah" Unless someone can come with easier or more automatable scheme. On 16.12.2016 16:58, Neels Hofmeyr wrote: > Sounds good, but how do we keep track which libosmocore version a dependent > project requires? When I add foo to libosmocore and use foo in openbsc, I will > definitely forget which needs which by the time a release is made... > > Write down required bumps in TODO-RELEASE of libosmocore? > > ~N > -- 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 Fri Dec 16 23:20:11 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 17 Dec 2016 00:20:11 +0100 Subject: libosmocore changes / release process In-Reply-To: <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> <20161216155829.GA15953@my.box> <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> Message-ID: How about when you make a release N of libosmocore, right after the release and tag you already upgrade the version internally to N+1 Then when you use a new function in the lib and depend on it in OpenBSC, you can directly add dependency to libosmocore version N+1 in the OpenBSC automake stuff. Cheers, Sylvain From nhofmeyr at sysmocom.de Sun Dec 18 15:53:10 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Dec 2016 16:53:10 +0100 Subject: libosmocore changes / release process In-Reply-To: References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> <20161216155829.GA15953@my.box> <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> Message-ID: <20161218155310.GA2439@my.box> On Sat, Dec 17, 2016 at 12:20:11AM +0100, Sylvain Munaut wrote: > How about when you make a release N of libosmocore, right after the > release and tag you already upgrade the version internally to N+1 > > Then when you use a new function in the lib and depend on it in > OpenBSC, you can directly add dependency to libosmocore version N+1 in > the OpenBSC automake stuff. I'd like to +1 this, but for one implementation detail: at the moment e.g. an installation of libosmocore finds the most recent signed tag in git and bases the installed version number on that. So either we need a "moving tag" that continuously follows master (I think not), or we change the way that ./configure figures out what the current version number to be installed is. It's nice to have an automatic lookup, so that the git tag magically gives the right version number, but we do also have manual work to do in the debian files for a release anyway. So I guess it would be handy to note the version manually instead of using git tags (i.e. keep the .version file in git), then we could go with this scheme. We could have some sort of validation step in the release process to ensure a tag is also set on a revision with matching content in .version. I think it's a really good idea, what do you others think? ~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 msuraev at sysmocom.de Sun Dec 18 16:26:09 2016 From: msuraev at sysmocom.de (Max) Date: Sun, 18 Dec 2016 17:26:09 +0100 Subject: libosmocore changes / release process In-Reply-To: <20161218155310.GA2439@my.box> References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> <20161216155829.GA15953@my.box> <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> <20161218155310.GA2439@my.box> Message-ID: Hi. Some comments are inline. 18.12.2016 16:53, Neels Hofmeyr ?????: > I'd like to +1 this, but for one implementation detail: at the moment e.g. an > installation of libosmocore finds the most recent signed tag in git and bases > the installed version number on that. So either we need a "moving tag" that > continuously follows master (I think not), or we change the way that > ./configure figures out what the current version number to be installed is. Could describe this in more details? What exactly do you mean by "installation finds"? When I install new libosmocore locally via dpkg the version number is defined by the latest entry in debian/changelog. > It's nice to have an automatic lookup, so that the git tag magically gives the > right version number, but we do also have manual work to do in the debian files > for a release anyway. So I guess it would be handy to note the version manually > instead of using git tags (i.e. keep the .version file in git), then we could > go with this scheme. We could have some sort of validation step in the release > process to ensure a tag is also set on a revision with matching content in > .version. > > I think it's a really good idea, what do you others think? > I think it's extremely bad idea to keep auto-generated data under version control and than try to deal with version controlled vs autogenerated mess. Besides I don't really understand the problem you're trying to solve to begin with, but I'm pretty sure that storing generated version data under git is not the best way to go. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From nhofmeyr at sysmocom.de Sun Dec 18 16:30:40 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Dec 2016 17:30:40 +0100 Subject: sporadic gerrit build job failue: "broken pipe" Message-ID: <20161218163040.GA3132@my.box> We get this more often than not in the openbsc build job, I'm still not sure how to fix it: ====================================================================== ERROR: testBSCreload (__main__.TestVTYNAT) ---------------------------------------------------------------------- Traceback (most recent call last): File "./vty_test_runner.py", line 785, in testBSCreload b0 = nat_bsc_sock_test(0, "lol") File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test ipa_handle_resp(bsc, tk, verbose) File "./vty_test_runner.py", line 1260, in ipa_handle_resp x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) error: [Errno 32] Broken pipe ---------------------------------------------------------------------- Ran 43 tests in 51.717s FAILED (errors=1) Reducing the nr of executors hasn't had an effect yet. Could there be another cause? Too fragile timing or something? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sun Dec 18 16:55:22 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Dec 2016 17:55:22 +0100 Subject: libosmocore changes / release process In-Reply-To: References: <20161216131043.GA4292@my.box> <20decf44-dc11-83d4-6290-1515b3e1d482@sysmocom.de> <20161216155829.GA15953@my.box> <10bb5283-a192-819f-8a22-927317c01797@sysmocom.de> <20161218155310.GA2439@my.box> Message-ID: <20161218165522.GA3215@my.box> On Sun, Dec 18, 2016 at 05:26:09PM +0100, Max wrote: > Hi. > > Some comments are inline. > > 18.12.2016 16:53, Neels Hofmeyr ?????: > > I'd like to +1 this, but for one implementation detail: at the moment e.g. an > > installation of libosmocore finds the most recent signed tag in git and bases > > the installed version number on that. So either we need a "moving tag" that > > continuously follows master (I think not), or we change the way that > > ./configure figures out what the current version number to be installed is. > > Could describe this in more details? What exactly do you mean by "installation > finds"? When I install new libosmocore locally via dpkg the version number is defined > by the latest entry in debian/changelog. The local file '.version' is created by the 'make' step (if it doesn't exist yet), and it is created by git-version-gen, which looks up a signed tag in git. When I do 'make install', this is what determines the version number. Now, I'm entirely not sure how this goes in debian. Does the debian package version also come from this .version file, or by an entirely separate process? In that case a 'make install' could possibly install one version, and a debian package install could install another, both based on the exact same source tree... :/ > I think it's extremely bad idea to keep auto-generated data under version control and > than try to deal with version controlled vs autogenerated mess. My idea was to not auto-generate .version anymore, so we can manually N+1 the revision without having to set a revision tag. > Besides I don't really understand the problem you're trying to solve to begin with Sylvain's idea is to manually N+1 after a release. As I said, to get the version number to change during 'make install', I so far need a git tag; and I don't want to maintain a git tag that follows every single 'master' commit. Hence manual .version file. (Of course I could manually overwrite my local .version file, but the point is to find a general way to N+1 the version directly after a release.) Does my argument make more sense now? A problem I still see is that the .version file also contains a git hash that is auto-generated. But I notice that this is updated only when I manually rm the '.version' file, so it is usually out of date for my local builds. A bit of detail should be sorted out there, but you get my general direction. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From radiarisainanasitraka at yahoo.fr Mon Dec 19 04:16:05 2016 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Mon, 19 Dec 2016 04:16:05 +0000 (UTC) Subject: osmo-iuh-3G_2016_09 References: <69243631.9080287.1482120965466.ref@mail.yahoo.com> Message-ID: <69243631.9080287.1482120965466@mail.yahoo.com> Hello, I have some question, is it possible to run osmo-iuh with? the vodafone signal secure 3 !? or should I root it !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Dec 19 08:06:16 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Dec 2016 09:06:16 +0100 Subject: osmo-iuh-3G_2016_09 In-Reply-To: <69243631.9080287.1482120965466@mail.yahoo.com> References: <69243631.9080287.1482120965466.ref@mail.yahoo.com> <69243631.9080287.1482120965466@mail.yahoo.com> Message-ID: <20161219080616.zwz7mcbp7kjmqpxw@nataraja> Hi Radiarisainana, On Mon, Dec 19, 2016 at 04:16:05AM +0000, Radiarisainana Sitraka wrote: > I have some question, is it possible to run osmo-iuh with? the > vodafone signal secure 3 !? or should I root it !? As we documented and mentioned before, you will need a Femtocell that exposes the Iuh protocol (specifically, the RUA+HNBAP protocol layers) an that you can make connect to your server running osmo-hnbgw. This means that you have to control the femtocell. Whether or not you need to be root for that depends on the specific software architecture of your femtocell, and which parameters you have e.g. for configuring it. The authors of osmo-iuh have no experience with the specific model you mention. 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 Dec 19 08:55:46 2016 From: msuraev at sysmocom.de (Max) Date: Mon, 19 Dec 2016 09:55:46 +0100 Subject: sporadic gerrit build job failue: "broken pipe" In-Reply-To: <20161218163040.GA3132@my.box> References: <20161218163040.GA3132@my.box> Message-ID: <95e454fd-58db-0fb9-31e5-cb28868418e0@sysmocom.de> Does this happen on any build slave or only with some particular type? On 18.12.2016 17:30, Neels Hofmeyr wrote: > We get this more often than not in the openbsc build job, I'm still not sure > how to fix it: > > ====================================================================== > ERROR: testBSCreload (__main__.TestVTYNAT) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "./vty_test_runner.py", line 785, in testBSCreload > b0 = nat_bsc_sock_test(0, "lol") > File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test > ipa_handle_resp(bsc, tk, verbose) > File "./vty_test_runner.py", line 1260, in ipa_handle_resp > x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) > error: [Errno 32] Broken pipe > > ---------------------------------------------------------------------- > Ran 43 tests in 51.717s > > FAILED (errors=1) > > > Reducing the nr of executors hasn't had an effect yet. Could there be another > cause? Too fragile timing or something? > > ~N > > -- 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 Dec 19 12:33:20 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Dec 2016 13:33:20 +0100 Subject: indicating a necessary revision Message-ID: <20161219123320.GA1567@my.box> When committing a change that needs a specific change from another project, but that other change is still in the gerrit queue and has no final git commit hash yet, it is handy to use the Change-Id to reference the given decision. Harald recently requested that I always include the Change-Id in the commit log. Now Max says: > It's better to update commit log with git commit hash instead of change-id > before final submission. Can we get consensus? Should we modify the commit log from Change-Id to git hash once the required other commit is through? The Change-Id is always there and can be searched for in the git log; and should we ever decide to rehash the git history or move to another version control software (losing all git hashes), the Change-Id would still be there. But the git hash, once it is finalized, can be used directly on the git commandline. I wouldn't have done the extra effort, but if all agree that the git hash is better, I'll change it (and hopefully remember to do it, too). ~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 Dec 19 12:35:25 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Dec 2016 13:35:25 +0100 Subject: sporadic gerrit build job failue: "broken pipe" In-Reply-To: <95e454fd-58db-0fb9-31e5-cb28868418e0@sysmocom.de> References: <20161218163040.GA3132@my.box> <95e454fd-58db-0fb9-31e5-cb28868418e0@sysmocom.de> Message-ID: <20161219123525.GB1567@my.box> AFAICT it only happens on the linux_amd64_debian8 https://jenkins.osmocom.org/jenkins/computer/OsmocomBuild1/. ~N On Mon, Dec 19, 2016 at 09:55:46AM +0100, Max wrote: > Does this happen on any build slave or only with some particular type? > > > On 18.12.2016 17:30, Neels Hofmeyr wrote: > >We get this more often than not in the openbsc build job, I'm still not sure > >how to fix it: > > > >====================================================================== > >ERROR: testBSCreload (__main__.TestVTYNAT) > >---------------------------------------------------------------------- > >Traceback (most recent call last): > > File "./vty_test_runner.py", line 785, in testBSCreload > > b0 = nat_bsc_sock_test(0, "lol") > > File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test > > ipa_handle_resp(bsc, tk, verbose) > > File "./vty_test_runner.py", line 1260, in ipa_handle_resp > > x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) > >error: [Errno 32] Broken pipe > > > >---------------------------------------------------------------------- > >Ran 43 tests in 51.717s > > > >FAILED (errors=1) > > > > > >Reducing the nr of executors hasn't had an effect yet. Could there be another > >cause? Too fragile timing or something? > > > >~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From keith at rhizomatica.org Mon Dec 19 19:10:43 2016 From: keith at rhizomatica.org (Keith) Date: Mon, 19 Dec 2016 20:10:43 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161210191139.rxtzqrdmsifwgi4s@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> Message-ID: <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> Hi all. Latish response to this thread is no indication of lack of interest! I was travelling and then thinking somewhat about the response. Also, allow me to assume if you're reading, you've read the thread, so I'll dispense with quoting and inline commenting of contributions so far. On "User" or "Dev": I believe there may be a kind of third hybrid here. Yes I care about config, monitoring, running, and this leads to discovering both bugs and lacking features, which therefore leads to caring about code. Thus I've been slowly over the last year or so, making an attempt to get familiar with that. Please let me also say that the hospitality of the osmocom group and having had to opportunity have a one to one with certain key individuals at times has been an enormous help! Therefore I'm very happy with Harald's proposal, I would concur with others on avoiding a parallel event. That said, and also seeing that the response so far has been limited to the usual suspects (+Shaddi maybe), I might be a somewhat unique case in terms of user/dev cross over. On OpenBSC etc al: Yes, although I'm not dis-interested in the other Osmo projects, my main focus is of course the cellular infrastructure. So I do have an interest in attending the "dev" part on those projects, whereas attending the talks on other osmo project would be.. well, interesting but not warranting taking up space.. On Venue and organisation. Berlin seems as good a place as any. Why break with tradition. If one needs to travel it's a reasonably easy place to get to and not so expensive to be in. As no users have replied yet, at this point it looks unlikely to find volunteers to help with registration, catering, although that might come on stream later. At this point, I can't confirm anything myself. I wonder if there might be a sufficiently large group of Osmo Devs/Users/Fans at congress this year to warrant a brief meeting, say 30 mins to discuss a possible agenda (workshop/talk titles) of the potential user part of OsmoDevCon 2017? From laforge at gnumonks.org Mon Dec 19 21:50:49 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Dec 2016 22:50:49 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> Message-ID: <20161219215049.o5gp4nzxm6fhwsi6@nataraja> Dear all, for further planning, I have created a new project in the osmocom.org redmine. You can find it at https://osmocom.org/projects/osmo-dev-con/issues Please feel free to add tickts or to add information to the existing tickets. Time is running, so we should try to align on the exact format, time and venue soon, so we can work on an announcement to be publsihed, etc. 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 Dec 20 00:22:43 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Dec 2016 01:22:43 +0100 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> Message-ID: <20161220002243.n7ebrknc4qtw22z7@nataraja> Hi Keith, On Mon, Dec 19, 2016 at 08:10:43PM +0100, Keith wrote: > I believe there may be a kind of third hybrid here. of course. The point is not to introduce artificial barriers. It's just that there are some users/sysadmins that clearly are not concerned with or involved in development of the code. And that should be the biggest group of people, actually. > I wonder if there might be a sufficiently large group of Osmo > Devs/Users/Fans at congress this year to warrant a brief meeting, say 30 > mins to discuss a possible agenda (workshop/talk titles) of the > potential user part of OsmoDevCon 2017? We could do that, sure. Most of the "usual suspects" will be around at 33C3, I guess. -- - 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 Dec 21 13:15:45 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Dec 2016 14:15:45 +0100 Subject: sporadic gerrit build job failue: "broken pipe" In-Reply-To: <20161218163040.GA3132@my.box> References: <20161218163040.GA3132@my.box> Message-ID: <20161221131545.GA2702@ass40.sysmocom.de> On Sun, Dec 18, 2016 at 05:30:40PM +0100, Neels Hofmeyr wrote: > We get this more often than not in the openbsc build job, I'm still not sure > how to fix it: > > ====================================================================== > ERROR: testBSCreload (__main__.TestVTYNAT) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "./vty_test_runner.py", line 785, in testBSCreload > b0 = nat_bsc_sock_test(0, "lol") > File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test > ipa_handle_resp(bsc, tk, verbose) > File "./vty_test_runner.py", line 1260, in ipa_handle_resp > x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) > error: [Errno 32] Broken pipe > > ---------------------------------------------------------------------- > Ran 43 tests in 51.717s > > FAILED (errors=1) > > > Reducing the nr of executors hasn't had an effect yet. Could there be another > cause? Too fragile timing or something? I've reduced the nr of executors from 6 down to 2 now. If this 'broken pipe' still appears, I can set it back up. Although things don't necessarily go faster with more executors, we build with 'make -j 9'. ~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 Dec 21 13:23:40 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Dec 2016 14:23:40 +0100 Subject: sporadic gerrit build job failue: "broken pipe" In-Reply-To: <20161221131545.GA2702@ass40.sysmocom.de> References: <20161218163040.GA3132@my.box> <20161221131545.GA2702@ass40.sysmocom.de> Message-ID: <20161221132340.GB2702@ass40.sysmocom.de> On Wed, Dec 21, 2016 at 02:15:45PM +0100, Neels Hofmeyr wrote: > Although things don't necessarily go faster with more executors, we > build with 'make -j 9'. Correction: I notice that in the python tests phase of the openbsc build, the build slave's CPU is 97% idle... One of those things I'd like to understand one day: why those are so slow and how to speed them 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 alexander.chemeris at gmail.com Thu Dec 22 14:37:22 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 22 Dec 2016 17:37:22 +0300 Subject: Debugging osmo-trx constellation on XTRX SDR Message-ID: Hi Thomas, We're porting osmo-trx to our XTRX and we see some weird constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97). It looks like a normal GMSK circle is there, but there is also a square like if a signal is clipped. Do you have any idea what could cause this from your previous experience? We're running osmo-trx at 4 SPS. Then we double sample rate in software (XTRX can't handle sample rates below 2 MSPS yet) and then transmit. See first image above. Then we tried to increase sample rate and enabled 4x interpolation in LMS7 - that led to a distorted cicrle + square constellation (https://goo.gl/photos/zMZRecxmZsqiCYMHA). -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From choukoumoun at gmail.com Thu Dec 22 16:58:18 2016 From: choukoumoun at gmail.com (Choukou Moun) Date: Thu, 22 Dec 2016 17:58:18 +0100 Subject: [XTRX] Price? Message-ID: Hello. Wath is the price of the xtrx board ? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayuri.tendulkar at gmail.com Thu Dec 22 17:29:23 2016 From: mayuri.tendulkar at gmail.com (Mayuri Tendulkar) Date: Thu, 22 Dec 2016 22:59:23 +0530 Subject: Error of skipping buffer data Message-ID: Hi Team Has anybody seen error like below while running osmo-stack on B210? What could be the reason of this failure? We are seeing this randomly. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 31.9377 sec. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 NOTICE 140460079380224 20:17:34.0 Transceiver.cpp:306:stop: Stopping the transceiver ALERT 140460079314688 20:24:03.3 radioInterface.cpp:323:pullBuffer: Receive error 0 ERR 140460079314688 20:24:03.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 437.017 sec. Regards Mayuri -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Thu Dec 22 18:41:11 2016 From: tom at tsou.cc (Tom Tsou) Date: Thu, 22 Dec 2016 10:41:11 -0800 Subject: Debugging osmo-trx constellation on XTRX SDR In-Reply-To: References: Message-ID: Hi Alexander, On Thu, Dec 22, 2016 at 6:37 AM, Alexander Chemeris wrote: > We're porting osmo-trx to our XTRX and we see some weird > constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97). It looks like > a normal GMSK circle is there, but there is also a square like if a > signal is clipped. Do you have any idea what could cause this from > your previous experience? Squaring of the constellation is typically associated with overpowering some part of the chain. What does the spectrum look like? > We're running osmo-trx at 4 SPS. Then we double sample rate in > software (XTRX can't handle sample rates below 2 MSPS yet) and then > transmit. See first image above. > > Then we tried to increase sample rate and enabled 4x interpolation in > LMS7 - that led to a distorted cicrle + square constellation > (https://goo.gl/photos/zMZRecxmZsqiCYMHA). Again, check spectrum. Severe bandlimiting and overpower conditions will have visible spectrum effects. Also, the I/Q offset is high - consider offset tuning to remove DC and quadrature imbalance from the test scenario. -TT From alexander.chemeris at gmail.com Sat Dec 24 22:29:45 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 25 Dec 2016 01:29:45 +0300 Subject: Debugging osmo-trx constellation on XTRX SDR In-Reply-To: References: Message-ID: Hi Thomas, On Thu, Dec 22, 2016 at 9:41 PM, Tom Tsou wrote: > On Thu, Dec 22, 2016 at 6:37 AM, Alexander Chemeris > wrote: >> We're porting osmo-trx to our XTRX and we see some weird >> constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97). It looks like >> a normal GMSK circle is there, but there is also a square like if a >> signal is clipped. Do you have any idea what could cause this from >> your previous experience? > > Squaring of the constellation is typically associated with > overpowering some part of the chain. What does the spectrum look like? Spectrum looked fine, as far as I could tell. It looks like that was a result of interpolation inside of LMS7 - we probably misconfigured it somehow. Have to go through documentation for it again. When we disabled all interpolation within LMS7, we've got a proper circle (https://goo.gl/photos/QY9dEgMLLkYcvmCb9), but phase noise is still too high. Maybe because of an uncompensated LO leakage. We'll probably look into this next. >> We're running osmo-trx at 4 SPS. Then we double sample rate in >> software (XTRX can't handle sample rates below 2 MSPS yet) and then >> transmit. See first image above. >> >> Then we tried to increase sample rate and enabled 4x interpolation in >> LMS7 - that led to a distorted cicrle + square constellation >> (https://goo.gl/photos/zMZRecxmZsqiCYMHA). > > Again, check spectrum. Severe bandlimiting and overpower conditions > will have visible spectrum effects. Also, the I/Q offset is high - > consider offset tuning to remove DC and quadrature imbalance from the > test scenario. Yes, we haven't tuned IQ offset and DC at all yet. Now is probably a good time to look into this. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From nhofmeyr at sysmocom.de Sun Dec 25 00:38:30 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 25 Dec 2016 01:38:30 +0100 Subject: ki in osmo-nitb's built-in HLR db Message-ID: <20161225003830.GA8552@my.box> Merry x-mas! Just now I found a curious problem with the current osmo-nitb ciphering key. I'm working on the new VLR, which will inherently fix this issue, but in the course of that I recapped the current osmo-nitb's sequence of events for 2G ciphering as it is on the openbsc master branch. It so happens that I'm using a SIM card with a fabricated Ki value of hex: 000102030405060708090a0b0c0d0e0f i.e. starting with a zero byte. I was able to store this in and retrieve from the hlr.sqlite3 db: sqlite> INSERT INTO "AuthKeys" VALUES(57,2,X'000102030405060708090A0B0C0D0E0F'); sqlite> select hex(a3a8_ki) from AuthKeys; 000102030405060708090A0B0C0D0E0F So there were 16 bytes worth of BLOB in the Ki column for sure. But in openbsc's db.c in db_get_authinfo_for_subscr(), I always got DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=0) Curious, could it be the zero byte? Just to check, I put the zero byte further left: sqlite> select hex(a3a8_ki) from AuthKeys; hex(a3a8_ki) F00102030405060008090A0B0C0D0E ^ nonzero ^^ zero Now the log says: DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=5) f1 f3 f4 f5 f6 That's even weirder. I was expecting a 7 byte BLOB, of f0 01 02 03 04 05 06 and not f1 f3 f4 f5 f6 ... what on earth ... It appears that we've so far always been unable to use Ki keys that contain a zero byte, or apparently anything that's outside the 7bit ascii space ... ? To be able to recap what the old osmo-nitb is doing (without going to fetch a card reader from the office and reprogram the Ki on the SIM card), I fixed this bug with this funny little hack: https://gerrit.osmocom.org/1504 Todo: are other BLOB values also affected? Is there a better way to fix? Even though the new VLR is on its way, it might be good to get a fix like this out in the meantime ... though it appears that no-one is using ciphering on 2G anyway? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sun Dec 25 00:41:38 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 25 Dec 2016 01:41:38 +0100 Subject: ki in osmo-nitb's built-in HLR db In-Reply-To: <20161225003830.GA8552@my.box> References: <20161225003830.GA8552@my.box> Message-ID: <20161225004138.GB8552@my.box> On Sun, Dec 25, 2016 at 01:38:30AM +0100, Neels Hofmeyr wrote: > Just to check, I put the zero byte further left "the other left" :P ~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 Dec 25 08:27:43 2016 From: holger at freyther.de (Holger Freyther) Date: Sun, 25 Dec 2016 09:27:43 +0100 Subject: ki in osmo-nitb's built-in HLR db In-Reply-To: <20161225004138.GB8552@my.box> References: <20161225003830.GA8552@my.box> <20161225004138.GB8552@my.box> Message-ID: <1C07D8C3-7CD1-4176-A627-520938FECA49@freyther.de> > On 25 Dec 2016, at 01:41, Neels Hofmeyr wrote: > > On Sun, Dec 25, 2016 at 01:38:30AM +0100, Neels Hofmeyr wrote: >> Just to check, I put the zero byte further left > > "the other left" :P libdbi's blob escape.. e.g. check pySIM for how to escape the key.. or maybe just use the VTY to set the key. :) holger From nhofmeyr at sysmocom.de Sun Dec 25 15:59:05 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 25 Dec 2016 16:59:05 +0100 Subject: ki in osmo-nitb's built-in HLR db In-Reply-To: <1C07D8C3-7CD1-4176-A627-520938FECA49@freyther.de> References: <20161225003830.GA8552@my.box> <20161225004138.GB8552@my.box> <1C07D8C3-7CD1-4176-A627-520938FECA49@freyther.de> Message-ID: <20161225155905.GA24370@my.box> On Sun, Dec 25, 2016 at 09:27:43AM +0100, Holger Freyther wrote: > libdbi's blob escape.. e.g. check pySIM for how to escape the key.. or maybe just use the VTY to set the key. :) How dumb of libdbi ... and me. 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 alexander.chemeris at gmail.com Sun Dec 25 17:15:55 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 25 Dec 2016 20:15:55 +0300 Subject: [XTRX] Price? In-Reply-To: References: Message-ID: Dear Choukou, this mailing list is for OpenBSC project. Please use https://xtrx.io to ask questions about XTRX not related to OpenBSC. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co On Dec 22, 2016 7:58 PM, "Choukou Moun" wrote: > Hello. > > Wath is the price of the xtrx board ? > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From unigames2013 at yandex.ru Wed Dec 28 12:34:27 2016 From: unigames2013 at yandex.ru (=?utf-8?B?0KDQvtC00LjQvtC9INCT0LDQtNGL0YDRiNC40L0=?=) Date: Wed, 28 Dec 2016 15:34:27 +0300 Subject: OsmoNITB timeslots configuration and UmTRX Message-ID: <199641482928467@web33j.yandex.ru> Hello, list. I have umtrx v2.1 and I have already built GSM and GPRS components. Now I want to know which way of configuring timeslots in osmobsc.cfn is the best. I want GPRS, calls and SMS work. My current configuration is: timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config PDCH hopping enabled 0 timeslot 5 phys_chan_config PDCH hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 Is there a better way to configure? Maybe better use TCH/F_TCH/H_PDCH, but I have heard, that TCH/F is currently not working in dynamic configurations - only TCH/H does. And there is no only TCH/H_PDCH mode. So, could you please give me an advice? From keith at rhizomatica.org Wed Dec 28 18:45:57 2016 From: keith at rhizomatica.org (Keith) Date: Wed, 28 Dec 2016 18:45:57 +0000 Subject: RFC: OsmoDevCon 2017 planning In-Reply-To: <20161220002243.n7ebrknc4qtw22z7@nataraja> References: <20161210191139.rxtzqrdmsifwgi4s@nataraja> <0a568f52-03c3-5cc7-b96c-b11899c72d77@rhizomatica.org> <20161220002243.n7ebrknc4qtw22z7@nataraja> Message-ID: <2F780DAF-558C-4420-A3BC-8D6CD68840B9@rhizomatica.org> On 20 December 2016 01:22:43 CET, Harald Welte >30 >> mins to discuss a possible agenda (workshop/talk titles) of the >> potential user part of OsmoDevCon 2017? > >We could do that, sure. Most of the "usual suspects" will be around at >33C3, I guess. So, should we make a time for this to happen? From nhofmeyr at sysmocom.de Sat Dec 31 16:46:45 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 31 Dec 2016 17:46:45 +0100 Subject: OsmoNITB timeslots configuration and UmTRX In-Reply-To: <199641482928467@web33j.yandex.ru> References: <199641482928467@web33j.yandex.ru> Message-ID: <20161231164645.GC4721@my.box> Hi , we currently have two types of dynamic channels, both of which are available and working with osmo-bts-trx, with the limitation that OsmoNITB can't transcode TCH/H <-> TCH/F. See chapter 9.7 "Dynamic Timeslot Configuration" in the OsmoBSC User Manual https://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf and the reference to https://osmocom.org/issues/1778 in 9.7.1. Configuration suggestions are also found in that chapter. BTW, about TCH/H_PDCH: https://osmocom.org/issues/1781 ~N On Wed, Dec 28, 2016 at 03:34:27PM +0300, ?????? ???????? wrote: > Hello, list. > > I have umtrx v2.1 and I have already built GSM and GPRS components. Now I want to know which way of configuring timeslots in osmobsc.cfn is the best. I want GPRS, calls and SMS work. > My current configuration is: > > timeslot 0 > phys_chan_config CCCH+SDCCH4 > hopping enabled 0 > timeslot 1 > phys_chan_config SDCCH8 > hopping enabled 0 > timeslot 2 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 3 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 4 > phys_chan_config PDCH > hopping enabled 0 > timeslot 5 > phys_chan_config PDCH > hopping enabled 0 > timeslot 6 > phys_chan_config PDCH > hopping enabled 0 > timeslot 7 > phys_chan_config PDCH > hopping enabled 0 > > Is there a better way to configure? Maybe better use TCH/F_TCH/H_PDCH, but I have heard, that TCH/F is currently not working in dynamic configurations - only TCH/H does. And there is no only TCH/H_PDCH mode. So, could you please give me an advice? -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat Dec 31 18:43:34 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 31 Dec 2016 19:43:34 +0100 Subject: libosmocore[master]: libosmocoding: migrate transcoding routines from OsmoBTS References: Message-ID: <20161231184334.GD4721@my.box> On Sat, Dec 31, 2016 at 01:10:30PM +0000, Vadim Yanitskiy wrote: > Regarding to the change, there is a problem: despite all tests > pass without any problems on my machine, some tests fail on Jenkins. > I will try to find out, what's wrong. Let me know if I should install some library dependencies or similar on the build slaves... ~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: