OpenBSC November 2017

openbsc@lists.osmocom.org

21 participants
43 discussions

osmo-bsc access lists semantics are confusing
by Neels Hofmeyr 10 Nov '17

10 Nov '17

I'm just now looking through osmo-bsc libfilter, and I would have expected a kind of top-down behavior like for firewalls: imsi-deny .* imsi-allow 12345.* imsi-deny 1234567.* imsi-allow 123456789.* imsi-deny .*[13579] i.e. start out denying everything. Except allow IMSIs starting with 12345. Except deny those that continue with 67. Unless they continue with 6789, allow those. Finally only service even-numbered IMSIs here. That would be quite powerful. Instead, what I see is that first, we go through the entire access list regarding only the allow-imsi entries. If any one of them matches, break the loop and return acceptance *right away*. If no accept rule matched, go through the list again, and see if any deny rule matches. If there is one, break and return failure right away. This was for the "local" per-msc rules, we also have a "global" rule set on the bsc level, which follows after that. For that, we currently actually completely ignore all allow rules, and only return error if any deny rule matches. In the end, if nothing matched, return acceptance. A code comment says that for the "global" rules, we want to deny first and accept second, so precisely reverse from the "local" level, but as a user I would find that rather confusing. See auth_imsi() in bsc_msg_filter.c. So in short, to get the intended behavior outlined above, you are forced to cram all rules into a single regex, sort of like imsi-allow 12345$<not>67\|6789$.*[02468] imsi-deny .* which I don't actually know how to express as you can see... or maybe imsi-allow 12345[^6].*[02468] imsi-allow 123456[^7].*[02468] imsi-deny .* My questions are: - Is it implemented this way for performance considerations? - Are we not going to change this, even assuming that we regard changes being useful, because we don't want to break with previous configs? - When looking in auth_imsi(), the access list names are: auth_imsi() name | comments | osmo-bsc passes bsc_lst "local" vty 'msc' level access rules nat_lst "global" vty 'bsc' level access rules Needless to say that "local", "global", "nat", "bsc" and "msc" are quite hard to follow. From the osmo-bsc filter code's perspective, there may be multiple MSCs configured, and per-msc config could be seen as more specific ("local") than bsc level, which applies to all MSCs ("global")... Was that the intention or is the local/global actually swapped by accident? (I notice that this feature seems to be intended for osmo-bsc-nat, and there's also a concept of a super-global blacklist that is always NULL in osmo-bsc.) Here's a patch to add imsi-allow evaluation on the "global" level; other than the comment says, I use the same order of 'allow' first and 'deny' second to be consistent: https://gerrit.osmocom.org/4750 Otherwise I believe this could benefit from some refactoring, but probably we don't have time/funding to care about that, do we... ~N

2 2

OsmoBSC now *requires* an OsmoMGW to run alongside it
by Neels Hofmeyr 10 Nov '17

10 Nov '17

There has been a profound change in RTP handling by OsmoBSC: we now require an OsmoMGW to run alongside it to manage RTP streams, and to be able to provide intra-BSC handover. Kindly refer to https://osmocom.org/news/80 ~N

2 1

GPRS EXperiments
by Keith 09 Nov '17

09 Nov '17

Hi List! As there isn't so much about GPRS on here, I though I might write something about experiments over the last couple of weeks with data inside and outside of the lab. I've installed up to date versions of osmo-bts and osmo-pcu on sysmobts 2050 hardware and it's working great! Dynamic channels are really nice, with half rate TCH and AMR working perfectly. Thanks for all that work! The question for this experiment was if it was going to be feasible to actually do anything with several hundred data hungry spying devices.... I mean mobile phones on the network. For the traffic control, I setup a local blacklisting or whitelisting dns server. I've tried both. Blacklisting the worst culprits would be nice, but in practice I think I'll have to go for whitelisting only the intended permitted services. I configured pcodns1 in the ggsn to point to this DNS server, AND I setup a port 53 redirect to catch quite a lot of traffic from android that likes to just talk directly to 8.8.8.8 anyway. In the wild, some dns request analysis reveals the worst culprits (this is a very basic analysis) appear to be all the google update stuff, play store etc, facebook iCloud, (all to be expected) , and certain CDNs. Some research shows that these CDN companys specialize in delivery of advertising content inside apps such as mobile platform games. Such is the sad state of affairs on today's internet. Fortunately, we have iptables and ip sets and we have AS blocks assigned to certain bandwidth hungry corporations :-) So turns out it seems quite feasible to supply service for text messages with certain popular IM services to many phones. Short voice clips worked quite well in the lab tests, although support for media such as pictures and videos was not so great. I have yet to successfully send an image (sourced via device camera within the app) over a "secret" chat with Telegram messenger. As this is not a very low level report, rather intended as some light reading :) I also have a question in a similar light vein. I'm still getting to grips with the log messages available in the pcu , the sgsn and not so much the ggsn, and I'm observing and learning the sequence of events, so at some point I should be able to present a better report about this with some relevant traces and better analysis. For now, In the lab tests I am constantly monitoring the RF uplink; I observe that a phone will attach and then go quiet. A foreground running app may report that it is "connecting" or some such, and the little arrows may be flashing to show that apparently we are transmitting data, but there is nothing on the uplink. My guess here is the OS has sent something and the baseband is saying yes yes doing it.. but the baseband at the same time is waiting for something from the network (and not getting it)? This situation can persist for some time.. several minutes. I have observed that if I initiate any data transfer from the network side then the uplink is established. By the same token, If I transfer a file from the network (http download or some such), the same applies. The link stays active and the IM chat session is very responsive alongside the file transfer. Shortly after the file transfer completes, the uplink is quiet again and the latency in the IM session becomes a problem. >From a UX point of view.. Let me put it this way.. I can start an IM chat, send a message.. but then we get to this quiet uplink sitation and the messages stop sending.. so from the user's point of view it's frustrating. the phone looks like it's transmitting.. until there are timeouts and disconnections and the app may show some indication to the user that it is having trouble connecting to the network. However if I run something on the network side like a script that sends one ping to the phone every ten seconds, this keeps the connection 'alive' and the IM session is much more satisfactory for the user. I should note I believe I observe this also on commercial networks in some places like certain Berlin U-bahn stations where you can still find (only) GPRS data coverage. Also, a more scientific report is needed, but I seem to observe some phones behaving "better" than others, as in being a little more active on the uplink. Maybe it is related to power saving configuration? The not very low level and scientific question here is: Is this kind of thing tunable with gprs parameters? Any tips on which ones to play with? ( Quite happy to wait until I can send a more useful report too! ) Thanks! Keith.

2 3

Range of "ipa unit-id" site_id vty config
by Pau Espin Pedrol 08 Nov '17

08 Nov '17

Hi, I see the range for ipa unit-d site_id range of values is 0-65534 as configured in the VTY: osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", However, being it a uint16_t having 2^16=65536 values, I would expect the range to be 0-65535 (finished in 5, not 4). The only reason I can think of is that the last address is somehow reserved and must not be used. Does somebody know if that's the case? I couldn't find any documentation and as far as I can tell our code doesn't seem to handle the site_id=65535 case specially. If it is not reserved, then I can send a patch to change the range to be 0-65535. I actually see the same range pattern in lots of places around osmocom vty parameters, which makes me think somebody may have initially introduced the wrong number and then people have been copy-pasting the same number over and over again when adding new parameters: $ ag "0-65534" libosmocore/src/gb/gprs_ns_vty.c 269: "nse <0-65535> nsvci <0-65534>", libosmo-sccp/src/osmo_ss7_vty.c 420: "listen " XUA_VAR_STR " <0-65534>", 442: "no listen " XUA_VAR_STR " <0-65534>", osmo-sgsn/src/gprs/gb_proxy_vty.c 149: "sgsn nsei <0-65534>", 364: "secondary-sgsn nsei <0-65534>", 532: "delete-gbproxy-peer <0-65534> bvci <2-65534>", 553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", 626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT", 698: "delete-gbproxy-link <0-65534> (stale|de-registered)", osmo-bsc/src/libbsc/bsc_vty.c 1850: "ip.access unit_id <0-65534> <0-255>", openbsc/openbsc/src/libmgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 596: "number endpoints <0-65534>", 755: "transcoder-remote-base <0-65534>", 1119: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", openbsc/openbsc/src/libbsc/bsc_vty.c 1803: "ip.access unit_id <0-65534> <0-255>", osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c 130: "mgw bts-base <0-65534>", 140: "mgcpgw bts-base <0-65534>", osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 606: "number endpoints <0-65534>", 765: "transcoder-remote-base <0-65534>", 1130: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", osmo-mgw/src/libosmo-mgcp/mgcp_vty.c 264: "bind port <0-65534>", 297: "rtp net-range <0-65534> <0-65534>", 509: "number endpoints <0-65534>", 947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>", osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", Regards, -- - Pau Espin Pedrol <pespin(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 4

GPRS on Ettus B210 hardware
by Lorenzo Cavallini 08 Nov '17

08 Nov '17

Hello everyone, I'm trying to setup OpenBSC to use GPRS on Ettus hardware with (B210). I followed what's written here more or less: https://osmocom.org/projec ts/cellular-infrastructure/wiki/OpenBSC_GPRS however for some reason I cannot get this to work. This is the first time that I try to setup GPRS with OpenBSC and even though I have a lot of experience working with OpenBSC for 2G stuff, this time I cannot figure out what's wrong. Here's the log from osmo-bts-trx when osmo-pcu connects: <0001> oml.c:76 Sending PCU version report to BSC: 0.4.0.2-bfc5 <0009> pcu_sock.c:336 Sending data indication: sapi=BCCH arfcn=0 block=0 data=01 06 00 90 00 19 5a 6f c9 e0 84 10 ab 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=2 <0000> rsl.c:669 (bts=0,trx=0,ts=2,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=3 <0000> rsl.c:669 (bts=0,trx=0,ts=3,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=4 <0000> rsl.c:669 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=5 <0000> rsl.c:669 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=6 <0000> rsl.c:669 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=7 <0000> rsl.c:669 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=0 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=0 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=1 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=1 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=2 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=2 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=1 arfcn=1 block=0 <0009> pcu_sock.c:487 Data request received: sapi=PTCCH arfcn=1 block=0 data=2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=3 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=3 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=4 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=4 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b the last part (Sending rts request: ...) just repeats over and over. Here's the log from osmo-pcu: <000b> telnet_interface.c:101 telnet at 127.0.0.1 4240 <0001> osmobts_sock.cpp:229 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:288 osmo-bts PCU socket /tmp/pcu_bts has been connected <0001> osmobts_sock.cpp:292 Sending version 0.4.0.2-bfc5 to BTS. <0001> pcu_l1_if.cpp:107 Sending 0.4.0.2-bfc5 TXT as PCU_VERSION to BTS <0001> pcu_l1_if.cpp:427 BTS available <0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC <0008> gprs_ns.c:1619 Listening for nsip packets from 127.0.0.1:23000 on 0.0.0.0:23000 <0008> gprs_ns.c:1638 NS UDP socket at 0.0.0.0:23000 <0008> gprs_ns.c:263 NSVCI=1800 Creating NS-VC <0008> gprs_ns.c:1656 NSEI=1800 RESET procedure based on API request <0008> gprs_ns.c:446 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=2 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=2 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=3 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=3 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=4 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=4 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=5 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=5 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=6 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=6 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=7 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=7 <0008> gprs_ns.c:887 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) <0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) <0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) <0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 <0008> gprs_ns.c:555 NSEI=1800 Tx NS UNBLOCK (NSVCI=1800) <0008> gprs_ns.c:1411 NSEI=1800 Rx NS UNBLOCK <000a> gprs_bssgp_pcu.cpp:541 NS-VC 1800 is unblocked. <0009> gprs_bssgp_pcu.cpp:820 Sending reset on BVCI 0 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0008> gprs_ns.c:1417 NSEI=1800 Rx NS UNBLOCK ACK <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:828 Sending reset on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC- UNBLOCK unknown <0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC- UNBLOCK unknown <0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK and like osmo-bts-trx, the last part (Sending unblock ...) repeats forever. Basically the two processes are stuck like these and nothing works, only 2G. The other components (ggsn, osmo-sgsn and osmo-nitb) seems to be fine, I'm not getting any error output in the their logs. The configuration should be fine, I just followed the mentioned link and all the components can talk to each other, so it's not an ip/port issue on my local system. Any help in this would be appreciated. Reading this ML seems like GPRS works for everyone except me...might be related to Ettus B210, I don't know to be honest, but I had no issue so far with OpenBSC and 2G. Eventually I can debug the source and provide more information if required. Everything was built from latest git repositories, might be related to recent split in osmo-nitb and gprs? Thanks for your help! Lorenzo

2 3

gerrit disk was full
by Neels Hofmeyr 08 Nov '17

08 Nov '17

Just now the gerrit disk quota filled up. It hit the limit at 7.6G disk usage. I gave it 10G of space via zfs to not get pulled in too deeply, we may want to investigate whether anything filled it up unintendedly/erratically. When I look at the listing I made when writing https://osmocom.org/projects/osmocom-servers/wiki/Osmocomorg_Web_Servers gerrit already had 7.19 G disk usage then. It seems some snapshot may have filled up the rest now, and the remaining 400Mb are from new commit objects / repos repack? It's too late now for me to wait for a du to complete... ~N

1 0

building osmo-iuh and libsctp
by Neels Hofmeyr 07 Nov '17

07 Nov '17

I've recently upgraded my OS to debian 9 and suddenly have difficulty building osmo-iuh: the osmo-hnbgw linking step complains about a missing sctp_send, which is resolved by adding -lsctp to LDADD. But I'm puzzled why this comes from a system upgrade and not a code change. Does anyone have an idea what could cause this, or what would have hidden the linking error before? What's the proper way to add -lsctp? The dependency comes from libosmo-ranap using libosmo-sigtran - should the libosmo-sigtran.pc include -lsctp? - should we add a libsctp detection to osmo-iuh's configure.ac (copy from libosmo-sccp) and use $(SCTP_LIBS) constants in Makefile.am LDADD? - is everything correct and my OS has a problem instead? Thanks for any input... ~N

2 2

Whitelisting/Blacklisiting of IMSI
by Ron 07 Nov '17

07 Nov '17

Hi All, May we request on how to allow specific number of IMSI in OSMO-BSC? We tried the following using the REGEXP below, but all kinds of IMSIs are still able to camp. First try: auth policy regexp authorized-regexp ^12312\d{10}$ Second try: auth policy regexp authorized-regexp 12312\d{10} We also tried to used the access-list imsi-allow under BSC and then declare it under MSC configuration but still has the same behavior. All kinds of IMSIs are still allowed. First try: bsc access-list TEST imsi-allow ^12312\d{10}$ access-list-name TEST msc 0 access-list-name TEST Second try: bsc access-list TEST imsi-allow 12312\d{10} access-list-name TEST msc 0 access-list-name TEST We also tried to to used the access-list imsi-deny using the same regular expressions, unfortunately, still have the same outcome. All IMSIs are still allowed. First try: bsc access-list TEST imsi-deny ^12312\d{10}$ 16 16 access-list-name TEST msc 0 access-list-name TEST Second try: bsc access-list TEST imsi-deny ^12312\d{10}$ 16 16 access-list-name TEST msc 0 access-list-name TEST But using access-list imsi-deny to a specific IMSI, we successfully block it. Is there a way to block a number of different IMSIs only? What regular expression format is used by OSMO-BSC? Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

1 0

Build failed in Jenkins: Coverity-Upload » linux_amd64_debian8 #1653
by jenkins＠lists.osmocom.org 05 Nov '17

05 Nov '17

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…> ------------------------------------------ [...truncated 1.84 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom 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... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... 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-unknown-linux-gnu checking host system type... x86_64-unknown-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 whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-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 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 pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.10-05bc > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c mv -f .deps/core.Tpo .deps/core.Po gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

3 10

New "osmocom:latest" package feed
by Harald Welte 03 Nov '17

03 Nov '17

Dear Osmocom community, since the NITB-split has completed, and we have integrated 3G fully into master, and also merged nitb-split and nitb packages in one feed, the next step on the agenda was to create packages/feeds that are more stable than "nightly". After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories. We now also have a "osmocom:latest" feed for various Debian and Ubuntu GNU/Linux distributions which contains packages for the last tagged version of each source code repository. The setup is fairly similar to that of the "osmocom:nightly" packages and is described at https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds I've also removed all known references to Nightly_Builds on the wiki and replaced it with a reference to the new Binary_Packages page explaining the differences between Nightly_Builds and Latest_Builds: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages As you can see at https://build.opensuse.org/project/monitor/network:osmocom:latest almost all the packages are building already. I intend to fix the remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly. -- - Harald Welte <hwelte(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 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2017