- OpenBSC - lists.osmocom.org

OpenBSC Random Access Channel: rach_bsic != bts_bsic
by Vadim Yanitskiy 12 Jul '17

12 Jul '17

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.

2 1

Control Interface to OsmoSGSN
by Omar Ramadan 12 Jul '17

12 Jul '17

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

3 2

Re: sscp-context initalization via VTY
by Philipp Maier 10 Jul '17

10 Jul '17

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 <pmaier(a)sysmocom.de> 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

3 5

VTY errors
by Neels Hofmeyr 07 Jul '17

07 Jul '17

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

1 0

semver for all Osmocom projects?
by Max 06 Jul '17

06 Jul '17

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 <msuraev(a)sysmocom.de> 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

1 0

Creating GSM Users Association (GSMUA)
by Mychaela Falconia 06 Jul '17

06 Jul '17

Hello FreeCalypso and Osmocom communities, I am in the process of creating an informal organisation representing the interests of those members of the GSM universe whose interests are not represented by GSMA etc, and I am inviting you to join me in this venture. I propose that we name our informal organisation GSMUA, standing for GSM Users Association, and my vision for this GSMUA is to be a counter-body (antibody?) to the official GSMA. I just registered the gsmua.org domain name, but there is no website or mailing list set up yet. If someone from the Osmocom camp would like to host the server infrastructure for gsmua.org, I will happily point the DNS to you, otherwise the FreeCalypso family can host it on our server. My vision for GSMUA is to represent the interests of GSM end users (empowered end users who wish to fully own and control all aspects of their user equipment while operating on public mobile networks in a fully spec-compliant manner), small boutique manufacturers of GSM devices (both MS/user equipment and network infrastructure), small community network operators and others whose interests are not represented by GSMA etc, especially in cases where our interests are in direct conflict with the interests of big players such as giant device manufacturers, giant commercial network operators and governments. A key goal of GSMUA is to be project-neutral, that is, every person and every small company belonging to any of the categories listed above (empowered end user, small boutique device manufacturer, small community network operator etc) should be fully welcome regardless of which specific project they are associated with. As of today there are at least two different projects offering GSM MS implementations (OsmocomBB and FreeCalypso) and at least two different projects offering network-side GSM implementations (Osmocom and OpenBTS), and I hope that this number of available alternatives will continue to grow: freedom of choice is always a good thing. But at the present time there exists no neutral soil on which members of different projects with a common interest (GSM networks and devices serving the interests of end users rather than big corporations and governments) and a common enemy (just named) can meet, and this lack of neutral meeting ground is the problem which GSMUA is meant to solve. I also have one practical application for GSMUA in mind already: to manage and legitimize recycling of wasted IMEI number ranges. By the official rules of GSMA etc each different *type* of GSM mobile equipment requires a different TAC, i.e., a range of at least 1 million IMEI numbers. So if a small boutique GSM device manufacturer makes a boutique MS device of which no more than 100 units will ever be made, 999900 IMEI numbers have to be wasted by the official rules. While I don't know of any manufacturer who got a range of 1 million IMEIs and only made 100 devices, we do have examples like Openmoko GTA01/02 and Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that about 15 thousand units were made in total; in the case of Pirelli DP-L10 it appears that the total number produced was somewhere under 100 thousand. In each case a full range of 1 million IMEIs was allocated, and at least 900 thousand numbers out of each range are currently unused and wasted. If a small boutique manufacturer wishes to offer a boutique GSM MS product to the general public and wishes to ship each unit with a world-unique IMEI that stands a good chance of being accepted as valid by common GSM networks, and the product in question does not qualify for IMEI allocation by the official rules (e.g., the product is a development board specifically intended for users to run their own firmware and connect to live public networks with it, taking full personal responsibility for their actions) - the situation I found myself in with my GSM MS development board - I feel that the small boutique manuf in question should be empowered to squat on a small subrange of someone else's IMEI range if it is known beyond reasonable doubt to be wasted and unused. However, this recycling of wasted IMEI number ranges could be better organized and given at least some aura of semi-legitimacy if there were a community body set up to manage it, and this is where my proposed GSMUA can come in. Once we get our GSMUA up and running and assign a group of volunteers to be IMEI recycling managers, any small GSM or 3G+ device manufacturer who needs a small range of IMEI numbers will be able to request one from GSMUA, and we will allocate and assign these small subranges out of whatever wasted range we decide to squat on, ensuring that each requestor gets a different subrange. So these are my ideas, and I would like to see them turn into reality. We are going to need a simple website and a community mailing list at gsmua.org, and for the IMEI recycling service we will need a small group of volunteers to serve as its managers - I and Das Signal from FreeCalypso will be happy to serve on that panel, but it would be nice to also have someone from the Osmocom camp for better neutrality. Bright Blessings, Mychaela Falconia, Mother of FreeCalypso

5 6

openBSC encryption
by robert 29 Jun '17

29 Jun '17

Hi, Till now I have always worked with simcards without knowing their ki so I was not using any encryption. I have recently bought some programmable simcards and gave them an IMSI and KI and tried to have them working with ‘encryption a5 1’ and ‘encryption a5 3’ and I faced some problems. First if I choose 'a5 3' the phone cannot connect to the BTS and nothing can be done, while if I set the encryption to 'a5 1’, the phone connects normally and can make and receive calls but sometimes the call fails for a reason that I don’t know. I have then tried the following setup: I have connected 3 phones A, B and C. A and B have no KI related to them so no encryption is applied while C was given a KI. If I call from A to B or from B to A, the call is done successfully every time, while if I call from either A or B to C or from C to A or B the call might work and might not. Is there something in the configuration that should be changed when adding the encryption support ? And how to enable the a5 3 encryption ? Best regards,

2 1

SS7 / SCCP design question: one or several SCCP instances?
by Neels Hofmeyr 29 Jun '17

29 Jun '17

We need to decide which way to go with point codes, sccp- and ss7-instances. pmaier and I have reached different conclusions and wrote patches going in opposite directions, now we need to decide and cosolidate: The MSC has various connections over SCCP: it serves BSSAP for several BSCs, and RANAP for several HNBGWs. BSC - A MSC: BSC -}----------> BSSAP BSC - -----> RANAP / HNBGW -}-/ IuCS HNBGW - 1) I went for exactly one point code at the MSC (say PC=1). There is exactly one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). When comparing to the TCP/IP model, the paradigm here is that a PC is like an IP address and the SSN like a port number. At the server, the MSC, I have one PC (IP address) and listen on one SSN (port) per protocol served, and clients all connect to the same PC+SSN, receiving separate connection IDs. I can also use the calling address to know which client I'm talking to. Hence I moved the osmo_sccp_instance creation up to "the top" and created two sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice. I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses. An pseudocode MSC VTY config for this scenario could look something like this: msc sccp local-pc 0.0.1 ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb remote-bsc 1 pc 1.0.1 remote-bsc 2 pc 1.0.2 remote-hnbgw 1 pc 2.0.2 i.e. one local PC is configured, each protocol has its separate SSN, each sccp_user_bind() serves all clients for that SSN. This is the direction I took to add IuCS to AoIP. 2) pmaier added VTY configuration for various point codes, and went the other way: the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is told the addresses of all known BSCs and) every time a BSC is configured via VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a distinct local PC for each BSC, and for each HNBGW. In this model there still is a code problem I noticed while adding IuCS to AoIP in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different PC, the osmo_ss7_instance used is still the same (still id=1), and notes this second PC as its global local PC. The messages received for the first client's PC are then seen as remote and routed back out -> infinite message loop. A solution here would be to either a) use a separate osmo_ss7_instance per osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to osmo_sccp_simpe_client() and increment by one each time) or b) implement the routing algorithm so that it notices the local PCs of several local SCCP clients. A VTY config for this scenario so far looks like this: ! define some addresses, referenced below cs7 instance 1 sccp-address msc_local subsystem-number 254 point-code 0.0.1 routing-indicator PC sccp-address bsc_remote subsystem-number 254 point-code 0.0.2 routing-indicator PC sccp-address bsc_remote2 subsystem-number 254 point-code 0.0.3 routing-indicator PC msc bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2 (I'm not sure whether it is possible to have several sccp_instances with the same msc_local address, but we would find solutions for these petty issues once we've decided which way to go.) (I also think 'calling-addr' and 'called-addr' should rather be named 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr can be the remote or the local one. That's also besides the point for now.) My personal idea is that 1) is simpler: we have one ss7 instance per program, no matter how many clients are served. I can still tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients per SSN is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and it sounds to me like a paradigm of creating a whole new server for each client that connects, so instead of using an ss7_instance's routing, we create separate instances, each sending to only one counterpart. But is 2) maybe the correct way to go for reasons I'm not aware of? I notice that what I wrote is biased towards 1) because that's my POV, but this is indended to be a neutral question. We need a choice for 1) or 2) so that pmaier and I can adjust and merge our patches accordingly. Can you help us decide, hopefully with some background knowledge on how an SCCP network is intended to be set up? Thanks! ~N

3 5

aoip branch
by Neels Hofmeyr 28 Jun '17

28 Jun '17

I successfully tested some new patches on the AoIP branch locally and pushed them to the openbsc.git/aoip branch. They allow using 3G with AoIP. @pespin: if aoip tester runs fail now, that's probably the cause. @pmaier: I tried to apply all patches found on the pmaier/aoip branch, but excluded the commits started with "MSC side reset" because of build failure. The failure is the same I saw a few days ago, still unchanged: CCLD osmo-bsc_nat ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_go_parent': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:130: undefined reference to `osmo_ss7_vty_go_parent' ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_is_config_node': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:140: undefined reference to `osmo_ss7_is_config_node' collect2: error: ld returned 1 exit status I suspect you still have some of your work not pushed to libosmo-sccp? I can't find a private branch or patches on gerrit about osmo_ss7_vty. In general I think it would be good to always keep your work on a private branch and push it frequently (doing anything you like on it, amending and so forth). For collaboration, but also to have a backup of your patches...? If you like, we can have a call soon to figure out a rebase of your work onto aoip. A merge conflict is solved on the neels/pmaier_aoip branch ('git fetch' first), but I get above build failure. ~N

3 3

.deb build as jenkins test
by Max 27 Jun '17

27 Jun '17

Hi. In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as an additional step for jenkins jobs triggered by gerrit push. It'll mean longer build times but it'll prevent breaking changes from reaching master. It won't guarantee that we won't see occasional arch/version specific breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it should make nightly builds more stable and easier to maintain. What do you think? -- Max Suraev <msuraev(a)sysmocom.de> 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

2 1