From michau.benoit at gmail.com Wed Aug 1 19:34:27 2018 From: michau.benoit at gmail.com (benoit michau) Date: Wed, 1 Aug 2018 21:34:27 +0200 Subject: CSN.1 directory Message-ID: Dear osmocom community, This email to point to a recent development I made on CSN.1, which might be of interest to some of you. I extracted and consolidated all CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" part was quite hard...). I have also developped a CSN.1 to Python translater, and a runtime to encode / decode any CSN.1 structures. This is available here: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir and there: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1 And there are some quick explanations on how to use this in the wiki: https://github.com/ANSSI-FR/pycrate/wiki/Using-the-pycrate-csn1-translator-and-runtime Regards Benoit From laforge at gnumonks.org Wed Aug 1 19:58:40 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Aug 2018 21:58:40 +0200 Subject: CSN.1 directory In-Reply-To: References: Message-ID: <20180801195840.GK21668@nataraja> Hi Benoit, On Wed, Aug 01, 2018 at 09:34:27PM +0200, benoit michau wrote: > This email to point to a recent development I made on CSN.1, which > might be of interest to some of you. Thanks a lot for implementing this in the first place, and also for sharing information about it here. It's amazing that we finally seem to be getting good CSN.1 tools > I extracted and consolidated all > CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" > part was quite hard...). I think the biggest problems are the many syntax errors in the official CSN.1 syntax in the specs. I once tried to parse it from proprietaryt CSN.1 tools, and it was a nightmare. In fact, there are companies selling the cleaned up and fully confirming syntax for money. Somebody should submit your fixed versin to 3GPP so they can release a correct syntax at least... > I have also developped a CSN.1 to Python > translater, and a runtime to encode / decode any CSN.1 structures. Thanks. What we need to figure out now is how to make best use of this from within Osmocom. OsmoPCU is - as you know - implemented in C. Rewriting it in python is unfortunately not an option, if not alone for performance reasons :/ However, it would be great if we could benefit from your work in other ways, such as a) for unit testing our code (particularly the hand-written encoders/decoders) b) for integration testing. Unfortunately TTCN3/TITAN doesn't have any CSN.1 tools, so we cannot use a "trusted, aut-generated" encoder/decoder from our existing integration tests. However, maybe there are ways we can integrate your python CSN.1 with TTCN-3? MAybe it's possible to auto-generate ASN.1 syntax and an ASN.1(BER)-to-CSN.1 transcoder in python. Then we could use TTCN3 templates in the TITAN world, and we'd simply call a function to encode as ASN.1-BER, and then into your transcoder to create CSN.1 from that (and vice versa)? c) something like a MS-side (E)GPRS RLC/MAC implementation in python. We could then use this over "virtual/simulated" radio against OsmoPCU. d) maybe generate C / C++ encoder/decoder from your python framework, since it fully parses and understands the syntax tree... I'm not a python expert and I have not used your code yet, so I'm not sure what is realistic/possible. But for sure it would be really great to use generated parser/encoders for CSN.1 in one way or another... If you (or anyone else) have any further ideas to share, please feel free to do so! 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 246tnt at gmail.com Wed Aug 1 20:47:58 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 1 Aug 2018 22:47:58 +0200 Subject: CSN.1 directory In-Reply-To: References: Message-ID: Hi, > This is available here: > https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir > and there: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1 Very cool ! I've just tried parsing the GMR-1 CSN with it. Doesn't work out of the box because of some minor syntax issues, but minor tweaks and then it seems to load them fine. I'm hoping to generate some template code to parse system informations in wireshark with this :) Cheers, Sylvain From mykola at razormaker.com Thu Aug 2 08:18:44 2018 From: mykola at razormaker.com (Mykola Shchetinin) Date: Thu, 2 Aug 2018 11:18:44 +0300 Subject: Reusing libosmovty library and licensing Message-ID: Hello, Harald, I am reusing the libosmovty in my program. And hence my program must have the same license (AGPL-3.0), mustn't it? Also, the question regarding the copyright message in the terminal: Should I leave the "Copyright (C) 201* by Harald Welte..." string or should I add my name and company there alongside yours. Or can I just leave my name there? With best wishes, Mykola From laforge at gnumonks.org Thu Aug 2 10:26:21 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Aug 2018 12:26:21 +0200 Subject: Reusing libosmovty library and licensing In-Reply-To: References: Message-ID: <20180802102621.GQ21668@nataraja> On Thu, Aug 02, 2018 at 11:18:44AM +0300, Mykola Shchetinin wrote: > Hello, Harald, > > I am reusing the libosmovty in my program. And hence my program must > have the same license (AGPL-3.0), mustn't it? libosmovty is not AGPL-3.0, but licensed under GNU GPL v2 or later. You can use any compatible license, such as (not exhaustive) GPLv2, GPLv3, AGPLv3, LGPLv2.1, LGPLv3, MIT/X, BSD, MPL 2.0, ... see for example https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses > Also, the question regarding the copyright message in the terminal: > Should I leave the "Copyright (C) 201* by Harald Welte..." string or > should I add my name and company there alongside yours. Or can I just > leave my name there? The copyright message is part of host.app_info->copyright, i.e. provided by the application. libosmovty doesn't print a message itself, so you do not need to attribute me or any other libosmovty authors (mainly Kuninhiro Ishiguro). Good luck with libosmovty! I don't think we have many users outside of Osmocom so far. May I ask what your program is doing/implementing? 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 ron.menez at entropysolution.com Sat Aug 4 04:29:40 2018 From: ron.menez at entropysolution.com (Ron) Date: Sat, 4 Aug 2018 04:29:40 +0000 Subject: SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx Message-ID: <8FA1BD82-28A7-4A88-8047-8D095EE99839@entropysolution.com> Hi Community, We had encountered an issue regarding the SDCCH channel not being released immediately after a "Radio Link Failure" is detected in osmo-bsc and an equivalent error of "Sending Connection Failure: cause = 0x01" in osmo-bts-trx. Error in osmo-bts-trx: <0000> rsl.c:797 (bts=0,trx=0,ts=0,ss=0) Sending Connection Failure: cause = 0x01 Error in osmo-bsc: <0003> abis_rsl.c:1372 (bts=0,trx=0,ts=0,ss=0) CONNECTION FAIL in state ACTIVE CAUSE=0x01(Radio Link Failure) With this issue, the SDCCH channel will then be exhausted and no other subscriber can attach and do any services (call and SMS). As per advised by Neels, we tried to used the neels/inter_bsc_ho branch for osmo-bsc to test if this issue is fixed. We are happy to inform the community that the SDCCH channel issue we had is not experienced from the neels/inter_bsc_ho branch but a different bug was experienced. The bug we seen in this branch is that, even we have a 2 TRX configuration in our setup, the osmo-bsc only uses the first TRX configuration. Kindly see logs below for your reference. OSMO-BSC: # /usr/local/osmo-bsc/src/osmo-bsc/osmo-bsc -c /root/demo/osmo-bsc.cfg logging level cc (everything|debug|info|notice|error|fatal) logging level mgcp (everything|debug|info|notice|error|fatal) <001f> osmo_ss7.c:1270 0: ASP Restart for server not implemented yet! % Ignoring deprecated logging level everything <0013> telnet_interface.c:104 telnet at 127.0.0.1 4242 <0015> input/ipaccess.c:846 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <001a> control_if.c:887 CTRL at 127.0.0.1 4249 <0007> osmo_bsc_sigtran.c:466 Initializing SCCP connection to MSC msc-0 <0007> osmo_bsc_sigtran.c:476 CS7 Instance identifier, A-Interface: 0 <0020> sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.23.3 <0020> sccp_user.c:421 msc-0: Using AS instance MSC_Test <0020> sccp_user.c:426 msc-0: Creating default route <0020> sccp_user.c:481 msc-0: Using ASP instance Huawei_MSC_Test <0020> sccp_user.c:484 msc-0: Creating SCCP instance <0007> osmo_bsc_sigtran.c:519 (msc-0) A-interface: local (BSC) SCCP address: RI=SSN_PC,PC=0.23.3,SSN=BSSAP <0007> osmo_bsc_sigtran.c:521 (msc-0) A-interface: remote (MSC) SCCP address: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_DOWN}: Event AS-TRANSFER.req not permitted <0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_DOWN}: Event AS-TRANSFER.req not permitted <0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_INACTIVE}: Event AS-TRANSFER.req not permitted <0022> m3ua.c:634 asp-Huawei_MSC_Test: Received NOTIFY Type State Change:AS Inactive () <001f> xua_default_lm_fsm.c:353 xua_default_lm(Huawei_MSC_Test)[0xce6de0]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm <0022> m3ua.c:634 asp-Huawei_MSC_Test: Received NOTIFY Type State Change:AS Active () <0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:74 A-RESET(msc-0)[0xce7480]{DISC}: SIGTRAN connection succeded. <0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3002 <0004> abis_nm.c:499 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:499 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:499 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:499 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:499 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:499 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:499 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.35-6575f0 <0004> abis_nm.c:438 BTS0 reported variant: omso-bts-trx <0004> abis_nm.c:460 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0004> abis_nm.c:460 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0004> abis_nm.c:2827 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0004> abis_nm.c:2827 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3003 <0003> osmo_bsc_main.c:282 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 111 using MCC-MNC 101-01 LAC=20259 CID=6966 BSIC=63 <0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3003 <0003> osmo_bsc_main.c:282 bootstrapping RSL for BTS/TRX (0/1) on ARFCN 13 using MCC-MNC 101-01 LAC=20259 CID=6966 BSIC=63 <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-0-CCCH_SDCCH4)[0xce0220]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-1-SDCCH8)[0xce0650]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-2-TCH_F)[0xce0c00]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-3-TCH_F)[0xce11b0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-4-TCH_F)[0xce1760]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-5-TCH_F)[0xce1d10]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-6-TCH_F)[0xce22c0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-7-TCH_F)[0xce2870]{UNUSED}: Event TS_EV_OML_READY not permitted  <0003> abis_rsl.c:1364 (bts=0) CHAN RQD: reason: other (ra=0xfe, neci=0x00, chreq_reason=0x04) <0010> lchan_fsm.c:76 lchan(0-0-0-CCCH_SDCCH4-0)[0xce7f70]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout <0010> lchan_fsm.c:95 lchan(0-0-0-CCCH_SDCCH4-0)[0xce7f70]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) Tx Immediate Assignment Reject (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout) <0003> abis_rsl.c:1364 (bts=0) CHAN RQD: reason: Location updating (ra=0x09, neci=0x00, chreq_reason=0x03) <0007> fsm.c:299 SUBSCR_CONN[0xce7910]{INIT}: Allocated <000f> fsm.c:299 LCLS[0xce7a40]{NO_LCLS}: Allocated <000f> fsm.c:329 LCLS[0xce7a40]{NO_LCLS}: is child of SUBSCR_CONN[0xce7910] OSMO-BSC CLI: OsmoBSC# show network BSC is on MCC-MNC 101-01 and has 1 BTS Encryption: A5/0 NECI (TCH/H): 0 Use TCH for Paging any: 0 Handover: Off Current Channel Load: CCCH+SDCCH4: 25% (1/4) TCH/F: 0% (0/6) SDCCH8: 0% (0/8) Last RF Command: Last RF Lock Command: OsmoBSC# show run Current configuration: ! ! bts 0 type sysmobts band GSM900 cell_identity 6966 location_area_code 20259 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 no access-control-class-ramping access-control-class-ramping-step-interval dynamic access-control-class-ramping-step-size 1 early-classmark-sending forbidden early-classmark-sending-3g allowed ip.access unit_id 1800 0 oml ip.access stream_id 255 line 0 neighbor-list mode manual-si5 neighbor-list add arfcn 100 neighbor-list add arfcn 200 si5 neighbor-list add arfcn 10 si5 neighbor-list add arfcn 20 codec-support fr hr efr amr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 111 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config SDCCH8+CBCH hopping enabled 0 trx 1 rf_locked 0 arfcn 13 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config TCH/F hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 OSMO-BTS-TRX CLI: OsmoBTS# show run Current configuration: ! ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive phy 0 osmotrx ip local 127.0.0.1 osmotrx ip remote 127.0.0.1 no osmotrx ms-power-loop osmotrx timing-advance-loop osmotrx base-port local 5800 osmotrx base-port remote 5700 osmotrx fn-advance 5 osmotrx rts-advance 5 instance 0 osmotrx rx-gain 0 osmotrx tx-attenuation 7 instance 1 osmotrx rx-gain 0 osmotrx tx-attenuation 7 bts 0 band GSM900 ipa unit-id 1800 0 oml remote-ip 5.40.0.1 rtp jitter-buffer 100 rtp port-range 16384 17407 paging queue-size 200 paging lifetime 0 uplink-power-target -75 gsmtap-sapi ccch gsmtap-sapi pdtch min-qual-rach 50 min-qual-norm -5 max-ber10k-rach 1707 trx 0 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 0 trx 1 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 1 end OSMO-TRX CLI: OsmoTRX# show run Current configuration: ! ! stats interval 5 ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 multi-arfcn disable swap-channels disable egprs disable chan 0 chan 1 end Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Mon Aug 6 13:51:27 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 6 Aug 2018 15:51:27 +0200 Subject: The magic behaviour of 'logging level all LEVEL' In-Reply-To: <20180730184305.GN30570@nataraja> References: <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de> <20180730184305.GN30570@nataraja> Message-ID: On 30/07/18 20:43, Harald Welte wrote: > On Wed, Jul 25, 2018 at 11:16:46AM +0200, Pau Espin Pedrol wrote: >> So, after your comments and thinking about it, here's my proposal: >> 1- Take my current patchset >> 2- Modification: "logging level all " sets the loglevel foreach >> category, not the target loglevel (aka the default loglevel). > > I think the "target loglevel" should/could be abandoned completely. I think that feature is useful and it's there already anyway, it just doesn't work correctly in current merged code base. > >> 3- Modification: "logging level unset " is renamed to "logging >> level default " > > IMHO it should be "logging level SUBSYSTEM unset" or "logging level > SUBSYSTEM default" which would then revert back to the compiled-in level > for that particular subsystem? > > I understand you can un-set or fall-back to the compiled-in default > of a given sub-system. But how can you un-set a given *level* ?!? > As explained in the thread, semantically it doesn't make much sense and that's why I was explaining I was modifying my patchset to remove that, and use "logging level default " instead, which better describes the action (setting the default log level to , meaning unset categories/subystems will use that log level). These modifications are already presnet in th new version of the patchset I submited 1-2 weeks ago in gerrit. -- - 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 Mon Aug 6 14:02:42 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 6 Aug 2018 16:02:42 +0200 Subject: The magic behaviour of 'logging level all LEVEL' In-Reply-To: References: <20180730183919.GM30570@nataraja> Message-ID: <2313bcb8-eea9-211b-6400-d4e0d48e6d75@sysmocom.de> Hi, I think Vadim did a pretty good explanation and I think we agree on most points here. Please correct me if I'm wrong. As far as I understand, my patchset implements the points Vadim suggested at the end of his last e-mail. And answering gerrit's comment from Harald: "Do we really have no more pressing needs than re-desinging/defining how the log configuration works?" I want to state again that my patchset is aiming at fixing something broken without trying to redefine or completely redesign the logging system, because indeed I didn't want to spend much time in this, only a few hours required to fix the issue and make it usable, because I'm always losing time and not trusting the logging system due to this broken behavior. I'm the first one not willing to invest lots of hours into this, just get something good enough that works fine. -- - 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 Thu Aug 16 18:48:41 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Aug 2018 20:48:41 +0200 Subject: OsmoCon 2018 draft schedule announced Message-ID: <20180816184841.GE25650@nataraja> Dear Osmocom community, the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced, see http://osmocom.org/news/99 for the announcment and https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule. At OsmoCon, we are not targetting developers, but more the wider community and Osmocom users. It would be great to meet many of you and hear more about your relation to Osmocom. Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/, and until August 31st the early bird discount still applies. For those with a community / "just for fun" background and no employer that would cover the ticket, we have a number of subsidized community discount vouchers available. See the OsmoCon 2018 wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 for more information. Looking forward to meeting as many of you as possible in roughly two months from now, Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From n.kremeris at live.com Fri Aug 17 09:47:01 2018 From: n.kremeris at live.com (Norbertas Kremeris) Date: Fri, 17 Aug 2018 09:47:01 +0000 Subject: Move osmo-bsc (with osmo-bts-trx and osmo-trx-lms) to another device Message-ID: Dear all, I have a running and working osmocom network stack (2g only, no GPRS/DATA) with osmo-trx-lms using a LimeSDR mini (osmo-trx-lms, osmo-bts-trx, osmo-bsc, osmo-hlr, osmo-stp, osmo-msc, a and single osmo-mgw process) , and I would like to have osmo-bts-trx, osmo-trx-lms and osmo-bsc moved to another computer. I would like to have an AoIP connection between the pc1 and pc2. As far as i understand, osmo-bsc and osmo-mgw communicate over AoIP (as per the manual here http://ftp.osmocom.org/docs/latest/osmomgw-usermanual.pdf). My knowledge about the interconnection of all the osmocom core components is rather limited, and what at first seemed like a trivial task (to move osmo-bsc to the other computer and changing the msc mgw remote ip) has turned into a 2 day ordeal with me trying to wrap my head around the functionality of all the core components without any success. I have modified my stack to work with a single osmo-mgw process (but the moving of osmo-bsc does not work with osmo-mgw-for-bsc and osmo-mgw-for-msc either). Attached are all the configuration files used. The IP of the osmo-bts-trx, osmo-trx-lms and osmo-bsc running pc (PC1) is 192.168.1.249, the ip of the pc (PC2) that is running the core network components is 192.168.1.219. All my osmocom components are built from source (latest tags). Running the osmoBSC on the PC1 connects to osmo-bts successfully and does result in a network being shown on the phone, but osmo-bsc constantly throws errors: ??? ??? <0007> a_reset.c:106 A-RESET(msc-0)[0x1ee0530]{DISC}: (re)sending BSSMAP RESET message... ??? ??? <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP ??? ??? <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1edfd30]{AS_DOWN}: Event AS-TRANSFER.req not permitted Any pointers would be very appreciated. Sincerely, Norbertas -------------- next part -------------- A non-text attachment was scrubbed... Name: osmosplit-aoip.tar.gz Type: application/gzip Size: 1659 bytes Desc: osmosplit-aoip.tar.gz URL: From laforge at gnumonks.org Sat Aug 18 15:51:50 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Aug 2018 17:51:50 +0200 Subject: SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx In-Reply-To: <8FA1BD82-28A7-4A88-8047-8D095EE99839@entropysolution.com> References: <8FA1BD82-28A7-4A88-8047-8D095EE99839@entropysolution.com> Message-ID: <20180818155150.GD31341@nataraja> Hi Ron, sorry for the late response. First of all, thanks for your two bug / experience reports. One very important bit was missing: Which exact version of the relevant osmocom programs were you using when observing the two issues, respectively? There's a lot of development going on, and without pin-pointing the exact versions it's hard to understand whether or not the related problem might still apply to current 'master', or whether it is likely a regression, etc. You can use "show version" on the VTY or call the respective program with "--version" command-line argument to extract the version information. If you have the time, it would also be very useful if you could file those two bugs as two separate issues in the respective issue tracker of the respective program (OsmoBSC in this case) on osmocom.org. Thanks in advance! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Sat Aug 18 16:29:13 2018 From: keith at rhizomatica.org (Keith) Date: Sat, 18 Aug 2018 18:29:13 +0200 Subject: GGSN p-t-p address? Message-ID: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> Hi all, idle curiosity here more than anything..... I noticed that if I bring up a pppd link with a GSM modem to an osmo stack GPRS network, I get assigned an IP address from the pool as configured on osmo-ggsn; ? ip prefix dynamic 10.20.0.0/16 ? ip dns 0 192.168.11.2 ? ip dns 1 192.168.11.2 ? ip ifconfig 10.20.20.253/16 but the p-t-p address is 192.168.100.101; Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: local? IP address 10.20.0.8 Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: remote IP address 192.168.100.101 Here's the resulting ifconfig: 3g-gwan?? Link encap:Point-to-Point Protocol? ????????? inet addr:10.20.0.8? P-t-P:192.168.100.101? Mask:255.255.255.255 ????????? UP POINTOPOINT RUNNING NOARP MULTICAST? MTU:1500? Metric:1 ????????? RX packets:3 errors:0 dropped:0 overruns:0 frame:0 ????????? TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 ????????? collisions:0 txqueuelen:3 ????????? RX bytes:54 (54.0 B)? TX bytes:76 (76.0 B) This is not really a problem but I thought it was weird so I looked for this IP (192.168.100.101) in the source code but it was nowhere to be found. I'm a bit rusty on ppp, but should it not be the address configured in the ggsn's ip config? I thought maybe it was coming from the local pppd stack, so I booted an old windows 7 machine and connnected the GSM modem, and it got the same p-t-p address of 192.168.100.101 thnx/ K. From laforge at gnumonks.org Sat Aug 18 19:37:34 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Aug 2018 21:37:34 +0200 Subject: GGSN p-t-p address? In-Reply-To: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> Message-ID: <20180818193734.GF31341@nataraja> Hi Keith, it would be useful if you could provide a PCAP file of the Gb interface and the GTP traffic for this, so we can look at the actual ip address allocation as it happens in the network. Please note that the PPP you speak is only between the modem and the ppp daemon, and there is no PPP over the radio interface. The IP address allocation happens via the PDP context activation on the signaling plane. 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 keith at rhizomatica.org Sun Aug 19 14:28:32 2018 From: keith at rhizomatica.org (Keith) Date: Sun, 19 Aug 2018 16:28:32 +0200 Subject: GGSN p-t-p address? In-Reply-To: <20180818193734.GF31341@nataraja> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> Message-ID: <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> On 18.08.2018 21:37, Harald Welte wrote: > Hi Keith, Hi Harald, thanks for taking the time to reply. > > it would be useful if you could provide a PCAP file of the Gb interface and > the GTP traffic for this, so we can look at the actual ip address allocation > as it happens in the network. Probably not worth spending time on this to open traces etc.. I looked at the trace and see what would be expected in the pdp context activation. > > Please note that the PPP you speak is only between the modem and the ppp daemon, > and there is no PPP over the radio interface. The IP address allocation happens > via the PDP context activation on the signaling plane. Yep, I see this, in the PDP Context Activation Ack, we have a Packet Data Protocol Address with the IPv4 Address then there's an PPP IP Control Protocol Configuration ACK with the Primary and Secondary DNS. No mention of 192.168.100.101. Maybe this is just what the ppp code in the pppd or in the kernel uses for the dstaddr of the p-t-p link if it is not getting this info elsewhere? I found this page which shows the same thing https://ubuntuforums.org/showthread.php?t=670714 k/ From laforge at gnumonks.org Sun Aug 19 20:15:13 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 19 Aug 2018 22:15:13 +0200 Subject: GGSN p-t-p address? In-Reply-To: <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> Message-ID: <20180819201513.GC31355@nataraja> Hi Keith, On Sun, Aug 19, 2018 at 04:28:32PM +0200, Keith wrote: > > Please note that the PPP you speak is only between the modem and the ppp daemon, > > and there is no PPP over the radio interface. The IP address allocation happens > > via the PDP context activation on the signaling plane. > Yep, I see this, in the PDP Context Activation Ack, we have a Packet > Data Protocol Address with the IPv4 Address > then there's an PPP IP Control Protocol Configuration ACK with the > Primary and Secondary DNS. > > No mention of 192.168.100.101. > > Maybe this is just what the ppp code in the pppd or in the kernel uses > for the dstaddr of the p-t-p link if it is not getting this info elsewhere? No, I think it's what some component in your phone is inventing and returning to the ppp daemon on your Linux machine :) Many [modern] modems are doing some internal NAT so that the IP addresses on the host PC (pppd) side don't correspond to those on the modem-sgsn side. -- - 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 Mon Aug 20 00:53:10 2018 From: ron.menez at entropysolution.com (Ron) Date: Mon, 20 Aug 2018 00:53:10 +0000 Subject: SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx In-Reply-To: <20180818155150.GD31341@nataraja> References: <8FA1BD82-28A7-4A88-8047-8D095EE99839@entropysolution.com> <20180818155150.GD31341@nataraja> Message-ID: Thank you for the respond Harald. Below are the versions of OSMO-BSC, OSMO-BTS-TRX, OSMO-TRX, and OSMO-MSC. OsmoBSC# show version OsmoBSC 1.2.1.91-3ff7 (OsmoBSC). Copyright (C) 2008-2018 Harald Welte, Holger Freyther Contributions by Daniel Willmann, Jan L?bbe, Stefan Schmidt Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoBTS# show version OsmoBTS 0.8.1.35-6575f0 (OsmoBTS). Copyright (C) 2010, 2011 by Harald Welte, Andreas Eversberg and On-Waves License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoTRX# show version OsmoTRX 0.4.0 (OsmoTRX). Copyright (C) 2007-2014 Free Software Foundation, Inc. Copyright (C) 2013 Thomas Tsou > Copyright (C) 2015 Ettus Research LLC Copyright (C) 2017-2018 by sysmocom s.f.m.c. GmbH > License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoMSC# show version OsmoMSC 1.2.0.20-2798 (OsmoMSC). OsmoMSC - Osmocom Circuit-Switched Core Network implementation Copyright (C) 2016 by sysmocom s.f.m.c. GmbH > Based on OsmoNITB: (C) 2008-2010 by Harald Welte > (C) 2009-2012 by Holger Hans Peter Freyther > Contributions by Daniel Willmann, Jan L?bbe, Stefan Schmidt Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Noted on the filing of 2 separate cases Harald. We?ll open 2 separate case for this. We are using UBUNTU 16.04 as OS. Best Regard, Ron Menez ron.menez at entropysolution.com On Aug 18, 2018, at 11:51 PM, Harald Welte > wrote: Hi Ron, sorry for the late response. First of all, thanks for your two bug / experience reports. One very important bit was missing: Which exact version of the relevant osmocom programs were you using when observing the two issues, respectively? There's a lot of development going on, and without pin-pointing the exact versions it's hard to understand whether or not the related problem might still apply to current 'master', or whether it is likely a regression, etc. You can use "show version" on the VTY or call the respective program with "--version" command-line argument to extract the version information. If you have the time, it would also be very useful if you could file those two bugs as two separate issues in the respective issue tracker of the respective program (OsmoBSC in this case) on osmocom.org. Thanks in advance! -- - 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 ron.menez at entropysolution.com Mon Aug 20 01:14:32 2018 From: ron.menez at entropysolution.com (Ron) Date: Mon, 20 Aug 2018 01:14:32 +0000 Subject: SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx In-Reply-To: References: <8FA1BD82-28A7-4A88-8047-8D095EE99839@entropysolution.com> <20180818155150.GD31341@nataraja> Message-ID: Hi Harald, Below are the URLs of the following bugs opened in the issue tracker: neels/inter_bsc_ho branch for osmo-bsc 2TRX configured but OSMO-BSC only uses the first TRX configuration: https://osmocom.org/issues/3475 SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx: https://osmocom.org/issues/3474 Best Regard, Ron Menez ron.menez at entropysolution.com On Aug 20, 2018, at 8:53 AM, Ron > wrote: Thank you for the respond Harald. Below are the versions of OSMO-BSC, OSMO-BTS-TRX, OSMO-TRX, and OSMO-MSC. OsmoBSC# show version OsmoBSC 1.2.1.91-3ff7 (OsmoBSC). Copyright (C) 2008-2018 Harald Welte, Holger Freyther Contributions by Daniel Willmann, Jan L?bbe, Stefan Schmidt Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoBTS# show version OsmoBTS 0.8.1.35-6575f0 (OsmoBTS). Copyright (C) 2010, 2011 by Harald Welte, Andreas Eversberg and On-Waves License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoTRX# show version OsmoTRX 0.4.0 (OsmoTRX). Copyright (C) 2007-2014 Free Software Foundation, Inc. Copyright (C) 2013 Thomas Tsou > Copyright (C) 2015 Ettus Research LLC Copyright (C) 2017-2018 by sysmocom s.f.m.c. GmbH > License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =============================================== OsmoMSC# show version OsmoMSC 1.2.0.20-2798 (OsmoMSC). OsmoMSC - Osmocom Circuit-Switched Core Network implementation Copyright (C) 2016 by sysmocom s.f.m.c. GmbH > Based on OsmoNITB: (C) 2008-2010 by Harald Welte > (C) 2009-2012 by Holger Hans Peter Freyther > Contributions by Daniel Willmann, Jan L?bbe, Stefan Schmidt Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr License AGPLv3+: GNU AGPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Noted on the filing of 2 separate cases Harald. We?ll open 2 separate case for this. We are using UBUNTU 16.04 as OS. Best Regard, Ron Menez ron.menez at entropysolution.com On Aug 18, 2018, at 11:51 PM, Harald Welte > wrote: Hi Ron, sorry for the late response. First of all, thanks for your two bug / experience reports. One very important bit was missing: Which exact version of the relevant osmocom programs were you using when observing the two issues, respectively? There's a lot of development going on, and without pin-pointing the exact versions it's hard to understand whether or not the related problem might still apply to current 'master', or whether it is likely a regression, etc. You can use "show version" on the VTY or call the respective program with "--version" command-line argument to extract the version information. If you have the time, it would also be very useful if you could file those two bugs as two separate issues in the respective issue tracker of the respective program (OsmoBSC in this case) on osmocom.org. Thanks in advance! -- - 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 mychaela.falconia at gmail.com Mon Aug 20 03:41:31 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 19 Aug 2018 19:41:31 -0800 Subject: GGSN p-t-p address? In-Reply-To: <20180819201513.GC31355@nataraja> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> Message-ID: Keith wrote: > No mention of 192.168.100.101. > > Maybe this is just what the ppp code in the pppd or in the kernel uses > for the dstaddr of the p-t-p link if it is not getting this info elsewhere? Harald Welte replied: > No, I think it's what some component in your phone is inventing and returning > to the ppp daemon on your Linux machine :) My first thought in reaction to Keith's analysis was what Harald said, so I decided to test it experimentally. I don't have my own Osmocom network or any BTS of my own to test with, but I do have active service on several SIMs with the local GSM&UMTS commercial network operator in my neck of the woods (T-Mobile USA), and the available services include mobile Internet in addition to calls and SMS. My thought was to make a pppd connection from the same host (my Slackware laptop) to the same T-Mobile network through two different GSM+GPRS(+UMTS) modem implementations, and see if the P-t-P address reported in ifconfig changes or not. The first tested implementation is Huawei E303, a 3G data modem in the USB stick form factor; it is Qualcomm-based to the best of my knowledge. Here is the ifconfig output: ppp0 Link encap:Point-to-Point Protocol inet addr:21.227.117.124 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:33967 errors:0 dropped:0 overruns:0 frame:0 TX packets:29454 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:28077904 (26.7 Mb) TX bytes:2831375 (2.7 Mb) The other tested implementation is my own FreeCalypso, or more specifically an FCDEV3B modem board running FreeCalypso Magnetite hybrid firmware, build date 2018-07-30T20:24:34Z. It is also using a different SIM, although on the same billing account with T-Mobile and with the same service configuration - I am too lazy to move the same SIM back and forth between the USB stick modem and my own board. Here is the ifconfig output: ppp0 Link encap:Point-to-Point Protocol inet addr:22.255.27.2 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:285 errors:0 dropped:0 overruns:0 frame:0 TX packets:341 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:79139 (77.2 Kb) TX bytes:35368 (34.5 Kb) The dynamically assigned IP address is different because I had to shut down pppd with one modem and start a new session with the other modem, but notice that the P-t-P address is the same fixed 10.64.64.64. One very special feature of my FreeCalypso GSM+GPRS modem implementation is that it is compiled from source code that is freely published for anyone to study or tweak as they like, so if anyone is interested, you are more than welcome to study the PPP-to-GPRS translation code in this modem implementation and see what it does. Unfortunately, though, I don't have any spare cycles at the present time to do such a code study myself - I am not the original author of this code, I inherited it from TI, and while I strive to maintain it, I will only be able to devote significant time to this task if someone buys my modem hardware (the firmware is useless without the hardware) in a commercially significant quantity, which hasn't happened yet. In the absence of commercial customers for FreeCalypso modems, I can only spend very little time on firmware maintenance, just enough to verify that it works on a basic level, which it does - I am sending this post through the mobile Internet GPRS connection going through my FreeCalypso modem. But I consider it rather unlikely that two independent and very different implementation of PPP-to-GPRS translation (or PPP-to-UMTS in the case of the 3G modem) have the same 10.64.64.64 IP address hard- coded in them, so in this case the P-t-P address is probably coming from T-Mobile's GGSN and not from the modem. > Many [modern] modems are doing some internal NAT so that the IP addresses on > the host PC (pppd) side don't correspond to those on the modem-sgsn side. While I don't have the time to study it and see for myself (see above), I highly doubt that the implementation which we (FreeCalypso) inherited from TI does such NAT. M~ From nhofmeyr at sysmocom.de Mon Aug 20 09:23:39 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Aug 2018 11:23:39 +0200 Subject: Move osmo-bsc (with osmo-bts-trx and osmo-trx-lms) to another device In-Reply-To: References: Message-ID: <20180820092339.GA3114@my.box> On Fri, Aug 17, 2018 at 09:47:01AM +0000, Norbertas Kremeris wrote: > Dear all, > > I have a running and working osmocom network stack (2g only, no > GPRS/DATA) with osmo-trx-lms using a LimeSDR mini (osmo-trx-lms, > osmo-bts-trx, osmo-bsc, osmo-hlr, osmo-stp, osmo-msc, a and single > osmo-mgw process) , and I would like to have osmo-bts-trx, osmo-trx-lms > and osmo-bsc moved to another computer. I would like to have an AoIP > connection between the pc1 and pc2. As far as i understand, osmo-bsc and > osmo-mgw communicate over AoIP (as per the manual here > http://ftp.osmocom.org/docs/latest/osmomgw-usermanual.pdf). osmo-mgw, the media gateway, has no AoIP connection. It receives MGCP from BSC and/or MSC, and directs RTP between BTS and remote peers. AoIP connects osmo-bsc to osmo-MSC. In detail, AoIP is an SCCP/M3UA connection, which is routed via an osmo-stp. Take a look at http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box#Topology > My knowledge about the interconnection of all the osmocom core > components is rather limited, and what at first seemed like a trivial > task (to move osmo-bsc to the other computer and changing the msc mgw > remote ip) has turned into a 2 day ordeal with me trying to wrap my head > around the functionality of all the core components without any success. Sorry to hear that, but it is rather complex, and has to be since we are trying to be as 3GPP compliant as possible, to remain interoperable with 3rd party components. My "personal pitfalls" are choosing the right IP addresses for the programs to listen on, so that they are reachable by the intended peers; and configuring the SCCP links between BSC via STP to MSC, i.e. the 'cs7' instance config. Once these are figured out, things shouldn't be too hard to get working, especially since your network already worked before. > I have modified my stack to work with a single osmo-mgw process (but the > moving of osmo-bsc does not work with osmo-mgw-for-bsc and > osmo-mgw-for-msc either). Attached are all the configuration files used. > The IP of the osmo-bts-trx, osmo-trx-lms and osmo-bsc running pc (PC1) > is 192.168.1.249, the ip of the pc (PC2) that is running the core > network components is 192.168.1.219. All my osmocom components are built > from source (latest tags). > > Running the osmoBSC on the PC1 connects to osmo-bts successfully and > does result in a network being shown on the phone, but osmo-bsc > constantly throws errors: > > ??? ??? <0007> a_reset.c:106 A-RESET(msc-0)[0x1ee0530]{DISC}: > (re)sending BSSMAP RESET message... > ??? ??? <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: > RI=SSN_PC,PC=0.23.1,SSN=BSSAP > ??? ??? <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1edfd30]{AS_DOWN}: > Event AS-TRANSFER.req not permitted > > Any pointers would be very appreciated. Apparently the 'cs7' config is wrong. Looking at your PC1/osmo-bsc.cfg, you don't have a 'cs7' config at all. The AoIP defaults only work when all components run on the same machine. The 'msc' config at the bottom of the file is related to the legacy osmo-bsc SCCPlite connection and does not affect the AoIP connection. So, you need to tell the SS7 stack (a.k.a. 'cs7 instance') at least the STP's IP address. Trying to point you at it, I notice that the osmo-bsc manual lacks this information :/ (opened https://osmocom.org/issues/3476 ) The OsmoMSC manual has this information, and it is mostly identical between osmo-bsc and osmo-msc; see http://ftp.osmocom.org/docs/latest/osmomsc-usermanual.pdf section 'Running OsmoMSC' / 'Configure primary links' / 'Configure SCCP/M3UA to accept A and IuCS links' (Easiest is to use the default point-codes; otherwise osmo-bsc.cfg also needs an address book entry under 'cs7', and pass this name to 'msc 0' / 'msc-addr'. point codes are logged on startup). You can also view the default cs7 instance config: start up your current osmo-bsc, connect via telnet vty: telnet localhost 4242 and do OsmoBSC> enable OsmoBSC# show running-config then look for the 'cs7 instance' section. I think osmo-stp by default listens on all interfaces, otherwise you also need to tell the osmo-stp.cfg to listen on a public IP address. cs7 instance 0 listen m3ua 2905 local-ip 123.45.67.8 Hope that helps! I think this information needs a wiki page... (opened https://osmocom.org/issues/3477 ) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Aug 20 10:15:05 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Aug 2018 12:15:05 +0200 Subject: CSN.1 directory In-Reply-To: <20180801195840.GK21668@nataraja> References: <20180801195840.GK21668@nataraja> Message-ID: <20180820101505.GB3114@my.box> On Wed, Aug 01, 2018 at 09:58:40PM +0200, Harald Welte wrote: > OsmoPCU is - as you know - implemented in C. (C++ actually) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From michau.benoit at gmail.com Tue Aug 21 19:27:39 2018 From: michau.benoit at gmail.com (benoit michau) Date: Tue, 21 Aug 2018 21:27:39 +0200 Subject: CSN.1 directory In-Reply-To: <20180801195840.GK21668@nataraja> References: <20180801195840.GK21668@nataraja> Message-ID: Hi Harald, vacation time, hence slow response. Thank you for your feedback. Here are few answers about your several ideas : b) converting CSN.1 to ASN.1 and back is not straightforward ; there are some structures in CSN.1 (such as recursive construct with a "continuation" bit) which may be hard to translate to ASN.1. I am not confident this would work well. c) this would be great. I was wondering if there exists a real-world GPRS L1 and transceiver that we could use, in addition to the direct / simulated connection to the OsmoPCU ? I am not aware of any unfortunately. d) I am not comfortable to generate a full C or C++ code. On the other side, it would be quite easy to generate headers with proper structs for each object. This would have to link with an appropriate C / C++ encoding runtime. Regards Benoit 2018-08-01 21:58 GMT+02:00 Harald Welte : > Hi Benoit, > > On Wed, Aug 01, 2018 at 09:34:27PM +0200, benoit michau wrote: > >> This email to point to a recent development I made on CSN.1, which >> might be of interest to some of you. > > Thanks a lot for implementing this in the first place, and also for > sharing information about it here. > > It's amazing that we finally seem to be getting good CSN.1 tools > > >> I extracted and consolidated all >> CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" >> part was quite hard...). > > I think the biggest problems are the many syntax errors in the official CSN.1 > syntax in the specs. I once tried to parse it from proprietaryt CSN.1 tools, > and it was a nightmare. In fact, there are companies selling the cleaned up > and fully confirming syntax for money. > > Somebody should submit your fixed versin to 3GPP so they can release a correct syntax at least... > >> I have also developped a CSN.1 to Python >> translater, and a runtime to encode / decode any CSN.1 structures. > > Thanks. What we need to figure out now is how to make best use of this from within > Osmocom. OsmoPCU is - as you know - implemented in C. Rewriting it in python is > unfortunately not an option, if not alone for performance reasons :/ > > However, it would be great if we could benefit from your work in other ways, such as > > a) for unit testing our code (particularly the hand-written encoders/decoders) > > b) for integration testing. Unfortunately TTCN3/TITAN doesn't have any CSN.1 tools, > so we cannot use a "trusted, aut-generated" encoder/decoder from our existing > integration tests. However, maybe there are ways we can integrate your python > CSN.1 with TTCN-3? MAybe it's possible to auto-generate ASN.1 syntax and an ASN.1(BER)-to-CSN.1 > transcoder in python. Then we could use TTCN3 templates in the TITAN world, and > we'd simply call a function to encode as ASN.1-BER, and then into your transcoder to create > CSN.1 from that (and vice versa)? > > c) something like a MS-side (E)GPRS RLC/MAC implementation in python. We could then use this > over "virtual/simulated" radio against OsmoPCU. > > d) maybe generate C / C++ encoder/decoder from your python framework, since it fully > parses and understands the syntax tree... > > I'm not a python expert and I have not used your code yet, so I'm not sure what is > realistic/possible. But for sure it would be really great to use generated parser/encoders > for CSN.1 in one way or another... > > If you (or anyone else) have any further ideas to share, please feel free to do so! > > 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 michau.benoit at gmail.com Tue Aug 21 19:48:58 2018 From: michau.benoit at gmail.com (benoit michau) Date: Tue, 21 Aug 2018 21:48:58 +0200 Subject: CSN.1 directory In-Reply-To: References: Message-ID: Hello, I did not know GMR-1 was so close from GSM / GPRS at the RRC / NAS layer. I found those GMR-1 specs which seem the most recent, with CSN.1 structures definition: - for RRC: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760413/03.05.01_60/ts_1013760413v030501p.pdf - for NAS: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/03.04.01_60/ts_1013760408v030401p.pdf I may be able to process them and create corresponding directories in pycrate. Regards, Benoit 2018-08-01 22:47 GMT+02:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > >> This is available here: >> https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir >> and there: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1 > > Very cool ! > > I've just tried parsing the GMR-1 CSN with it. Doesn't work out of the > box because of some minor syntax issues, but minor tweaks and then it > seems to load them fine. > > I'm hoping to generate some template code to parse system informations > in wireshark with this :) > > Cheers, > > Sylvain From keith at rhizomatica.org Wed Aug 22 10:07:39 2018 From: keith at rhizomatica.org (Keith) Date: Wed, 22 Aug 2018 12:07:39 +0200 Subject: GGSN p-t-p address? In-Reply-To: References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> Message-ID: <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> On 20.08.2018 05:41, Mychaela Falconia wrote: > Keith wrote: > >> No mention of 192.168.100.101. >> >> Maybe this is just what the ppp code in the pppd or in the kernel uses >> for the dstaddr of the p-t-p link if it is not getting this info elsewhere? > Harald Welte replied: > >> No, I think it's what some component in your phone is inventing and returning >> to the ppp daemon on your Linux machine :) > My first thought in reaction to Keith's analysis was what Harald said, > so I decided to test it experimentally. I don't have my own Osmocom > network or any BTS of my own to test with, but I do have active service > on several SIMs with the local GSM&UMTS commercial network operator in > my neck of the woods So, I decided to carry out a similar simple test, by putting my local operator SIM into the modem. I still got the 192.168.100.101 p-t-p address. Given that this happens on OpenWRT and Windows, although I didn't bother test windows with the local operator, I would have to assume that in my case, it's coming from the modem, as Harald suggests. An interesting side point, I noticed on connecting to the commercial operator that the modem (actually the motozrkr k3 in USB comms mode, which I had locked in 2G mode) does have a different icon for EDGE and GPRS. In all my use of it on my osmocom network, I have never seen the EDGE icon, though all my androids show "E" when I have gprs mode egprs - (they also take a while to go back to "G" after setting gprs mode gprs and restarting everything) Besides, I've never seen any performance difference between gprs and egprs modes on my osmocom network, but now this is off topic, but maybe something is not quite right with our SI or maybe the GPRS negociations? > so if anyone is interested, you > are more than welcome to study the PPP-to-GPRS translation code in > this modem implementation and see what it does. Can we see diagnostic output on gprs negociation on the freecalypso side? Does it give us an "insight" into what this TI baseband is doing? Harald, would this help at all in developing the osmo-pcu, sgsn, ggsn et al? Thanks! k/ From mardnh at gmx.de Wed Aug 22 16:55:31 2018 From: mardnh at gmx.de (Martin Hauke) Date: Wed, 22 Aug 2018 18:55:31 +0200 Subject: *** GMX Spamverdacht *** Re: GGSN p-t-p address? In-Reply-To: References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> Message-ID: <11a9c6eb-ab86-2055-6abc-4b700c066048@gmx.de> Mychaela Falconia wrote: > The first tested implementation is Huawei E303, a 3G data modem in the > USB stick form factor; it is Qualcomm-based to the best of my knowledge. > Here is the ifconfig output: > > ppp0 Link encap:Point-to-Point Protocol > inet addr:21.227.117.124 P-t-P:10.64.64.64 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:33967 errors:0 dropped:0 overruns:0 frame:0 > TX packets:29454 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:28077904 (26.7 Mb) TX bytes:2831375 (2.7 Mb) > > The other tested implementation is my own FreeCalypso, or more > specifically an FCDEV3B modem board running FreeCalypso Magnetite > hybrid firmware, build date 2018-07-30T20:24:34Z. It is also using a > different SIM, although on the same billing account with T-Mobile and > with the same service configuration - I am too lazy to move the same > SIM back and forth between the USB stick modem and my own board. Here > is the ifconfig output: > > ppp0 Link encap:Point-to-Point Protocol > inet addr:22.255.27.2 P-t-P:10.64.64.64 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:285 errors:0 dropped:0 overruns:0 frame:0 > TX packets:341 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:79139 (77.2 Kb) TX bytes:35368 (34.5 Kb) > > The dynamically assigned IP address is different because I had to shut > down pppd with one modem and start a new session with the other modem, > but notice that the P-t-P address is the same fixed 10.64.64.64. In this case the P-t-P IP address 10.64.64.64 is probably coming from the pppd on your linux machine. If the remote P-t-P IP address cannot be determined via IPCP pppd is using fallback IP addresses. The IP address pppd then uses is 0x0a404040 + a interface unit id. The interface unit id is "0" for ppp0, "1" for ppp1, ... The resulting (fake) fallback P-t-P remote IP addresses are ppp0 -> 10.64.64.64 ppp1 -> 10.64.64.65 For more details see: https://github.com/paulusmack/ppp/blob/5c765a67fd25f9d84e71ed61ace37c8c97f6be15/pppd/ipcp.c#L1752 This ppp implementation aka "Paul's PPP Package" from https://ppp.samba.org/ is used by more or less all linux distributions these days. best regards, Martin From mychaela.falconia at gmail.com Wed Aug 22 18:06:13 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Wed, 22 Aug 2018 10:06:13 -0800 Subject: GGSN p-t-p address? In-Reply-To: <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> Message-ID: Hi Keith! > So, I decided to carry out a similar simple test, by putting my local > operator SIM into the modem. > I still got the 192.168.100.101 p-t-p address. Given that this happens > on OpenWRT and Windows, although I didn't bother test windows with the > local operator, I would have to assume that in my case, it's coming from > the modem, as Harald suggests. I wonder, is it possible for the GGSN to either provide or not provide the far end IP address? I wonder if the modems pass on the far end IP address provided by the GGSN if there is one, and make up their own placeholder otherwise? I suppose I won't know until I take the time to study the implementation code I got from TI, and I don't know when I may be able to find the time to do that... I wish I could send you one of my FreeCalypso modem boards so you could test it against your Osmocom network - it would be the first- ever GPRS connection made between a free, fully understood modem implementation and a free, fully understood network - but I don't have any boards left: all V1 boards are sold out, and I need about 3000 USD to order the PCB fabrication of V2 boards. > Can we see diagnostic output on gprs negociation on the freecalypso side? By default only L1 emits voluminous debug output, not any of the upper protocol stack layers, but you can send developer commands to the running fw over the second UART (the same one on which the debug output is, not the one that carries AT commands and PPP) to enable more verbose debug traces. However, you cannot enable "everything", as the trace output mechanism will be overwhelmed and you will be lost in the noise, instead you need to study the code first, get a good grip on its architecture, and then selectively enable the traces of interest to whatever you are investigating. > Does it give us an "insight" into what this TI baseband is doing? "What this TI baseband is doing" - just to be sure that everyone understands the context, the hardware and the DSP black box only receive and transmit bursts, nothing more; everything above the physical layer is done by software running on the ARM7 processor, and we have the complete C source for that software, no blobs. It is a *different* version of TI's upper level protocol stack code than the one that was used by Openmoko - the latter had blobs with no corresponding source. I am using a newer version of TI's upper level protocol stack code that was originally supported by TI only on their LoCosto chipset, which is much less understood by the community than the good old Calypso - so I backported that code from LoCosto to Calypso, and then built my own Calypso-based board to run it on. Motorola C1xx phones that are used by OsmocomBB aren't good enough for this purpose: I really needed two UARTs (one for AT commands and PPP, the other for development and debug), whereas those Motorolas only have one usable UART. People should also get over the incorrect notion that it is all TI's stuff and that I am merely pirating and remarketing it. The FC Magnetite repository alone (the one from which I make stable production builds) has more than 500 commits since the initial import, it took 349 commits in another repository to reconstruct the L1 code (watch my REcon Montreal 2017 video for the details), another 806 commits across several repositories to develop various supporting tooling, and all of that was *after* my initial attempt (freecalypso-sw) which I concluded was the wrong approach; that "rough first attempt" freecalypso-sw repository got 1034 commits at the time of its retirement. There is no practically available hardware on which one could run any of TI's original code versions without my changes, and the only hardware that *is* practically available (my development board, called FCDEV3B) requires FreeCalypso firmware to function usefully, not any of the historical pre-existing versions from TI or from other companies. TI has not provided one bit of support for any of this software or for the silicon needed to run it since 2009, all development after that date (almost a decade) was done by me and not by them. I am not merely "hacking" this code, I am striving to maintain it, support it and continue further development of it no worse than TI did in their peak days. However, the code base is huge, and being just one person working on it in my spare time without commercial funding, I can only do so much - there are many parts of the code which I haven't studied yet because the code "just works" and I haven't had a need to delve into it yet - most of the GPRS code is in this category. I was actually quite amazed that the GPRS code just worked out of the box when I backported the new TCS3/LoCosto version of G23M to the Calypso and made it compile in my Magnetite build environment. This new code version differs from the old one which TI officially supported on the Calypso: they added a new protocol stack component called UPM (User Plane Manager), and it appears to originate from TI's dual-mode GSM+UMTS (3G) protocol stack - but it also has a 2G-only mode when no UMTS protocol stack components are present, and this 2G-only UPM is a required component of the FreeCalypso hybrid (previously TI LoCosto) protocol stack for GPRS. Osmocom has done a magnificent job of bringing to the world a FLOSS implementation of the network side of GSM, GPRS and UMTS, but there are no practically usable Osmocom offerings for the mobile side - every one of those awesome Osmocom 2G or 3G networks out there is still serving end user phones and modems that are 100% closed and proprietary. It is high time for the user equipment side to be freed too, and if Osmocom is not doing it, then someone else will. At the present time I am not aware of anyone else other than FreeCalypso offering any kind of practically usable cellular end user equipment that is anything other than an impenetrable binary blob that is also tivoized most of the time. M~ P.S. I wish I could meet you all at OsmoCon in October, but it won't be possible even if someone volunteered to pay for my airfare: I would need to get a U.S. Travel Document (aka Re-entry Permit) in order to travel outside of USA+Canada+Mexico territory, and that process would certainly take longer than the two months or less between now and OsmoCon. However, if there is any other conference or gathering coming a little further out, and if someone would like me to come to that one and would cover my flight, please let me know and I will start the months-long application process to get my travel document, which will then be good for 2 y. From 246tnt at gmail.com Wed Aug 22 21:01:08 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 22 Aug 2018 23:01:08 +0200 Subject: CSN.1 directory In-Reply-To: References: Message-ID: Hi, > I did not know GMR-1 was so close from GSM / GPRS at the RRC / NAS layer. GMR-1 is heavily derived from GSM. Mostly just all the physical medium specific stuff had to be adapted. > I found those GMR-1 specs which seem the most recent, with CSN.1 > structures definition: > - for RRC: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760413/03.05.01_60/ts_1013760413v030501p.pdf > - for NAS: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/03.04.01_60/ts_1013760408v030401p.pdf Yes, and there are also some in https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/03.01.01_60/ts_1013760408v030101p.pdf Unfortunately that doc has plenty of reference to the "previous" versions : https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/02.03.01_60/ts_1013760408v020301p.pdf https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/01.03.01_60/ts_1013760408v010301p.pdf > I may be able to process them and create corresponding directories in pycrate. That would be really nice :) Do you have some tool to automatically extract the definitions from the pdf ? Cheers, Sylvain From keith at rhizomatica.org Thu Aug 23 10:47:38 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 23 Aug 2018 12:47:38 +0200 Subject: GGSN p-t-p address? In-Reply-To: <11a9c6eb-ab86-2055-6abc-4b700c066048@gmx.de> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <11a9c6eb-ab86-2055-6abc-4b700c066048@gmx.de> Message-ID: <82cb8a18-9be5-6cd0-fa1c-7a434dcbce61@rhizomatica.org> On 22.08.2018 18:55, Martin Hauke wrote: > > If the remote P-t-P IP address cannot be determined via IPCP pppd is > using fallback IP addresses. > > The IP address pppd then uses is 0x0a404040 + a interface unit id. > The interface unit id is "0" for ppp0, "1" for ppp1, ... > > The resulting (fake) fallback P-t-P remote IP addresses are > > ppp0 -> 10.64.64.64 > ppp1 -> 10.64.64.65 > For more details see: > https://github.com/paulusmack/ppp/blob/5c765a67fd25f9d84e71ed61ace37c8c97f6be15/pppd/ipcp.c#L1752 Interesting! But I note the code there is: ??? if (wo->hisaddr == 0 && !noremoteip) { ??????? /* make up an arbitrary address for the peer */ ??????? wo->hisaddr = htonl(0x0a707070 + ifunit); wo->hisaddr being the p-t-p side, so the IP should be 10.112.112.112 in that case, no? Ah.. no.. reading further down in the next function: https://github.com/paulusmack/ppp/blob/5c765a67fd25f9d84e71ed61ace37c8c97f6be15/pppd/ipcp.c#L1812 To try to bring this back on topic for the list, I still have the question of whether the GGSN /could/ in fact provide the correct p-t-p address? From keith at rhizomatica.org Thu Aug 23 10:54:04 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 23 Aug 2018 12:54:04 +0200 Subject: GGSN p-t-p address? In-Reply-To: References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> Message-ID: On 22.08.2018 20:06, Mychaela Falconia wrote: > > Osmocom has done a magnificent job of bringing to the world a FLOSS > implementation of the network side of GSM, GPRS and UMTS, but there > are no practically usable Osmocom offerings for the mobile side - > every one of those awesome Osmocom 2G or 3G networks out there is > still serving end user phones and modems that are 100% closed and > proprietary. Hi Mychaela.? It's a problem for sure, even if such a (mobile side) device existed, users would likely in most cases just use it to connect to closed, proprietary, centralised, surrveillance based and advertising funded networks to give away their thoughts and minds and freedoms. What to do? > However, if there is any other conference or gathering > coming a little further out, OsmoCon next year? (Maybe rhizomatica should host it in Mexico, although that would mean a lot of carbon burning for most people to get there!) From laforge at gnumonks.org Thu Aug 23 11:10:18 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Aug 2018 13:10:18 +0200 Subject: GGSN p-t-p address? In-Reply-To: <82cb8a18-9be5-6cd0-fa1c-7a434dcbce61@rhizomatica.org> References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <11a9c6eb-ab86-2055-6abc-4b700c066048@gmx.de> <82cb8a18-9be5-6cd0-fa1c-7a434dcbce61@rhizomatica.org> Message-ID: <20180823111018.GL28063@nataraja> Hi Keith, On Thu, Aug 23, 2018 at 12:47:38PM +0200, Keith wrote: > To try to bring this back on topic for the list, I still have the > question of whether the GGSN /could/ in fact provide the correct p-t-p > address? A GTP tunnel is *not* a point-to-point link, and hence it technically doesn't have a point-to-point address. This is a mismatch between IETF/PPP and 3GPP architecture. The point is that a GGSN is not seen as a router, but merely a tunnel entry point, transporting user packet data such as IP. The actual GGSN implementation may be implemented as a router, but that's then an implementation detail and nothing in the 3GPP design. So I think it would be illogical if the GGSN would advertise a point-to-point address, if it isn't a point-to-point link :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michau.benoit at gmail.com Thu Aug 23 14:02:37 2018 From: michau.benoit at gmail.com (benoit michau) Date: Thu, 23 Aug 2018 16:02:37 +0200 Subject: CSN.1 directory In-Reply-To: References: Message-ID: Hi, I have been using the scripts here: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir/generator/ - extract.py: to extract csn.1 definitions from those 3GPP 44.018, 44.060 and 24.008 after converting them to txt files with microsoft word. I am not sure it would work well with ETSI specs in PDF converted to text. - gen.py: to convert csn.1 specs to Python files by batch. Beware some pathes are hardcoded, this may have to be adjusted in the header of those scripts. Regards Benoit 2018-08-22 23:01 GMT+02:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > >> I did not know GMR-1 was so close from GSM / GPRS at the RRC / NAS layer. > > GMR-1 is heavily derived from GSM. Mostly just all the physical medium > specific stuff had to be adapted. > >> I found those GMR-1 specs which seem the most recent, with CSN.1 >> structures definition: >> - for RRC: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760413/03.05.01_60/ts_1013760413v030501p.pdf >> - for NAS: https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/03.04.01_60/ts_1013760408v030401p.pdf > > Yes, and there are also some in > > https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/03.01.01_60/ts_1013760408v030101p.pdf > > Unfortunately that doc has plenty of reference to the "previous" versions : > https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/02.03.01_60/ts_1013760408v020301p.pdf > https://www.etsi.org/deliver/etsi_ts/101300_101399/1013760408/01.03.01_60/ts_1013760408v010301p.pdf > >> I may be able to process them and create corresponding directories in pycrate. > > That would be really nice :) > > Do you have some tool to automatically extract the definitions from the pdf ? > > Cheers, > > Sylvain From mychaela.falconia at gmail.com Thu Aug 23 16:16:41 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 23 Aug 2018 08:16:41 -0800 Subject: GGSN p-t-p address? In-Reply-To: References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> Message-ID: Hi Keith! > It's a problem for sure, even if such a (mobile side) device existed, > users would likely in most cases just use it to connect to closed, > proprietary, centralised, surrveillance based and advertising funded > networks to give away their thoughts and minds and freedoms. What to do? I don't see how it would be a problem if people use a FLOSS phone to connect to mainstream commercial GSM or UMTS networks. I don't see those networks as advertising-funded, they sure seem subscriber-funded to me (everyone pays a monthly bill to get a SIM with a phone number), and if you have the complete source code plus hardware schematics for your phone, then *you* control what your phone does and doesn't do, and it simply interacts with the operator's network in accordance with standard protocol specs. If I use the cellular voice network of T-Mobile USA with my own phone (not issued and not approved by T-Mobile) for everyday mundane business like calling in to say that I am on my way in traffic when I'm running a little late for an appointment, I don't see how I am giving away my thoughts or my mind or my freedom - in my view, I am not. > OsmoCon next year? If someone is interested enough in my mobile-side work to sponsor my travel costs, then sure, and in that case the prospective sponsor would need to tell me now so I can start the months-long application process for the travel document - it can't be done at the last minute. In the absence of such interest and sponsorship, I do hope to make it out to OsmoCon on my own dime eventually, but it won't be next year: it would have to be after my surgery, which means at least another 2-3 years. Leah Rowe of Libreboot just got hers done (vimuser.org/surgery), now it's time for mine, so that's where I am currently directing all of my spare money. > (Maybe rhizomatica should host it in Mexico, although > that would mean a lot of carbon burning for most people to get there!) If you do host something in Mexico (preferably somewhere close to the border like Tijuana), that should definitely be affordable for me to travel to on my own! I am just north of that border. M~ From nhofmeyr at sysmocom.de Fri Aug 24 11:38:07 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Aug 2018 13:38:07 +0200 Subject: GGSN p-t-p address? In-Reply-To: References: <50670f42-f665-79f1-6965-0031c352d8e5@rhizomatica.org> <20180818193734.GF31341@nataraja> <53b83c61-cf1d-bc45-765d-97d075f3d345@rhizomatica.org> <20180819201513.GC31355@nataraja> <00fb29f5-8cb7-63a1-c1f2-bcbb5e6cb3f1@rhizomatica.org> Message-ID: <20180824113807.GB16638@my.box> On Thu, Aug 23, 2018 at 08:16:41AM -0800, Mychaela Falconia wrote: > I don't see how it would be a problem if people use a FLOSS phone to > connect to mainstream commercial GSM or UMTS networks. I think this was rather aimed at the twitboogle services used over the networks, which Keith sees most activity going to from Rhizomatica users; That the current status quo is pretty much all of humanity being oblivious that we're handing on a golden plate 1st class surveillance data about *all* users worldwide not even to our own state, but actually to a single commercial entity somewhere else on the planet, who aren't even bound by the ethics of an elected government or for the good of whoever, and can basically define themselves what laws apply to the data. But obviously that's politics and socio-economics and several layers above the "free my handset" / "free my mobile network" discussion. It's an immensely important subject that's still several magnitudes too under-emphasized... ...but frankly off-topic here. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Aug 30 14:05:45 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 30 Aug 2018 16:05:45 +0200 Subject: The magic behaviour of 'logging level all LEVEL' In-Reply-To: <2313bcb8-eea9-211b-6400-d4e0d48e6d75@sysmocom.de> References: <20180730183919.GM30570@nataraja> <2313bcb8-eea9-211b-6400-d4e0d48e6d75@sysmocom.de> Message-ID: <20180830140545.GA12498@my.box> With a bit of time passed, I am revisiting this. It seems that my plan to have a per-subsystem configurable default log level as well as a per-subsystem configurable elevated/silenced log level is pretty much off the table. So then, for me that means it opens the door to accept Pau's patch. There was other criticism though: > You certainly don't want to set DEBUG on all categories, as otherwise you're > going to be spammed and will drown in too much information. For some programs (osmo-hlr, osmo-msc, osmo-bsc) it does actually make perfect sense to set everything to DEBUG in a lab environment. That's why the brokenness of 'logging level all debug' is so annoying. You think you've set each and every log level to debug, but for some obscure reason still some logging is missing. Similarly, if I want to silence all logging except ERRORs, 'logging level all error' is a very useful command -- if it works the way that it sounds. > "Do we really have no more pressing needs than re-desinging/defining how the > log configuration works?" Above annoyance is recurring and hindering everything else by constant uncertainty of what is being logged and/or the need to consider each individual logging category all the time. > > while 'logging level default LEVEL' > > would only affect the default logging level... > > What is the "default logging level" ? The level compiled-into the struct > log_info? The "default" would be a single global setting for all categories. I sense a conflict between the "default" level and the struct log_info compiled-in defaults. Would the "default" level override the compiled-in defaults? Would the "default" have no effect until the vty command is issued? Or would the "default" have no effect until we call 'unset-all' to "unset" the initial levels copied from struct log_info levels? Now that I've accepted that we will not have a per-category adjustable default level, I think we might as well just stay with the compiled-in log_info defaults, and not introduce another default level. I want to be able to change all categories' current levels to "DEBUG" or "ERROR" with a single command, but I don't really have a need for a common default to fall back to. (Instead I would again set 'all' to that level.) So I've swerved 180? and now think that even the proposed one common default level across all categories is more complexity than we need. Can we fix 'logging level all foo' separately, without introducing more defaults first? We can then still consider the default,unset feature on its own. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Thu Aug 30 19:23:10 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 30 Aug 2018 21:23:10 +0200 Subject: The magic behaviour of 'logging level all LEVEL' In-Reply-To: <20180830140545.GA12498@my.box> References: <20180730183919.GM30570@nataraja> <2313bcb8-eea9-211b-6400-d4e0d48e6d75@sysmocom.de> <20180830140545.GA12498@my.box> Message-ID: <20180830192310.GG32717@nataraja> Hi Neels, On Thu, Aug 30, 2018 at 04:05:45PM +0200, Neels Hofmeyr wrote: > With a bit of time passed, I am revisiting this. > > It seems that my plan to have a per-subsystem configurable default log level as > well as a per-subsystem configurable elevated/silenced log level is pretty much > off the table. > > So then, for me that means it opens the door to accept Pau's patch. At this point, I am sorry to say the topic has somehow become somewhat of a "red flag" to me. So I'll hereby bestow you with the title of "Osmocom Supreme Chief Logging Officer" and you get all the freedom to decide how you'd like to change it, as you see fit. My rough outline is: * try to handle existing config files in a useful way, without obvious breakage * make sure all documentation is updated at the very same time as the change is merged, so that user manuals / vty reference / wiki / etc. are correct. This is without bitterness, don't get me wrong. I just don't feel like I can come to a good conclusion here, and hence I delegate it and make it your problem :P Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)