From nhofmeyr at sysmocom.de Wed Jul 5 10:13:13 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Jul 2017 12:13:13 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> Message-ID: <20170705101313.GB5921@my.box> pespin has submitted a patch for osmo-trx that appears to completely fix the osmo-bts-trx clock skew instability problem! Please merge it if possible :) https://gerrit.osmocom.org/3120 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 domi at tomcsanyi.net Thu Jul 6 09:06:52 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Thu, 6 Jul 2017 11:06:52 +0200 (CEST) Subject: Creating GSM Users Association (GSMUA) In-Reply-To: <247401497031472@web42j.yandex.ru> References: <20170529081407.deqbb2gdycpcf7uf@nataraja> <247401497031472@web42j.yandex.ru> Message-ID: <37652F31-C745-47FE-B1D4-4D1218B4EDB0@tomcsanyi.net> Hello, I am sorry, but you seem to ignore a lot of things making it hard to have a meaningful conversation that actually brings something to the table. The leaks you keep mentioning are not comparable to each other at all - like apples and oranges. Calypso is a relatively simple system - at least compared to Qcom's Hexagon, and it still took years of work by and effort by talented people to have OsmocomBB running. So please stop saying that "leak is there what's stopping us". Qcom's architecture complexity is greater than Calypso's by multiple magnitudes. Last but not least I for sure would really appreciate if you would use proper punctuation, complete sentences and correct spelling of the right words. You could be young or old writing proper emails is always important. If I could do it using a touchscreen device you could as well. It makes your efforts and ideas look a lot more serious as well. I am sorry if I offended you, but I felt I need to tell you this and I couldn't stop myself. Kind regards, Domi 2017. j?l. 6. d?tummal, 10:14 id?pontban thayyil09 yil ?rta: > michela are you kidding ( dont worrry iam a kid at twentees) > > calypso bb starts from leaked Docs ( if not sorry ) > so why qcom code leak is ugly > > osmocom is for open softwear not for any specific hardware > so > > keeping updated with mainstream hardware is the way > so we may have to throw old one ( realy i never bcos i love it like my pet .old is Gold for me ) > but in concept its the way ( hope you understand it ) > > greetings for your GSMUA . iam sure and will there for any help. > i hope they will host your project. > its happy to know your the mother of freecalypso. > in softwear world you maybe first mom :) > > and i here for osmocom on qcom == osmodroidbb.wordpress.com > > if you mind helping me just put your hands on qcom leaked code > i stucked at understanding code. > still now i cant find where tmsi like layer3 things handling in qcom modem proc leaked code From pmaier at sysmocom.de Thu Jul 6 09:31:26 2017 From: pmaier at sysmocom.de (Philipp Maier) Date: Thu, 6 Jul 2017 11:31:26 +0200 Subject: sscp-context initalization via VTY In-Reply-To: <20170705161650.GA7799@my.box> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> Message-ID: <595E036E.1050905@sysmocom.de> Hello Neels, > (any reason to not discuss this on openbsc@?) I put it on CC. > Still missing in this proposal: how do you tell e.g. the MSC's A and IuCS code > to use a given SCCP instance, local SSN and remote SCCP address? I would add a VTY command where the user has to tell on which ss7 instance the A or IuCS interface should bind. When the IDs for both match up, we know that we use the same SCCP instance, but I think we do not even have to check that. Its implicit by the pointers. If the numbers are the same we will end up with the same sccp instance pointer for both. The SCCP-Addresses are defined by the addressbook. Which one is used will be configured via a VTY command seperately. The SSNs are hardcoded, so this is not a problem currently. If someone wants configurable SSNs and wants two users with different SSNs but same local point codes (which is mandatory in this case), then the user would have to define two addressbook entries where only the SSN is different. Logically this is then a different address and look at postal addresses, there its the same. Two different houses next to each other will have different addresses. The only difference is the number (SSN). At some point we have to make the cut. We could think about unifying the osmo_sccp_user_bind() function as well, so we would get pointers for ready-to-go sccp-users as well, but I think this is out of scope right now. The solution would be similar to the addressbook. We would just define nodes which hold the parameters. The results end up in a list and after parsing is done. The user can call a function that only gets the ID that references the parameter set, the pointer to the sscp instance and the function pointer for the SAP. e.g.: osmo_sccp_user_bind_id(sscp,2,sccp_sap_up) > A much simpler soultion to the problem would be to pack the configuration > options into struct osmo_ss7_instance. Then when the config file parsing > is done, the user must call a function e.g. "osmo_sscp_init()" or so to > trigger the call to osmo_sccp_simple_client(). In struct osmo_ss7_instance we already have the .cfg sub struct. I think we should add the items there instead of introducing something new. Also if we do so we would have to change it for the existing code too to have it consistent. Lets do some practical examples: 1) A and IuCS use the same sscp/ss7 instance cs7 instance 1 sccp-address msc_local point-code 0.0.2 routing-indicator PC sccp name iucs_and_a pc msc_local prot M3UA local-port 1234 remote-port 5678 local-ip 1.1.1.1 remote-ip 2.2.2.2 msc cs7-inst-a 1 cs7-inst-iucs 1 local-addr msc_local 1) A and IuCS use separate sscp/ss7 instances cs7 instance 1 sccp-address msc_local point-code 0.0.1 routing-indicator PC sccp name a pc msc_local prot M3UA local-port 1230 remote-port 5670 local-ip 1.1.1.4 remote-ip 2.2.2.4 cs7 instance 2 sccp-address msc_local point-code 0.0.2 routing-indicator PC sccp name iucs pc msc_local prot M3UA local-port 1234 remote-port 5678 local-ip 1.1.1.1 remote-ip 2.2.2.2 msc cs7-inst-a 1 cs7-inst-iucs 2 local-addr msc_local regards. Philipp -- Philipp Maier http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Jul 6 11:57:05 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 6 Jul 2017 13:57:05 +0200 Subject: semver for all Osmocom projects? Message-ID: HI. While working on smoothing out our release process (see https://projects.osmocom.org/issues/1861 and gerrit 3130, 3131, 3143) I've noticed that some of Osmocom projects follow semver [1] spec (OsmoBTS) while others don't (Osmo-PCU). Is this just "it happened this way" or there're other reasons for that? Shall we enforce semver for all projects? [1] http://semver.org/ -- 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 Jul 6 13:10:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 6 Jul 2017 15:10:37 +0200 Subject: sscp-context initalization via VTY In-Reply-To: <595E036E.1050905@sysmocom.de> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> <595E036E.1050905@sysmocom.de> Message-ID: <20170706131037.GA4576@my.box> > In struct osmo_ss7_instance we already have the .cfg sub struct. I think we > should add the items there instead of introducing something new. Also if we My concern was that we might mix scopes that should rather remain independent. I don't know any details or reasons though. Now I noticed that struct osmo_ss7_instance does contain an osmo_sccp_instance pointer as well as the sccp_address_book, i.e. they are already intimately related. So that seems to be the right place after all. These being so closely tied brings me to a simplification of the VTY I'll get to at the end of this mail. Will we ever use osmo_ss7_instance for anything else than SCCP? > 1) A and IuCS use the same sscp/ss7 instance > > cs7 instance 1 > sccp-address msc_local > point-code 0.0.2 > routing-indicator PC > sccp > name iucs_and_a > pc msc_local so this takes just the PC from the msc_local address, ok. Techincally we don't even need to define a separate address, but give only a PC: pc 0.0.2 This is much shorter; should be easy to allow both. (That's because osmo_sccp_simple_client() accepts a PC argument that is set as ss7->cfg.primary_pc. I wonder whether we use a routing indicator of PC in a hardcoded way then? Future plans?) > prot M3UA > local-port 1234 > remote-port 5678 For prot M3UA, the ports should be M3UA_PORT by default, if the port commands are omitted. > msc > cs7-inst-a 1 > cs7-inst-iucs 1 > local-addr msc_local [...] > msc > cs7-inst-a 1 > cs7-inst-iucs 2 > local-addr msc_local Let's allow two separate local SCCP addresses as well. Actually, I think we can drop the local-addr completely: It doesn't make sense to have the same ss7 instance wih two distinct local addresses; at least in the current code state, we can handle only one local PC per ss7 instance. And actually you already define a local PC in 'sccp' above with 'pc msc_local'. All that we need for osmo_sccp_user_bind() is an sccp instance pointer (taken from the osmo_ss7_instance) and an SSN (hardcoded). So this is sufficient: msc cs7-inst-a 1 cs7-inst-iucs 1 or msc cs7-inst-a 1 cs7-inst-iucs 2 One more thing: each ss7_instance will only find those address book entries defined in its own address book list, right? For example this won't work? cs7 instance 1 sccp-address address_on_instance_1 point-code 0.0.2 routing-indicator PC cs7 instance 2 sccp pc address_on_instance_1 That could be a reason to keep the address book separate from osmo_ss7_instance structs, as one global list usable everywhere, and also to place the address book vty commands on its own VTY scope. Can we make 'pc' rather 'local-pc'? If I explore the case of passing the PC directly and using a global SCCP address book, the VTY becomes simpler. We don't actually need an cs7-instance scope anymore, since all we do in it would be defining an SCCP instance: ! global address book would look something like this sccp-address msc_local point-code 0.0.2 sccp-address another_one point-code 0.0.3 ! The number '1' passed as the ss7 instance id. VTY shall disallow passing the ! same id another time. sccp-inst 1 name OsmoMSC local-pc msc_local ! or maybe just 'local-pc 0.0.2' prot M3UA local-ip 1.1.1.4 ! local-port 1230 remote-ip 2.2.2.4 ! remote-port 5670 msc iface-a sccp-inst 1 iface-iucs sccp-inst 1 OR even not needing any address book entries: sccp-inst 1 name OsmoMSC-A local-pc 0.0.2 prot M3UA local-ip 1.1.1.4 remote-ip 2.2.2.4 sccp-inst 2 name OsmoMSC-IuCS local-pc 0.23.0 prot M3UA local-ip 1.1.1.1 remote-ip 2.2.2.2 msc iface-a sccp-inst 1 iface-iucs sccp-inst 2 I like this better because it hides the unneeded duality of ss7-instance and sccp-instance from the config file, and it keeps the address book feature separate and optional. Does this make sense to you? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pespin at sysmocom.de Thu Jul 6 15:07:00 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 6 Jul 2017 17:07:00 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170705101313.GB5921@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> Message-ID: <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> On 05/07/17 12:13, Neels Hofmeyr wrote: > pespin has submitted a patch for osmo-trx that appears to completely fix the > osmo-bts-trx clock skew instability problem! Please merge it if possible :) > > https://gerrit.osmocom.org/3120 > The issue is still there, however error rate dropped dramatically after that patch. See for instance: https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/1186/console I think there are some bits remaining to be improved on the osmo-bts-trx side now in order to get rid of the issue. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From vmarcusv at gmail.com Thu Jul 6 19:54:07 2017 From: vmarcusv at gmail.com (Marcus Dias) Date: Thu, 6 Jul 2017 16:54:07 -0300 Subject: Question about activate GPRS Message-ID: Dear all, I have one sysmo2050, with the GSM running fine. However, i would like to test GPRS data transmission, I was following this setup page ( https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#OpenBSC-configuration), but i couldnt make it work. Anyone has done it before / can help me? Thanks beforehand, Marcus Dias UFPA - Lasse - LaPS -------------- next part -------------- An HTML attachment was scrubbed... URL: From hwelte at sysmocom.de Thu Jul 6 23:12:04 2017 From: hwelte at sysmocom.de (Harald Welte) Date: Fri, 7 Jul 2017 00:12:04 +0100 Subject: sscp-context initalization via VTY In-Reply-To: <595E036E.1050905@sysmocom.de> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> <595E036E.1050905@sysmocom.de> Message-ID: <20170706231204.2x75dmnd3oroox6g@nataraja> Hi Philipp and Neels, On Thu, Jul 06, 2017 at 11:31:26AM +0200, Philipp Maier wrote: > > (any reason to not discuss this on openbsc@?) > I put it on CC. > > > Still missing in this proposal: how do you tell e.g. the MSC's A and IuCS > code > > to use a given SCCP instance, local SSN and remote SCCP address? > > I would add a VTY command where the user has to tell on which ss7 instance > the A or IuCS interface should bind. When the IDs for both match up, we know > that we use the same SCCP instance, but I think we do not even have to check > that. Its implicit by the pointers. If the numbers are the same we will end > up with the same sccp instance pointer for both. sounds fine. > > A much simpler soultion to the problem would be to pack the configuration > > options into struct osmo_ss7_instance. Then when the config file parsing > > is done, the user must call a function e.g. "osmo_sscp_init()" or so to > > trigger the call to osmo_sccp_simple_client(). > > In struct osmo_ss7_instance we already have the .cfg sub struct. I think we > should add the items there instead of introducing something new. Also if we > do > so we would have to change it for the existing code too to have it > consistent. > > Lets do some practical examples: > > 1) A and IuCS use the same sscp/ss7 instance > > cs7 instance 1 > sccp-address msc_local > point-code 0.0.2 > routing-indicator PC > sccp > name iucs_and_a > pc msc_local > prot M3UA > local-port 1234 > remote-port 5678 > local-ip 1.1.1.1 > remote-ip 2.2.2.2 No, this looks wrong. Why are we inventing new VTY configuration for anything below the SCCP protocol layer? This is all already present in libosmo-sigtran? The application *only* cares about using the SCCP User SAP. It does not care about what happens below that SAP, and who and how it is configured. What signalling links exist, and which protocol (M3UA) they use, etc. is all out of scope/concern here. This is done by the existing 'cs7 as' and 'cs7 asp' and friends. The only difference between STP and ASP side configuration in all of the related data structures is a single flag. So whether you configure an AS/ASP on the STP, or you do that on the ASP side (e.g. OsmoMSC) is not different. I'm not entirely happy about the amount of discussion this entire topic is drawing up, for several weeks. IMHO it should in fact be very straight forward and simple: * osmo_ss7 code handles M3UA + related config/vty (99.9% exists for months) * osmo_sccp code handles SCCP address book * application simply uses adresses from SCCP address book. By the addresses being each part of a ss7 instance, it is well-defined via which SCCP-instance communication to the respective peer should happen, and that SCCP instance is bound to the respective SS7 instacne. Please let me know which particular part I am missing here? -- - Harald Welte 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 hwelte at sysmocom.de Thu Jul 6 23:22:05 2017 From: hwelte at sysmocom.de (Harald Welte) Date: Fri, 7 Jul 2017 00:22:05 +0100 Subject: sscp-context initalization via VTY In-Reply-To: <20170706131037.GA4576@my.box> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> <595E036E.1050905@sysmocom.de> <20170706131037.GA4576@my.box> Message-ID: <20170706232205.jwlvriaydoxytxmi@nataraja> Hi Neels and Philipp, On Thu, Jul 06, 2017 at 03:10:37PM +0200, Neels Hofmeyr wrote: > Will we ever use osmo_ss7_instance for anything else than SCCP? no current plans, but completely likely for e.g. ISUP. > (That's because osmo_sccp_simple_client() accepts a PC argument that is set as > ss7->cfg.primary_pc. I wonder whether we use a routing indicator of PC in a > hardcoded way then? Future plans?) Can you please all get detached from what simple_client() currently does? It is nothing less than a crude hack that I introduced so we (and particularly Philipp) can make quick progress on the higher layers without having to wait for the then-non-existant ss7 vty code in libosmo-sccp and the related full configuration, using OsmoSTP, etc. So whatever that API hack does or doesn't do is not really relevant in the bigger picture. > So this is sufficient: > > msc > cs7-inst-a 1 > cs7-inst-iucs 1 The MSC should point to the address book (by name) and the address book contains the point code and/or global title, etc. (i.e. the local sccp address) that it should use, together with the ss7 instance number. anything else is determined by configuration of the lower layer in osmo_ss7 vty. > One more thing: each ss7_instance will only find those address book entries > defined in its own address book list, right? yes. > If I explore the case of passing the PC directly and using a global SCCP > address book, the VTY becomes simpler. We don't actually need an cs7-instance > scope anymore, since all we do in it would be defining an SCCP instance: Configuration of the SCCP instance and anything below it are not the concern of the MSC. Please do not mix the layers. As analogy: You also don't configure the MAC address and the IP address, netmask, IP routes, etc. in the system when you crate a TCP socket. The Ethernet and IP layer configuration (e.g. MTP/M3UA/ASP/links/linksets/routes/...) is independent of the application layer, where when you bind a socket, you simply specify one of many local IP addresses + the respective port number. The fact that various layers are running within one process, or the fact that they share one config file / vty doesn't mean those parts are not separate and have a *very* thin line of interaction: The SCCP-User-SAP only. Regards, Harald -- - Harald Welte 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 Jul 7 00:43:26 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 7 Jul 2017 02:43:26 +0200 Subject: VTY errors Message-ID: <20170707004326.GA9089@my.box> I have a problem with VTY validation. When there is wrong command formatting, we exit VTY parsing in error, which leads to a program exit in error. However, if the format matches but the value is wrong in a way that the VTY format description is unable to detect, the way to escalate an error up the VTY call chain is a bit weird. The concrete item in question is the SCCP address point code. The format is like A.B.C, while ranges are variable depending on configuration. point-code 0.0.1 If I write 'point-code 0.0.99', it exceeds the range and I want to immediately abort the program, indicating the VTY config error. If I return CMD_WARNING, it is merely ignored. There are various CMD_ERR_* values to return, but there is no plain error like CMD_ERR_INVALID_VALUE. I can for example return CMD_ERR_AMBIGUOUS; then the code will try to parse the same line a second time, to see whether the command succeeds on a child of the parent node (we had this before, about implicit node 'exit'). DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99' DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99' There is no such command. Error occurred during reading below line: point-code 0.42.99 % Power 21 dB is not an even value Invalid point code (0.42.99) Invalid point code (0.42.99) This result is rather curious. I would like to have a CMD_ERROR return value that immediately exits VTY parsing with a clear error return code. (We can't abort with an assertion, because that would cause the program to exit in case someone enters a wrong value on the telnet VTY.) This is the function in question: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); // I would insert something like this: // if (ret == CMD_ERROR) // return ret; /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); // same here } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } Am I on the right track here, have I missed 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 nhofmeyr at sysmocom.de Fri Jul 7 00:59:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 7 Jul 2017 02:59:36 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> Message-ID: <20170707005936.GB9089@my.box> On Thu, Jul 06, 2017 at 05:07:00PM +0200, Pau Espin Pedrol wrote: > > > On 05/07/17 12:13, Neels Hofmeyr wrote: > >pespin has submitted a patch for osmo-trx that appears to completely fix the > >osmo-bts-trx clock skew instability problem! Please merge it if possible :) > > > >https://gerrit.osmocom.org/3120 > > > > The issue is still there, however error rate dropped dramatically after that > patch. See for instance: > https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/1186/console To clarify the term "dramatically": failure rate is now about three out of 50 tester runs, i.e. three out of 100 osmo-bts-trx tests. Lately it had been failing every second test, so the improvement is huge, from 50% down to 3%. Kudos to pespin for finding that issue. Hopefully we can also get rid of the remaining odd failure. Interesting that it doesn't happen every time, nor on everyone else's equipment. Maybe CPU speed or faster I/O makes it less likely to happen. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tom at tsou.cc Fri Jul 7 01:23:06 2017 From: tom at tsou.cc (Tom Tsou) Date: Thu, 6 Jul 2017 18:23:06 -0700 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170707005936.GB9089@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> <20170707005936.GB9089@my.box> Message-ID: On Thu, Jul 6, 2017 at 5:59 PM, Neels Hofmeyr wrote: > Kudos to pespin for finding that issue. Hopefully we can also get rid of the > remaining odd failure. Absolutely. > Interesting that it doesn't happen every time, nor on everyone else's > equipment. Maybe CPU speed or faster I/O makes it less likely to happen. That is likely. The bts-trx socket interface has been fairly static and I know that L2 scheduling issues have existed in OpenBTS. I doubt that there has been any recent regression; the use of faster CPU's has probably been covering up the issue for a very long time. -TT From nhofmeyr at sysmocom.de Fri Jul 7 02:04:39 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 7 Jul 2017 04:04:39 +0200 Subject: sscp-context initalization via VTY In-Reply-To: <20170706231204.2x75dmnd3oroox6g@nataraja> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> <595E036E.1050905@sysmocom.de> <20170706231204.2x75dmnd3oroox6g@nataraja> Message-ID: <20170707020439.GC9089@my.box> On Fri, Jul 07, 2017 at 12:12:04AM +0100, Harald Welte wrote: > I'm not entirely happy about the amount of discussion this entire topic > is drawing up, for several weeks. IMHO it should in fact be very > straight forward and simple: "All" that we need is a blueprint of what the OsmoMSC's VTY configuration should look like, the rest would fall into place. It would be quite helpful if you could provide us with that so that we can see it in a straight forward way. Can you re-arrange this (or any other suggestion) to match your expectations: sccp-inst 1 name OsmoMSC-A local-pc 0.0.2 prot M3UA local-ip 1.1.1.4 remote-ip 2.2.2.4 sccp-inst 2 name OsmoMSC-IuCS local-pc 0.23.0 prot M3UA local-ip 1.1.1.1 remote-ip 2.2.2.2 msc iface-a sccp-inst 1 iface-iucs sccp-inst 2 The bounds are... I cannot use two distinct local SCCP addresses with one osmo_ss7_instance; current code dictates a single local PC. If I configure A and IuCS on the same SS7 instance but use distinct addresses, it will silently not work. There can be only one SCCP client tied to a given osmo_ss7_instance, the osmo_ss7_instance->sccp pointer is a 1:1 relation. (Shouldn't it be the other way, the sccp instance having a pointer to an ss7?) Address names are scoped per osmo_ss7_instance, so I can easily have the same name in two separate ss7 instances. Hence the application needs to be aware of which instance it should take the address from. Why not one global name scope? It is also conceivable that I want to use the same SCCP address in two distinct SS7+SCCP instances, e.g. using the same PC in distinct STP spheres. The application dictates an SSN, which is technically part of the SCCP address, but nevertheless should not be VTY configurable. Basically all that we want to configure of the local SCCP address *is* a local PC. Each single SCCP client will connect to one OsmoSTP remote. We need to bind to a local IP address and contact a remote one. It makes sense to write that VTY once and re-use in every application. We can run both A and IuCS on the same SCCP instance using an identical local PC and connecting to the same STP; Or we can have each on its own SCCP instance with distinct PCs and STPs. This should be cast into a plain VTY structure that is helpful in avoiding mistakes. ~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 Jul 7 02:14:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 7 Jul 2017 04:14:53 +0200 Subject: Question about activate GPRS In-Reply-To: References: Message-ID: <20170707021453.GD9089@my.box> On Thu, Jul 06, 2017 at 04:54:07PM -0300, Marcus Dias wrote: > Dear all, > > I have one sysmo2050, with the GSM running fine. However, i would like to > test GPRS data transmission, I was following this setup page ( > https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#OpenBSC-configuration), > but i couldnt make it work. Anyone has done it before / can help me? Hard to help with this little information. I have attached a tar with scripts and configs I use to run voice and data on a sysmoBTS. Note that this is a rather convoluted way that fits my personal needs of development testing. Maybe you can figure something out from it... Feel free to ask more specific questions here, including your config and error symptoms. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: sysmo.tgz Type: application/x-gtar-compressed Size: 3841 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 pespin at sysmocom.de Sun Jul 9 16:35:51 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 9 Jul 2017 18:35:51 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> <20170707005936.GB9089@my.box> Message-ID: Hi, On 07/07/17 03:23, Tom Tsou wrote: > On Thu, Jul 6, 2017 at 5:59 PM, Neels Hofmeyr wrote: >> Kudos to pespin for finding that issue. Hopefully we can also get rid of the >> remaining odd failure. > > Absolutely. > >> Interesting that it doesn't happen every time, nor on everyone else's >> equipment. Maybe CPU speed or faster I/O makes it less likely to happen. > > That is likely. The bts-trx socket interface has been fairly static > and I know that L2 scheduling issues have existed in OpenBTS. I doubt > that there has been any recent regression; the use of faster CPU's has > probably been covering up the issue for a very long time. > On top of that, I think the issues come too from the fact that we are starting the whole network in an automatic way at the same time, which increases the number of messages and time required to sync everything and become stable. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Mon Jul 10 09:59:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 10 Jul 2017 11:59:35 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> <20170707005936.GB9089@my.box> Message-ID: <20170710095935.GA32278@my.box> On Sun, Jul 09, 2017 at 06:35:51PM +0200, Pau Espin Pedrol wrote: > On top of that, I think the issues come too from the fact that we are > starting the whole network in an automatic way at the same time, which > increases the number of messages and time required to sync everything and > become stable. I did try once to add several seconds of delay between launching osmo-trx and osmo-bts-trx, without effect, so I doubt that it's system load. (osmo-bts-trx is typically the last program to be launched.) ~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 Jul 10 10:20:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 10 Jul 2017 12:20:53 +0200 Subject: sscp-context initalization via VTY In-Reply-To: <20170706231204.2x75dmnd3oroox6g@nataraja> References: <595CED00.9090904@sysmocom.de> <20170705161650.GA7799@my.box> <595E036E.1050905@sysmocom.de> <20170706231204.2x75dmnd3oroox6g@nataraja> Message-ID: <20170710102053.GA1259@my.box> On Fri, Jul 07, 2017 at 12:12:04AM +0100, Harald Welte wrote: > No, this looks wrong. Why are we inventing new VTY configuration for > anything below the SCCP protocol layer? This is all already present in > libosmo-sigtran? Argh, missed this one. I now see that there are VTY commands for local and remote IPs, we'll take looks. ~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 Jul 10 15:33:14 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 10 Jul 2017 17:33:14 +0200 Subject: plan for openbsc.git split and code review Message-ID: <20170710153314.GA1446@my.box> I am currently setting up separate repositories to replace openbsc.git. Aspects: - choice how to separate - apply 3G and AoIP changes to do code review My plan is to separate openbsc.git into these parts: osmo-msc.git = OsmoMSC osmo-bsc.git = OsmoBSC, OsmoBSCNAT osmo-sgsn.git = OsmoSGSN, OsmoGTPHUB osmo-mgw.git = new OsmoMGW, at first plain renamed from osmo-bsc_mgcp + libosmo-mgcp Each of these will contain the full openbsc.git history to be able to follow changes back in the log easily. The libmgcp has so far been internal to openbsc.git. I intend to make it an installed library from osmo-mgw.git (similar to libosmo-ranap from osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not been aware of until now. libiu, shared between MSC and SGSN, has already moved to osmo-iuh. The other thing the MSC and SGSN still share is the GSUP client. The GSUP protocol code has already moved to libosmocore, but the gsup_client is still in openbsc. I believe it is appropriate to move the gsup_client along to libosmocore, even though the notion so far has been to keep it out of there. Otherwise we either duplicate the gsup_client or need another separate libosmo-gsupclient. Possibly other code needs to be moved around similarly, but AFAICT "decreasing in importance". Code review: We can review in various ways. I believe the least troublesome would be this: - create osmo-msc git from the current openbsc. - remove the top level 'openbsc' dir. - go through all of the patches in gerrit to apply to 'master', which will apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW, all of these in osmo-msc.git. - the state thus reached is the basis for the split. Copy this to osmo-*.git - in each separate git, remove the files not needed for that particular project. Remove possible remaining code duplication as we go. openbsc.git | | copy v osmo-msc.git | | - `mv openbsc/* .` v | gerrit code review: | +VLR | +3G | +AoIP | +------------------------------- | | v | ----------copy-------- | | | | | v v v | osmo-bsc osmo-sgsn osmo-mgw osmo-msc | | | | | | | | clean unrelated files v v v v continue ongoing development from these new master HEADs I'm currently playing through the separation, osmo-msc with top-level openbsc removed is done, osmo-mgw and osmo-bsc pending. This means that I will need to apply commits merged to openbsc from now on to the new separate gits until we move over for good. That's fairly similar to keeping the 3G,AoIP branch rebased onto openbsc master as we did previously. It may make sense to focus AoIP development onto the new repositories soon. So far I'm keeping the gits privately on a sysmocom office machine. We could also open up new osmo-* repositories on gerrit and git.osmocom.org now. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pespin at sysmocom.de Mon Jul 10 15:59:05 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 10 Jul 2017 17:59:05 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170710095935.GA32278@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170705101313.GB5921@my.box> <936c956d-945c-3fe3-9933-ebf33e9aad72@sysmocom.de> <20170707005936.GB9089@my.box> <20170710095935.GA32278@my.box> Message-ID: <31370b69-ca23-de11-9240-0c29c38f001f@sysmocom.de> On 10/07/17 11:59, Neels Hofmeyr wrote: > On Sun, Jul 09, 2017 at 06:35:51PM +0200, Pau Espin Pedrol wrote: >> On top of that, I think the issues come too from the fact that we are >> starting the whole network in an automatic way at the same time, which >> increases the number of messages and time required to sync everything and >> become stable. > > I did try once to add several seconds of delay between launching osmo-trx and > osmo-bts-trx, without effect, so I doubt that it's system load. (osmo-bts-trx > is typically the last program to be launched.) > Indeed, that was not the root cause for the issue I already fixed in osmo-trx, which was the most common issue, but I'm still not sure about the other one we are still facing, I need to look into it. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Jul 10 19:15:32 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 10 Jul 2017 21:15:32 +0200 Subject: plan for openbsc.git split and code review In-Reply-To: <20170710153314.GA1446@my.box> References: <20170710153314.GA1446@my.box> Message-ID: <323ed871-f5e4-8295-9429-4897732dd645@sysmocom.de> Excellent news! On top of that I propose to switch old openbsc.git to read-only the moment new repositories are public to make sure people use proper HEADs for development right away. Also, we should remove conflicting .deb packaging before enabling nightly builds for split repositories - do we have a separate ticket for that? 10.07.2017 17:33, Neels Hofmeyr ?????: > So far I'm keeping the gits privately on a sysmocom office machine. We could > also open up new osmo-* repositories on gerrit and git.osmocom.org now. > > ~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 Directors: Holger Freyther, Harald Welte From msuraev at sysmocom.de Tue Jul 11 13:06:18 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 11 Jul 2017 15:06:18 +0200 Subject: Osmocom releases Message-ID: Hi. So far releases of Osmocom project were rather rare and without any schedule. It would be nice to change that but to do that we've got to make the process of making a release as smooth as possible. The ticket which tracks this activity: https://projects.osmocom.org/issues/1861 What we have right now: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release What I've implemented: https://gerrit.osmocom.org/#/c/3130/ The TLDR: we type "make REL=minor release" and get: * signed and tagged commit * automated version bump * updated debian/changelog Longer explanation: That's implemented as separate makefile which is installed as part of libosmocore-dev and can be re-used by other projects in few lines (see https://gerrit.osmocom.org/#/c/3131/ for example). It treats libraries separately from non-library projects (we don't have to clean up TODO-RELEASE in the latter case). Also, it does not update LIBVERSION automatically (see https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info" for details) - I'm not quite sure how this can be automated. Caveats: - it does not push the committed result automatically - so far it's left as an additional chance to inspect the changes before pushing them. Also I'm not sure if we have to tweak our gerrit setup to allow for signed tags to go through and how will it interact with auto-rebase. - it does not replace human decision, it's still your job to adjust version requirements for the libraries you use and properly bump LIBVERSION - it enforces use of semantic versioning (see my previous email about semver and http://semver.org/ for details) Questions: - does it make sense? - what and, more importantly, how can we automate in addition to that? The intention is to make release process easy enough so we could make releases more frequently (maybe even have some schedule for it in a long run). -- 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 Jul 11 13:36:01 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 11 Jul 2017 15:36:01 +0200 Subject: compiling tests during make Message-ID: <1eb55ea6-a27e-b44a-f423-1abb4bf91d94@sysmocom.de> Hi. I've noticed that we do not use check_PROGRAMS in any of our Makefile.am (happy to be corrected :) so all the tests/ binaries are built during "make" step instead of "make check". Is this intentional? If so - why? Is this smth we'd rather fix? -- 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 oramadan at fb.com Tue Jul 11 15:01:37 2017 From: oramadan at fb.com (Omar Ramadan) Date: Tue, 11 Jul 2017 08:01:37 -0700 Subject: Control Interface to OsmoSGSN Message-ID: <861a804e-3f21-1c29-f5cd-f404e417860d@fb.com> Hey Osmocom, I am trying to understand how to interact with the SGSN via the control interface and do a few things that I can't find documentation for. Hoping you can help explain how to: 1) Query(or push) CDRs for active data sessions 2) Terminate active PDP context (network initiated detach) 3) Manage the ACL for the PS domain (assuming via HLR?) Thanks, Omar From lynxis at fe80.eu Tue Jul 11 15:49:47 2017 From: lynxis at fe80.eu (Alexander Couzens) Date: Tue, 11 Jul 2017 17:49:47 +0200 Subject: [RFC] rework location update request Message-ID: <20170711174932.67ae1fcb@lazus.yip> Hi, recently my modem with an already known SIM got a location update reject, because the procedure timed out. So I looked more into the location updates. How openbsc location update works: MS Network LOC REQ -> <- Identity Req IMSI Identity Resp IMSI -> <- Identity Req IMEI Identity Resp IMEI -> <- LOC ACCEPT OpenBSC is using a Timeout (5 sec) for the completion of location update. So let's say we trigger for unknown reason the timeout (e.g. RF problem). MS Network LOC REQ -> <- Identity Req IMSI (No response) <- LOC Reject! cause 13 / No roaming allowed. If the MS receive it, it will put our network on it's blacklist and won't try it again until power cycled. We could change reject cause to something different [1], but we might want to reject foreign SIMs not to try our network again. The problem here is that openBSC use the same configuration to reject unknown SIMs as well for timeouts. But I think this timeout should be removed. 04.08 doesn't describe a timeout on location update request on network side. But it describes other timeouts: 04.08 describes: - T3260 auth req. sent, wait until response (12 sec) - T3270 identity req. sent, wait until response (12 sec) I think we should implement both timers and drop the RR connection if it fires. I'm unsure if it's needed: But OpenBSC could count un-successful location update req. Reset counter if it's succeeded. After a certain amount of failures we send a location update reject. (unsure which cause) best, lynxis Related Specs: GSM 04.08 [1] Chapter 4.4 describing location update GSM 04.08 [1] Chapter 11.2 Timers GSM 04.08 [1] Chapter Annex G Reject Causes [0] nitb.cfg: network: location updating reject cause [1] ETSI TS 100 940 -- Alexander Couzens mail: lynxis at fe80.eu jabber: lynxis at fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From msuraev at sysmocom.de Tue Jul 11 19:07:18 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 11 Jul 2017 21:07:18 +0200 Subject: Control Interface to OsmoSGSN In-Reply-To: <861a804e-3f21-1c29-f5cd-f404e417860d@fb.com> References: <861a804e-3f21-1c29-f5cd-f404e417860d@fb.com> Message-ID: <58ddb902-8654-f0bc-76f0-0151633e5638@sysmocom.de> The short answer: not yet. Somewhat longer version: Regarding the first 2 points, the currently implemented CTRL commands and traps are documented in chapter ?6 of osmosgsn-usermanual.pdf from https://cgit.osmocom.org/osmo-gsm-manuals/ Having said that, those can be implemented - please add tickets at https://projects.osmocom.org/projects/cellular-infrastructure/issues Also, there's similar ticket for TRAP in OsomNITB: https://projects.osmocom.org/issues/2331 As for last point (if I understood it correctly) - it does exist but not documented yet: you can use "enable-ps", "disable-ps" and "status-ps" to control the PS services for a given IMSI using OsmoHLR's CTRL interface. See https://projects.osmocom.org/issues/1645 for more details. I've also created https://projects.osmocom.org/issues/2359 issue for missing OsmoHLR manual. On 11.07.2017 17:01, Omar Ramadan wrote: > Hey Osmocom, > > I am trying to understand how to interact with the SGSN via the control interface > and do a few things that I can't find documentation for. Hoping you can help > explain how to: > > 1) Query(or push) CDRs for active data sessions > > 2) Terminate active PDP context (network initiated detach) > > 3) Manage the ACL for the PS domain (assuming via HLR?) > > Thanks, > > Omar > -- 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 Tue Jul 11 19:09:37 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 11 Jul 2017 21:09:37 +0200 Subject: plan for openbsc.git split and code review In-Reply-To: <20170710153314.GA1446@my.box> References: <20170710153314.GA1446@my.box> Message-ID: <20170711190937.mugzztag4mkycrvt@nataraja> Hi Neel,s On Mon, Jul 10, 2017 at 05:33:14PM +0200, Neels Hofmeyr wrote: > I am currently setting up separate repositories to replace openbsc.git. great. > The libmgcp has so far been internal to openbsc.git. I intend to make it an > installed library from osmo-mgw.git (similar to libosmo-ranap from > osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate > with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not > been aware of until now. I think we have to be careful to review its API in detail before making it a public, system-installed library where we have to deal with API or ABI breakage of anything we modify later on. One idea that Holger formerly pursued with libsccp.a was to only have static libraries - we might revisit that idea if we cannot go through related API review. > libiu, shared between MSC and SGSN, has already moved to osmo-iuh. I presume it is then called libosmo-iu ? > The other thing the MSC and SGSN still share is the GSUP client. The GSUP > protocol code has already moved to libosmocore, but the gsup_client is still in > openbsc. I believe it is appropriate to move the gsup_client along to > libosmocore, even though the notion so far has been to keep it out of there. The problem is again API/ABI stability. It restricts the way we can use code, and I would prefer to avoid constraining ourselves... > Otherwise we either duplicate the gsup_client or need another separate > libosmo-gsupclient. I don't like the latter part. > Code review: > > We can review in various ways. I believe the least troublesome would be this: > - create osmo-msc git from the current openbsc. > - remove the top level 'openbsc' dir. > - go through all of the patches in gerrit to apply to 'master', which will > apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW, > all of these in osmo-msc.git. > - the state thus reached is the basis for the split. Copy this to osmo-*.git > - in each separate git, remove the files not needed for that particular project. > Remove possible remaining code duplication as we go. makes sense. > So far I'm keeping the gits privately on a sysmocom office machine. We could > also open up new osmo-* repositories on gerrit and git.osmocom.org now. No need to keep it private. Feel free to put it on git.osmocom.org. Good luck! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Wed Jul 12 01:43:40 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 12 Jul 2017 08:43:40 +0700 Subject: OpenBSC Random Access Channel: rach_bsic != bts_bsic Message-ID: Hi all, During experimenting with RACH requests in my virtual Um-interface environment, I found an interesting issue in OpenBSC. According to the specifications, every RACH request should contain BSIC value of target base station, and if I understand correctly BSC (or BTS?) should ignore such requests, where rach_bsic != bts_bsic (Ghost RACH). Meanwhile, when I send all-zero sequence (just for testing) on RACH lchan, BSC allocates me a channel despite bts_bsic != 0x00. It probably also explains the reason, why sometimes in a real OpenBSC + OsmoBTS setup I see channel requests, followed by channel allocation without any further response from MS side. So, do we have any BSIC matching functionality implemented somewhere? If not, I could try to open an issue and implement it. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 12 08:58:23 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Jul 2017 10:58:23 +0200 Subject: Control Interface to OsmoSGSN In-Reply-To: <861a804e-3f21-1c29-f5cd-f404e417860d@fb.com> References: <861a804e-3f21-1c29-f5cd-f404e417860d@fb.com> Message-ID: <20170712085823.2tmfdzgx6jkuxgpc@nataraja> Hi Omar, On Tue, Jul 11, 2017 at 08:01:37AM -0700, Omar Ramadan wrote: > 1) Query(or push) CDRs for active data sessions push (aka CTRL TRAP) is not implemented at this point. Getting the counters should be possible, given that we have * a complete set of 'rate_ctr' for the SGSN: ** number of {packets,bytes} {in,out} for each MM context (Subscriber) ** number of {packets,bytes} {in,out} for each PDP context * libosmocore contains a generic + automatic exposure of all rate_ctr via CTRL, see libosmocore/src/ctrl/control_if.c get_rate_ctr() & Co The format shoudl be something like "rate_ctr.{abs,per_sec,per_min,per_hour,per_day}.GROUP.IDX.NAME" where GROUP is sgsn.pdpctx + IDX=NSAPI with NAME in * udata.packets.in * udata.packets.out * udata.bytes.in * udata.bytes.out or where GROUP is sgsn.mmctx + IDX=TLLI and NAME in * udata.packets.in * udata.packets.out * udata.bytes.in * udata.bytes.out Now the problem is that the group name contains a '.', and this is the same character used for tokenizing the individual parts of the CTRL interface command. So what we have here is a nicely defined generic architecture for (rate) counters, and an equally generic way to export them - but they will fail in this specific example based on bad choice of naming, and no verification if invalid names (prefixes) are registered. As a result, a lot of counters that we previously assumed to be exported automatically are thus currently unreachable from the CTRL interface :( I've created https://osmocom.org/issues/2362 for this. Once that is fixed, the mechanism should work as expected. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jul 12 09:10:47 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Jul 2017 11:10:47 +0200 Subject: OpenBSC Random Access Channel: rach_bsic != bts_bsic In-Reply-To: References: Message-ID: <20170712091047.3as5467fvz7o6kac@nataraja> Hi Vadim, On Wed, Jul 12, 2017 at 08:43:40AM +0700, Vadim Yanitskiy wrote: > So, do we have any BSIC matching functionality implemented somewhere? > If not, I could try to open an issue and implement it. The BSIC matching must be implemented in the PHY layer, ie. the non-common part of OsmoBTS. Only there do you have the raw bits of the RACH burst in order to make that decision. From L1SAP upwards you only know the 8bit (11bit) "payload" and have no clue anymore about the C(0) to C(5) bits generated by 05.03 Chapter 4.6. -- - 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 Jul 12 12:31:39 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Jul 2017 14:31:39 +0200 Subject: plan for openbsc.git split and code review In-Reply-To: <20170711190937.mugzztag4mkycrvt@nataraja> References: <20170710153314.GA1446@my.box> <20170711190937.mugzztag4mkycrvt@nataraja> Message-ID: <20170712123139.GA32597@my.box> On Tue, Jul 11, 2017 at 09:09:37PM +0200, Harald Welte wrote: > > The libmgcp has so far been internal to openbsc.git. I intend to make it an > > installed library from osmo-mgw.git (similar to libosmo-ranap from > > osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate > > with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not > > been aware of until now. > > I think we have to be careful to review its API in detail before making > it a public, system-installed library where we have to deal with API or > ABI breakage of anything we modify later on. > > One idea that Holger formerly pursued with libsccp.a was to only have > static libraries - we might revisit that idea if we cannot go through > related API review. I'm not really aware how a dynamically linked libosmo-mgcp has more problems than a static one. About the API I notice that there is a header called mgcp_internal.h, with a comment "Private data" at the top, suggesting that it would be used only within mgcp*.c; but osmo-bsc_nat wants to use that header file and its functions, so I added this header to the install. This just to say that indeed there may be some review, renaming, rearranging at hand. My idea is to first get it to work with as little modifications as possible (besides renaming directories / larger scopes), and refine the structure later. The review process may become rather important... > > libiu, shared between MSC and SGSN, has already moved to osmo-iuh. Correction: I thought that we had already merged it, but in fact it's still on a private branch of mine. Now https://gerrit.osmocom.org/3187 > I presume it is then called libosmo-iu ? What our libiu does is actually dock fairly tightly to libosmo-ranap, providing the code that each of the Iu interfaces use commonly to act as a RANAP endpoint. Hence I decided to include it in libosmo-ranap as iu_client_*. One reason to indeed want to separate it again could be that it uses libosmo-sigtran, accepting an sccp instance like this: int ranap_iu_init(void *ctx, int log_subsystem, const char *sccp_user_name, struct osmo_sccp_instance *sccp, ranap_iu_recv_cb_t iu_recv_cb, ranap_iu_event_cb_t iu_event_cb) Including in libosmo-ranap was the simplest way to go. The osmo-iuh build depends on libosmo-sigtran anyway because of OsmoHNBGW, and all users of libosmo-ranap also naturally link libosmo-sigtran already. > > I believe it is appropriate to move the gsup_client along to > > libosmocore, even though the notion so far has been to keep it out of there. > > The problem is again API/ABI stability. It restricts the way we can use > code, and I would prefer to avoid constraining ourselves... > > > Otherwise we either duplicate the gsup_client or need another separate > > libosmo-gsupclient. > > I don't like the latter part. Are you implying that we should indeed duplicate? The same rationale could actually apply to above iu client. I don't know; Yes, it's not really that much code to duplicate, but keeping separate copies of entire APIs feels undesirable. Is modifying the API/ABI really such a big problem? "Simply" keep older function signatures, possibly deprecate some, possibly even make a breaking change and depend on new library versions occasionally ... isn't that expected daily business? ~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 Jul 12 13:11:30 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Jul 2017 15:11:30 +0200 Subject: Osmocom releases In-Reply-To: References: Message-ID: <20170712131130.GC32597@my.box> Let me also re-plug the following thread, it has results from OsmoDevCon: https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html "Using repo to make 'regular' releases" on Tue Apr 25 13:40:15 UTC 2017 It seems that we have reached some conclusions which are fading away (at least in my memory), it helps to re-read. Note the separate topics, on the one hand a general "Osmocom feed" version that provides distribution packages and a common reference for our users, on the other hand the individual version numbers kept in each git tree. One thing mentioned in that mail is the separation of openbsc.git, which I'm currently working on. Regarding the patches, I've posted a comment asking about installation of osmo-release.mk, otherwise I haven't taken a detailed look yet. The topic is non-trivial, and I guess it would be good to have a practical example that includes the entire process: make a change to libosmocore that bumps a version and is required by e.g. libosmo-abis; what exactly are my steps in sequence to achieve that? Does it make sense to have this in a WIP wiki page? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jul 12 13:17:13 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Jul 2017 15:17:13 +0200 Subject: compiling tests during make In-Reply-To: <1eb55ea6-a27e-b44a-f423-1abb4bf91d94@sysmocom.de> References: <1eb55ea6-a27e-b44a-f423-1abb4bf91d94@sysmocom.de> Message-ID: <20170712131712.GD32597@my.box> On Tue, Jul 11, 2017 at 03:36:01PM +0200, Max wrote: > Hi. > > I've noticed that we do not use check_PROGRAMS in any of our Makefile.am (happy to be > corrected :) so all the tests/ binaries are built during "make" step instead of "make > check". > > Is this intentional? If so - why? Is this smth we'd rather fix? I remember at least sometimes having binaries built only during 'make check' ... there are some check_PROGRAMS around our repositories. I personally don't care much either way; having test binaries built during 'make' forces me to fix the test builds along right away, not only when I remember to run 'make check', which can be helpful or get in the way depending on the situation. We can change to use check_PROGRAMS everywhere, but there are other more important things to care about (unless there are packaging / release implications). ~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 Wed Jul 12 13:23:36 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 12 Jul 2017 15:23:36 +0200 Subject: Osmocom releases In-Reply-To: <20170712131130.GC32597@my.box> References: <20170712131130.GC32597@my.box> Message-ID: <7f19e82d-7137-a03a-fa74-4bb946ff0b24@sysmocom.de> On 12.07.2017 15:11, Neels Hofmeyr wrote: > Let me also re-plug the following thread, it has results from OsmoDevCon: > https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html > "Using repo to make 'regular' releases" on Tue Apr 25 13:40:15 UTC 2017 > It seems that we have reached some conclusions which are fading away (at least > in my memory), it helps to re-read. I think we should put this into wiki. > Regarding the patches, I've posted a comment asking about installation of > osmo-release.mk, otherwise I haven't taken a detailed look yet. Thanks, will fix in next revision. > The topic is non-trivial, and I guess it would be good to have a practical > example that includes the entire process: make a change to libosmocore that > bumps a version and is required by e.g. libosmo-abis; what exactly are my steps > in sequence to achieve that? Does it make sense to have this in a WIP wiki > page? I think it's better to add WIP section to https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release Also, have a look at "When to make a new release" section. I think it's essential to clearly distinguish between "make a change to library" and "making library release". The former is the usual commit (make sure to update TODO-RELEASE if necessary) and does not require anything special. The latter is when proposed makefile helper comes into play (it batches together several of "make a change to library" commits). Once the result release commit lands in master it you can bump version requirements of projects which depends on it as necessary. Overall though, I think we should do it other way around: when we need to release one of non-library projects (Osmo*) we should check dependencies and make their releases if necessary before proceeding with the release of the Osmo* project. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Wed Jul 12 13:35:49 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Jul 2017 15:35:49 +0200 Subject: [RFC] rework location update request In-Reply-To: <20170711174932.67ae1fcb@lazus.yip> References: <20170711174932.67ae1fcb@lazus.yip> Message-ID: <20170712133549.GE32597@my.box> On Tue, Jul 11, 2017 at 05:49:47PM +0200, Alexander Couzens wrote: > recently my modem with an already known SIM got a location update > reject, because the procedure timed out. So I looked more > into the location updates. > > How openbsc location update works: > > MS Network > LOC REQ -> > <- Identity Req IMSI > Identity Resp IMSI -> > <- Identity Req IMEI > Identity Resp IMEI -> > <- LOC ACCEPT > > OpenBSC is using a Timeout (5 sec) for the completion of location > update. One important fact here is that we have completely re-implemented location updating when introducing the VLR + HLR, since the openbsc.git vlr_2G branch. This uses brand new finite state machines with capabilities for individual timers for each step. These could be refined, but the point is that we're definitely not going to revisit the old location updating code. You may take a look at how the new code reacts to timeouts. https://git.osmocom.org/openbsc/tree/openbsc/src/libmsc/subscr_conn.c?h=aoip suggests that on conn timeout, we simply and bluntly close the connection without answering with 'Roaming not allowed' now. Also see https://git.osmocom.org/openbsc/tree/openbsc/tests/msc_vlr/msc_vlr_test_ms_timeout.err?h=aoip which tests timeout explicitly. There's also an HLR timeout test in that dir. https://git.osmocom.org/openbsc/tree/openbsc/tests/msc_vlr?h=aoip There are also various LU reject causes tested in e.g. https://git.osmocom.org/openbsc/tree/openbsc/tests/msc_vlr/msc_vlr_test_hlr_reject.err?h=aoip If you'd like to refine LU reject messages, go for the vlr_2G branch (to use the OsmoNITB with a separate OsmoHLR) or the aoip branch (to use the entirely new OsmoMSC with separate OsmoSTP, OsmoHLR, OsmoBSC and a real A-interface). The aoip branch constitutes what are going to be the new osmo-msc and osmo-bsc master branches in the split repositories. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From vmarcusv at gmail.com Wed Jul 12 19:18:21 2017 From: vmarcusv at gmail.com (Marcus Dias) Date: Wed, 12 Jul 2017 16:18:21 -0300 Subject: Question about activate GPRS In-Reply-To: <20170707021453.GD9089@my.box> References: <20170707021453.GD9089@my.box> Message-ID: Hi Neels, Looking into your configuration, I managed to start sgsn,ggsn,nitb and pcu without error. However, When I look into the pcu running configuration I see that there is a different configuration from the starting one ( no egprs ), is this normal? I changed it to egprs. Another issue that I faced yesterday, was that I could connect my phone to the network (this one time, today I was trying to connect but it didnt connected), and the symbol of GPRS appeared, but couldnt make a ping to 8.8.8.8 for example, even after doing the nat masquerade thing. I see in the vty sgsn that my phone does several routing area update, but does not connect. what it could be? Here is my configuration attached, I am running everything on sysmo2050. Best, Marcus Dias UFPA - Lasse - LaPS 2017-07-06 23:14 GMT-03:00 Neels Hofmeyr : > On Thu, Jul 06, 2017 at 04:54:07PM -0300, Marcus Dias wrote: > > Dear all, > > > > I have one sysmo2050, with the GSM running fine. However, i would like to > > test GPRS data transmission, I was following this setup page ( > > https://osmocom.org/projects/cellular-infrastructure/wiki/ > OpenBSC_GPRS#OpenBSC-configuration), > > but i couldnt make it work. Anyone has done it before / can help me? > > Hard to help with this little information. > > I have attached a tar with scripts and configs I use to run voice and data > on a > sysmoBTS. Note that this is a rather convoluted way that fits my personal > needs > of development testing. Maybe you can figure something out from it... > > Feel free to ask more specific questions here, including your config and > error > symptoms. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sysmo.zip Type: application/zip Size: 3262 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Jul 12 21:17:56 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Jul 2017 23:17:56 +0200 Subject: new osmo-msc repository Message-ID: <20170712211756.GH32597@my.box> I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed the first few patches for gerrit review to move to our "new" Osmocom CN: https://gerrit.osmocom.org/#/q/topic:vlr As suggested before, osmo-msc will see code review and patches merged for VLR, 3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and osmo-sgsn, as distinct repositories replacing the current openbsc.git. All further development happening in openbsc.git from now on will have to be applied to the new repositories later. Keep that in mind, and maybe postpone larger conflict prone efforts for later. The review process could take some effort. Some of the commits are one collapsed commit of fairly large development efforts. Normally, commits should be small, but in the case of completely refactoring an entire section of the code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really help to see incremental back-and-forth changes with intermediate errors and fixes. I decided to collapse the errors with their fixes, and to save the effort of logically plucking apart the large commits, since they anyway only make sense as a whole. If necessary for review, we can still do so. Despite the mass of changes, please do look closely. Parts of the new code have possibly been hacked up in a preliminary fashion and were forgotten to implement properly later -- this will become our new Osmocom master branches, the stable releases and our main development arena, so do apply your scrutiny and let's fix early what we can fix now. The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am preparing to make them work as separate entities after the code review, on respective neels/split branches. Each fresh repository contains the *full* openbsc.git history. The option of relying on grafts to include the old openbsc.git history when needed has been mentioned, but so far was more or less turned down. It is still possible to change that. The openbsc.git history is about 9 Mb -- not too large, so IMHO best to keep it with each separate repos to ease log browsing, git blame and so forth. OTOH, we have it four times, which makes 36 Mb of duplicated history. If anyone still prefers a flat snapshot migration with a wiki page describing how to graft in the old history, we may discuss and change that. No branches have been migrated except the current aoip development branch that is going to become the new master. All tags are included, except: the signed '0.1.2' openbsc version tags are replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we don't confuse them with the new version tags in each new project. Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in order to get *something* out from git-version-gen, useful for referencing a version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac. We still need to decide whether to start versioning afresh or continue from the openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice would be to bump the major and start from 1.0.0 in each new repository. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jul 13 02:15:28 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 13 Jul 2017 04:15:28 +0200 Subject: Question about activate GPRS In-Reply-To: References: <20170707021453.GD9089@my.box> Message-ID: <20170713021528.GI32597@my.box> On Wed, Jul 12, 2017 at 04:18:21PM -0300, Marcus Dias wrote: > When I look into the pcu running configuration I > see that there is a different configuration from the starting one ( no > egprs ), is this normal? I changed it to egprs. Sorry, I don't follow. I don't see egprs anywhere in your config. I'm also not familiar with egprs really, but AFAIK you don't configure that in the PCU but in the NITB config? In my ggsn.conf, I use 'net' and no 'dynip'. This should be sufficient: listen 127.0.0.2 net 192.168.42.0/24 pcodns1 8.8.8.8 > Another issue that I faced > yesterday, was that I could connect my phone to the network (this one time, > today I was trying to connect but it didnt connected), Are you able to connect or not? Is it not reproducible? > and the symbol of > GPRS appeared, but couldnt make a ping to 8.8.8.8 for example, even after > doing the nat masquerade thing. The "thing" is enable forwarding and masquerading for the appropriate ethernet interface. Did you do both? sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > I see in the vty sgsn that my phone does several routing area update, but > does not connect. what it could be? It's impossible to guess from over here what is going on in your setup. You need to be more specific: Log output? Actual commands? Pcaps? Maybe with those someone here can see a solution. (in text form, no image screenshots please) ~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 Thu Jul 13 07:04:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 13 Jul 2017 09:04:24 +0200 Subject: Question about activate GPRS In-Reply-To: References: <20170707021453.GD9089@my.box> Message-ID: <20170713070424.s6hk3crafylq2dnd@nataraja> Hi Marcus, *please* make such reports with proper protocol traces and log file output attached. I will not spend further time on speculating about things if it is so easy to look at hard evidence instead. If the phone performs successful routing area attach, it is "connected". The next step is the PDP context activation. If you see not even an attempt of that, it is most likely your phone that is lacking proper APN configuration. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Jul 13 07:08:55 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 13 Jul 2017 09:08:55 +0200 Subject: new osmo-msc repository In-Reply-To: <20170712211756.GH32597@my.box> References: <20170712211756.GH32597@my.box> Message-ID: <20170713070855.dxezudnsipwa3qc7@nataraja> On Wed, Jul 12, 2017 at 11:17:56PM +0200, Neels Hofmeyr wrote: > No branches have been migrated except the current aoip development branch that > is going to become the new master. Please open a redmine issue about performing thorough branch review (after all new repos exist and are filled) on the old openbsc.git to see which branches still contain interesting bits that we want to pick into which of the new repos. I think that's quite important. > We still need to decide whether to start versioning afresh or continue from the > openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice > would be to bump the major and start from 1.0.0 in each new repository. I would start with 1.99.0 or something like that for now and aim for tagging a 2.0.0 release once the entire transition is done. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Jul 13 12:07:09 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 13 Jul 2017 14:07:09 +0200 Subject: new osmo-msc repository In-Reply-To: <20170713070855.dxezudnsipwa3qc7@nataraja> References: <20170712211756.GH32597@my.box> <20170713070855.dxezudnsipwa3qc7@nataraja> Message-ID: <20170713120709.GA3317@my.box> On Thu, Jul 13, 2017 at 09:08:55AM +0200, Harald Welte wrote: > Please open a redmine issue about performing thorough branch review > (after all new repos exist and are filled) on the old openbsc.git to see > which branches still contain interesting bits that we want to pick into > which of the new repos. I think that's quite important. https://osmocom.org/issues/2363 > I would start with 1.99.0 or something like that for now and aim for > tagging a 2.0.0 release once the entire transition is done. 1.inf.0 ;) Seems a bit artificial but it does make sense to talk about a version two when the transition is done. ~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 Fri Jul 14 22:11:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 15 Jul 2017 00:11:45 +0200 Subject: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS Message-ID: <20170714221145.hctt6a2ip27nwjvu@nataraja> Hi all! Some of you will have alrady noticed, over the last few days I reviewed, cleaned up, submitted and merged the virtual Um interface support on both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS). Thanks to Sebastian Stumpf for working out most of the related code, after my initial attempt on this got stalled more than 1.5 years ago. This means that you can now run a complete circuit-switched GSM network without posession of any real hardware or use of any radio waves. While that takes away almost all the fun for some of us (I would typically agree), it opens up possibilities, particularly in terms of testing. If anyone wants to play with it, it's actually very easy: * build osmo-bts and the rest of the network-side code (I don't think osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry) * run osmo-bts-virtual with a config file (example included in osmo-bts.git) * make sure you have matching unit_id, band, ... between BTS and BSC/NITB, just like with real hardware OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If you don't have any specific multicast routing set up, this will be visible with TTL=1 on the network device of your default route. You should see the GSMTAP frames in wireshark. On the OsmocomBB side, simply start the virt_phy binary. It replaces your calypso based phoen and its firmware and offers the L1CTL socket to the "layer23" programs like "mobile". Once virt_phy is running, you can start "mobile" just like with real hardware. The phone will scan the multicast frames for BCCH messages, build up a list of currently received BTSs and then perform normal cell selection followed by location update. Everything from this point on is just normal. You cannot make voice calls, but any signaling related transactions (LU, SMS, USSD, even call signalling) should work. Voice is missing as there is no format specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet. If somebody plays with this, I would really appreciate if they could update the Osmocom wiki with a guide/howto on how to use such a setup. My personal plans are to use this for verification/testing of those bits that are difficult in a true end-to-end setup like osmo-gsm-tester. That includes: * simulation of massive amount of phones, more than one can easily set up in a lab and connect to USB + RF cabling. * verification of SYSTEM INFORMATION messages, particularly in response to different config files, ensuring that all related bits are set correctly at all times, even after making dynamic updates * verification of the PAGING code, i.e. that paging load is correctly reported, paging messages are structured correctly, ... * exhausting all channels using simulated phones, verification of IMM.ASS.REJECT being sent ins such cases * verification of TA loop * verification of uplink power control loop * verification of radio link timeout * testing of emergency calls, which is very critical with real phones as there's always some possible leakage into real networks * verification of correct CBCH messages * verification of LAPDm contention resolution (two phones selecting same RACH value and going both on same dedicated channel) * verification of measurement reporting (Um vs. RSL) * verification of downlink RF power ramping This will of course take some time, but I'm already making good progress implementing some SYSTEM INFORMATION test code. In case somebody wants to join in on any of the above topics (or has even more ideas on what kind of tests he would want to implement), feel free to follow up so we can coordinate. 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 Mon Jul 17 20:09:27 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 17 Jul 2017 22:09:27 +0200 Subject: legacy codecs / mixing rates and versions Message-ID: <20170717200927.GB3839@my.box> Today I checked the new AoIP core network using an old Nokia 1100 handset, which confronted me with codecs. The Nokia 1100 says it is capable of FR2, FR1, HR1: Channel Type - (Speech) Element ID: 0x0b Length: 5 0000 .... = Spare bit(s): 0x00 .... 0001 = Speech/Data Indicator: Speech (1) Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8) 1... .... = Extension: Additional Octet .001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11) 1... .... = Extension: Additional Octet .000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01) 0... .... = Extension: Last Octet .000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05) The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I naively thought, let's do: codec-list hr3 fr2 hr1 But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? Then I picked: codec-list hr3 hr1 That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the BTS was configured for only TCH/F channels, so instead the Nokia actually got assigned an FR1 channel). The call was established but no audio worked. I believe in the OsmoNITB we used to complain in the log that we don't transcode in such a situation, and the call was aborted... When I pick codec-list hr1 then the call works between the handsets. Again both get assigned FR1 on TCH/F; if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as expected. All in all an interesting situation, which appears to mean that we practically can't allow the newer codecs alone because older handsets would not work, and we can't allow both because each side may pick a different one. Should we wait until we know both sides' codecs and consolidate with each other to pick matching ones before assigning? Is that a "late assignment" as in issue "avoid mismatching TCH/F vs TCH/H pchan types"? https://osmocom.org/issues/1778 But what if no match can be found? only MGW transcoding will solve all situations I guess. Are we planning to do that, also with IuUP in mind? https://osmocom.org/issues/1936 https://osmocom.org/issues/1937 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Jul 18 07:48:01 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 18 Jul 2017 09:48:01 +0200 Subject: legacy codecs / mixing rates and versions In-Reply-To: <20170717200927.GB3839@my.box> References: <20170717200927.GB3839@my.box> Message-ID: <20170718074801.zmmgfi5tbhxclvow@nataraja> Hi Neels, On Mon, Jul 17, 2017 at 10:09:27PM +0200, Neels Hofmeyr wrote: > Today I checked the new AoIP core network using an old Nokia 1100 handset, > which confronted me with codecs. what you are observing is the de-facto situation for the NITB for many years. Unfortunately nobody has investigated this thoroughly and implemented a solution. In classic/commercial GSM networks a call is always transcoded, so basically at the level between MSCs there is PCM audio, and somewhere (typically already at the BSC) the voice is transcoded for each of the two call legs. There's a convoluted mechanism called "tandem free operation" (TFO) in which the two transcoders can use the LSB of the PCM audio samples to implement a "covert channel" by which they can detect their presence and simultaneously switch both transcoders off. This is to avoid the speech quality degradation that happens by transcoding twice, particularly with HRv1. None of the above is implemented, as we take a "we don't transcode in OsmoNITB" attitude. The problem (or rather difficulty) with that is that in a mobile-to-mobile call, we don't yet know the least common denominator of the codecs supported by both the MO call leg and the MT call leg until very late (after having paged the subscriber, authenticated him and performed the first couple of CC message exchange). Please note that we actually need to take the codec restrictions of all elements into consideration, i.e. * capabilities of the phone(s) * capabilities of the BTS(s) * capabilities + policy of the BSC(s) * capabilities + policy of the MSC(s) Where it becomes even more interesting in the new post-NITB world is once we have calls between two subscribers at different MSCs, where the codec capabilities / negotiation will have to be forwarded between them e.g. by means of SIP :) "It just needs to be implemented" There should be open tickets about this for about a decade now. Sadly it seems nobody has had a significant enough interest or need to actually get it done. > But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is > that a hard limitation? I'm not at all familiar with the reasons. Will we never > be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? I'm not sure why the BSC would ever say something like that. The BSC normally simply picks a codec from the codecs that the MSC permits for the given call. The MSC should be in charge of requesting a specific codec if it wants a specific one. -- - 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 Jul 18 09:58:58 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 18 Jul 2017 11:58:58 +0200 Subject: legacy codecs / mixing rates and versions In-Reply-To: <20170718074801.zmmgfi5tbhxclvow@nataraja> References: <20170717200927.GB3839@my.box> <20170718074801.zmmgfi5tbhxclvow@nataraja> Message-ID: <20170718095858.GA5300@ass40.sysmocom.de> On Tue, Jul 18, 2017 at 09:48:01AM +0200, Harald Welte wrote: > > But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is > > that a hard limitation? I'm not at all familiar with the reasons. Will we never > > be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? > > I'm not sure why the BSC would ever say something like that. The BSC > normally simply picks a codec from the codecs that the MSC permits for > the given call. The MSC should be in charge of requesting a specific > codec if it wants a specific one. Been there since late in 2010: http://git.osmocom.org/openbsc/commit/?id=7bf66c5a6ee085bb84e5f1de12725d7006cf6a3c It sounds a bit like this belongs in the MSC instead. So far it's in the BSC config's 'msc' item, i.e. telling the BSC the remote MSC's config. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Jul 18 10:05:35 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 18 Jul 2017 12:05:35 +0200 Subject: legacy codecs / mixing rates and versions In-Reply-To: <20170718095858.GA5300@ass40.sysmocom.de> References: <20170717200927.GB3839@my.box> <20170718074801.zmmgfi5tbhxclvow@nataraja> <20170718095858.GA5300@ass40.sysmocom.de> Message-ID: <20170718100535.m25qnaku2hqjybul@nataraja> On Tue, Jul 18, 2017 at 11:58:58AM +0200, Neels Hofmeyr wrote: > On Tue, Jul 18, 2017 at 09:48:01AM +0200, Harald Welte wrote: > > > But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is > > > that a hard limitation? I'm not at all familiar with the reasons. Will we never > > > be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? > > > > I'm not sure why the BSC would ever say something like that. The BSC > > normally simply picks a codec from the codecs that the MSC permits for > > the given call. The MSC should be in charge of requesting a specific > > codec if it wants a specific one. > > Been there since late in 2010: > http://git.osmocom.org/openbsc/commit/?id=7bf66c5a6ee085bb84e5f1de12725d7006cf6a3c > > It sounds a bit like this belongs in the MSC instead. So far it's in the > BSC config's 'msc' item, i.e. telling the BSC the remote MSC's config. I completely understand that there is a point to having a policy that can be configured at the BSC to restrict its supported codecs for whatever local policy/configuration reason. This makes complete sense. I however don't understand why we should enforce that this policy does not include both a restriction for which codecs to use on TCH/H and also which codecs to use on TCH/F. Holger, do you remember? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Tue Jul 18 10:20:35 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 18 Jul 2017 12:20:35 +0200 Subject: legacy codecs / mixing rates and versions In-Reply-To: <20170718100535.m25qnaku2hqjybul@nataraja> References: <20170717200927.GB3839@my.box> <20170718074801.zmmgfi5tbhxclvow@nataraja> <20170718095858.GA5300@ass40.sysmocom.de> <20170718100535.m25qnaku2hqjybul@nataraja> Message-ID: <7648D307-B5D5-4CC9-83C3-AEA2CF73C8AC@freyther.de> > On 18. Jul 2017, at 12:05, Harald Welte wrote: > Hey! > I completely understand that there is a point to having a policy that > can be configured at the BSC to restrict its supported codecs for > whatever local policy/configuration reason. This makes complete sense. > > I however don't understand why we should enforce that this policy does > not include both a restriction for which codecs to use on TCH/H and also > which codecs to use on TCH/F. It was just the easiest path forward. The customer that paid for the development of the BSC didn't have a mixed TCH/H and TCH/F network, we didn't have much tools to verify these things and it greatly reduced the effort to test it (as I think all untested code is likely to be broken). Looking at bssmap_handle_assignm_req we would support a mixed hr/fr list right now. holger From fanx07 at gmail.com Tue Jul 18 14:23:11 2017 From: fanx07 at gmail.com (Anonim Stefan) Date: Tue, 18 Jul 2017 17:23:11 +0300 Subject: osmo-nitb enable SMS delivery reports Message-ID: Hi, I'm using osmo-nitb in a testing environment and I've soon received a request to enable SMS delivery reports. After looking on the user manual, I couldn't find anything related to this. I've also enabled debug logging and tried to grep for something like that when sending a SMS between two handsets that have SMS delivery reports enabled, without finding out anything. (SMS delivery reports tested and worked on a public telephony system, for those two handsets) Is there such an option available in osmo-nitb to enable delivery reports? --- Thank you, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Tue Jul 18 14:40:42 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 18 Jul 2017 16:40:42 +0200 Subject: osmo-nitb enable SMS delivery reports In-Reply-To: References: Message-ID: <6a884e63-b6ee-3f6f-32f9-fa4dc45593af@sysmocom.de> On 18/07/17 16:23, Anonim Stefan wrote: > Hi, > > I'm using osmo-nitb in a testing environment and I've soon received a > request to enable SMS delivery reports. > > After looking on the user manual, I couldn't find anything related to this. > > I've also enabled debug logging and tried to grep for something like > that when sending a SMS between two handsets that have SMS delivery > reports enabled, without finding out anything. (SMS delivery reports > tested and worked on a public telephony system, for those two handsets) > > Is there such an option available in osmo-nitb to enable delivery reports? > > --- I recently run into a similar issue with delivery reports not being sent to an ESME, but the code paths are not the same afaik: https://osmocom.org/issues/2353 I just created a task to remember to implement your test case in osmo-gsm-tester with two ofono modems in the future: https://osmocom.org/issues/2374 -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From alexander.chemeris at gmail.com Tue Jul 18 14:54:35 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 18 Jul 2017 17:54:35 +0300 Subject: osmo-nitb enable SMS delivery reports In-Reply-To: References: Message-ID: Stefan, Delivery reports are not implemented in OsmoNITB, unfortunately. If you have a commercial interest in this, may be you could implement it? :) Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On Jul 18, 2017 5:29 PM, "Anonim Stefan" wrote: > Hi, > > I'm using osmo-nitb in a testing environment and I've soon received a > request to enable SMS delivery reports. > > After looking on the user manual, I couldn't find anything related to this. > > I've also enabled debug logging and tried to grep for something like that > when sending a SMS between two handsets that have SMS delivery reports > enabled, without finding out anything. (SMS delivery reports tested and > worked on a public telephony system, for those two handsets) > > Is there such an option available in osmo-nitb to enable delivery reports? > > --- > Thank you, > Stefan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Tue Jul 18 18:59:20 2017 From: keith at rhizomatica.org (Keith) Date: Tue, 18 Jul 2017 20:59:20 +0200 Subject: osmo-nitb enable SMS delivery reports In-Reply-To: References: Message-ID: <0e1eee03-eb6b-ad1a-6baf-8bdd953dd3d2@rhizomatica.org> On 18/07/2017 16:23, Anonim Stefan wrote: > > > Is there such an option available in osmo-nitb to enable delivery reports? No, and implementation of an SMSC in the osmo-nitb itself is rather basic. The nitb is more or less EOL anyway and I think this is going to go in the direction of an external SMSC. Working delivery reports should be the result of the next expected code commit that Rhizomatica (and collaborator) are working on. I hate to make promises, only to have to look back and say "yes I said it'd be ready by, but" however I'd hope to see it in master by end September. Look forward to testing with you! Do you have an interest in working on this, and an open source solution for all the parts of the SMPP, SMSC, ESME, Store and forward and queueing puzzle? k From msuraev at sysmocom.de Wed Jul 19 10:07:24 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 19 Jul 2017 12:07:24 +0200 Subject: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS In-Reply-To: <20170714221145.hctt6a2ip27nwjvu@nataraja> References: <20170714221145.hctt6a2ip27nwjvu@nataraja> Message-ID: <84433dfb-ea78-fcda-e370-6ad1bdff1161@sysmocom.de> Awesome to see this moving forward. Would it make sense now to package osmocom-bb as .deb so it can be used (virt-phy parts at least) the same way as OsmoBTs etc.? On a somewhat related note - do we have a ticket which tracks removal of copy-pasted libosmocore from osmoom-bb and transition to main libosmocore built with --embedded configure option? -- 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 Jul 19 11:39:26 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Jul 2017 13:39:26 +0200 Subject: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS In-Reply-To: <84433dfb-ea78-fcda-e370-6ad1bdff1161@sysmocom.de> References: <20170714221145.hctt6a2ip27nwjvu@nataraja> <84433dfb-ea78-fcda-e370-6ad1bdff1161@sysmocom.de> Message-ID: <20170719113926.gwpdavgudad66afu@nataraja> Hi Max, On Wed, Jul 19, 2017 at 12:07:24PM +0200, Max wrote: > Would it make sense now to package osmocom-bb as .deb so it can be used (virt-phy > parts at least) the same way as OsmoBTs etc.? possibly, but I think there is no urgency as a lot of parts still need some cleanup before it is straight-forward to be used easily. > On a somewhat related note - do we have a ticket which tracks removal of copy-pasted > libosmocore from osmoom-bb and transition to main libosmocore built with --embedded > configure option? I would suggest you check the redmine issues yourself in order to find out about that :P In general, feel free to open as many tickets as you want. However, keep in mind that OsmocomBB is (and will likely remain) a pure community project, with close to zero commercial interest or backing. Combined with the fact that it hadn't seen contributions for almost five years, I'm not quite sure if somebody would ever be found to look at related tickets in their spare time. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jul 19 16:08:44 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Jul 2017 18:08:44 +0200 Subject: Documentation on how to use virtual Um between BTS + MS Message-ID: <20170719160844.f5m3k4u3u6v5fiqq@nataraja> Hi! Next to the announcement (http://osmocom.org/news/75) I've put together some guide in the wiki as to how the Virtual Um interface can be used with the osmo-bts-virtual, virtphy and mobile programs running all on your local PC: https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um Feel free to try it out and/or improve the wiki page and/or let me know if something is not sufficintly clear. I intentionally don't want to repeat general information about configuring OsmoNITB or using OsmocomBB. The above-mentioned page should only document those aspects that are different from the classic setup with real hardware. I'm now investigating some more of the bugs I'm starting to find with using the VirtualUm interface from my related TTCN-3 testsuite, at this time particularly https://osmocom.org/issues/2380 Will document that testsuite once it can actually run as expected. 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 aaguila at algoritmo.tech Wed Jul 19 17:14:22 2017 From: aaguila at algoritmo.tech (Alejandro Aguila) Date: Wed, 19 Jul 2017 12:14:22 -0500 Subject: Can't connect NanoBTS Message-ID: Hi there! I just got a nanobts, this if my first time using openBSC. Here is some info: System: gsm at debian:~/osmo_src/bin$ uname -a Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux SETTING IP's: /gsm at debian:~/osmo_src/bin$ ./ipaccess-config -o 10.1.121.1 10.1.121.151// //ipaccess-config (C) 2009-2010 by Harald Welte and others// //This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY/ /Trying to connect to ip.access BTS ...// //<0005> ../../../src/libbsc/abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //OML link established using TRX 0// //setting primary OML link IP to '10.1.121.1'// //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:2599 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xf0): SET NVATTR ACK// //Set the NV Attributes.// //gsm at debian:~/osmo_src/bin$ / FINDING BTS: /gsm at debian:~/osmo_src/bin$ sudo ./abisip-find enp0s3// //abisip-find (C) 2009 by Harald Welte// //This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY/ /Trying to find ip.access BTS by broadcast UDP...// //MAC_Address='00:02:95:00:41:2a' IP_Address='10.1.121.151' Unit_ID='20800/0/0' Location_1='' Location_2='BTS_NBT131G' Equipment_Version='140_029_59' Software_Version='120a002_v200b24d0' Unit_Name='nbts-00-02-95-00-41-2A' Serial_Number='00073914' / CONFIG: ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 334 mobile network code 020 short name AlgoOpenBSC long name OpenBSC auth policy accept-all location updating reject cause 13 encryption a5 0 neci 1 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 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 20800 0 oml ip.access stream_id 255 line 0 gprs mode none trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F OUTPUT: /gsm at debian:~/osmo_src/bin$ ./osmo-nitb// //<001e> ../../../src/vty/telnet_interface.c:102 telnet at 127.0.0.1 4242// //<0005> ../../../src/libbsc/bsc_init.c:465 // //WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage!// // //<0020> ../../src/input/ipaccess.c:846 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports// //<0017> ../../../src/libmsc/smpp_smsc.c:1001 SMPP at 0.0.0.0 2775// //<0025> ../../../src/ctrl/control_if.c:788 CTRL at 127.0.0.1 4249// //DB: Database initialized.// //DB: Database prepared.// //<0020> ../../src/input/ipa.c:263 accept()ed new link from 10.1.121.151 to port 3002// //Getting attributes from BTS0 type nanobts is not supported.// //Getting attributes from BTS0 type nanobts is not supported.// //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM:ULM_FIFODRV:fifodrv.c#1864 (6082). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0TxQueue full. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM ra=080036ae sp=40017a38. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [400179e8] |4000b518|00000000|08000af0|08000998|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [400179f8] |20000093|080007e8|00000000|00000093|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a08] |40017b58|40003c64|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a18] |80380000|00000000|40003c64|08002d8b|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a28] |00000000|40017a38|40004a7c|40017a90|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a38] |00000000|40017ab0|080595b8|00000002|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a48] |40006fbc|0800762f|40017ac4|08059a78|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a58] |0000000d|40007098|400047d8|40017a88|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a68] |00000001|00000000|080417f8|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a78] |0800c321|40017b58|08007c45|40000093|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS:ULS_FIFODRV:fifodrv.c#1864 (7540). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0TxQueue full. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS ra=08011da8 sp=4000c7c8. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c778] |4000c784|08000af0|080012d8|000000b3|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c788] |c0000000|00001950|00000050|00000040|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c798] |00000000|00000001|40000093|400032c0|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7a8] |00000000|00000000|80380000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7b8] |60000093|4000c7c8|08011da9|08011da8|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7c8] |40003b10|4000c7e0|400000d3|08000c14|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7d8] |0800a900|55555555|40003b40|4000d288|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7e8] |50036300|400049c4|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7f8] |00000000|00000000|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c808] |00000000|00000000|08011d8b|4000c77c|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP:L2_BCH:l2_bch.c#1065 (2586). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0BCHbcchSItypeValid( prim_p->infoType ). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP ra=0801446c sp=4000d724. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6d4] |4000d6e0|08000af0|080012d8|000000b3|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6e4] |c0000000|00001950|00000050|00000040|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6f4] |00000000|00000001|40000093|40003bb8|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d704] |00000000|00000000|80380000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d714] |60000093|4000d724|0801446d|0801446c|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d724] |400049d8|4000d73c|400000d3|08000c14|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d734] |0800a900|55555555|40004a08|4000e1e4|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d744] |50036300|4000588c|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d754] |00000000|00000000|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d764] |00000000|00000000|0801444f|4000d6d8|. // //<0020> ../../src/input/ipa.c:263 accept()ed new link from 10.1.121.151 to port 3003// //<0004> ../../../src/libbsc/bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=334 MNC=20 LAC=1 CID=0 BSIC=63// //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Process stopped, Additional Text=lme_manage_fsm_actions.c:636IPC Ping timeout - DLP FAILED. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=38454:WARN:OAM_RES:res_trx_status.c#209:TRX is not responding - reinitialising . // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="DISABLED RSP" st=ini. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Radio Carrier inst=0 ev="DISABLED RSP" st=initial// //. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="CLEAR I REQ" st=init. // //<0020> ../../src/input/ipaccess.c:241 Sign link vanished, dead socket// //<0020> ../../src/input/ipaccess.c:69 Forcing socket shutdown with no signal link set/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 19 18:43:54 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Jul 2017 20:43:54 +0200 Subject: BSC+BTS SI + LAPD validation, TTCN-3 Testsuite Message-ID: <20170719184354.n7dvcyp3kif7mctz@nataraja> Dear all, I've started to implement some test cases that validate the accuracy of OsmoBTS and OsmoBSC SYSTEM INFORMATION generation. Those test cases are written in TTCN-3, which is a special programming language specifically designed for testing and validation of protocol stacks. For those present at OsmoDevCon, I've briefly presented about it there. In terms of general core infrastructure, I've written: * Definition of GSM RR and some other commonly used GSM types using the TTCN-3 type description language and the TITAN RAW (binary) encoder/decoder. The beauty of this is that one can simply describe the message structure without having to generate any code for encoding/decoding the message. See http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_Types.ttcn and http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_SystemInformation.ttcn * A GSMTAP Test Port, whcih is basically how a TTCN-3 testcase/testsuite interacts with a given IUT (implementation under test). It is implemented as dual-faced port on top of the TITAN IPL4asp (ip layer 4) port and implements GSMTAP header encoding/decoding from/to TTCN-3 structured data types: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_PortType.ttcn which uses http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_Types.ttcn describing the GSMTAP header format. * Helper functions to emulate interactive use of the VTY based on the existing TITAN TELNETasp Test Port: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/Osmocom_VTY_Functions.ttcn * L1CTL type definition (again using auto-generated encoder/decoders!) http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_Types.ttcn as well as an L1CTL Test Port at http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_PortType.ttcn Using the above one can easily interface from TTCN3 with L1CTL of virtphy in order to e.g. sync to a BTS on a given ARFCN and establish a dedicated radio channel. Here is where the beautoy of the TTCN3 type language, templates and matching can be seen. It's very easy to perform something like "does this IMMEDIATE ASSIGNMENT match the RA + FN of the RACH request that I sent? Based on all of the above, there's two test suites: == Test Suites 1) SYSTEM INFORMATION contents and scheduling validation I've written some SI validation code which can be found at http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo SI scheduling is quite complex, particularly when you have many of the 2ter/2bis/2quater/13/2n/... enabled. At some point actually you will overflow what's possible to comply with the rules in a BCCH Norm. and you have to go to a BCCH Extd. (OsmoBTS doesn't implement the latter yet, btw). See e.g. function f_validate_si_scheduling() for validation of scheduling constraints: http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn#n229 Later in the file you can find test cases TC_cellid() and below for the individual test cases that validate that individual VTY configured values such as BSIC, CellId, LAC, ... are actually broadcast in the SI message. IT will update its internal matching template and then perform a sequence of VTY commands to e.g. change the LAC followed by verifying that the LAC of the decoded SI has actually changed. The above tools have helped to discover (and fix) the following bugs: * http://osmocom.org/issues/2368 * http://osmocom.org/issues/2367 * http://osmocom.org/issues/2365 (very critical, I believe) and also the not-yet-fixed but low-importance * http://osmocom.org/issues/2364 2) LAPDm testing I've written some (early) LAPDm testing code at http://git.osmocom.org/osmo-ttcn3-hacks/tree/lapdm The idea here is to test for valid and invalid transactions on the Um interface and see how OsmoBTS and the libosmcore lapdm code perform. With very few lines, this has already uncovered the following issues: * http://osmocom.org/issues/2370 * http://osmocom.org/issues/2380 Unfortunately my progress was severely affected over the weekend as I spent about one working day wrapping my head around something that turned out to be a bug in the Eclipse TITAN RAW coder, see https://www.eclipse.org/forums/index.php/t/1087557/ - fortuantely the Titan team has provided both a work-around and a fix today, which I count as excellent service. If you're curious about TTCN-3, I strongly recommend http://www.ttcn-3.org/files/TTCN3_P.pdf as an introductory slide deck. == Outlook I want to add more test cases to the sysinfo and lapdm test suites and get hands-on experience with the Junit XML output plugin. At that point, a Debian 9 build slave of our jenkins should be able to automatically build + run the latest test cases from osmo-ttcn3-hacks.git and present the individual test case results inside jenkins. I also want to add test suites for validation of: * proper generation + scheduling of of PAGING REQUEST in the BTS, considering paging groups particularly in the context of different BS_AG_BLKS_RES values * CBCH validation * proper generation of CCCH load indications by the BTS, i.e. generate a certian load e.g. on uplink RACH and check the reports * TA loop verification (add timing information to GSMTAP and then dynamically change timing from MS side to see that BTS is compensating as expected * power control loop verification: GSMTAP already has a field for transmitting RSSI in dBm. We can adjust this from the MS side to validate the BTS will adjus the instructed transmit power level of the virtual MS accordingly * actually exhaust all channels of a multi-TRX virtual BTS in different channel combinations, verify we can establish all existing logical channels in each configuration * combine the last topic with configurations that have dynamic PDCH/TCH channels to verify we properly switch forward and backward * various link failure conditions, i.e. does the BTS close the logical channel in the expected timing after uplink loss? Despite my current excitement about all of this, I'm not sure how much time I will be able to spend on this, given that the sysmocom customer priority is typically not the development of automatic test suites. But I'll try my best. If anyone wants to join: TITAN is just one "apt-get install eclipse-titan" away! == What's not good to test with TTCN-3 / TITAN: While the existing infrastructure I've built is very suitable to test low-level protocol topics, I think it's not particularly useful/applicable in other areas: * SI REST OCTETS and GPRS RLC/MAC, as they're defined in CSN.1 and TITAN has no CSN.1 encoder/decoder. For easy mathing/generation of those messages, we'd have to find something like an external CSN.1-to-ASN.1-BER or CSN.1-to-XML converter which we could use. I'd be happy to consider paying a reasonable amount for a proprietary product, just as long as we are sure that it will provde the kind of productivity that's useful here. * full end-to-end tests with actual mobile phones, RF and BTSs in the picture. We already have osmo-gsm-tester for this, and Titan with its powerful type language, templates and matching capabilities doesn't provide all that much benefit here over other languages/approaches * higher-layer protocol testing. We do have OsmocomBB as a L2 + L3 MS-side implementation, and I don't think it makes sense to replicate this. Even while the message encoding/decoding is super easy with TITAN, we still have all the related state machines. So I'd rather extend OsmocomBB where needed for automatic test cases than reinvent the wheel here. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From aaguila at algoritmo.tech Wed Jul 19 20:13:44 2017 From: aaguila at algoritmo.tech (Alejandro Aguila) Date: Wed, 19 Jul 2017 15:13:44 -0500 Subject: Can't connecto NanoBTS (More and Better Info) Message-ID: <51dff32f-f475-ef95-0fa4-77433f511518@algoritmo.tech> Hi there! LaF0rge made me some suggestions for a better troubleshooting, so here are the logs in .log format, since the previous email wasn't readable. I'm attaching the RSL+OML pcap file. Please let me know if someone knows how to connect this nanobts =) Cheers! -------------- next part -------------- A non-text attachment was scrubbed... Name: bisip-find.log Type: text/x-log Size: 444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaccess-config.log Type: text/x-log Size: 2644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenBSC_nanoBTS.pcap Type: application/vnd.tcpdump.pcap Size: 28492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-nitb.log Type: text/x-log Size: 11242 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Jul 20 22:47:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Jul 2017 00:47:35 +0200 Subject: code being sacrificed in the course of the OmsoNITB split-up Message-ID: <20170720224735.GA20016@my.box> Some code that is disabled to be able to compile libmsc without libbsc is related to communication to the BTS, that is replaced by the new A-interface. However, the following bits are not; Any opinions about what to do with it: - Report on which ARFCN and timeslot a silent call has occured. I would simply drop the ARFCN and timeslot information, saying "silent call successful". (same in two log messages) static int scall_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data) { struct scall_signal_data *sigdata = signal_data; struct vty *vty = sigdata->data; switch (signal) { case S_SCALL_SUCCESS: vty_out(vty, "%% silent call on ARFCN %u timeslot %u%s", sigdata->conn->lchan->ts->trx->arfcn, sigdata->conn->lchan->ts->nr, VTY_NEWLINE); break; case S_SCALL_EXPIRED: vty_out(vty, "%% silent call expired paging%s", VTY_NEWLINE); break; } return 0; } - Add Osmocom specific TLVs to SMPP /* Append the Osmocom vendor-specific additional TLVs to a SMPP msg */ static void append_osmo_tlvs(tlv_t **req_tlv, const struct gsm_lchan *lchan) { int idx = calc_initial_idx(ARRAY_SIZE(lchan->meas_rep), lchan->meas_rep_idx, 1); const struct gsm_meas_rep *mr = &lchan->meas_rep[idx]; const struct gsm_meas_rep_unidir *ul_meas = &mr->ul; const struct gsm_meas_rep_unidir *dl_meas = &mr->dl; /* Osmocom vendor-specific SMPP34 extensions */ append_tlv_u16(req_tlv, TLVID_osmo_arfcn, lchan->ts->trx->arfcn); if (mr->flags & MEAS_REP_F_MS_L1) { uint8_t ms_dbm; append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_l1.ta); ms_dbm = ms_pwr_dbm(lchan->ts->trx->bts->band, mr->ms_l1.pwr); append_tlv_u8(req_tlv, TLVID_osmo_ms_l1_txpwr, ms_dbm); } else if (mr->flags & MEAS_REP_F_MS_TO) /* Save Timing Offset field = MS Timing Offset + 63 */ append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_timing_offset + 63); append_tlv_u16(req_tlv, TLVID_osmo_rxlev_ul, rxlev2dbm(ul_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_ul, ul_meas->full.rx_qual); if (mr->flags & MEAS_REP_F_DL_VALID) { append_tlv_u16(req_tlv, TLVID_osmo_rxlev_dl, rxlev2dbm(dl_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_dl, dl_meas->full.rx_qual); } if (lchan->conn && lchan->conn->vsub) { struct vlr_subscr *vsub = lchan->conn->vsub; size_t imei_len = strlen(vsub->imei); if (imei_len) append_tlv(req_tlv, TLVID_osmo_imei, (uint8_t *)vsub->imei, imei_len+1); } } deliver_to_esme() { [...] if (esme->acl && esme->acl->osmocom_ext && conn->lchan) append_osmo_tlvs(&deliver.tlv, conn->lchan); [...] } - Siemens BS11 MRPCI /* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100 * We need to hook sending of MRPCI to Siemens BS11 somewhere else */ if (is_siemens_bts(conn->bts)) send_siemens_mrpci(msg->lchan, classmark2-1); - Debug log: report bts - trx - ts - ti in mncc_rcvmsg() (No BTS information available in OsmoMSC anymore) - In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type. (lchan information is no longer available in OsmoMSC) - In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc. /* * This will be run by the linker when loading the DSO. We use it to * do system initialization, e.g. registration of signal handlers. */ static __attribute__((constructor)) void on_dso_load_0408(void) { osmo_signal_register_handler(SS_ABISIP, handle_abisip_signal, NULL); } ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jul 20 22:58:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Jul 2017 00:58:36 +0200 Subject: Can't connect NanoBTS In-Reply-To: References: Message-ID: <20170720225836.GB20016@my.box> On Wed, Jul 19, 2017 at 12:14:22PM -0500, Alejandro Aguila wrote: > Hi there! I just got a nanobts, this if my first time using openBSC. Here is > some info: I am not familiar with the nanoBTS, though: it looks like it connects ok, but is severely broken: //<0020> ../../src/input/ipa.c:263 accept()ed new link from 10.1.121.151 to port 3002// //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM:ULM_FIFODRV:fifodrv.c#1864 (6082). // BTW, we'd appreciate if you sent logs in plain text format instead of HTML, maybe next time. 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 nhofmeyr at sysmocom.de Thu Jul 20 23:03:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Jul 2017 01:03:53 +0200 Subject: BSC+BTS SI + LAPD validation, TTCN-3 Testsuite In-Reply-To: <20170719184354.n7dvcyp3kif7mctz@nataraja> References: <20170719184354.n7dvcyp3kif7mctz@nataraja> Message-ID: <20170720230353.GC20016@my.box> Won't be able to measure up to it with these few words, but: Sounds like excellent news for Osmocom! :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jul 20 23:06:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Jul 2017 01:06:11 +0200 Subject: Can't connecto NanoBTS (More and Better Info) In-Reply-To: <51dff32f-f475-ef95-0fa4-77433f511518@algoritmo.tech> References: <51dff32f-f475-ef95-0fa4-77433f511518@algoritmo.tech> Message-ID: <20170720230611.GD20016@my.box> Ah, this is much better, thanks! Didn't see that when I answered to the other mail. I'm afraid I have no new conclusions, maybe someone else can tell you more about it... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Jul 21 06:42:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Jul 2017 08:42:38 +0200 Subject: code being sacrificed in the course of the OmsoNITB split-up In-Reply-To: <20170720224735.GA20016@my.box> References: <20170720224735.GA20016@my.box> Message-ID: <20170721064238.pkltqvlxqo5xtjk6@nataraja> Hi Neels, On Fri, Jul 21, 2017 at 12:47:35AM +0200, Neels Hofmeyr wrote: > Some code that is disabled to be able to compile libmsc without libbsc is > related to communication to the BTS, that is replaced by the new A-interface. > However, the following bits are not; Any opinions about what to do with it: my suggestion here would be a set of optional, vendor-specific TLVs that we can introduce in the A interface to convey related information. Those extensions could be enabled by default using a vty command on the BSC, and could be disabled for strict interop with other implementations that don't understand them. > - Report on which ARFCN and timeslot a silent call has occured. > I would simply drop the ARFCN and timeslot information, saying "silent call > successful". (same in two log messages) Would be easy to include information about the actual physical channel from BSC -> MSC, such as BTS number (maybe CGI=MCC+MNC+LAC+CID), ARFCN, timeslot/sub-slot (rsl chan_nr)... This is generally useful for all kinds of debugging. In a similar manner I would tranasport some kind of subscriber name/identification from the MSC to the BSC so the BSC can still show who has allocated a given channel. In its most generic form it could be as simple as a string TLV that the MSC can add to whatever downlink A interface message, and which the BSC accepts in every such message to talloc_replace_string() a field in its lchan, which can then be printed by various code (particularly logging) or used as log filter, or whatever else. > - Add Osmocom specific TLVs to SMPP Could be handled the same way, but should be yet another option, as it adds a lot of verbosity to the A interface which it otherwise doesn't need. Not the highest priority, but definitely doable with reasonable effort. > - Siemens BS11 MRPCI > > /* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100 > * We need to hook sending of MRPCI to Siemens BS11 somewhere else */ > if (is_siemens_bts(conn->bts)) > send_siemens_mrpci(msg->lchan, classmark2-1); this has to be moved to the BSC. > - Debug log: report bts - trx - ts - ti in mncc_rcvmsg() > (No BTS information available in OsmoMSC anymore) see above, can be retrieved from those TLVs which we send once when confirming the activation of a channel (= SCCP connection). > - In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type. > (lchan information is no longer available in OsmoMSC) same as above. > - In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is > done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be > dropped from libmsc. well, who are the usrers of the signal? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gerrit-no-reply at lists.osmocom.org Fri Jul 21 10:07:15 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 10:07:15 +0000 Subject: [PATCH] osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... Message-ID: Review at https://gerrit.osmocom.org/3322 Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server} This naming is more in line with what all the other osmocom programs are doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't generally use osmo_ anywhere else, so I suggest to change it for more uniformity. Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 --- M src/Makefile.am 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/1 diff --git a/src/Makefile.am b/src/Makefile.am index 0532acf..17ed4e3 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,7 +1,7 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/ AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS) -bin_PROGRAMS = osmo_pcap_client osmo_pcap_server +bin_PROGRAMS = osmo-pcap-client osmo-pcap-server osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \ osmo_client_core.c osmo_client_vty.c \ -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte From gerrit-no-reply at lists.osmocom.org Fri Jul 21 10:07:15 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 10:07:15 +0000 Subject: [PATCH] osmo-pcap[master]: Use TCP port numbers for VTY that don't overlap with other O... Message-ID: Review at https://gerrit.osmocom.org/3323 Use TCP port numbers for VTY that don't overlap with other Osmocom Software osmo-pcap historically was using port numbers that ware already used by OsmoPCU and OsmoBTS. This leads to problems when wanting to run related software together on one system. Let's break the historical assumptions and start with non-overlapping port numbers that are allocated/assigned from https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 --- M include/osmo-pcap/common.h M osmoappdesc.py M src/osmo_client_main.c M src/osmo_server_main.c 4 files changed, 13 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/23/3323/1 diff --git a/include/osmo-pcap/common.h b/include/osmo-pcap/common.h index 13c76e1..27fd514 100644 --- a/include/osmo-pcap/common.h +++ b/include/osmo-pcap/common.h @@ -28,6 +28,15 @@ #include #include #include +#include + +/* support old versions of libosmocore */ +#ifndef OSMO_VTY_PORT_PCAP_CLIENT +#define OSMO_VTY_PORT_PCAP_CLIENT 4237 +#endif +#ifndef OSMO_VTY_PORT_PCAP_SERVER +#define OSMO_VTY_PORT_PCAP_SERVER 4238 +#endif enum { DPCAP, diff --git a/osmoappdesc.py b/osmoappdesc.py index 39928eb..6f66702 100644 --- a/osmoappdesc.py +++ b/osmoappdesc.py @@ -20,8 +20,8 @@ } apps = [ - (4241, "src/osmo_pcap_server", "OsmoPCAPServer", "osmo-pcap-server"), - (4240, "src/osmo_pcap_client", "OsmoPCAPClient", "osmo-pcap-client"), + (4238, "src/osmo_pcap_server", "OsmoPCAPServer", "osmo-pcap-server"), + (4237, "src/osmo_pcap_client", "OsmoPCAPClient", "osmo-pcap-client"), ] vty_command = ["src/osmo_pcap_server", "-c", "contrib/osmo-pcap-server.cfg"] diff --git a/src/osmo_client_main.c b/src/osmo_client_main.c index 89d7e04..46a49b5 100644 --- a/src/osmo_client_main.c +++ b/src/osmo_client_main.c @@ -206,7 +206,7 @@ osmo_tls_init(); - rc = telnet_init(tall_bsc_ctx, NULL, 4240); + rc = telnet_init(tall_bsc_ctx, NULL, OSMO_VTY_PORT_PCAP_CLIENT); if (rc < 0) { LOGP(DCLIENT, LOGL_ERROR, "Failed to bind telnet interface\n"); exit(1); diff --git a/src/osmo_server_main.c b/src/osmo_server_main.c index 37a9632..95f3ce1 100644 --- a/src/osmo_server_main.c +++ b/src/osmo_server_main.c @@ -219,7 +219,7 @@ osmo_tls_init(); - rc = telnet_init(tall_bsc_ctx, NULL, 4241); + rc = telnet_init(tall_bsc_ctx, NULL, OSMO_VTY_PORT_PCAP_SERVER); if (rc < 0) { LOGP(DCLIENT, LOGL_ERROR, "Failed to bind telnet interface\n"); exit(1); -- To view, visit https://gerrit.osmocom.org/3323 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte From gerrit-no-reply at lists.osmocom.org Fri Jul 21 10:19:15 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 10:19:15 +0000 Subject: osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... In-Reply-To: References: Message-ID: Patch Set 1: Code-Review-1 If you upgrade and test the debian package, we can do that. -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Fri Jul 21 11:11:30 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 11:11:30 +0000 Subject: [PATCH] osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... In-Reply-To: References: Message-ID: Hello Jenkins Builder, Holger Freyther, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/3322 to look at the new patch set (#2). Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server} This naming is more in line with what all the other osmocom programs are doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't generally use osmo_ anywhere else, so I suggest to change it for more uniformity. Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 --- M debian/osmo-pcap-client.install M debian/osmo-pcap-server.install M src/Makefile.am 3 files changed, 3 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/2 diff --git a/debian/osmo-pcap-client.install b/debian/osmo-pcap-client.install index a1f9f59..f149b14 100644 --- a/debian/osmo-pcap-client.install +++ b/debian/osmo-pcap-client.install @@ -1 +1 @@ -usr/bin/osmo_pcap_client +usr/bin/osmo-pcap-client diff --git a/debian/osmo-pcap-server.install b/debian/osmo-pcap-server.install index 1157484..ad58c8e 100644 --- a/debian/osmo-pcap-server.install +++ b/debian/osmo-pcap-server.install @@ -1 +1 @@ -usr/bin/osmo_pcap_server +usr/bin/osmo-pcap-server diff --git a/src/Makefile.am b/src/Makefile.am index 0532acf..17ed4e3 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,7 +1,7 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/ AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS) -bin_PROGRAMS = osmo_pcap_client osmo_pcap_server +bin_PROGRAMS = osmo-pcap-client osmo-pcap-server osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \ osmo_client_core.c osmo_client_vty.c \ -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Fri Jul 21 11:11:31 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 11:11:31 +0000 Subject: [PATCH] osmo-pcap[master]: sock_src_init(): Don't freeaddrinfo() undefined src_result Message-ID: Review at https://gerrit.osmocom.org/3324 sock_src_init(): Don't freeaddrinfo() undefined src_result src_result is only valid "if (src)", so we cannot unconditionally free it: (gdb) bt host=0x52 , src=0x0) at /usr/src/debug/osmo-pcap/0.0.6+gitrAUTOINC+4776b2972e-r1d/git/src/osmo_client_network.c:165 Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9 --- M src/osmo_client_network.c 1 file changed, 2 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/24/3324/1 diff --git a/src/osmo_client_network.c b/src/osmo_client_network.c index 937caa0..27c649a 100644 --- a/src/osmo_client_network.c +++ b/src/osmo_client_network.c @@ -162,7 +162,8 @@ close(sfd); } freeaddrinfo(result); - freeaddrinfo(src_result); + if (src) + freeaddrinfo(src_result); if (rp == NULL) { fprintf(stderr, "unable to connect/bind socket: %s:%u: %s\n", -- To view, visit https://gerrit.osmocom.org/3324 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte From gerrit-no-reply at lists.osmocom.org Fri Jul 21 11:51:58 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 11:51:58 +0000 Subject: osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... In-Reply-To: References: Message-ID: Patch Set 2: Code-Review-1 One more file to go. sorry. debian/osmo-pcap-client.init (at least DAEMON) -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Fri Jul 21 11:53:41 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 11:53:41 +0000 Subject: osmo-pcap[master]: Use TCP port numbers for VTY that don't overlap with other O... In-Reply-To: References: Message-ID: Patch Set 2: Code-Review+2 Strictly speaking osmo-pcap was first and OsmoPCU and OsmoBTS used them besides they were already being used. ;) Anyway, I don't know any big consumers of the pcap-client VTY -- To view, visit https://gerrit.osmocom.org/3323 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Fri Jul 21 11:55:09 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 11:55:09 +0000 Subject: osmo-pcap[master]: sock_src_init(): Don't freeaddrinfo() undefined src_result In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+1 (2 comments) https://gerrit.osmocom.org/#/c/3324/1/src/osmo_client_network.c File src/osmo_client_network.c: Line 47: * Move to libosmocore... if the api makes source s/source/sense/ lol... Line 165: if (src) Why not src_result directly? -- To view, visit https://gerrit.osmocom.org/3324 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:17:44 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 13:17:44 +0000 Subject: osmo-pcap[master]: sock_src_init(): Don't freeaddrinfo() undefined src_result In-Reply-To: References: Message-ID: Patch Set 1: (1 comment) https://gerrit.osmocom.org/#/c/3324/1/src/osmo_client_network.c File src/osmo_client_network.c: Line 165: if (src) > Why not src_result directly? because it's not initialized with NULL, so we cannot check if it contains random chunk or valid data. Hence I used the same condition that you use before getaddrinfo(). -- To view, visit https://gerrit.osmocom.org/3324 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:21:37 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 13:21:37 +0000 Subject: [PATCH] osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... In-Reply-To: References: Message-ID: Hello Jenkins Builder, Holger Freyther, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/3322 to look at the new patch set (#3). Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server} This naming is more in line with what all the other osmocom programs are doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't generally use osmo_ anywhere else, so I suggest to change it for more uniformity. Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 --- M debian/osmo-pcap-client.init M debian/osmo-pcap-client.install M debian/osmo-pcap-server.install M osmoappdesc.py M src/Makefile.am 5 files changed, 7 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/3 diff --git a/debian/osmo-pcap-client.init b/debian/osmo-pcap-client.init index 29a51e6..6bfee7a 100755 --- a/debian/osmo-pcap-client.init +++ b/debian/osmo-pcap-client.init @@ -15,7 +15,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC=osmo-pcap-client # Introduce a short description here NAME=osmo-pcap-client # Introduce the short server's name here -DAEMON=/usr/bin/osmo_pcap_client # Introduce the server's location here +DAEMON=/usr/bin/osmo-pcap-client # Introduce the server's location here DAEMON_ARGS="-c /etc/osmo-pcap/osmo-pcap-client.cfg" # Arguments to run the daemon with PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME diff --git a/debian/osmo-pcap-client.install b/debian/osmo-pcap-client.install index a1f9f59..f149b14 100644 --- a/debian/osmo-pcap-client.install +++ b/debian/osmo-pcap-client.install @@ -1 +1 @@ -usr/bin/osmo_pcap_client +usr/bin/osmo-pcap-client diff --git a/debian/osmo-pcap-server.install b/debian/osmo-pcap-server.install index 1157484..ad58c8e 100644 --- a/debian/osmo-pcap-server.install +++ b/debian/osmo-pcap-server.install @@ -1 +1 @@ -usr/bin/osmo_pcap_server +usr/bin/osmo-pcap-server diff --git a/osmoappdesc.py b/osmoappdesc.py index 6f66702..2be96db 100644 --- a/osmoappdesc.py +++ b/osmoappdesc.py @@ -20,11 +20,11 @@ } apps = [ - (4238, "src/osmo_pcap_server", "OsmoPCAPServer", "osmo-pcap-server"), - (4237, "src/osmo_pcap_client", "OsmoPCAPClient", "osmo-pcap-client"), + (4238, "src/osmo-pcap-server", "OsmoPCAPServer", "osmo-pcap-server"), + (4237, "src/osmo-pcap-client", "OsmoPCAPClient", "osmo-pcap-client"), ] -vty_command = ["src/osmo_pcap_server", "-c", "contrib/osmo-pcap-server.cfg"] +vty_command = ["src/osmo-pcap-server", "-c", "contrib/osmo-pcap-server.cfg"] vty_app = apps[0] diff --git a/src/Makefile.am b/src/Makefile.am index 0532acf..17ed4e3 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,7 +1,7 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/ AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS) -bin_PROGRAMS = osmo_pcap_client osmo_pcap_server +bin_PROGRAMS = osmo-pcap-client osmo-pcap-server osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \ osmo_client_core.c osmo_client_vty.c \ -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:21:37 2017 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Fri, 21 Jul 2017 13:21:37 +0000 Subject: [PATCH] osmo-pcap[master]: Use TCP port numbers for VTY that don't overlap with other O... In-Reply-To: References: Message-ID: Hello Jenkins Builder, Holger Freyther, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/3323 to look at the new patch set (#3). Use TCP port numbers for VTY that don't overlap with other Osmocom Software osmo-pcap for historical reasons uses the same port numbers as OsmoPCU and OsmoBTS. This leads to problems when wanting to run related software together on one system. Let's break the historical assumptions and start with non-overlapping port numbers that are allocated/assigned from https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 --- M include/osmo-pcap/common.h M osmoappdesc.py M src/osmo_client_main.c M src/osmo_server_main.c 4 files changed, 13 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/23/3323/3 diff --git a/include/osmo-pcap/common.h b/include/osmo-pcap/common.h index 13c76e1..27fd514 100644 --- a/include/osmo-pcap/common.h +++ b/include/osmo-pcap/common.h @@ -28,6 +28,15 @@ #include #include #include +#include + +/* support old versions of libosmocore */ +#ifndef OSMO_VTY_PORT_PCAP_CLIENT +#define OSMO_VTY_PORT_PCAP_CLIENT 4237 +#endif +#ifndef OSMO_VTY_PORT_PCAP_SERVER +#define OSMO_VTY_PORT_PCAP_SERVER 4238 +#endif enum { DPCAP, diff --git a/osmoappdesc.py b/osmoappdesc.py index 39928eb..6f66702 100644 --- a/osmoappdesc.py +++ b/osmoappdesc.py @@ -20,8 +20,8 @@ } apps = [ - (4241, "src/osmo_pcap_server", "OsmoPCAPServer", "osmo-pcap-server"), - (4240, "src/osmo_pcap_client", "OsmoPCAPClient", "osmo-pcap-client"), + (4238, "src/osmo_pcap_server", "OsmoPCAPServer", "osmo-pcap-server"), + (4237, "src/osmo_pcap_client", "OsmoPCAPClient", "osmo-pcap-client"), ] vty_command = ["src/osmo_pcap_server", "-c", "contrib/osmo-pcap-server.cfg"] diff --git a/src/osmo_client_main.c b/src/osmo_client_main.c index 89d7e04..46a49b5 100644 --- a/src/osmo_client_main.c +++ b/src/osmo_client_main.c @@ -206,7 +206,7 @@ osmo_tls_init(); - rc = telnet_init(tall_bsc_ctx, NULL, 4240); + rc = telnet_init(tall_bsc_ctx, NULL, OSMO_VTY_PORT_PCAP_CLIENT); if (rc < 0) { LOGP(DCLIENT, LOGL_ERROR, "Failed to bind telnet interface\n"); exit(1); diff --git a/src/osmo_server_main.c b/src/osmo_server_main.c index 37a9632..95f3ce1 100644 --- a/src/osmo_server_main.c +++ b/src/osmo_server_main.c @@ -219,7 +219,7 @@ osmo_tls_init(); - rc = telnet_init(tall_bsc_ctx, NULL, 4241); + rc = telnet_init(tall_bsc_ctx, NULL, OSMO_VTY_PORT_PCAP_SERVER); if (rc < 0) { LOGP(DCLIENT, LOGL_ERROR, "Failed to bind telnet interface\n"); exit(1); -- To view, visit https://gerrit.osmocom.org/3323 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:22:40 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 13:22:40 +0000 Subject: osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c... In-Reply-To: References: Message-ID: Patch Set 3: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:23:25 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 13:23:25 +0000 Subject: osmo-pcap[master]: Use TCP port numbers for VTY that don't overlap with other O... In-Reply-To: References: Message-ID: Patch Set 3: Code-Review+2 (1 comment) https://gerrit.osmocom.org/#/c/3323/3//COMMIT_MSG Commit Message: Line 9: osmo-pcap for historical reasons uses the same port numbers as That was not necessary but thank you. -- To view, visit https://gerrit.osmocom.org/3323 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Fri Jul 21 13:24:47 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 13:24:47 +0000 Subject: osmo-pcap[master]: sock_src_init(): Don't freeaddrinfo() undefined src_result In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 > (1 comment) This explains the crash. Do you have a backtrace as well? It would be interesting to see why it is NULL. But very minor issue so let's not lose too much time here. -- To view, visit https://gerrit.osmocom.org/3324 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From nhofmeyr at sysmocom.de Fri Jul 21 13:48:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Jul 2017 15:48:37 +0200 Subject: sorry for the noise at osmo-msc patches Message-ID: <20170721134837.GA5267@my.box> btw, I apologize for the noise around the osmo-msc patch review, it's a challenge to keep all the eggs in the basket. For once I added python tests as well as the various --enable- flags to 'make distcheck', then tried to get the patches to pass the build check, and only now am really taking care of the all the remaining code review. Every time I think it's settled, something else pops up. Hope to be done with the current batch today. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gerrit-no-reply at lists.osmocom.org Fri Jul 21 14:26:29 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 14:26:29 +0000 Subject: [PATCH] osmo-pcap[refs/meta/config]: Edit Project Config In-Reply-To: References: Message-ID: Edit Project Config Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 --- M project.config 1 file changed, 0 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/28/3328/2 diff --git a/project.config b/project.config index ab43d3d..cebf266 100644 --- a/project.config +++ b/project.config @@ -3,5 +3,3 @@ [submit] action = rebase if necessary mergeContent = false -[notify "team"] - email = openbsc at lists.osmocom.org -- To view, visit https://gerrit.osmocom.org/3328 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: refs/meta/config Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Fri Jul 21 14:26:33 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 14:26:33 +0000 Subject: [PATCH] osmo-pcap[refs/meta/config]: Edit Project Config Message-ID: Review at https://gerrit.osmocom.org/3328 Edit Project Config Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 --- M project.config 1 file changed, 0 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/28/3328/2 diff --git a/project.config b/project.config index ab43d3d..cebf266 100644 --- a/project.config +++ b/project.config @@ -3,5 +3,3 @@ [submit] action = rebase if necessary mergeContent = false -[notify "team"] - email = openbsc at lists.osmocom.org -- To view, visit https://gerrit.osmocom.org/3328 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: refs/meta/config Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Fri Jul 21 14:26:35 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 14:26:35 +0000 Subject: osmo-pcap[refs/meta/config]: Edit Project Config In-Reply-To: References: Message-ID: Patch Set 2: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/3328 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: refs/meta/config Gerrit-Owner: Holger Freyther Gerrit-Reviewer: Holger Freyther Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Fri Jul 21 14:28:08 2017 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Fri, 21 Jul 2017 14:28:08 +0000 Subject: osmo-pcap[refs/meta/config]: Edit Project Config In-Reply-To: References: Message-ID: Patch Set 2: Trying to figure out how to submit it.. -- To view, visit https://gerrit.osmocom.org/3328 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I343a8f967e7d07d543807f292e5be60af61a0c97 Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcap Gerrit-Branch: refs/meta/config Gerrit-Owner: Holger Freyther Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-HasComments: No From aaguila at algoritmo.tech Fri Jul 21 16:08:38 2017 From: aaguila at algoritmo.tech (Alejandro Aguila) Date: Fri, 21 Jul 2017 11:08:38 -0500 Subject: build_2g.sh doubt Message-ID: Hi there! I've been trying to install some old releases using the build_2g.sh script, but I'm having problems. The releases are: OpenBSC 0.14.0 opengssn 0.92 libosmo-abis 0.3.1 libosmo-netif 0.0.4 libosmo-sccp 0.0.6.3 libsmpp34 1.10 libosmocore 0.8.0 Here is the output, I just want to know if this script is not compatible with those releases, because building one by one on Debian 9 has been a real fight, lol. Cheers! openbsc at debian:~/osmo$ ./build_2g.sh + base=/home/openbsc/osmo + builddir=build-2G + echo ======================= libosmocore ====================== ======================= libosmocore ====================== + cd /home/openbsc/osmo/libosmocore + [ 1 = 1 ] + set +e + make distclean make: *** No rule to make target 'distclean'. Stop. + rm -rf build-2G + set -e + autoreconf -fi libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' configure.ac:14: installing './compile' configure.ac:16: installing './config.guess' configure.ac:16: installing './config.sub' configure.ac:5: installing './install-sh' configure.ac:5: installing './missing' src/Makefile.am: installing './depcomp' src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/gsm/Makefile.am:15: warning: source file 'milenage/aes-internal.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled src/gsm/Makefile.am:15: warning: source file 'milenage/aes-internal-enc.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled src/gsm/Makefile.am:15: warning: source file 'milenage/milenage.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled src/sim/Makefile.am:5: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') tests/Makefile.am:21: warning: source file 'a5/a5_test.c' is in a subdirectory, tests/Makefile.am:21: but option 'subdir-objects' is disabled tests/Makefile.am:30: warning: source file 'auth/milenage_test.c' is in a subdirectory, tests/Makefile.am:30: but option 'subdir-objects' is disabled tests/Makefile.am:33: warning: source file 'bits/bitrev_test.c' is in a subdirectory, tests/Makefile.am:33: but option 'subdir-objects' is disabled tests/Makefile.am:27: warning: source file 'comp128/comp128_test.c' is in a subdirectory, tests/Makefile.am:27: but option 'subdir-objects' is disabled tests/Makefile.am:36: warning: source file 'conv/conv_test.c' is in a subdirectory, tests/Makefile.am:36: but option 'subdir-objects' is disabled tests/Makefile.am:78: warning: source file 'fr/fr_test.c' is in a subdirectory, tests/Makefile.am:78: but option 'subdir-objects' is disabled tests/Makefile.am:66: warning: source file 'gb/bssgp_fc_test.c' is in a subdirectory, tests/Makefile.am:66: but option 'subdir-objects' is disabled tests/Makefile.am:69: warning: source file 'gb/gprs_bssgp_test.c' is in a subdirectory, tests/Makefile.am:69: but option 'subdir-objects' is disabled tests/Makefile.am:72: warning: source file 'gb/gprs_ns_test.c' is in a subdirectory, tests/Makefile.am:72: but option 'subdir-objects' is disabled tests/Makefile.am:42: warning: source file 'gsm0408/gsm0408_test.c' is in a subdirectory, tests/Makefile.am:42: but option 'subdir-objects' is disabled tests/Makefile.am:39: warning: source file 'gsm0808/gsm0808_test.c' is in a subdirectory, tests/Makefile.am:39: but option 'subdir-objects' is disabled tests/Makefile.am:24: warning: source file 'kasumi/kasumi_test.c' is in a subdirectory, tests/Makefile.am:24: but option 'subdir-objects' is disabled tests/Makefile.am:24: warning: source file '../src/gsm/kasumi.c' is in a subdirectory, tests/Makefile.am:24: but option 'subdir-objects' is disabled tests/Makefile.am:45: warning: source file 'lapd/lapd_test.c' is in a subdirectory, tests/Makefile.am:45: but option 'subdir-objects' is disabled tests/Makefile.am:75: warning: source file 'logging/logging_test.c' is in a subdirectory, tests/Makefile.am:75: but option 'subdir-objects' is disabled tests/Makefile.am:81: warning: source file 'logging/logging_test.c' is in a subdirectory, tests/Makefile.am:81: but option 'subdir-objects' is disabled tests/Makefile.am:48: warning: source file 'msgfile/msgfile_test.c' is in a subdirectory, tests/Makefile.am:48: but option 'subdir-objects' is disabled tests/Makefile.am:57: warning: source file 'sms/sms_test.c' is in a subdirectory, tests/Makefile.am:57: but option 'subdir-objects' is disabled tests/Makefile.am:54: warning: source file 'smscb/gsm0341_test.c' is in a subdirectory, tests/Makefile.am:54: but option 'subdir-objects' is disabled tests/Makefile.am:51: warning: source file 'smscb/smscb_test.c' is in a subdirectory, tests/Makefile.am:51: but option 'subdir-objects' is disabled tests/Makefile.am:84: warning: source file 'strrb/strrb_test.c' is in a subdirectory, tests/Makefile.am:84: but option 'subdir-objects' is disabled tests/Makefile.am:60: warning: source file 'timer/timer_test.c' is in a subdirectory, tests/Makefile.am:60: but option 'subdir-objects' is disabled tests/Makefile.am:63: warning: source file 'ussd/ussd_test.c' is in a subdirectory, tests/Makefile.am:63: but option 'subdir-objects' is disabled tests/Makefile.am:18: warning: source file 'utils/utils_test.c' is in a subdirectory, tests/Makefile.am:18: but option 'subdir-objects' is disabled tests/Makefile.am:87: warning: source file 'vty/vty_test.c' is in a subdirectory, tests/Makefile.am:87: but option 'subdir-objects' is disabled + mkdir -p build-2G + cd build-2G + [ 1 = 1 ] + opt_enable= + [ libosmocore = openbsc/openbsc ] + ../configure --prefix=/home/openbsc/osmo checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for ANSI C header files... (cached) yes checking execinfo.h usability... yes checking execinfo.h presence... yes checking for execinfo.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking for library containing dlopen... -ldl checking for backtrace in -lexecinfo... no checking for doxygen... false checking if gcc supports -fvisibility=hidden... yes checking whether struct tm has tm_gmtoff member... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PCSC... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating libosmocore.pc config.status: creating libosmocodec.pc config.status: creating libosmovty.pc config.status: creating libosmogsm.pc config.status: creating libosmogb.pc config.status: creating libosmoctrl.pc config.status: creating libosmosim.pc config.status: creating include/Makefile config.status: creating src/Makefile config.status: creating src/vty/Makefile config.status: creating src/codec/Makefile config.status: creating src/sim/Makefile config.status: creating src/gsm/Makefile config.status: creating src/gb/Makefile config.status: creating src/ctrl/Makefile config.status: creating tests/Makefile config.status: creating utils/Makefile config.status: creating Doxyfile.core config.status: creating Doxyfile.gsm config.status: creating Doxyfile.vty config.status: creating Doxyfile.codec config.status: creating Makefile config.status: creating config.h config.status: executing tests/atconfig commands config.status: executing depfiles commands config.status: executing libtool commands + set +e + make clean Making clean in include make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/include' rm -rf .libs _libs rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include' Making clean in src make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' test -z "libosmocore.la" || rm -f libosmocore.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' Making clean in src/vty make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' test -z "libosmovty.la" || rm -f libosmovty.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' Making clean in src/codec make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' test -z "libosmocodec.la" || rm -f libosmocodec.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' Making clean in src/gsm make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' test -z "libosmogsm.la" || rm -f libosmogsm.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' Making clean in src/gb make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' test -z "libosmogb.la" || rm -f libosmogb.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' Making clean in src/ctrl make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' test -z "libosmoctrl.la" || rm -f libosmoctrl.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' Making clean in src/sim make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' test -z "libosmosim.la" || rm -f libosmosim.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' Making clean in tests make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/tests' rm -f timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test kasumi/kasumi_test logging/logging_test fr/fr_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test msgfile/msgfile_test rm -rf .libs _libs rm -rf a5/.libs a5/_libs rm -rf auth/.libs auth/_libs rm -rf bits/.libs bits/_libs rm -rf comp128/.libs comp128/_libs rm -rf conv/.libs conv/_libs rm -rf fr/.libs fr/_libs rm -rf gb/.libs gb/_libs rm -rf gsm0408/.libs gsm0408/_libs rm -rf gsm0808/.libs gsm0808/_libs rm -rf kasumi/.libs kasumi/_libs rm -rf lapd/.libs lapd/_libs rm -rf logging/.libs logging/_libs rm -rf loggingrb/.libs loggingrb/_libs rm -rf msgfile/.libs msgfile/_libs rm -rf sms/.libs sms/_libs rm -rf smscb/.libs smscb/_libs rm -rf strrb/.libs strrb/_libs rm -rf timer/.libs timer/_libs rm -rf ussd/.libs ussd/_libs rm -rf utils/.libs utils/_libs rm -rf vty/.libs vty/_libs test ! -f '../../tests/testsuite' || \ /bin/bash '../../tests/testsuite' --clean rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/tests' Making clean in utils make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/utils' rm -f osmo-arfcn osmo-auc-gen rm -rf .libs _libs rm -f osmo-sim-test rm -f *.o rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/utils' make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G' rm -rf .libs _libs test -z "" || rm -f rm -f *.lo make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G' + set -e + make -j echo UNKNOWN > ../.version-t && mv ../.version-t ../.version make all-recursive make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G' Making all in include make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/include' GEN osmocom/core/bit32gen.h GEN osmocom/core/crc8gen.h GEN osmocom/core/crc16gen.h GEN osmocom/core/crc32gen.h GEN osmocom/core/crc64gen.h GEN osmocom/core/bit16gen.h GEN osmocom/core/bit64gen.h GEN osmocom/core/crc64gen.h GEN osmocom/core/crc32gen.h GEN osmocom/core/crc8gen.h GEN osmocom/core/bit16gen.h GEN osmocom/core/bit64gen.h GEN osmocom/core/bit32gen.h GEN osmocom/core/crc16gen.h make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include' Making all in src make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' GEN crc64gen.c GEN crc32gen.c GEN crc8gen.c GEN crc16gen.c make all-am make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' CC select.lo CC bits.lo CC signal.lo CC timer.lo CC write_queue.lo CC socket.lo CC statistics.lo CC bitvec.lo CC msgb.lo CC utils.lo CC logging.lo CC gsmtap_util.lo CC logging_syslog.lo CC rate_ctr.lo CC panic.lo CC crc16.lo CC application.lo CC backtrace.lo CC conv.lo CC strrb.lo CC rbtree.lo CC crc16gen.lo CC loggingrb.lo CC crc8gen.lo CC crc32gen.lo CC crc64gen.lo CC macaddr.lo CC plugin.lo CC msgfile.lo CC talloc.lo CC serial.lo CCLD libosmocore.la ar: `u' modifier ignored since `D' is the default (see `U') make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' Making all in src/vty make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' CC command.lo CC utils.lo CC vector.lo CC buffer.lo CC telnet_interface.lo CC vty.lo CC logging_vty.lo CCLD libosmovty.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' Making all in src/codec make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' CC gsm620.lo CC gsm660.lo CC gsm610.lo CC gsm690.lo CCLD libosmocodec.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' Making all in src/gsm make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' CC tlv_parser.lo CC rxlev_stat.lo CC comp128v23.lo CC a5.lo CC gsm48.lo CC rsl.lo CC gsm_utils.lo CC comp128.lo CC gsm48_ie.lo CC gprs_cipher_core.lo CC gsm0808.lo CC sysinfo.lo CC gsm0502.lo CC abis_nm.lo CC gsm0480.lo CC gsm0411_smr.lo CC gsm0411_utils.lo CC gsm0411_smc.lo CC lapd_core.lo CC lapdm.lo CC auth_comp128v1.lo CC kasumi.lo CC auth_milenage.lo CC auth_comp128v23.lo CC auth_core.lo CC aes-encblock.lo CC milenage.lo CC aes-internal.lo CC aes-internal-enc.lo CC gsm0341.lo CC gan.lo CC ipa.lo ../../../src/gsm/gan.c:71:34: warning: ?gan_pdisc_vals? defined but not used [-Wunused-const-variable=] static const struct value_string gan_pdisc_vals[] = { ^~~~~~~~~~~~~~ CCLD libosmogsm.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' Making all in src/gb make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' CC gprs_ns_vty.lo CC gprs_ns_frgre.lo CC gprs_bssgp.lo CC gprs_bssgp_util.lo CC gprs_bssgp_bss.lo CC gprs_bssgp_vty.lo CC gprs_ns.lo CC common_vty.lo ../../../src/gb/gprs_bssgp_bss.c: In function ?bssgp_rx_paging?: ../../../src/gb/gprs_bssgp_bss.c:542:2: warning: this ?if? clause does not guard... [-Wmisleading-indentation] if (TLVP_PRESENT(&tp, BSSGP_IE_TMSI) && ^~ ../../../src/gb/gprs_bssgp_bss.c:546:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ?if? *(pinfo->ptmsi) = ntohl(*(uint32_t *) ^ ../../../src/gb/gprs_bssgp_vty.c:47:34: warning: ?gprs_bssgp_timer_strs? defined but not used [-Wunused-const-variable=] static const struct value_string gprs_bssgp_timer_strs[] = { ^~~~~~~~~~~~~~~~~~~~~ CCLD libosmogb.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' Making all in src/ctrl make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' CC control_cmd.lo CC control_if.lo ../../../src/ctrl/control_if.c: In function ?listen_fd_cb?: ../../../src/ctrl/control_if.c:365:15: warning: unused variable ?on? [-Wunused-variable] int ret, fd, on; ^~ CCLD libosmoctrl.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' Making all in src/sim make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' CC reader_pcsc.lo CC card_fs_usim.lo CC card_fs_uicc.lo CC card_fs_sim.lo CC reader.lo CC card_fs_isim.lo CC core.lo CC card_fs_tetra.lo In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/card_fs_uicc.c:24: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. Makefile:470: recipe for target 'card_fs_uicc.lo' failed make[2]: *** [card_fs_uicc.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/card_fs_isim.c:27: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/core.c:29: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/reader_pcsc.c:30: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/card_fs_usim.c:27: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. compilation terminated. compilation terminated. In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/card_fs_sim.c:26: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. Makefile:470: recipe for target 'card_fs_usim.lo' failed make[2]: *** [card_fs_usim.lo] Error 1 Makefile:470: recipe for target 'reader_pcsc.lo' failed make[2]: *** [reader_pcsc.lo] Error 1 Makefile:470: recipe for target 'card_fs_isim.lo' failed make[2]: *** [card_fs_isim.lo] Error 1 Makefile:470: recipe for target 'card_fs_sim.lo' failed make[2]: *** [card_fs_sim.lo] Error 1 Makefile:470: recipe for target 'core.lo' failed make[2]: *** [core.lo] Error 1 In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/card_fs_tetra.c:26: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../src/sim/reader.c:32: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. Makefile:470: recipe for target 'card_fs_tetra.lo' failed make[2]: *** [card_fs_tetra.lo] Error 1 Makefile:470: recipe for target 'reader.lo' failed make[2]: *** [reader.lo] Error 1 make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' Makefile:518: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G' Makefile:386: recipe for target 'all' failed make: *** [all] Error 2 + make make all-recursive make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G' Making all in include make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/include' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include' Making all in src make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' make all-am make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' Making all in src/vty make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' Making all in src/codec make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' Making all in src/gsm make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' Making all in src/gb make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' Making all in src/ctrl make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' Making all in src/sim make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' CC core.lo In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/core.c:29: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. Makefile:470: recipe for target 'core.lo' failed make[2]: *** [core.lo] Error 1 make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' Makefile:518: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G' Makefile:386: recipe for target 'all' failed make: *** [all] Error 2 + make make all-recursive make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G' Making all in include make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/include' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include' Making all in src make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' make all-am make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src' Making all in src/vty make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty' Making all in src/codec make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/codec' Making all in src/gsm make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm' Making all in src/gb make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb' Making all in src/ctrl make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/ctrl' Making all in src/sim make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' CC core.lo In file included from ../../../include/osmocom/core/msgb.h:25:0, from ../../../include/osmocom/sim/sim.h:4, from ../../../src/sim/core.c:29: ../../../include/osmocom/core/bits.h:6:35: fatal error: osmocom/core/bit16gen.h: No such file or directory #include ^ compilation terminated. Makefile:470: recipe for target 'core.lo' failed make[2]: *** [core.lo] Error 1 make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim' Makefile:518: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G' Makefile:386: recipe for target 'all' failed make: *** [all] Error 2 From mychaela.falconia at gmail.com Fri Jul 21 22:47:16 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 21 Jul 2017 14:47:16 -0800 Subject: sysmoUSIM variants and alternatives Message-ID: (Posting to the OpenBSC list because I figured that the set of people who issue their own SIMs probably has a good overlap with the set of people who operate their own physical GSM networks.) I am shopping for some non-carrier-branded, non-carrier-issued SIM cards for use in testing my FreeCalypso GSM MS devices (specifically, testing of the SIM interface in isolation without bringing up radio, as well as radio and full MS functionality testing with a base station simulator like CMU200 instead of live networks), and the only product I found so far is sysmoUSIM - if anyone else makes a similar product ("generic" SIM cards for tinkerers), I would like to know about it. In the case of sysmo(U)SIM cards, it looks like 2FF-only cards are no longer available, and the current choices are 2FF+3FF or 2FF+4FF. My question is: if I only want 2FF and have no interest in 3FF or 4FF, which variant should I buy? In other words, which variant is mechanically stronger and less likely to break in 2FF-only usage in various kinds in 2FF sockets? TIA, Mychaela From laforge at gnumonks.org Sat Jul 22 08:52:26 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 22 Jul 2017 10:52:26 +0200 Subject: sysmoUSIM variants and alternatives In-Reply-To: References: Message-ID: <20170722085226.wi7aorfwczffl56t@nataraja> Hi Mychaela, On Fri, Jul 21, 2017 at 02:47:16PM -0800, Mychaela Falconia wrote: > In the case of sysmo(U)SIM cards, it looks like 2FF-only cards are no > longer available, Yes, we had sysmoSIM-GR1 in 2FF-only form factor very early on (> 5 years ago), but the specific chip/OS was not satisfactory (GRcard), and most people were asking about smaller form-factors > and the current choices are 2FF+3FF or 2FF+4FF. My > question is: if I only want 2FF and have no interest in 3FF or 4FF, > which variant should I buy? In other words, which variant is > mechanically stronger and less likely to break in 2FF-only usage in > various kinds in 2FF sockets? I would recommend the 2FF+3FF. You could put some strong, thin adhesive tape (like kapton used in electronics rework) on the back to avoid the frame and the 3FF part from separating. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Sat Jul 22 10:37:34 2017 From: ron.menez at entropysolution.com (Ron) Date: Sat, 22 Jul 2017 10:37:34 +0000 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) Message-ID: <9549B376-0D58-4022-A622-5381F02D46EC@entropysolution.com> Hi All, Requesting your help on this kind of issue. Upon running the osmo-nitb, we had received and error regarding the timer configuration. osmo-nitb -C -c /root/osmocom_files/openbsc_1trx.conf -T -P -m Sat Jul 22 18:28:18 2017 <0006> mncc_sock.c:316 MNCC socket at /tmp/bsc_mncc There is no such command. Error occurred during reading below line: timer t3103 0 % Ignoring deprecated logging level everything % Ignoring deprecated logging level everything Sat Jul 22 18:28:18 2017 <0005> bsc_init.c:536 Failed to parse the config file: '/root/osmocom_files/openbsc_1trx.conf' Reading config failed. Exiting. But upon removing all the timer configured in the configuration file, osmo-nitb run as usual. Not sure if you guys removed it in purpose. Kindly advice please. osmo-nitb version used: 0.15.1.20170721 Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sat Jul 22 11:00:03 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 22 Jul 2017 18:00:03 +0700 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) Message-ID: Hi, > Error occurred during reading below line: > timer t3103 0 I may be wrong, but it's probably related to recent change: http://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600f85176b In short, it doesn't make sense to set '0' value to any timer. So, updating the software, please also keep your configuration updated ;) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Sat Jul 22 11:13:30 2017 From: ron.menez at entropysolution.com (Ron) Date: Sat, 22 Jul 2017 11:13:30 +0000 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: References: Message-ID: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> Thanks for the heads up Vadim. We?ll try changing the timer value to non-zero. Best regards, Ron Menez ron.menez at entropysolution.com On Jul 22, 2017, at 7:00 PM, Vadim Yanitskiy > wrote: Hi, > Error occurred during reading below line: > timer t3103 0 I may be wrong, but it's probably related to recent change: http://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600f85176b In short, it doesn't make sense to set '0' value to any timer. So, updating the software, please also keep your configuration updated ;) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jul 22 13:58:11 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 22 Jul 2017 16:58:11 +0300 Subject: sysmoUSIM variants and alternatives In-Reply-To: References: Message-ID: Hello Mychaela, On Sat, Jul 22, 2017 at 1:47 AM, Mychaela Falconia wrote: > the only product > I found so far is sysmoUSIM - if anyone else makes a similar product > ("generic" SIM cards for tinkerers), I would like to know about it. > In the case of sysmo(U)SIM cards, it looks like 2FF-only cards are no > longer available, and the current choices are 2FF+3FF or 2FF+4FF. My > question is: if I only want 2FF and have no interest in 3FF or 4FF, > which variant should I buy? I'm curious - since you're doing your own hardware, why not install a 3FF/4FF slot instead of a 2FF? Or even install two or three of them to give users a choice? I don't think you're really limited in space on your PCB, looking at it. But even with a 2FF slot, I'm surprised you have issues with mechanical strength - 3FF/4FF SIMs work fine with 2FF slots with an "adaptor", unless you plan to insert/remove them really frequently. And then, as Harald has mentioned, a small piece of a thin tape helps a lot. PS We're also making / selling our own Fairwaves branded SIM cards, but only to customers who buy our BTS so far and we make them 2FF/3FF/4FF by default, as that's what most people want nowadays. So that's not much of a difference from what you get from Sysmocom. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From pespin at sysmocom.de Sat Jul 22 22:46:31 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 23 Jul 2017 00:46:31 +0200 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <9549B376-0D58-4022-A622-5381F02D46EC@entropysolution.com> References: <9549B376-0D58-4022-A622-5381F02D46EC@entropysolution.com> Message-ID: On 22/07/17 12:37, Ron wrote: > Hi All, > > Requesting your help on this kind of issue. Upon running the osmo-nitb, > we had received and error regarding the timer configuration. > > osmo-nitb -C -c /root/osmocom_files/openbsc_1trx.conf -T -P -m > > Sat Jul 22 18:28:18 2017 <0006> mncc_sock.c:316 MNCC socket at > /tmp/bsc_mncc > > There is no such command. > > Error occurred during reading below line: > > timer t3103 0 > > > % Ignoring deprecated logging level everything > > % Ignoring deprecated logging level everything > > Sat Jul 22 18:28:18 2017 <0005> bsc_init.c:536 Failed to parse > the config file: '/root/osmocom_files/openbsc_1trx.conf' > > Reading config failed. Exiting. > > > But upon removing all the timer configured in the configuration file, > osmo-nitb run as usual. Not sure if you guys removed it in purpose. > It may be related to this commit from a few days ago, which disabled settting timers to 0. https://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600f85176b -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From pespin at sysmocom.de Sat Jul 22 22:49:09 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 23 Jul 2017 00:49:09 +0200 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: References: <9549B376-0D58-4022-A622-5381F02D46EC@entropysolution.com> Message-ID: <5643a560-c68f-1618-7367-7b386d527e54@sysmocom.de> On 23/07/17 00:46, Pau Espin Pedrol wrote: > > It may be related to this commit from a few days ago, which disabled > settting timers to 0. > > https://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600f85176b > Ops I just realized Vadim already answered this issue, but I didn't see it because my e-mail client broke his answer into a new thread. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Sun Jul 23 10:18:18 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 23 Jul 2017 12:18:18 +0200 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> References: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> Message-ID: <20170723101818.icqmfaeva4esy4ti@nataraja> On Sat, Jul 22, 2017 at 11:13:30AM +0000, Ron wrote: > We?ll try changing the timer value to non-zero. just remove all lines specifying timers with '0', the system will use reasonable defaults. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Sun Jul 23 11:40:17 2017 From: ron.menez at entropysolution.com (Ron) Date: Sun, 23 Jul 2017 11:40:17 +0000 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <20170723101818.icqmfaeva4esy4ti@nataraja> References: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com>, <20170723101818.icqmfaeva4esy4ti@nataraja> Message-ID: Thanks for the advice Harald. We'll also do that. BR, Ron -------- Original Message -------- Subject: Re: osmo-nitb error during execution (Error occured... timer t3103 0) From: Harald Welte To: Ron CC: Vadim Yanitskiy ,OpenBSC Mailing List On Sat, Jul 22, 2017 at 11:13:30AM +0000, Ron wrote: > We?ll try changing the timer value to non-zero. just remove all lines specifying timers with '0', the system will use reasonable defaults. -- - 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 Sun Jul 23 12:11:59 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 23 Jul 2017 14:11:59 +0200 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <20170723101818.icqmfaeva4esy4ti@nataraja> References: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> <20170723101818.icqmfaeva4esy4ti@nataraja> Message-ID: <20170723121159.27lyuexwvjk3q7am@nataraja> On Sun, Jul 23, 2017 at 12:18:18PM +0200, Harald Welte wrote: > On Sat, Jul 22, 2017 at 11:13:30AM +0000, Ron wrote: > > We?ll try changing the timer value to non-zero. > > just remove all lines specifying timers with '0', the system will use reasonable defaults. Actually, I think we should start accepting '0' as valid input in validating the config file, but simply ignore it and use the compile-time default if the value is 0. -- - 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 Sun Jul 23 13:03:54 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 23 Jul 2017 16:03:54 +0300 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <20170723121159.27lyuexwvjk3q7am@nataraja> References: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> <20170723101818.icqmfaeva4esy4ti@nataraja> <20170723121159.27lyuexwvjk3q7am@nataraja> Message-ID: On Sun, Jul 23, 2017 at 3:11 PM, Harald Welte wrote: > On Sun, Jul 23, 2017 at 12:18:18PM +0200, Harald Welte wrote: >> On Sat, Jul 22, 2017 at 11:13:30AM +0000, Ron wrote: >> > We?ll try changing the timer value to non-zero. >> >> just remove all lines specifying timers with '0', the system will use reasonable defaults. > > Actually, I think we should start accepting '0' as valid input in > validating the config file, but simply ignore it and use the > compile-time default if the value is 0. That's a very good idea. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From nhofmeyr at sysmocom.de Mon Jul 24 11:49:04 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Jul 2017 13:49:04 +0200 Subject: osmo-nitb error during execution (Error occured... timer t3103 0) In-Reply-To: <20170723121159.27lyuexwvjk3q7am@nataraja> References: <30D97293-061A-445F-8C98-FF0939B1C8F4@entropysolution.com> <20170723101818.icqmfaeva4esy4ti@nataraja> <20170723121159.27lyuexwvjk3q7am@nataraja> Message-ID: <20170724114904.GA21377@my.box> On Sun, Jul 23, 2017 at 02:11:59PM +0200, Harald Welte wrote: > On Sun, Jul 23, 2017 at 12:18:18PM +0200, Harald Welte wrote: > > On Sat, Jul 22, 2017 at 11:13:30AM +0000, Ron wrote: > > > We?ll try changing the timer value to non-zero. > > > > just remove all lines specifying timers with '0', the system will use reasonable defaults. From a user interface perspective, IMHO it makes more sense to keep '0' as "take action immediately", even though we're not using that at the moment. How about https://gerrit.osmocom.org/3339 ~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 Jul 24 13:35:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Jul 2017 15:35:37 +0200 Subject: code being sacrificed in the course of the OmsoNITB split-up In-Reply-To: <20170720224735.GA20016@my.box> References: <20170720224735.GA20016@my.box> Message-ID: <20170724133537.GB21377@my.box> What about this one: I assume handover will be an entirely different issue to be tackled with the new A-interface and we can drop this VTY command without substitute for now? DEFUN(ena_subscr_handover, ena_subscr_handover_cmd, "subscriber " SUBSCR_TYPES " ID handover BTS_NR", SUBSCR_HELP "Handover the active connection\n" "Number of the BTS to handover to\n") { #if BEFORE_MSCSPLIT int ret; struct gsm_subscriber_connection *conn; struct gsm_bts *bts; struct gsm_network *gsmnet = gsmnet_from_vty(vty); struct vlr_subscr *vsub = get_vsub_by_argv(gsmnet, argv[0], argv[1]); if (!vsub) { vty_out(vty, "%% No subscriber found for %s %s.%s", argv[0], argv[1], VTY_NEWLINE); return CMD_WARNING; } conn = connection_for_subscr(vsub); if (!conn) { vty_out(vty, "%% No active connection for subscriber %s %s.%s", argv[0], argv[1], VTY_NEWLINE); vlr_subscr_put(vsub); return CMD_WARNING; } bts = gsm_bts_num(gsmnet, atoi(argv[2])); if (!bts) { vty_out(vty, "%% BTS with number(%d) could not be found.%s", atoi(argv[2]), VTY_NEWLINE); vlr_subscr_put(vsub); return CMD_WARNING; } /* now start the handover */ ret = bsc_handover_start(conn->lchan, bts); if (ret != 0) { vty_out(vty, "%% Handover failed with errno %d.%s", ret, VTY_NEWLINE); } else { vty_out(vty, "%% Handover started from %s", gsm_lchan_name(conn->lchan)); vty_out(vty, " to %s.%s", gsm_lchan_name(conn->ho_lchan), VTY_NEWLINE); } vlr_subscr_put(vsub); return CMD_SUCCESS; #else vty_out(vty, "%% Not implemented!%s", VTY_NEWLINE); return -1; #endif } ~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 Jul 24 14:45:02 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Jul 2017 16:45:02 +0200 Subject: code being sacrificed in the course of the OmsoNITB split-up In-Reply-To: <20170721064238.pkltqvlxqo5xtjk6@nataraja> References: <20170720224735.GA20016@my.box> <20170721064238.pkltqvlxqo5xtjk6@nataraja> Message-ID: <20170724144502.GC21377@my.box> On Fri, Jul 21, 2017 at 08:42:38AM +0200, Harald Welte wrote: > my suggestion here would be a set of optional, vendor-specific TLVs that > we can introduce in the A interface to convey related information. > Would be easy to include information about the actual physical channel > from BSC -> MSC, such as BTS number (maybe CGI=MCC+MNC+LAC+CID), ARFCN, > timeslot/sub-slot (rsl chan_nr)... > > This is generally useful for all kinds of debugging. > > In a similar manner I would tranasport some kind of subscriber > name/identification from the MSC to the BSC so the BSC can still show > who has allocated a given channel. In its most generic form it could be > as simple as a string TLV that the MSC can add to whatever downlink A > interface message, and which the BSC accepts in every such message to > talloc_replace_string() a field in its lchan, which can then be printed > by various code (particularly logging) or used as log filter, or > whatever else. Agreed. For the code review this means: we cannot sensibly add those kinds of TLVs before we actually have the A-interface in the MSC. So the MSCSPLIT stage of the code review in osmo-msc.git will drop the code and we shall re-add once we have osmocom-specific TLVs added to our A-interface code. I tend towards leaving the '#if BEFORE_MSCSPLIT' markings there to disable the code instead of dropping it, to be able to easily find it later and see what it was supposed to do. > > - Add Osmocom specific TLVs to SMPP > > Could be handled the same way, but should be yet another option, as it > adds a lot of verbosity to the A interface which it otherwise doesn't > need. Not the highest priority, but definitely doable with reasonable > effort. I notice that this uses lchan measurement reports... not sure whether / when we want to send those to the MSC, but am not familiar enough. OS#2390 > > - Siemens BS11 MRPCI > this has to be moved to the BSC. OS#2389 -- also makes sense to drop in initial split and re-add in osmo-bsc after AoIP. > > - In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is > > done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be > > dropped from libmsc. > > well, who are the usrers of the signal? OsmoMSC no longer has an Abis interface, so it does not make sense to handle that signal. Anyway, in osmo-nitb, the consumer was handle_abisip_signal() in gsm_04_08.c, which apparently does RTP stream handling: - receives S_ABISIP_CRCX_ACK to connect an RTP socket; and flush pending pending tch_recv_mncc requests (which I don't fully understand, guess it's RTP also stream related) - receives S_ABISIP_DLCX_IND and frees an RTP socket. Since RTP is now handled via osmo-bsc_mgcp, I conclude that this is indeed obsolete. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Mon Jul 24 17:09:33 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 24 Jul 2017 19:09:33 +0200 Subject: code being sacrificed in the course of the OmsoNITB split-up In-Reply-To: <20170724133537.GB21377@my.box> References: <20170720224735.GA20016@my.box> <20170724133537.GB21377@my.box> Message-ID: <20170724170933.jlpkl6vmpjtryqh7@nataraja> Hi Neels, On Mon, Jul 24, 2017 at 03:35:37PM +0200, Neels Hofmeyr wrote: > What about this one: I assume handover will be an entirely different issue to > be tackled with the new A-interface and we can drop this VTY command without > substitute for now? You have to differentiate between intra-BSC hand-over and inter-BSC hand-over (or even inter-MSC hand-over). Intra-BSC hand-over is exactly like it is now. The command you're referring to thus simply has to go to into the BSC. The only problem is that the subscriber will probably not be possible to be identified by the IMSI as the BSC doesn't normally cache that information. But what kind of identifier do we show in "show lchan"? TMSI? SCCP Connection ID? This VTY command is quite essential to test hand-over during development and testing. Once we have the Osmocom extension TLVs by which the MSC can provide a subscriber identity to the BSC, we can re-introduce identifying the subscriber connection by such identity/name. Inter-BSC or Inter-MSC handover is something that we didn't have in NITB, but which is not really relevant to this question. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Thu Jul 27 10:30:31 2017 From: ron.menez at entropysolution.com (Ron) Date: Thu, 27 Jul 2017 10:30:31 +0000 Subject: Ring Back Tone Missing during Call Setup Message-ID: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com> Hi All, I?m not sure if this is a valid question but still I?m going to try. I just updated from my old version of OSMOCOM to the latest one. Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing. Can anyone direct me to the right path where to check it? Below are the configuration files used for each OSMOCOM elements. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.conf Type: application/octet-stream Size: 7024 bytes Desc: openbsc.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 1994 bytes Desc: osmo-bts.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-sip-connector.cfg Type: application/octet-stream Size: 1075 bytes Desc: osmo-sip-connector.cfg URL: From nhofmeyr at sysmocom.de Thu Jul 27 10:55:48 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 27 Jul 2017 12:55:48 +0200 Subject: libosmo-sccp vty point-code Message-ID: <20170727105548.GB27101@my.box> In the libosmo-sigtran cs7-instance vty scope, we have the same point-code command on adjacent scopes: cs7 instance 1 point-code 1.2.3 ! sets primary_pc sccp-address msc point-code 0.0.1 sccp-address sgsn point-code 0.0.2 So if we reverse the order, we're in trouble: cs7 instance 1 sccp-address msc point-code 0.0.1 sccp-address sgsn point-code 0.0.2 point-code 1.2.3 ! sets primary_pc The parser interprets the last point-code to belong to the sgsn address scope, not the outer cs7 scope. We could rename the sccp-address one to 'pc', but... This reinforces the idea to do strict parsing of leading spaces in all our vty config files to interpret as explicit scope exit. That would break some running configs with odd spacing, but would also fix all of these issues forever. Given we're moving to a kind of Osmocom 2.0, now would be a good time to make such a change. If we from now on disallow tabs and enforce single-space indenting of child scopes, the code for that should be rather simple: count leading spaces and done. And we'd need to turn this off for interactive VTY shells. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From info at meathbroadband.com Wed Jul 26 14:21:00 2017 From: info at meathbroadband.com (Meath Broadband) Date: Wed, 26 Jul 2017 15:21:00 +0100 Subject: ip.access nano 3G S8 Configuration Message-ID: We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root at osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thewlis at meathbroadband.com Wed Jul 26 19:23:36 2017 From: john.thewlis at meathbroadband.com (John Thewlis - Meath Broadband) Date: Wed, 26 Jul 2017 20:23:36 +0100 Subject: ip.access nano 3G S8 Configuration Message-ID: <8e610b41-0b7d-ac57-f2a5-7503b840e2e1@meathbroadband.com> We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root at osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Jul 28 13:48:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 28 Jul 2017 15:48:36 +0200 Subject: ip.access nano 3G S8 Configuration In-Reply-To: <8e610b41-0b7d-ac57-f2a5-7503b840e2e1@meathbroadband.com> References: <8e610b41-0b7d-ac57-f2a5-7503b840e2e1@meathbroadband.com> Message-ID: <20170728134836.GC27101@my.box> On Wed, Jul 26, 2017 at 08:23:36PM +0100, John Thewlis - Meath Broadband wrote: > We are trying to setup this AP as part of the 3.5G Osmocom project. > > We have the software stack operational and are now preparing the nano > for testing. > > When we try to login via telnet at port 8090 we are getting a constant > refusal to connect:- > > root at osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 > Trying 192.168.192.30... > telnet: Unable to connect to remote host: Connection refused If you are absolutely positive that the nano3G has this IP address, then there might be something wrong with the firmware image. Related: if a nano3G has a dmi config file in its file system, the dmi telnet will not launch. You may verify these things by logging in via ssh: https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G#SSH-Access I believe there's also a web interface to the nano3G, but I never use it and notice that it isn't described on the wiki. Feel free to add if you find one. If that doesn't help, sysmocom may have to flash a fresh firmware to fix it, which involves physical shipping I guess. > The device seems to be locked as indicated by the leds on the front panel. What exactly is indicated? ~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 Fri Jul 28 19:14:01 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 28 Jul 2017 21:14:01 +0200 Subject: ip.access nano 3G S8 Configuration In-Reply-To: <20170728134836.GC27101@my.box> References: <8e610b41-0b7d-ac57-f2a5-7503b840e2e1@meathbroadband.com> <20170728134836.GC27101@my.box> Message-ID: To be very clear here: sysmocom does *not* operate any service (nor has it authority) to flash firmware images of third party manufacturers to devices. Those firmware images are subject to copyright like any other software. All we can do is to restore a backup to a device which we sold, as part of normal repair procedures. Any related communication should happen between that customer and sysmocom, as this is not about the osmocom software we discuss on community mailing lists. @neels: please be careful you don't raise the impression that sysmocom offers services it cannot legally provide. Thanks! -- Sent from a mobile device. Please excuse my brevity. From holger at freyther.de Sat Jul 29 17:00:32 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 30 Jul 2017 01:00:32 +0800 Subject: Ring Back Tone Missing during Call Setup In-Reply-To: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com> References: <956FFAE8-85A6-4EB4-8852-A81873744E4B@entropysolution.com> Message-ID: <36F67A89-DD01-49DF-B921-E8CCE2661F70@freyther.de> > On 27. Jul 2017, at 18:30, Ron wrote: > > Hi All, > > I?m not sure if this is a valid question but still I?m going to try. > > I just updated from my old version of OSMOCOM to the latest one. > > Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing. > > Can anyone direct me to the right path where to check it? Check if this[1] is in your checkout and being called during the call. Check what happens if you revert it. Check the diff of the MNCC log.. send a patch. cheers holger [1] http://git.osmocom.org/osmo-sip-connector/commit/?id=9d796ff15690eb313ec6d2323902f9ea677f300e From akibsayyed at gmail.com Sun Jul 30 06:46:35 2017 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 30 Jul 2017 10:46:35 +0400 Subject: Need nano3G (S8 - Model 237A) Message-ID: Dear List I am extremely sorry for off the topic question. I am willing to buy nano3G Nodeb. Is anyone in list have spare which can be sold. Please let me know. -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From choukoumoun at gmail.com Sun Jul 30 21:34:45 2017 From: choukoumoun at gmail.com (Choukoumoun) Date: Sun, 30 Jul 2017 23:34:45 +0200 Subject: Need nano3G (S8 - Model 237A) In-Reply-To: References: Message-ID: <5c599abe-d25a-5e6d-e1d5-077f91787be6@gmail.com> Hello i want one unit to. Thank you. Le 30/07/2017 ? 08:46, Akib Sayyed a ?crit : > Dear List > > I am extremely sorry for off the topic question. I am willing to buy > nano3G Nodeb. Is anyone in list have spare which can be sold. > > Please let me know. > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > > > Virus-free. www.avast.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: