From axilirator at gmail.com Fri Jun 14 04:39:01 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 14 Jun 2019 11:39:01 +0700 Subject: OsmoSGSN: optional / mandatory authentication Message-ID: Hi Pau, today I cannot sign in to Gerrit for some magic reason, so I would like to post some notes about your change [1]. [1] https://gerrit.osmocom.org/#/c/osmo-sgsn/+/14445/ > [...] it changed the default logic for remote policy to not require > authentication, which broke TTCN3 tests because sgsn no longer > tries to authenticate the users. My bad, sorry for that. > let's enable it by default when on auth-policy remote. ACK. > doc/manuals/vty/sgsn_vty_reference.xml > Allow MS to attach via GERAN without authentication > (default and only possible value for non-remote auth-policy) Actually, no. My motivation for introducing this VTY parameter was exactly the ability to use remote auth-policy (i.e. OsmoHLR) to check if a subscriber is known, but not to require authentication, just like we can do in CS-domain. In other words, 'authentication optional' should work with 'auth-policy remote'. > src/gprs/sgsn_vty.c > DEFUN(cfg_authentication, cfg_authentication_cmd, > [...] > Allow MS to attach via GERAN without authentication > (default and only possible value for non-remote auth-policy) Same here. It *is* possible for 'auth-policy remote' too. > src/gprs/gprs_sgsn.c > struct sgsn_instance *sgsn_instance_alloc(void *talloc_ctx) > [...] > inst->cfg.auth_policy = SGSN_AUTH_POLICY_CLOSED; > /* only applies if auth_policy is REMOTE */ > inst->cfg.require_authentication = true; > [...] Are you sure this wouldn't break non-remote auth-policy use cases? AFAIR, the GMM layer requests authentication regardless of the 'auth-policy', so then in 'gprs/sgsn_auth.c' we conditionally perform authentication or immediately return SGSN_AUTH_ACCEPTED. An alternative solution is to invert 'cfg.require_authentication', e.g. to 'cfg.omit_authentication', so by default we will require authentication since it's initialized to false. With best regards, Vadim Yanitskiy. From pespin at sysmocom.de Fri Jun 14 10:58:12 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 14 Jun 2019 12:58:12 +0200 Subject: OsmoSGSN: optional / mandatory authentication In-Reply-To: References: Message-ID: <2667015a-e370-24dd-0ff5-12738a4d174b@sysmocom.de> Hi Vadim, On 6/14/19 6:39 AM, Vadim Yanitskiy wrote: >> doc/manuals/vty/sgsn_vty_reference.xml >> Allow MS to attach via GERAN without authentication >> (default and only possible value for non-remote auth-policy) > > Actually, no. My motivation for introducing this VTY parameter > was exactly the ability to use remote auth-policy (i.e. OsmoHLR) > to check if a subscriber is known, but not to require > authentication, just like we can do in CS-domain. In other words, > 'authentication optional' should work with 'auth-policy remote'. > I think you are reading it wrong / too quickly, or perhaps it's me not expressing it correctly, but to me what you say and what I say there is the same. In there I'm saying auth-policy DIFFERENT THAN "remote" (non-remote) can only take the value "optional". Hence, I'm NOT stating that "remote" cannot take the value "optional". As a result, optional is a possible value for "remote". So the important thing here is: If you are using any auth-policy other than "remote", you MUST use this authentication value (even implicitly since anyway it doesn't make sense and doesn't really apply). If you are using remote, use whichever you want. >> src/gprs/sgsn_vty.c >> DEFUN(cfg_authentication, cfg_authentication_cmd, >> [...] >> Allow MS to attach via GERAN without authentication >> (default and only possible value for non-remote auth-policy) > > Same here. It *is* possible for 'auth-policy remote' too. Same string as above, not repeating. > >> src/gprs/gprs_sgsn.c >> struct sgsn_instance *sgsn_instance_alloc(void *talloc_ctx) >> [...] >> inst->cfg.auth_policy = SGSN_AUTH_POLICY_CLOSED; >> /* only applies if auth_policy is REMOTE */ >> inst->cfg.require_authentication = true; >> [...] > > Are you sure this wouldn't break non-remote auth-policy use cases? > > AFAIR, the GMM layer requests authentication regardless of the > 'auth-policy', so then in 'gprs/sgsn_auth.c' we conditionally > perform authentication or immediately return SGSN_AUTH_ACCEPTED. > Only places where "require_authentication" is checked are: src/gprs/sgsn_auth.c:115 src/gprs/sgsn_auth.c:177 And both are code paths only executed under condition that auth_policy is SGSN_AUTH_POLICY_REMOTE. Which means "require_authentication" is not checked/used at all for other auth_policy scenarios. So we are safe, the change is not affecting other auth_policy. So I think my patch is fine and actually simplifies older state. I'm happy to rework stuff it you can find any flaw I didn't see. Regards, Pau -- - 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 axilirator at gmail.com Sat Jun 15 16:45:13 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 15 Jun 2019 23:45:13 +0700 Subject: URGENT: OsmoMSC is broken by the recent changes in libosmocore Message-ID: Hi Harald! Unfortunately, your change [1] breaks some osmo-* projects. I am getting the following segfault with OsmoMSC: [1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329a73155d46ff8 [1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/ ERROR: osmo_log_info == NULL! You must call log_init() before using logging in log_check_level()! Assert failed osmo_log_info logging.c:184 backtrace() returned 10 addresses /usr/local/lib/libosmocore.so.12(+0x16f6b) [0x7ffff72dff6b] /usr/local/lib/libosmocore.so.12(osmo_panic+0xc0) [0x7ffff72dff20] /usr/local/lib/libosmocore.so.12(+0x14487) [0x7ffff72dd487] /usr/local/lib/libosmocore.so.12(log_check_level+0x1a) [0x7ffff72de82a] /usr/local/lib/libosmocore.so.12(osmo_fsm_register+0xef) [0x7ffff72d81bf] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x692e03] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x9b6aad] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7ffff595fed5] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x4215cc] gdb-peda$ bt #0 0x00007ffff5974c37 in __GI_raise (sig=sig at entry=0x6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff5978028 in __GI_abort () at abort.c:89 #2 0x00007ffff72dff25 in osmo_panic_default (args=0x7fffffffda48, fmt=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:49 #3 osmo_panic (fmt=fmt at entry=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:84 #4 0x00007ffff72dd487 in assert_loginfo (src=) at logging.c:184 #5 0x00007ffff72de82a in log_check_level (subsys=subsys at entry=0xffffffff, level=level at entry=0x7) at logging.c:1033 #6 0x00007ffff72d81bf in osmo_fsm_register (fsm=0xcc6c20 ) at fsm.c:261 #7 0x0000000000692e03 in msc_a_fsm_init () at msc_a.c:1003 #8 0x00000000009b6aad in __libc_csu_init () #9 0x00007ffff595fed5 in __libc_start_main (main=0x517540
, argc=0x1, argv=0x7fffffffdcb8, init=0x9b6a60 <__libc_csu_init>, fini=, rtld_fini=, stack_end=0x7fffffffdca8) at libc-start.c:246 #10 0x00000000004215cc in _start () As can be seen, this happens when we register 'msc_a' FSM, which of course has .allstate_event_mask == 0x00, and dummy .allstate_action == msc_a_fsm_allstate_action(), which basically does nothing. The registration happens even before the main() is called, since we use '__attribute__((constructor))', and logging is not yet initialized at that time. We need to fix the FSM definition, but right now I think we have no other way than reverting [1]. With best regards, Vadim Yanitskiy. From osmith at sysmocom.de Tue Jun 18 07:22:47 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Tue, 18 Jun 2019 09:22:47 +0200 Subject: Errors from git.osmocom.org Message-ID: <87c149e4-17ad-0213-45e8-c43bd27ba659@sysmocom.de> Hello ML, cloning from git.osmocom.org is sporadically failing. From one CI job that ran today: > Cloning into 'osmo-bsc'... > error: garbage at end of loose object 'b5511145af6213e2d23a3e9890fd42b8aaa0dc1b' > fatal: loose object b5511145af6213e2d23a3e9890fd42b8aaa0dc1b (stored in is corrupt > Build step 'Execute shell' marked build as failure https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/628/display/redirect Another job failed today with: > + git -C osmo-bts fetch > fatal: unable to access 'https://git.osmocom.org/osmo-bts/': The requested URL returned error: 504 I've restarted the CI jobs. Regards, Oliver -- - Oliver Smith https://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 Fri Jun 21 16:54:04 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Jun 2019 18:54:04 +0200 Subject: Osmocom Village at CCC Camp 2019 Message-ID: <20190621165404.GU25425@nataraja> Dear all, I've been asked by a number of pepole about a possible Osmocom village at the CCC Camp 2019. I personally didn't really have any plans, but given related e-mails and "encouragement" I went ahead and registered an "Osmocom Village", see https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3 I also created a wiki page (as nobody else did, despite earlier discussion on IRC, SCNR) for coordinating related efforts at https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019 One of the bigger questions is about having a tent as well as some tables/benches to sit on and work. The Camp orga team nas been negotiating rates with a tent rental company, but to be honest I'm rather surprised by the extremely steep pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not sure we want to raise that amount of money? Even if we'd be 10 people sharing it, its still 82.50 EUR per person. And that excludes any tables/chairs. I'm attaching the relevant parts of a mail from the assemblies orga team FYI. Please note there also is some kind of fragmentation / overlap with the team planning to run the GSM/3G networks at the camp, see Lynxis' related post at https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/000362.html It's questionable whether it makes sense to have tow distinct 'villages', but given that e.g. I don't know anyone of that singularity city, I'm not sure if we'd either be welcome there, nor whether we'd want to associate us with them? Also, while the GSM network operation for sure has good reasons to mingle with the POC and whatever facilities they have, I'm not sure if the wider Osmocom community attendees unrelated to the GSM network operation wouldn't just be a disturbance/nuisance. In the end, to be honest, I personally do not feel I have the time and mental capacity to take on any additional tasks in terms of organizing anything. I just created the entry in c3assemblies as I was asked to, and I similarly created the related mailing list and wiki page. So please, anyone interested in making an Osmocom village happen one way or another, step up [and continue this discussion on the camp2019-village at lists.osmocom.org mailing list, without crossposting everywhere else :) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- Ticket sale is over. There are no more tickets available. There will be no ticket sale on site. That means you should know how many will join your village. In the next days we start planning the placing of the assemblies, we need your help. Please update your village registration at [3] https://signup.c3assemblies.de/ with the number of people who will join, extra space you require, power requirements, and such. Please write all information to be considered in the village registration form. There have been some frequently asked questions in the last weeks. So we want to address some topics here: Tents/Tables/Benches/Construction Wood: Prebuilt tents, tables, benches and wood can be borrowed or bought via the presale system: [4] https://tickets.events.ccc.de/camp2019hw/. For now there are only tents because we need to order them soon. The rest will follow and can be bought with the same voucher. You will recieve a voucher with this email (see below). The earlier you order your stuff, the more likely we can provide what you want. Especially tents might be in short supply. Please remember bringing cash for the mandatory deposit of ? 100,- for renting tables and benches. Water: We want to remind you, if you bring cooking equipment, there will be no direct fresh water and waste water supply for your kitchen. We will have some central places with fresh water supply and where you can wash your kitchen utensiles and dishes. Power: Power will be generated from diesel with power generators. All engergy you'll use will have to be generated. Think about our environment and use as little power as possible. For that reason, there is no possibility to fulfill high power demands for pizza ovens, saunas and alike. If you need cooling for your food supplies, please think about your refrigeration requirements. Less is more. And please bring enough outdoor and rain proof extension cables to connect your tents and equipment. Fire: Open wood or coal fire is not allowed at any time. That applies for anything that needs heat for kitchen usage. If you need heat, please bring your own safe gas-based camping heaters. Waste: Of course there will be containers for waste, paper and glass on the camp site. But the camp tries to be as sustainable and ecological as possible. So please consider bringing reusable dishes and cutlery. Also think about bringing a refillable water bottle for this is the more ecological alternative to bottled water. The tap water is perfectly drinkable. Wiki: There will be no automatic transfer of your data from the village registration tool to the wiki. Please create your own Wiki page using the form at [5] https://events.ccc.de/camp/2019/wiki/Form:Village if you want your village appear in the wiki. Please be aware that the only valid place for village registration is [6] https://signup.c3assemblies.de/ Timeline: 14.8: Buildup: Only for angels who help with buildup and registered at the orga- or angelsystem with their dates 16.8: People can start to build up their villages, no power or network yet 19.8: Power is probably(!) available from now 21.8: Offical start of the CCCamp19 \o/ 25.8: Last day of the CCCamp19, start of disassembly in the evening 28.8: Last day of disassembly, all must be finished no later than this day. If you stay 27th/28th, you are expected to help out! Please see [7] https://events.ccc.de/camp/2019/wiki/Timeline for recent updates. [1] https://signup.c3assemblies.de/ [2] https://tickets.events.ccc.de/camp2019hw/ [3] https://signup.c3assemblies.de/ [4] https://tickets.events.ccc.de/camp2019hw/ [5] https://events.ccc.de/camp/2019/wiki/Form:Village [6] https://signup.c3assemblies.de/ [7] https://events.ccc.de/camp/2019/wiki/Timeline From osmith at sysmocom.de Mon Jun 24 07:19:15 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 24 Jun 2019 09:19:15 +0200 Subject: Enable gsmtap logging for TTCN3 testsuites? Message-ID: <2604c254-3b7b-f115-2705-3dbbd1c71412@sysmocom.de> Dear ML, I'm wondering why we do not have gsmtap logging enabled for TTCN3 testsuites, and if there are any reasons against doing that. Personally I find it very useful to have gsmtap logs in pcap files, because then then there is no need to manually match the timestamps of the log file and interesting parts of the pcap dump. Especially in the TTCN3 testsuites, where we generate a separate pcap file for each test, but have one big log file of the SUT (e.g. osmo-hlr) for the entire testsuite run. Thoughts? Thanks, Oliver -- - Oliver Smith https://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 tyruskam at gmail.com Thu Jun 27 19:55:14 2019 From: tyruskam at gmail.com (ty) Date: Thu, 27 Jun 2019 22:55:14 +0300 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: <20190509193726.GV27066@nataraja> Message-ID: Hey all. Just bumping this since I haven?t heard any revert Thanks On Mon, 13 May 2019 at 15:31, ty wrote: > Hi Pau > Once again I truly appreciate your revert. You're right. I managed to pull > the osmoBsc and compiled it together with the dependencies. > Every thing works fine until I ran 'make' which throws this struct error > > In file included from gsm_04_80_utils.c:22:0: > /usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here > struct msgb *gsm0480_create_ussd_release_complete(void) > ^ > CC gsm_data.o > CC handover_cfg.o > CC handover_decision.o > CC handover_decision_2.o > CC handover_fsm.o > CC handover_logic.o > CC handover_vty.o > CC lchan_fsm.o > CC lchan_rtp_fsm.o > lchan_rtp_fsm.c: In function ?mgcp_pick_codec?: > lchan_rtp_fsm.c:841:12: error: ?struct mgcp_conn_peer? has no member named > ?param_present? > verb_info->param_present = true; > ^ > lchan_rtp_fsm.c:842:12: error: ?struct mgcp_conn_peer? has no member named > ?param? > verb_info->param.amr_octet_aligned_present = true; > ^ > lchan_rtp_fsm.c:851:12: error: ?struct mgcp_conn_peer? has no member named > ?param? > verb_info->param.amr_octet_aligned = true; > ^ > lchan_rtp_fsm.c:854:12: error: ?struct mgcp_conn_peer? has no member named > ?param? > verb_info->param.amr_octet_aligned = > lchan->conn->sccp.msc->amr_octet_aligned; > ^ > Makefile:616: recipe for target 'lchan_rtp_fsm.o' failed > make[3]: *** [lchan_rtp_fsm.o] Error 1 > make[3]: Leaving directory '/home/tyrus/osmo-bsc/src/osmo-bsc' > Makefile:405: recipe for target 'all-recursive' failed > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory '/home/tyrus/osmo-bsc/src' > Makefile:448: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/home/tyrus/osmo-bsc' > Makefile:380: recipe for target 'all' failed > make: *** [all] Error 2 > So I have tried all weekend to debug it but unfortunately haven't made > much headway. Any leads? > > Many thanks > > On Mon, May 13, 2019 at 12:30 PM Pau Espin Pedrol > wrote: > >> Hi. >> >> On 5/10/19 10:20 AM, ty wrote: >> > >> > tyrus at the-jedi-council:~/openbsc/openbsc/src/osmo-nitb$ ./osmo-nitb >> > .*/osmo-nitb: /usr/lib/i386-linux-gnu/libosmoctrl.so.0: no version >> > information available (required by ./osmo-nitb)* >> > *./osmo-nitb: relocation error: ./osmo-nitb: symbol ctrl_vty_init, >> > version LIBOSMOCTRL_1.0 not defined in file libosmoctrl.so.0 with link >> > time reference* >> > * >> > * >> >> You say you installed programs from .deb but you are still running the >> version of osmo-nitb from your compiled version. Use the one from >> packages to avoid this kind of issues, otherwise the version you built >> and the ones from the .deb packages won't much unless you really know >> what you are doing. >> >> -- >> - 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 >> > -- Excuse my brevity, sent on the run. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Fri Jun 28 08:32:40 2019 From: keith at rhizomatica.org (Keith) Date: Fri, 28 Jun 2019 10:32:40 +0200 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: <20190509193726.GV27066@nataraja> Message-ID: On 27/06/2019 21:55, ty wrote: > Hey all. Just bumping this since I haven?t heard any revert In fact there was a reply, via the mailing list, from Vasil who explained the last hurdles you were facing. http://lists.osmocom.org/pipermail/openbsc/2019-May/012932.html IIUC, you seem to have a goal which is to test/run an ip.access nanoBTS, however it seems you are getting bogged down in problems which are more leading you in the direction of C development, possibly distracting from your goal? My suggestions are: 1) If at all possible, build a new VM or install a fresh OS and install the osmo stack from packages. https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds If a fresh OS install is really not possible, then clean up your existing work machine; * run make uninstall for each component you installed from source. * Even then, check for and remove and libosmo* (and maybe other lib* and/or executables from osmo source) from where ever you installed from source.? This is probably /usr/local/lib * Now install from packages. 2) Test your ip.access nanoBTS and deal with learning how to configure all the parts of the osmo stack to have it work. 3) If you want, and now with the first hand knowledge of what a running system looks like, return to the project of building from source. Be aware that there is a lot of development and things often move quickly. It does happen that you cannot clone one repo, and expect to compile it's master branch against libraries you compiled yesterday. If you are going to compile the entire stack, know that sometimes dependencies are not in obvious places. but for now, How do you feel about cleaning up your work machine and using the packages to get your hardware running?