From msuraev at sysmocom.de Fri Nov 2 17:21:50 2018 From: msuraev at sysmocom.de (Max) Date: Fri, 2 Nov 2018 18:21:50 +0100 Subject: BSSAP parsing in Osmo*SC Message-ID: <555f1158-da06-31c4-68e1-b9feaee9cdcc@sysmocom.de> Hi. While browsing through the code I've noticed that BSSMAP is parsed differently by OsmoBSC and OsmoMSC. In MSC we use "msg->l3h = &msg->l2h[sizeof(struct bssmap_header)];" in a_iface_bssap.c:707 and 202 In BSC we use "msg->l4h = &msg->l3h[sizeof(struct bssmap_header)];" in osmo_bsc_bssap.c:988 What's the reason for this difference? I thought that if protocol is the same than the basic layering and parsing should look the same as well. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From oramadan at fb.com Sat Nov 3 02:59:39 2018 From: oramadan at fb.com (Omar Ramadan) Date: Sat, 3 Nov 2018 02:59:39 +0000 Subject: AMR misconfiguration or bug Message-ID: Hey Osmocom, I am working to test hrAMR codec with osmo-bts-oc2g but it doesn't seem the correct TCH/F frame type is being activated: <0000> ../../../osmo-bts/src/common/rsl.c:2805 (bts=0,trx=0,ts=1,pchan=TCH/F_TCH/H_PDCH as PDCH) ss=0 Rx RSL CHAN_ACTIV <0000> ../../../osmo-bts/src/common/amr.c:105 AMR Multirate with 6 modes len=2 not possible <0000> ../../../osmo-bts/src/common/rsl.c:1159 (bts=0,trx=0,ts=1,ss=0): chan_nr=TCH/H(0) on TS1 type=0x01 mode=SPEECH_AMR <0006> ../../../osmo-bts/src/common/l1sap.c:1471 activating channel chan_nr=TCH/H(0) on TS1 trx=0 <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:937 (bts=0,trx=0,ts=1,ss=0): lchan2lch_par tch_mode=0x41 <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:1083 (bts=0,trx=0,ts=1,ss=0) MPH-ACTIVATE.req (hL2=0x000100bb, TCH/H TxDL) <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:822 (bts=0,trx=0,ts=1,ss=0) MPH-ACTIVATE.conf (TCH/H TxDL) <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:833 Error activating L1 SAPI TCH/H on TS 1: Invalid parameter <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:1109 (bts=0,trx=0,ts=1,ss=0) act failed mark broken due status: -4 <0006> ../../../osmo-bts/src/common/l1sap.c:623 activate confirm chan_nr=TCH/H(0) on TS1 trx=0 <0000> ../../../osmo-bts/src/common/rsl.c:787 (bts=0,trx=0,ts=1,ss=0): Sending Channel Activated NACK: cause = 0x25 Frame 202: 101 bytes on wire (808 bits), 101 bytes captured (808 bits) on interface 0 Linux cooked capture Internet Protocol Version 4, Src: 10.42.0.1, Dst: 10.42.0.50 Transmission Control Protocol, Src Port: 3003, Dst Port: 51480, Seq: 90, Ack: 206, Len: 33 IPA protocol ip.access, type: RSL Radio Signalling Link (RSL) 0000 100. = Message discriminator: Dedicated Channel Management messages (4) .... ...0 = T bit: Not considered transparent by BTS .010 0001 = Message type: CHANnel ACTIVation (0x21) Channel number IE Activation Type IE Channel Mode IE Channel Identification IE BS Power IE MS Power IE Timing Advance IE MultiRate configuration IE Element identifier: MultiRate Configuration (0x36) Length: 2 001. .... = Multirate speech version: Adaptive Multirate speech version 1 (1) ...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0) .... 1... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the Start Mode field (1) .... ..00 = Start Mode: 0 0... .... = 12,2 kbit/s codec rate: is not part of the subset .0.. .... = 10,2 kbit/s codec rate: is not part of the subset ..1. .... = 7,95 kbit/s codec rate: is part of the subset ...1 .... = 7,40 kbit/s codec rate: is part of the subset .... 1... = 6,70 kbit/s codec rate: is part of the subset .... .1.. = 5,90 kbit/s codec rate: is part of the subset .... ..1. = 5,15 kbit/s codec rate: is part of the subset .... ...1 = 4,75 kbit/s codec rate: is part of the subset I am trying to understand how codec negotiation is performed, and whether this is a bug or mis-configuration. I've attached the BTS pcap and configurations that are being used. Thanks, Omar -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts-oc2g-amr-call.pcapng Type: application/x-pcapng Size: 843380 bytes Desc: osmo-bts-oc2g-amr-call.pcapng URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configs.tgz Type: application/x-compressed-tar Size: 2687 bytes Desc: configs.tgz URL: From axilirator at gmail.com Sat Nov 3 10:43:49 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 3 Nov 2018 17:43:49 +0700 Subject: EUSE with user input Message-ID: Hello Michael, > I have tried changing the session state to > `OSMO_GSUP_SESSION_STATE_CONTINUE`, and the gsup_msg_type to > `OSMO_GSUP_MSGT_PROC_SS_REQUEST` in `euse_tx_ss`. I see the ?You > sent?? response on my phone, but do not get an input field. Since GSUP is used as the transport layer for encoded USSD payload, changing GSUP header fields wouldn't change the payload itself. In other words, what you are doing is correct, but additionally you need to change the message itself. The current code is using gsm0480_gen_ussd_resp_7bit() function from libosmocore, where you can find the following: // ... /** * Here you should change GSM0480_OP_CODE_PROCESS_USS_REQ * to GSM0480_OP_CODE_USS_REQUEST (see GSM 04.80). */ /* Pre-pend the operation code */ msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); // ... /** * ... * Here you should change GSM0480_CTYPE_RETURN_RESULT * to GSM0480_CTYPE_INVOKE (see GSM 04.80). */ /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); so it makes sense to introduce a new function. Moreover, you should take care about InvokeID, it should uniquely identify each request-response pair in the following way: msc { MS [label="Subscriber"], EUSE [label="SS/USSD handler"]; MS => EUSE [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_INVOKE, invokeID=X"]; EUSE => MS [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_INVOKE, invokeID=X+1"]; MS => EUSE [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_RETURN_RESULT, invokeID=X+1"]; EUSE => MS [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_RETURN_RESULT, invokeID=X"]; } I am using X because not all phones start counting from 0, and this should be handled properly. X+1 is just an example, it can be calculated in a different way, but in any case it should be unique for the current stack of requests. Keep us updated, good luck! With best regards, Vadim Yanitskiy. From keith at rhizomatica.org Sat Nov 3 11:40:02 2018 From: keith at rhizomatica.org (Keith) Date: Sat, 3 Nov 2018 12:40:02 +0100 Subject: AMR misconfiguration or bug In-Reply-To: References: Message-ID: <3fc1591d-6b64-003b-6f4e-9efa32432cbe@rhizomatica.org> On 03/11/2018 03:59, Omar Ramadan wrote: > > Hey Osmocom, > > Hi Omar! > I am working to test hrAMR codec with osmo-bts-oc2g but it doesn't > seem the correct TCH/F frame type is being activated: > > > <0000> ../../../osmo-bts/src/common/rsl.c:2805 > (bts=0,trx=0,ts=1,pchan=TCH/F_TCH/H_PDCH as PDCH) ss=0 Rx RSL CHAN_ACTIV > <0000> ../../../osmo-bts/src/common/amr.c:105 AMR Multirate with 6 > modes len=2 not possible I'm not sure, this is just off the top of my head, but I'd hazard a guess that not having all AMR modes "allowed" in open-bsc.cfg might do the trick for you. Try amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 4_75k forbidden or some such.. Does it work? Thanks k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Sat Nov 3 16:07:50 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 3 Nov 2018 17:07:50 +0100 Subject: AMR misconfiguration or bug In-Reply-To: References: Message-ID: <20181103160749.GD19254@my.box> > I am working to test hrAMR codec with osmo-bts-oc2g but it doesn't seem the correct TCH/F frame type is being activated: Just a quick note, I noticed pmaier fixing some AMR related problems quite recently. Just maybe using most up-to-date nightly / master builds could help? ~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 Sat Nov 3 14:52:36 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 3 Nov 2018 15:52:36 +0100 Subject: AMR misconfiguration or bug In-Reply-To: <3fc1591d-6b64-003b-6f4e-9efa32432cbe@rhizomatica.org> References: <3fc1591d-6b64-003b-6f4e-9efa32432cbe@rhizomatica.org> Message-ID: <20181103145235.GT3801@nataraja> Hi Keith and Omar, just some brief response with general context (I'm busy with renovation work these days): Any given GSM channel cannot have more than four AMR codec modes in the active set. That's a limitation of the way AMR is specified in GSM. 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 oramadan at fb.com Sun Nov 4 00:52:19 2018 From: oramadan at fb.com (Omar Ramadan) Date: Sun, 4 Nov 2018 00:52:19 +0000 Subject: AMR misconfiguration or bug In-Reply-To: <20181103160749.GD19254@my.box> References: , <20181103160749.GD19254@my.box> Message-ID: Hi Neels, Keith, Harald, Thanks all for your responses > Just a quick note, I noticed pmaier fixing some AMR related problems quite recently. Just maybe using most up-to-date nightly / master builds could help? I've recompiled my MGW, BSC, MSC from master > I'm not sure, this is just off the top of my head, but I'd hazard a guess that not having all AMR modes "allowed" in open-bsc.cfg might do the trick for you. That seemed to be the issue causing the error. It seems that the call is setup with a length two multirate configuration which means I can only activate only a single AMR codec according to src/common/amr.c:amr_parse_mr_conf Still couldn't figure out how to configure more than a single AMR codec. Call has proceeded further, but still can't establish a call using freeswitch as PBX. The SIP connector is still being incorrectly assigned the PCMU codec. Attaching more traces. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bsc_msc_mgw_sip_pbx_amr.pcapng Type: application/x-pcapng Size: 155528 bytes Desc: bsc_msc_mgw_sip_pbx_amr.pcapng URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bts_trace_amr.pcapng Type: application/x-pcapng Size: 39920 bytes Desc: bts_trace_amr.pcapng URL: From snehasish.cse at LIVE.COM Sat Nov 3 12:06:33 2018 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Sat, 3 Nov 2018 12:06:33 +0000 Subject: Help with silent call Message-ID: Hello I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC or any such way exists to do this or any other alternative does exists? BR Snehasish -------------- next part -------------- An HTML attachment was scrubbed... URL: From k at rhizomatica.org Sun Nov 4 08:56:11 2018 From: k at rhizomatica.org (k at rhizomatica.org) Date: Sun, 4 Nov 2018 09:56:11 +0100 Subject: AMR misconfiguration or bug In-Reply-To: References: <20181103160749.GD19254@my.box> Message-ID: <16e62aa7-8b20-3c5f-6146-3ec2d1871055@rhizomatica.org> On 04/11/2018 01:52, Omar Ramadan wrote: > > Hi Neels, Keith, Harald, > > Hi again Omar :) > > > Call has proceeded further, but still can't establish a call using > freeswitch as PBX. The SIP connector is still being incorrectly > assigned the PCMU codec.? > Indeed :( https://osmocom.org/issues/3650 k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Nov 4 10:26:48 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 4 Nov 2018 17:26:48 +0700 Subject: Help with silent call Message-ID: > If yes, can it [silent call] be done in OpenBSC or any such way > exists to do this or any other alternative does exists? Please check out http://ftp.osmocom.org/docs/latest/, you can find OsmoNiTB / OsmoMSC user manuals there. Silent call feature is supported, but not documented. Feel free to contribute! With best regards, Vadim Yanitskiy. From nhofmeyr at sysmocom.de Sun Nov 4 19:16:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 4 Nov 2018 20:16:23 +0100 Subject: Help with silent call In-Reply-To: References: Message-ID: <20181104191623.GA22559@my.box> On Sat, Nov 03, 2018 at 12:06:33PM +0000, Snehasish Kar wrote: > I have read that silent-calls in GSM can be used to make a call to a target > MS and listen to it Not listen to it in terms of audio. You can't eavesdrop on an MS with a slient call. You *can* open a channel and receive measurement reports from it, so that you see which other cells it sees at which receive levels, and how far it is from the current cell (TA). From that you could derive its position. The silent call has been one of the earliest features in Osmocom, but until recently has been broken in osmo-msc. IIUC it is now fixed again in current master, but might not be in a release yet. There's also the APDU a.k.a. the RR App Info (I hope I got the names right), which may or may not contain GPS positioning data that the MS is sending to the core net. In both cases the owner of the MS has no explicit idea that they are sharing any details on their position. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From oramadan at fb.com Sun Nov 4 21:55:08 2018 From: oramadan at fb.com (Omar Ramadan) Date: Sun, 4 Nov 2018 21:55:08 +0000 Subject: AMR misconfiguration or bug In-Reply-To: <16e62aa7-8b20-3c5f-6146-3ec2d1871055@rhizomatica.org> References: <20181103160749.GD19254@my.box> , <16e62aa7-8b20-3c5f-6146-3ec2d1871055@rhizomatica.org> Message-ID: That?s the same issue I?m seeing Keith. Thanks for reporting it. Get Outlook for iOS ________________________________ From: k at rhizomatica.org Sent: Sunday, November 4, 2018 1:56:11 AM To: Omar Ramadan; Neels Hofmeyr Cc: OpenBSC Mailing List Subject: Re: AMR misconfiguration or bug On 04/11/2018 01:52, Omar Ramadan wrote: Hi Neels, Keith, Harald, Hi again Omar :) Call has proceeded further, but still can't establish a call using freeswitch as PBX. The SIP connector is still being incorrectly assigned the PCMU codec. Indeed :( https://osmocom.org/issues/3650 k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Mon Nov 5 09:08:37 2018 From: keith at rhizomatica.org (Keith) Date: Mon, 5 Nov 2018 10:08:37 +0100 Subject: AMR misconfiguration or bug In-Reply-To: References: <20181103160749.GD19254@my.box> Message-ID: <753a9ee2-137a-7748-afef-622c3decb76e@rhizomatica.org> On 04/11/2018 01:52, Omar Ramadan wrote: > The SIP connector is still being incorrectly assigned the PCMU codec.? > Omar, a quick and dirty hack for the osmo-sip-connector, to (probably) get your calls running through FreeSwitch: Hardcode override the pt in sdp_create_file() in sdp.c by adding other->payload_type = 98; (or for full rate GSM, it would be other->payload_type = 3;) somewhere in the top of that function, at line 170 for example, here: http://git.osmocom.org/osmo-sip-connector/tree/src/sdp.c#n170) k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CSENKAL at havelsan.com.tr Tue Nov 6 07:02:53 2018 From: CSENKAL at havelsan.com.tr (=?utf-8?B?w4dhxJ9yxLEgxZ5FTktBTA==?=) Date: Tue, 6 Nov 2018 07:02:53 +0000 Subject: about piswords sim cards Message-ID: <1541487761230.25955@havelsan.com.tr> Hi, I am trying to program a USIM that I bought from aliexpress- piswords store. I think I need to have ADM pin to program the cards. Is it really necessary for piswords cards, do you have any experience? If so how did you get ADM pin? They sent me an ADM of 16 digits : 3838383838383838 However I think that it should be 8 digits. I tried 8 first 8 digits and it did not work I asked them to send me correct ADM . Do you have any experience regarding piswords cards? Any help is much appreciated. Regards, Cagri SENKAL [cid:image950557.PNG at 39f2571e.4ca4c0cb] [cid:imagee20435.JPG at 6468be44.4fabfbb6] ?a?r? ?ENKAL TEST ANAL?ST? Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 ?ankaya Ankara T?RK?YE [cid:image66a2f6.PNG at 2379de89.4e94e966] +90 312 219 57 87 [cid:image52a873.PNG at 0085d638.49a22037] +90 312 219 57 97 [cid:image63fd4b.JPG at b3e744d5.419497ba] YASAL UYARI: Bu elektronik posta i?bu linki kullanarak ula?abilece?iniz Ko?ul ve ?artlar dok?man?na tabidir. LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. [http://www.havelsan.com.tr/Library/images/mail/email.jpg] L?tfen gerekmedik?e bu sayfa ve eklerini yazd?rmay?n?z / Please consider the environment before printing this email -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image950557.PNG Type: image/png Size: 4676 bytes Desc: image950557.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagee20435.JPG Type: image/jpeg Size: 305 bytes Desc: imagee20435.JPG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image66a2f6.PNG Type: image/png Size: 360 bytes Desc: image66a2f6.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image52a873.PNG Type: image/png Size: 313 bytes Desc: image52a873.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image63fd4b.JPG Type: image/jpeg Size: 28166 bytes Desc: image63fd4b.JPG URL: From alan at kageds.com Tue Nov 6 09:18:29 2018 From: alan at kageds.com (Alan Evans) Date: Tue, 6 Nov 2018 09:18:29 +0000 Subject: about piswords sim cards (?a?r? ?ENKAL) In-Reply-To: References: Message-ID: <8f5dd501-7c78-7398-14e7-da82af1d5eea@kageds.com> On 06/11/2018 07:12:AM, openbsc-request at lists.osmocom.org wrote: > They sent me an ADM of 16 digits : 3838383838383838 This is hex: 3838383838383838 = 0x38, 0x38, 0x38, 0x38, 0x38, 0x38,0x38, 0x38 = '88888888' ASCII Depending in what tool you are using the ADM is either: 0x3838383838383838 or '88888888' --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From CSENKAL at havelsan.com.tr Tue Nov 6 09:38:39 2018 From: CSENKAL at havelsan.com.tr (=?utf-8?B?w4dhxJ9yxLEgxZ5FTktBTA==?=) Date: Tue, 6 Nov 2018 09:38:39 +0000 Subject: about piswords sim cards (?a?r? ?ENKAL) In-Reply-To: <8f5dd501-7c78-7398-14e7-da82af1d5eea@kageds.com> References: , <8f5dd501-7c78-7398-14e7-da82af1d5eea@kageds.com> Message-ID: Already tried 88888888 It did not work also [cid:imagee94703.PNG at 6c554c26.46aedfbe] [cid:image45ba60.JPG at d7536850.40aa3ab0] ?a?r? ?ENKAL TEST ANAL?ST? Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 ?ankaya Ankara T?RK?YE [cid:image417cc3.PNG at b98c07dc.4aadb74a] +90 312 219 57 87 [cid:imageb5ebd3.PNG at 63d6f540.47879f91] +90 312 219 57 97 [cid:image5a3af1.JPG at 22ff3cf0.47b3412e] YASAL UYARI: Bu elektronik posta i?bu linki kullanarak ula?abilece?iniz Ko?ul ve ?artlar dok?man?na tabidir. LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. [http://www.havelsan.com.tr/Library/images/mail/email.jpg] L?tfen gerekmedik?e bu sayfa ve eklerini yazd?rmay?n?z / Please consider the environment before printing this email On Tue, Nov 6, 2018 at 12:27 PM +0300, "Alan Evans" > wrote: On 06/11/2018 07:12:AM, openbsc-request at lists.osmocom.org wrote: > They sent me an ADM of 16 digits : 3838383838383838 This is hex: 3838383838383838 = 0x38, 0x38, 0x38, 0x38, 0x38, 0x38,0x38, 0x38 = '88888888' ASCII Depending in what tool you are using the ADM is either: 0x3838383838383838 or '88888888' --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagee94703.PNG Type: image/png Size: 4676 bytes Desc: imagee94703.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image45ba60.JPG Type: image/jpeg Size: 305 bytes Desc: image45ba60.JPG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image417cc3.PNG Type: image/png Size: 360 bytes Desc: image417cc3.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb5ebd3.PNG Type: image/png Size: 313 bytes Desc: imageb5ebd3.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image5a3af1.JPG Type: image/jpeg Size: 28166 bytes Desc: image5a3af1.JPG URL: From snehasish.cse at live.com Tue Nov 6 09:08:53 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Tue, 6 Nov 2018 09:08:53 +0000 Subject: Help with silent call In-Reply-To: <20181104191623.GA22559@my.box> References: , <20181104191623.GA22559@my.box> Message-ID: Thanks Neel, it was of real help. BR ________________________________ From: Neels Hofmeyr Sent: Monday, November 5, 2018 12:46:23 AM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: Help with silent call On Sat, Nov 03, 2018 at 12:06:33PM +0000, Snehasish Kar wrote: > I have read that silent-calls in GSM can be used to make a call to a target > MS and listen to it Not listen to it in terms of audio. You can't eavesdrop on an MS with a slient call. You *can* open a channel and receive measurement reports from it, so that you see which other cells it sees at which receive levels, and how far it is from the current cell (TA). From that you could derive its position. The silent call has been one of the earliest features in Osmocom, but until recently has been broken in osmo-msc. IIUC it is now fixed again in current master, but might not be in a release yet. There's also the APDU a.k.a. the RR App Info (I hope I got the names right), which may or may not contain GPS positioning data that the MS is sending to the core net. In both cases the owner of the MS has no explicit idea that they are sharing any details on their position. ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From radiarisainanasitraka at yahoo.fr Tue Nov 6 15:16:32 2018 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Tue, 6 Nov 2018 15:16:32 +0000 (UTC) Subject: MISDN like a string not like a number References: <1403077938.2949360.1541517392124.ref@mail.yahoo.com> Message-ID: <1403077938.2949360.1541517392124@mail.yahoo.com> Hello, In our country at Madagascar , operator could send message on phone with MISDN like a string not like a number. I would like to ask if it's possible to do the same thing with osmo-bts !!! For example : They could send message with the phone and the identity on the phone is like : "Telma", "Mvola", "orangeinfo" ...with a samsung phone I could not call this identity and with tecno phone, it shows that the number is for the MISDN "telma" is 83562 and for the MISDN "Mvola" is 68652 .... The logic of this number on tecno is that , it the number on the touchscreen of the old phone without the repetition of the tape of the touch. in this, 2=abc and 3=def and 4=ghi and 5=jkl and 6=mno and 7=pqrs and 8=tuv and 9=wxyz. My last goal is to send a message with a phone on the network (osmo-bts) and it's my that appears on the destinary. chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Tue Nov 6 15:43:26 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 6 Nov 2018 16:43:26 +0100 Subject: MISDN like a string not like a number In-Reply-To: <1403077938.2949360.1541517392124@mail.yahoo.com> References: <1403077938.2949360.1541517392124.ref@mail.yahoo.com> <1403077938.2949360.1541517392124@mail.yahoo.com> Message-ID: <7c99f369-daec-404e-1c2a-78359cb7cd48@rhizomatica.org> On 06/11/2018 16:16, Radiarisainana Sitraka wrote: > Hello, > In our country at Madagascar , operator could send message on phone > with MISDN like a string not like a number. I would like to ask if > it's possible to do the same thing with osmo-bts !!! Well, osmo-bts is not really the component of the network that is handling this, but yes, the answer to your question it is possible. What you are looking for is to set the TON (type of number) in the Short Message that you submit via SMPP to the osmo-msc (or osmo-nitb) k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CSENKAL at havelsan.com.tr Tue Nov 6 18:33:38 2018 From: CSENKAL at havelsan.com.tr (=?utf-8?B?w4dhxJ9yxLEgxZ5FTktBTA==?=) Date: Tue, 6 Nov 2018 18:33:38 +0000 Subject: about piswords sim cards (?a?r? ?ENKAL) In-Reply-To: References: , <8f5dd501-7c78-7398-14e7-da82af1d5eea@kageds.com>, Message-ID: https://m.tr.aliexpress.com/item/32808269061.html?pid=808_0011_0131&spm=a2g0n.search-amp.list.32808269061&aff_trace_key=&aff_platform=msite&m_page_id=7483amp-VzpxMgKtsaeeJYgw0WeBuw1541528840553 According to seller it is a Gr card sim 2. I tried this apdu, but it did not work A0 20 00 0B 08 38 38 38 38 38 38 38 Any clues, why it is not working? Regards [cid:imagedd0c50.PNG at 6a244310.4ab02ca7] [cid:image389282.JPG at af233472.4dbd1419] ?a?r? ?ENKAL TEST ANAL?ST? Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 ?ankaya Ankara T?RK?YE [cid:image08ce58.PNG at fbc4bcdb.43b16ce0] +90 312 219 57 87 [cid:image9108d3.PNG at b05c5c3a.4d9a477a] +90 312 219 57 97 [cid:imageb57708.JPG at 968f7296.4fb2f32c] YASAL UYARI: Bu elektronik posta i?bu linki kullanarak ula?abilece?iniz Ko?ul ve ?artlar dok?man?na tabidir. LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. [http://www.havelsan.com.tr/Library/images/mail/email.jpg] L?tfen gerekmedik?e bu sayfa ve eklerini yazd?rmay?n?z / Please consider the environment before printing this email On Tue, Nov 6, 2018 at 12:38 PM +0300, "?a?r? ?ENKAL" > wrote: Already tried 88888888 It did not work also On Tue, Nov 6, 2018 at 12:27 PM +0300, "Alan Evans" > wrote: On 06/11/2018 07:12:AM, openbsc-request at lists.osmocom.org wrote: > They sent me an ADM of 16 digits : 3838383838383838 This is hex: 3838383838383838 = 0x38, 0x38, 0x38, 0x38, 0x38, 0x38,0x38, 0x38 = '88888888' ASCII Depending in what tool you are using the ADM is either: 0x3838383838383838 or '88888888' --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagedd0c50.PNG Type: image/png Size: 4676 bytes Desc: imagedd0c50.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image389282.JPG Type: image/jpeg Size: 305 bytes Desc: image389282.JPG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image08ce58.PNG Type: image/png Size: 360 bytes Desc: image08ce58.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image9108d3.PNG Type: image/png Size: 313 bytes Desc: image9108d3.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb57708.JPG Type: image/jpeg Size: 28166 bytes Desc: imageb57708.JPG URL: From axilirator at gmail.com Tue Nov 6 19:42:55 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 7 Nov 2018 02:42:55 +0700 Subject: about piswords sim cards (?a?r? ?ENKAL) Message-ID: Hi, > I tried this apdu, but it did not work [...] > Any clues, why it is not working? Most likely, your SIM card is blocked now. There is some kind of protection against ADM PIN brute-forcing - after 3 incorrect ADM presentations, the SIM card blocks itself. AFAIK, there is no way to unblock it anymore. P.S. Please read how to use the mailing lists. 70% of this E-mail is unreadable (and useless) garbage (i.e. images, quoted replays, Avast PR, etc.). With best regards, Vadim Yanitskiy. From alan at kageds.com Wed Nov 7 09:42:16 2018 From: alan at kageds.com (Alan Evans) Date: Wed, 7 Nov 2018 09:42:16 +0000 Subject: about piswords sim cards In-Reply-To: References: <8f5dd501-7c78-7398-14e7-da82af1d5eea@kageds.com> Message-ID: <99a61f98-6fd6-8499-5395-c529c01fd610@kageds.com> On 06/11/2018 06:33:PM, ?a?r? ?ENKAL wrote: > A0 20 00 0B 08 38 38 38 38 38 38 38 Maybe just a cut n paste issue but I count 7 38s whereas there should be 8. Also I think P2 should be 0A and not 0B and not sure why you are using CLA A0. Try 00 20 00 0A 08 38 38 38 38 38 38 38 38 And share the response you get back form the card what are SW1 and SW2? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From ng91 at glonti.com Wed Nov 7 10:48:58 2018 From: ng91 at glonti.com (NG) Date: Wed, 7 Nov 2018 11:48:58 +0100 Subject: Cheap, and easy accesible femtocell support Message-ID: <92da210f-c319-86fb-34ab-06a53924dac5@glonti.com> Hi everybody, Had somebody made a support for a femtocell like Samsung, or huawei(uap2105), or any common femtocells? I just want to test and learn how MN works Thanks Niko From nhofmeyr at sysmocom.de Wed Nov 7 14:18:14 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Nov 2018 15:18:14 +0100 Subject: Cheap, and easy accesible femtocell support In-Reply-To: <92da210f-c319-86fb-34ab-06a53924dac5@glonti.com> References: <92da210f-c319-86fb-34ab-06a53924dac5@glonti.com> Message-ID: <20181107141814.GI19568@my.box> On Wed, Nov 07, 2018 at 11:48:58AM +0100, NG wrote: > Hi everybody, > > Had somebody made a support for a femtocell like Samsung, or > huawei(uap2105), or any common femtocells? > I just want to test and learn how MN works You're talking about 3G right? sysmocom offers a nano3G femto cell ready-for-use with Osmocom. For commercial buyers there is the "3G5 Starter Kit", but in the past sysmocom has also made more affordable offers to developers from the Free Software community around Osmocom, including a giveaway for free a while ago. Not sure how we handle it these days, but it can't hurt to ask sales at sysmocom.de. So far we know of no other cheap femto cells that would be ready for use, i.e. we have some contestants, but they don't talk to us yet. ~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 Nov 8 11:09:58 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Nov 2018 12:09:58 +0100 Subject: OC-2G design files released (was Re: OC-2G merge to osmo-bts) In-Reply-To: <20181029204637.GL31654@nataraja> References: <20181024094001.GJ27815@nataraja> <20181024110141.GO27815@nataraja> <20181029204637.GL31654@nataraja> Message-ID: <20181108110958.GR3801@nataraja> Hi all, following up on a thread from ~ 10 days ago: On Mon, Oct 29, 2018 at 09:46:37PM +0100, Harald Welte wrote: > At this point, to the best of my knowledge, OC-2G yet has to deliver on their > open hardware promise. The design files like schematics / PCB layouts / mechanical > drawings / BOM, etc. are yet to be published. I could only find those of OC-SDR and > OC-LTE on the OpenCellular git repository so far. There has been an update from OpenCellular today: OC-2G files are now pushed into mainline: https://github.com/Telecominfraproject/OpenCellular/tree/master/electronics/oc-2g << electronics files. https://github.com/Telecominfraproject/OpenCellular/tree/master/hardware/oc-2g << enclosure/system I havent yet had time to look at them myself, but I know there are several people interested in it here... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From m.ordean at cs.bham.ac.uk Thu Nov 8 13:45:55 2018 From: m.ordean at cs.bham.ac.uk (Mihai Ordean) Date: Thu, 8 Nov 2018 13:45:55 +0000 Subject: ipaccess-proxy usage help Message-ID: <360cbb1c-272b-26dd-4eb4-af1ea913a9a1@cs.bham.ac.uk> Hey guys, Sorry to keep insisting on this, but I don't seem to be able to make ipaccess-proxy work with either the old OpenBTS nor with the new Osmocom stack. Did anyone have any recent(ish) experience using it. At this point I'd appreciate any tip anyone can provide towards getting a working setup. Thanks, -- Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: m_ordean.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From msuraev at sysmocom.de Thu Nov 8 16:50:15 2018 From: msuraev at sysmocom.de (Max) Date: Thu, 8 Nov 2018 17:50:15 +0100 Subject: handover request Message-ID: <97e3d820-bf79-f471-e5ce-98a10eab9cd1@sysmocom.de> Hi. I've noticed that we don't have any code (besides basic definition) for handover request message (BSS_MAP_MSG_HANDOVER_RQST) from 48.008 3.2.1.8 in libosmocore or osmo-*sc. Is it because it's in some patch hanging somewhere in gerrit or we don't need it (yet)? -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From nhofmeyr at sysmocom.de Thu Nov 8 23:58:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Nov 2018 00:58:55 +0100 Subject: ttcn3 question Message-ID: <20181108235855.GA12427@my.box> I guess I'm again hitting the same ttcn3 wall that has caused me trouble countless times before... I'm trying to run the already existing TC_ho_into_this_bsc(), but before it starts I want to occupy all lchans. This is the working TC_ho_into_this_bsc(): testcase TC_ho_into_this_bsc() runs on test_CT { var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_into_this_bsc), pars); vc_conn.done; } I just want to insert a bit of TC_chan_exhaustion() like so: testcase TC_ho_in_fail_no_chan() runs on test_CT { var integer i; var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); /* occupy all lchans */ for (i := 0; i < NUM_TCHF_PER_BTS + NUM_TCHH_PER_BTS + NUM_SDCCH_PER_BTS; i := i+1) { var RslChannelNr chan_nr := f_chreq_act_ack('23'O, i); } pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_in_fail_no_chan), pars); vc_conn.done; } But no matter which way I turn it, ttcn3 does not agree. * I either get: 21:36:03.008137 mtc BSC_Tests.ttcn:1553 Dynamic test case error: Using the value of an unbound component reference. 21:36:03.008163 mtc BSC_Tests.ttcn:1553 setverdict(error): none -> error This is during f_connect_handler(): connect(vc_conn:BSSMAPEM, g_bssap.vc_BSSMAP:PROC); with the log revealing [1] below * Or I get: 21:31:45.678006 mtc BSC_Tests.ttcn:366 Dynamic test case error: Port IPA_RSL[0] has neither connections nor mappings. Message cannot be sent on it. 21:31:45.678094 mtc BSC_Tests.ttcn:366 setverdict(error): none -> error This stuff really gets me steaming with ttcn... anyhow... I'm fairly certain it has to do with the 'true' arg of f_init() starting the RSL emulation, so I need to re-invent TC_chan_exhaustion() on the MSC_ConnHdlr? Sort of like the hack I have in f_tc_ho_into_this_bsc()? " /* Hack: the proper way would be to wait for the BSSMAP Handover Request ACK and extract the * actual assigned chan_nr from its L3 (RR Handover Command) message. But osmo-bsc starts acting * on the lchan even before we get a chance to evaluate the BSSMAP Handover Request ACK. So we * need to assume that osmo-bsc will activate TS 1 and already set up this lchan's RSL emulation * before we get started. */ var RslChannelNr new_chan_nr := valueof(t_RslChanNr0(1, RSL_CHAN_NR_Bm_ACCH)); f_rslem_register(0, new_chan_nr); g_chan_nr := new_chan_nr; f_sleep(1.0); " I wish it were easier...? ~N [1] 21:36:03.008009 mtc BSC_Tests.ttcn:1552 XXXXX { vc_M3UA := VirtMSC-M3UA(4), vc_IPA := , vc_WAIT := , vc_SCCP := VirtMSC-SCCP(3), sccp_pars := { sio := { ni := '10'B, prio := '00'B, si := '0011'B }, opc := 185, dpc := 187, sls := 0, sccp_serviceType := "mtp3_itu", ssn := 254 }, sccp_addr_own := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111001'B, subsystemNumber := 254, globalTitle := omit }, sccp_addr_peer := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111011'B, subsystemNumber := 254, globalTitle := omit }, vc_BSSMAP := } -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Nov 9 00:07:33 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Nov 2018 01:07:33 +0100 Subject: handover request In-Reply-To: <97e3d820-bf79-f471-e5ce-98a10eab9cd1@sysmocom.de> References: <97e3d820-bf79-f471-e5ce-98a10eab9cd1@sysmocom.de> Message-ID: <20181109000732.GB12427@my.box> On Thu, Nov 08, 2018 at 05:50:15PM +0100, Max wrote: > Hi. > > I've noticed that we don't have any code (besides basic definition) for > handover request message (BSS_MAP_MSG_HANDOVER_RQST) from 48.008 3.2.1.8 in > libosmocore or osmo-*sc. > > Is it because it's in some patch hanging somewhere in gerrit or we don't > need it (yet)? We have a BSSMAP Handover *Required*, which is what osmo-bsc sends to the MSC to initiate inter-BSC handover. The MSC then composes the Handover Request message sent to the new BSC, and since osmo-msc doesn't support inter-BSC ho yet (I will soon implement it), we indeed have no encoding or use of that message in Osmocom yet. See https://www.eventhelix.com/RealtimeMantra/Telecom/GSM_Handover_Call_Flow.pdf When testing osmo-bsc, I relied on a third-party MSC to send this message. Also ttcn3-bsc-tests encode it when emulating the MSC part of inter-BSC handover, but that's from ttcn3, not from libosmocore. I'm curious, why would you need this message? You're not writing the MSC part of inter-BSC HO, are you? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Fri Nov 9 09:01:11 2018 From: msuraev at sysmocom.de (Max) Date: Fri, 9 Nov 2018 10:01:11 +0100 Subject: handover request In-Reply-To: <20181109000732.GB12427@my.box> References: <97e3d820-bf79-f471-e5ce-98a10eab9cd1@sysmocom.de> <20181109000732.GB12427@my.box> Message-ID: <6c469ade-450a-191c-0f5b-633a288af618@sysmocom.de> Hi. Thanks for detailed write-up. 09.11.18 01:07, Neels Hofmeyr ?????: > > I'm curious, why would you need this message? You're not writing the MSC part > of inter-BSC HO, are you? I'm working on LCLS which have to work properly in case of handover as well. Handover request is one of the messages which have LCLS-specific fields so it peeked my curiosity :) -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From admin at manateeshome.com Sun Nov 11 06:00:50 2018 From: admin at manateeshome.com (Pierre Kim) Date: Sun, 11 Nov 2018 15:00:50 +0900 Subject: GSN Error Indication behavior Message-ID: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> After some debugging I found that the intermittent data loss was caused by the GSN not properly reacting to Error Indication packets. >From GGSN: <0002> ggsn.c:809 PDP(450091417013617:5): Packet received on APN(internet): forwarding to tun apn0 <000d> gtp.c:2681 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 40 8e 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> pdp.c:255 Begin pdp_tiddel tid = 5716310714190054 <000d> pdp.c:262 End pdp_tiddel: PDP found When the GGSN receives an error indication, isnt' it supposed to acknowlege the SGSN and attempt to reinitialize the connection? In my case the GGSN simply deleted the PDP context locally and both SGSN and GGSN gets flooded by unknown PDP context error, while the phone keeps trying to transmit data. Tested on lastest git version and lastest release version: osmo-sgsn 1.3.0, osmo-ggsn 1.2.1 Regards, Pierre From pespin at sysmocom.de Mon Nov 12 09:34:28 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 12 Nov 2018 10:34:28 +0100 Subject: GSN Error Indication behavior In-Reply-To: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> References: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> Message-ID: Hi, please open a ticket in redmine with: * information about osmocom versions used (and commit hash if you are not running a release). * Explanation about what you see * Expected behavior (if possible linked to some spec section) * pcap trace of what you see IIRC it's good behavior to drop the connections when you receive an Error Indication with the reset counter incremented. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Nov 12 09:34:44 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 12 Nov 2018 10:34:44 +0100 Subject: GSN Error Indication behavior In-Reply-To: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> References: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> Message-ID: <7666ac3b-b85a-7b15-e608-2e209321642d@sysmocom.de> Hi! Thanks for your feedback. Seems like a bug indeed. Could you please make a ticket via https://osmocom.org/projects/openggsn/issues/new (registration sould be quick and easy if you don't have one yet). Would be great if you could share more details in the ticket as well: - your configs - how to trigger this error indication reliably - any spec. reference for proper behavior - whatever else you think is relevant 11.11.18 07:00, Pierre Kim ?????: > After some debugging I found that the intermittent data loss was caused > by the GSN not properly reacting to Error Indication packets. > > From GGSN: > > <0002> ggsn.c:809 PDP(450091417013617:5): Packet received on > APN(internet): forwarding to tun apn0 > <000d> gtp.c:2681 Packet from 192.168.27.49:2152, length: 24 content: 32 > 1a 00 10 00 00 00 00 40 8e 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : > Received Error Indication > <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context > <000d> pdp.c:255 Begin pdp_tiddel tid = 5716310714190054 > <000d> pdp.c:262 End pdp_tiddel: PDP found > > > When the GGSN receives an error indication, isnt' it supposed to > acknowlege the SGSN and attempt to reinitialize the connection? In my > case the GGSN simply deleted the PDP context locally and both SGSN and > GGSN gets flooded by unknown PDP context error, while the phone keeps > trying to transmit data. > > Tested on lastest git version and lastest release version: osmo-sgsn > 1.3.0, osmo-ggsn 1.2.1 > > > Regards, > > Pierre > > -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From keith at rhizomatica.org Mon Nov 12 11:21:56 2018 From: keith at rhizomatica.org (Keith) Date: Mon, 12 Nov 2018 12:21:56 +0100 Subject: SMS: UCS-2 concatenation with UTF16 emoticons Message-ID: Hi all, I noticed that SMS with emoticons on the boundary of the concatenated segments are not displaying correctly on the destination handset. * - imagine the disaster when that kiss-blowing smiley face thing at the end of your SMS turns out as a diamond with a ? for the recpipient! OMG, the potential butterfly effect is too much to think about... :))? So... This is my analysis: We have 140 bytes for the message, less the 6 bytes for the user header data in the case of concatenated SMS , leaving 134 bytes. It's well know that this means 67 characters per segment for an SMS using UCS-2 encoding. But, it we fill the message with emoticons that are using 4 bytes per 'character', then we have space for 134/4 = 33 and a half. Ooops. Still, the destination handset should reassemble the message and stick the two "halves" of the emoticon together, right? - except I'm not observing this. To rule out us doing something wrong in osmo, I wonder might somebody else (who has an unlimited SMS package) from a commercial provider try sending some crafted SM from one emoji-enabled phone to another, something like this: ?abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123?56789 That's likely going to get mangled by mailing list or your mua, so it is: [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[4 byte emoji]56789 You could also try various messages filled with emojis. Of course, if you bring up your osmo network with SMPP-mirror you can watch the trace in wireshark, you'll see when the last emoji gets chopped in two. You could try the same message on osmo and your commerical network. If it's actually a problem of the phones, you should get [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[two diamonds with ?]56789 Thanks! Keith. From msuraev at sysmocom.de Mon Nov 12 14:04:21 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 12 Nov 2018 15:04:21 +0100 Subject: GSN Error Indication behavior In-Reply-To: References: <616babdc-55ca-029f-f6d2-2fd9ff27d8da@manateeshome.com> Message-ID: <459772ce-7d4d-af33-c080-4efe0f7fb95c@sysmocom.de> Lol, what a synchronicity we got :-D 12.11.18 10:34, Pau Espin Pedrol ?????: > Hi, > > please open a ticket in redmine with: > * information about osmocom versions used (and commit hash if you are > not running a release). > * Explanation about what you see > * Expected behavior (if possible linked to some spec section) > * pcap trace of what you see > > IIRC it's good behavior to drop the connections when you receive an > Error Indication with the reset counter incremented. > > -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From mykola at kingmuffin.com Mon Nov 12 15:25:06 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Mon, 12 Nov 2018 17:25:06 +0200 Subject: Femto Access Point provisioning for Osmocom/Sysmocom Message-ID: Hello, dear Osmocom Community and Sysmocom Team! We are trying out Osmocom software (3G only) to replace the proprietary software that we are using now. And we like it very much :) Our femtocells were provisioned with the same proprietary software we used but now we have to do that ourselves when using Osmocom software. We have come up with a solution which we wish to share with you and hope it will come in handy. Also, I am curious about how you handle it. How do you provision femtocells you have? We've found this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G But we were unable to follow the procedures described there as they are outdated (to be precise, they are for outdated firmware). We use ip.access nano3g femtocells (S8 and S16) which are provisioned by means of CWMP server (also called ACS - auto configuration server). (more info: https://en.wikipedia.org/wiki/TR-069) The network configuration and an address of ACS for a femtocell to use are configured through the web page after a factory reset of a femtocell. We looked at FreeACS at first (https://github.com/freeacs/freeacs). It looked quite dead half year ago, but it seems that it is being revived. Then we looked at GenieACS (https://github.com/genieacs/genieacs) and managed to make it provision the femtocell. I did get all CWMP params from the femtocell first by sending appropriate CWMP messages (getParameterNames, getParameterValues) to the FAP from the ACS and recording traffic with tcpdump. From the information I got, I made a configuration file where I changed some parameters like PLMNID or NTP server addresses to desired values. Then I wrote a script which read the configuration file and set the params of the femtocell using functions provided by GenieACS. I configured the GenieACS to execute the script when getting a request from femtocell. The sample configuration file and sample scripts are described in a document-reminder I wrote for myself: https://gist.github.com/efistokl/b95538772e54e5edb7765021c2b5a745#22-configuring-genieacs-to-use-a-specific-configuration-file I didn't make it use different configurations for different femtocells yet. I just made it to allow me to work with Osmocom software and my femtocell. I wish to improve the usability of this by writing some cli program to make the configuration process of the femtocell more automated as we will need to provision multiple femtocells connected to a single Osmocom system and a single ACS later. (or change the ACS choice completely) Thank You for creating and maintaining such a cool software! Kind regards, Mykola Shchetinin P.S. Does anybody have experience using some other ACS/CWMP solution? Could you share it? From nhofmeyr at sysmocom.de Mon Nov 12 15:54:52 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Nov 2018 16:54:52 +0100 Subject: SMS: UCS-2 concatenation with UTF16 emoticons In-Reply-To: References: Message-ID: <20181112155452.GA9896@my.box> With my commercial operator: Tried to compose an SMS with emojis but my current SMS app doesn't seem to support them (FP2 Open). I guess I could set signal as my SMS app... I sent myself 40 emoticons and at least signal displays them correctly. Then I sent 40 and quickly changed the default SMS app back to the stock Messaging thing to receive the SMS there, and it also shows all 40 intact. Notably displayed as emoticons, apparently it does support them after all. ~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 Nov 12 16:08:30 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Nov 2018 17:08:30 +0100 Subject: Femto Access Point provisioning for Osmocom/Sysmocom In-Reply-To: References: Message-ID: <20181112160830.GB9896@my.box> On Mon, Nov 12, 2018 at 05:25:06PM +0200, Mykola Shchetinin wrote: > Hello, dear Osmocom Community and Sysmocom Team! > > We are trying out Osmocom software (3G only) to replace the proprietary > software that we are using now. And we like it very much :) Hi Mykola, thanks for your excellent feedback! With current attention of users still pretty firmly on 2G, it's great to also see an enquiry for the 3G stack. The topic of femto cell provisioning is not so trivial. IIUC we have pretty much found one firmware that we are able to open up so that it talks to us. But that's all I can say: I personally am not so familiar with the firmware specifics nor ACS, but since I know that certain people that are more familiar are currently very busy, I at least wanted to reply to your mail, even though I can't say anything useful. AFAICT you're striking a very interesting chord there, and I'm certain that we (the community) will get in touch soon! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ruben.undheim at gmail.com Mon Nov 12 21:35:28 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Mon, 12 Nov 2018 22:35:28 +0100 Subject: Failing test cases (and builds) on other architectures in Debian Message-ID: Hi, Most of the openbsc packages are now up-to-date in Debian! : https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org , but there are a few failing builds on some officially supported Debian architectures (mostly failing test suites): osmo-bsc: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1-1&stamp=1542052520&raw=0) ("gsm0408" and many "handover" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=s390x&ver=1.2.1-1&stamp=1542050980&raw=0) ("gsm0408" and many "handover" tests failing) osmo-iuh: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=mips&ver=0.3.0-4&stamp=1541467766&raw=0) ("helpers" and "ranap" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=s390x&ver=0.3.0-4&stamp=1541462970&raw=0) ("helpers" and "ranap" tests failing) osmo-msc: - mips64el (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mips64el&ver=1.2.0-2&stamp=1541485859&raw=0) ("msc_vlr_test_gsm_ciph" test failing) - mipsel (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mipsel&ver=1.2.0-2&stamp=1541523664&raw=0) ("msc_vlr_test_gsm_ciph" test failing) osmo-pcu: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=mips&ver=0.5.1-1&stamp=1541542424&raw=0) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=s390x&ver=0.5.1-1&stamp=1541540930&raw=0) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") Maybe some of you can immediately see what is wrong, and what needs to be fixed? Best regards Ruben From admin at manateeshome.com Fri Nov 9 05:11:02 2018 From: admin at manateeshome.com (Pierre Kim) Date: Fri, 9 Nov 2018 14:11:02 +0900 Subject: 3G data connection loss Message-ID: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> Hello, I've set up a mini 3G RAN with yesterday's git repo. The phone works fine and successfully creates a PDP context, but data only works for a few minutes before it stops. Logs from SGSN and GGSN are as follows. Any help will be appreciated. >From SGSN: <000e> sgsn_libgtp.c:175 PDP(450091417013617/0) Create PDP Context <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6) <0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6)<0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 95 content: 32 ff 00 57 00 00 00 05 11 b4 00 00 45 00 00 53 ad fc 40 00 38 06 7b 5c 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c a6 c2 6b 46 39 80 18 01 fc 05 54 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 15 03 03 00 1a 6e ec c9 35 4b a9 48 c5 23 b0 fa 35 a5 d6 e7 e5 5b 95 f0 38 45 0a cf c8 97 d1 : Unknown PDP context, GTPv1 <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 64 content: 32 ff 00 38 00 00 00 05 11 b5 00 00 45 00 00 34 ad fd 40 00 38 06 7b 7a 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c c5 c2 6b 46 39 80 11 01 fc dd ce 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 : Unknown PDP context, GTPv1 GGSN <0002> ggsn.c:735 PDP(450091417013617:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=192.168.100.2, IPv6=none <000d> gtp.c:2761 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b4 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> gtp.c:2755 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b5 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Unknown PDP context <000d> gtp.c:2117 Packet from 192.168.27.49:2123, length: 52 content: 32 12 00 2c 00 00 00 01 4c 0a 00 00 0e 13 10 00 00 00 05 14 05 85 00 04 c0 a8 1b 31 85 00 04 c0 a8 1b 2a 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Unknown PDP context: 1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 00 00 00 45 00 00 3c 6f 51 40 00 40 06 08 fb c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff ce 3c 00 00 02 04 05 b4 04 02 08 0a ff ff c7 58 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 01 00 00 45 00 00 3c 6f 52 40 00 40 06 08 fa c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cd 42 00 00 02 04 05 b4 04 02 08 0a ff ff c8 52 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 02 00 00 45 00 00 3c 6f 53 40 00 40 06 08 f9 c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cb 4d 00 00 02 04 05 b4 04 02 08 0a ff ff ca 47 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 From pespin at sysmocom.de Tue Nov 13 14:49:47 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 13 Nov 2018 15:49:47 +0100 Subject: 3G data connection loss In-Reply-To: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> Message-ID: <132dc509-7842-66e6-9a0e-288e3b6c6f52@sysmocom.de> Hi, usually it's better if you open a redmine ticket with more information: - releases you are using of each related component - pcap trace taken while the issue appear -- - 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 stsp at stsp.name Tue Nov 13 15:43:50 2018 From: stsp at stsp.name (Stefan Sperling) Date: Tue, 13 Nov 2018 16:43:50 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) Message-ID: <20181113154350.GA11128@fintan.stsp.name> There has been some face-to-face discussion about Osmocom's code review process within sysmocom recently. I am posting to this list now with the consent of everyone involved so far, in order to involve the Osmocom community at large in this discussion as well. There has been a lack of code review from people who don't have "+2" super powers in Gerrit. This applies to anyone among us, independently of any individual's relationship with sysmocom. The bulk of the work involved in reviewing code falls on Harald's shoulders, with Pau and Neels sharing most of the rest between themselves. At present, while people who add a +1 have their voices heard, their input does not formally affect the decision to merge a change. A change still has to pass by the pre-selected +2 gatekeepers in order to be merged, no matter how many other people have provided input. The implication for developers without +2 powers is that their time is more effectively spent on advancing their own changes towards a +2 vote, rather than spending time on whatever else is waiting in Gerrit. This may not apply to everyone, of course. But at least for me, this is certainly the case; I have only been reviewing other people's patches when I was explicitly asked to do so. Myself and several other developers hope that with a change to our review process we can fix this inertia, spread code review across more shoulders and encourage more collaborative code review in Osmocom. The basic idea is that everyone's input should count for something. If those among us with +1 powers were given a partial say on the fate of every change, our decisions will carry more weight and our influence within the project will slightly increase. We'd also be encouraged to step out of our own corners of expertise every now and then, and look at what other developers are working on. On the flip side, this means we'd carry more responsibility than we do now. We wouldn't always be relying on our +2 gate keepers and would have to apply our own judgement more carefully. The concrete proposal is to make votes in Gerrit accumulative. Each change would require a total score of +3 to be merged. This score can consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes. Also, +2 developers would keep their ability to unilaterally block or revert changes under this new model. They'd keep their existing role as arbiters in case of disputes. Max figured out how Gerrit could be configured for this behaviour. It involves Prolog code, but since we're all quite smart we should be able to figure that out, right? https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_example_13_1_1_2_code_review We'd be interested to hear what the community thinks about this proposal. Thanks, Stefan From pespin at sysmocom.de Tue Nov 13 16:08:49 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 13 Nov 2018 17:08:49 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> Hi, I agree with implementing this kind of change, I really like the idea of getting more people into reviewing and their vote counting so there's no need for somebody with +2 to merge it. The only drawback I see is the fact that if +3 is needed, then a +2 from some people is now not enough, which can be a pity for patches that can be merged quickly (cosmetic, logging, etc.) or important fixes which require quick merge. Also, for some repos most people don't care bout or don't have much knowledge about it, for instance the case os myself and osmo-gsm-tester, where I usually +2 my patches right away or after leaving them under review for a few hours/days. This would block my development or fix of setup-related issues. So good for me, but we need to resolve this kind of details in the proposal beforehand. > It involves Prolog code, but since we're all quite smart we should be able > to figure that out, right? From creators of joke "how many developers are required to change a bulb", we now get "How many developers are required to write a prolog program than sums three numbers?" -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Tue Nov 13 17:16:02 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Nov 2018 18:16:02 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> Message-ID: <20181113171602.GA20444@my.box> > "How many developers are required to write a prolog program than sums three > numbers?" Answer: none, they are responsible community members. This works pretty well at subversion.apache.org, where everyone who is accepted as committer (often happens like after the first five patches or so) can directly commit to trunk and wreak havoc if they were so inclined, but since you don't want to stir up the community against you nor want your patches reverted, you adhere to the votes of the others on the ML. I think just giving +2 permissions to "everyone" is the easiest and socially most beautiful solution: rely on social policy rather than enforcing UI. That would mean in practice: everyone that is considered a reviewer automatically gets permission to cast +2 votes, and we simply ask everyone to adhere to otiquette ("Osmocom etiquette"), to only give +2 when, say, two others have already cast a +1. If there are any mistakes happening because of that, we can always revert; we can look in gerrit who cast the vote and come back at this person and complain. This also implies that if someone is absolutely sure, she can +2 directly, things get merged and since it is obviously correct, no-one will come back and complain about it. This way would not require an add-up plugin and wouldn't introduce gerrit upgrade problems or prolog error message parsing difficulties or whatnot. Everyone would have the power to fast-track important or trivial patches without bothering anyone else or blocking own work. And everyone will in awe refrain from abusing these powers. If one of the community gurus is convinced, they can still issue immediate +2. If no guru shows up, two or three others can still legitimately reach a +2. Or even, if >=3 reviewers cast a +1, the original poster sees that and decides "that's sufficient" and casts +2 herself to merge. A minor drawback I see is in the UI: I usually want to quickly see in the overview what patches make sense to take a closer look at now. But even if 10 people cast a +1, the gerrit UI will only show a "+1" in the overview. Also, if one of those is a -1, I think it still shows "+1". So I would welcome listing all the individual votes in the overview list, like "-1,+1x10" -- not sure if that makes sense to implement in a plugin, probably not. Part of this problem goes away when a reviewer casts +2, then the overview will show "+2". But we still lose the "-1" part. A workaround is to always click and open every individual issue... that then shows each single vote of course. I think this minor drawback will still exist if we add up votes: not seeing -1s immediately. A similar problem I have, independently from above, is that in the overview it is not visible whether my issue had a comment or not. It goes like this: I review a patch, and have a question / remark / tweak. Then I don't really want to vote -1, because that sounds so negative. I don't want to discourage, I rather want to be interested and get a reply. So then I just comment. But on the list of patches, nothing indicates that there is a comment; maybe someone else has voted +2, and the patch gets merged from some other later patch ("Submit including parents") without the comment being seen. Also, if someone cast +2 (or if we add up, when sufficient votes are in), then I still cannot see that there is a -1 and might merge the patch without noticing the question. The only solution now is to click on each individual patch and check one by one whether there are remarks; or to read every single gerrit mail, which I don't do anymore. That's why I prefer that if someone asks even a trivial question on my patch, to please mark -1. Instead, I would love to have some +0 or some '?' indicator in the overview list of patches. One workaround so far was to just issue a +1, which says "yeah, looks ok, but you can't just merge including-all-parents yet, first think about my question on the third patch down". If we add up votes, that would not work anymore, because that +1 already means that I would merge this. Not sure if there is an easy solution. In summary, I would give all "known users" +2 powers and have an otiquette; Otherwise I'd be ok with trying the add-up plugin. In all cases I will still have cumbersome issues with the gerrit UI and will have to open each patch individually. ~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 Wed Nov 14 13:05:44 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Nov 2018 14:05:44 +0100 Subject: 3G data connection loss In-Reply-To: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> Message-ID: <20181114130544.GB17000@my.box> On Fri, Nov 09, 2018 at 02:11:02PM +0900, Pierre Kim wrote: > The phone works fine and successfully creates a PDP context, but data > only works for a few minutes before it stops. If you go to flight mode and back, does data continue? If you wait two minutes and try again, does it work again? I have often seen odd data unreliabilities on 3G, AFAIK it's still an issue which hasn't been resolved yet. I think at some point we had (or still have) an error in a flag indicating whether we're re-using an auth key or using a new one, not sure if that's resolved yet. If it's not that, it should be some obscure protocol corner case that we need to find and fix, once identified it should be quick to solve. The issue I created back in the days was https://osmocom.org/issues/1977 -- not sure if it applies to your situation. That report is notoriously under-informative... Apologies for my past self. It would be excellent if someone familiar with the inner workings of the SGSN could investigate and pinpoint what is going wrong sporadically on 3G. Also recently there was http://lists.osmocom.org/pipermail/openbsc/2018-November/012362.html Oh wait, that was you, as well! BTW, technically the right ML for PS issues would be osmocom-net-gprs (but I personally don't mind it being discussed 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 admin at manateeshome.com Wed Nov 14 13:19:03 2018 From: admin at manateeshome.com (Pierre Kim) Date: Wed, 14 Nov 2018 22:19:03 +0900 Subject: 3G data connection loss In-Reply-To: <20181114130544.GB17000@my.box> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> <20181114130544.GB17000@my.box> Message-ID: <354f193c-6f22-f435-0737-3a0ba2798714@manateeshome.com> > If you go to flight mode and back, does data continue? > If you wait two minutes and try again, does it work again? Switching to flight mode itself doesn't help, I guess I have to wait two minutes until the SGSN finds out about the missing PDP context and tries to reopen the connection. > Also recently there was > http://lists.osmocom.org/pipermail/openbsc/2018-November/012362.html > Oh wait, that was you, as well! Yeah thats me, I ended up creating two separate threads because one got held in the moderation queue for a few days. Sorry for that. One interesting thing that I discovered is that if I just patch the GGSN to ignore all Error Indication packets(not deleting the PDP context), data works surprisingly well. Still there are some quirks but it becomes very reliable. That makes me wonder if those Error Indications are even needed in the first place. One could look into the cause of Error Indication from the SGSN. Regards, Pierre -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1765 bytes Desc: not available URL: From msuraev at sysmocom.de Wed Nov 14 14:04:03 2018 From: msuraev at sysmocom.de (Max) Date: Wed, 14 Nov 2018 15:04:03 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> Hi. I really like this idea: merging at +3 seems like a nice balance between not letting code go into master unchecked and having all the reviews by few people only. If some patch really got to be merged ASAP than I don't think it would be that hard to get extra +1 necessary: just ask at #osmocom :) I think giving everybody ability to +2 patches and merge them right away defeats the very purpose of having code review system in a first place - we could just merge to master directly in this case. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From nhofmeyr at sysmocom.de Wed Nov 14 14:05:41 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Nov 2018 15:05:41 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <20181114140541.GC17000@my.box> Hi Ruben, > Most of the openbsc packages are now up-to-date in Debian! : > https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org Nice! I'd like to mention a detail, recently I tried to build osmo-iuh on a freshly installed Debian 9 machine, and it gets a segfault in gcc. Do you hit this when building packages? Thanks! ~N On Mon, Nov 12, 2018 at 10:35:28PM +0100, Ruben Undheim wrote: > Hi, > > > , but there are a few failing builds on some officially supported > Debian architectures (mostly failing test suites): > > osmo-bsc: > - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1-1&stamp=1542052520&raw=0) > ("gsm0408" and many "handover" tests failing) I rebuilt repositories matching osmo-bsc version 1.2.1 as indicated here; was a bit hard until I disabled Werror as well as the address sanitizer. Comparing the output... Quite early up in the test, a measurement report is simulated, and on mips, it is interpreted as two neighbors, while there should be only one neighbor. Should be: - Sending measurement report from mobile #0 (rxlev=30, rxqual=6) * Neighbor cell #0, actual BTS 1 (rxlev=40) DRSL abis_rsl.c:1538 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0 DMEAS abis_rsl.c:1409 [(bts=0,trx=0,ts=1,ss=0)] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-110dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR=-22dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-80dBm RXL-SUB-dl=-80dBm RXQ-FULL-dl=6 RXQ-SUB-dl=6 NUM_NEIGH=1 DMEAS abis_rsl.c:1442 IDX=0 ARFCN=871 BSIC=63 => -70 dBm DHODEC handover_decision_2.c:1131 (lchan 0.010 TCH/F) (subscr unknown) MEASUREMENT REPORT (1 neighbors) DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 0: arfcn=871 bsic=63 neigh_idx=0 rxlev=40 flags=0 DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 871 new in report rxlev=40 last_seen_nr=0 mips gets: - Sending measurement report from mobile #0 (rxlev=30, rxqual=6) * Neighbor cell #0, actual BTS 1 (rxlev=40) DRSL abis_rsl.c:1538 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0 DMEAS abis_rsl.c:1409 [(bts=0,trx=0,ts=1,ss=0)] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-110dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR=-22dBm L1_FPC=0 L1_TA=0 DTXu NOT VALID NUM_NEIGH=2 DMEAS abis_rsl.c:1442 IDX=28 ARFCN=0 BSIC=0 => -77 dBm DMEAS abis_rsl.c:1442 IDX=0 ARFCN=871 BSIC=0 => -96 dBm DHODEC handover_decision_2.c:1131 (lchan 0.010 TCH/F) (subscr unknown) MEASUREMENT REPORT (2 neighbors) DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 0: arfcn=0 bsic=0 neigh_idx=28 rxlev=33 flags=0 DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 1: arfcn=871 bsic=0 neigh_idx=0 rxlev=14 flags=0 DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 0 new in report rxlev=33 last_seen_nr=0 DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 871 new in report rxlev=14 last_seen_nr=0 On mips the report is misinterpreted with wildly wrong values; actually starts with "DTXu NOT VALID", continues with the bsic and rxlev... I wonder why that happens. Either handover_test.c encodes it non-portably, or the decoding has a problem. handover_test.c encodes a measurement report using struct gsm48_meas_res, which has sub-byte ints. It is known that these need #ifdef shims to swap the positions for big-endian vs. little-endian, which this struct does *not* have. This mips is big endian, right? Then that would be the issue. Unfortunately I can't test on mips, is there any way that we can easily test a patch on such an arch? Also, if we fix this on current master, then that doesn't help osmo-bsc v 1.2.1 using libosmocore 0.11.0. We don't have a backporting process at Osmocom. Yet. Maybe it will just be broken until we package more recent versions? There are numerous other packed structs in libosmocore/include/osmocom/gsm/protocol/gsm_04_08.h with sub-byte ints that lack the BIG_ENDIAN shims. https://osmocom.org/issues/3693 I don't have a fix yet, let's discuss how a fix would help debian builds as asked above... And whether we really need to support big endian...? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Wed Nov 14 14:09:46 2018 From: msuraev at sysmocom.de (Max) Date: Wed, 14 Nov 2018 15:09:46 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <563aa5b5-e62a-1673-dc14-912dafbdacea@sysmocom.de> Hi. I don't think we have tested this on BE architecture yet. Could you make tickets via https://osmocom.org/projects/osmobsc/issues/new and alike for corresponding projects? At least some of those doesn't look like it could be fixed quickly. Out of curiosity - do you use real hw to run those builds or it's some sort of vm/emulator? 12.11.18 22:35, Ruben Undheim ?????: > Hi, > > Most of the openbsc packages are now up-to-date in Debian! : > https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org > > , but there are a few failing builds on some officially supported > Debian architectures (mostly failing test suites): > > osmo-bsc: > - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1-1&stamp=1542052520&raw=0) > ("gsm0408" and many "handover" tests failing) > - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=s390x&ver=1.2.1-1&stamp=1542050980&raw=0) > ("gsm0408" and many "handover" tests failing) > > osmo-iuh: > - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=mips&ver=0.3.0-4&stamp=1541467766&raw=0) > ("helpers" and "ranap" tests failing) > - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=s390x&ver=0.3.0-4&stamp=1541462970&raw=0) > ("helpers" and "ranap" tests failing) > > osmo-msc: > - mips64el (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mips64el&ver=1.2.0-2&stamp=1541485859&raw=0) > ("msc_vlr_test_gsm_ciph" test failing) > - mipsel (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mipsel&ver=1.2.0-2&stamp=1541523664&raw=0) > ("msc_vlr_test_gsm_ciph" test failing) > > osmo-pcu: > - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=mips&ver=0.5.1-1&stamp=1541542424&raw=0) > (error: #error "Only little endian headers are supported yet. > TODO: add missing structs") > - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=s390x&ver=0.5.1-1&stamp=1541540930&raw=0) > (error: #error "Only little endian headers are supported yet. > TODO: add missing structs") > > Maybe some of you can immediately see what is wrong, and what needs to be fixed? > > Best regards > Ruben -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From msuraev at sysmocom.de Wed Nov 14 14:36:56 2018 From: msuraev at sysmocom.de (Max) Date: Wed, 14 Nov 2018 15:36:56 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <5b370c9d-ce96-2f71-0622-ac14ecc0b755@sysmocom.de> Hi. On a related note: I see several patches from Debian devs - for example https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/ Are there any plans to get those upstreamed? -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From pespin at sysmocom.de Wed Nov 14 14:46:17 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 14 Nov 2018 15:46:17 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <563aa5b5-e62a-1673-dc14-912dafbdacea@sysmocom.de> References: <563aa5b5-e62a-1673-dc14-912dafbdacea@sysmocom.de> Message-ID: <2998b5ee-17ba-d870-3a83-13cff2658371@sysmocom.de> Hi, The best solution would be to build for MIPS or any other Big Endian architecture in our OBS server, so we can catch this kind of issues during nightly build. Unfortunately, as far as I can see, there's no MIPS architecture support in https://build.opensuse.org. -- - 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 Wed Nov 14 14:48:00 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 14 Nov 2018 15:48:00 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: Hi, as a side note, we are planning to make a new release of most components soon, since there's been lot of fixes and new features since last release, just letting you know. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From keith at rhizomatica.org Wed Nov 14 15:08:15 2018 From: keith at rhizomatica.org (Keith) Date: Wed, 14 Nov 2018 16:08:15 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113171602.GA20444@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> <20181113171602.GA20444@my.box> Message-ID: I like what Neels is saying; * It doesn't look like a technical problem to me, so it probably does not have a technical solution - no change to gerrit required. I'd put it like this: 1) Everyone, please review more code. (and comment, and +/-1) 2) Code pushers, take a moment to comment your own commits, if it might help other code reviewers. 3) +2er people, take a look at who is doing a lot of code review and consider reaching out to them to invite them to take on +2er responsibility. k. From stsp at stsp.name Wed Nov 14 15:16:49 2018 From: stsp at stsp.name (Stefan Sperling) Date: Wed, 14 Nov 2018 16:16:49 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> Message-ID: <20181114151649.GB44110@ted.stsp.name> On Wed, Nov 14, 2018 at 03:04:03PM +0100, Max wrote: > Hi. > > I really like this idea: merging at +3 seems like a nice balance between not > letting code go into master unchecked and having all the reviews by few > people only. > > If some patch really got to be merged ASAP than I don't think it would be > that hard to get extra +1 necessary: just ask at #osmocom :) > > I think giving everybody ability to +2 patches and merge them right away > defeats the very purpose of having code review system in a first place - we > could just merge to master directly in this case. I fully agree with Max. A transition to "everyone has +2" would be a far more drastic change than what I was proposing. I believe this would result in less code review being done than is being done today. The goal is to get more code review done, not less of it. Requiring +2 voters to also obtain a +1 is part of this idea because it encourages +1 voters to add their votes to changes which already have a +2, whereas today +1 voters tend to ignore changes other than their own. From ruben.undheim at gmail.com Wed Nov 14 18:06:22 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Wed, 14 Nov 2018 19:06:22 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: Hi, > I'd like to mention a detail, recently I tried to build osmo-iuh on a freshly > installed Debian 9 machine, and it gets a segfault in gcc. Do you hit this when > building packages? segfault in gcc really!? I have not seen it, but I have only built it in Debian 10. > This mips is big endian, right? Then that would be the issue. Yes, it is probably the main issue. Assuming big-endianness is the problem for all failures on mips and s390x, we are left with the failures for osmo-msc on mips64el and mipsel (the low-endian variants of mips). So the test "msc_vlr_test_gsm_ciph" is failing. Does this tell you anything? > Also, if we fix this on current master, then that doesn't help osmo-bsc v 1.2.1 > using libosmocore 0.11.0. We don't have a backporting process at Osmocom. Yet. > Maybe it will just be broken until we package more recent versions? This is unproblematic in the Debian context. As long as we know what the fix is, we can backport the fix wherever we want. Maybe the trick is to just start going over all structs in libosmocore and upwards, and see if the problem disappears on big-endian architectures. I can start on it, when I find some time for it. > And whether we really need to support big endian...? Well, nobody has to support big-endian. But building on other archs is a nice test for robustness of the code and the test suite. :) > Unfortunately I can't test on mips, is there any way that we can easily test a > patch on such an arch? If you do not have real hardware or any machines to login to, I think your best option is to try qemu. It should have pretty good support for these things, although it is not as fast as real hardware. > Out of curiosity - do you use real hw to run those builds or it's some > sort of vm/emulator? These are the official Debian build machines, and am pretty sure it is real hw. There are Debian porter boxes I can SSH into also to test on real hardware. > On a related note: I see several patches from Debian devs - for example > https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/ Interesting. I did not know about this way of viewing the patches, although I am behind most of the patches. Please just pull back whatever you find useful. Best regards Ruben From nhofmeyr at sysmocom.de Wed Nov 14 19:24:01 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Nov 2018 20:24:01 +0100 Subject: 3G data connection loss In-Reply-To: <354f193c-6f22-f435-0737-3a0ba2798714@manateeshome.com> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> <20181114130544.GB17000@my.box> <354f193c-6f22-f435-0737-3a0ba2798714@manateeshome.com> Message-ID: <20181114192401.GA16956@my.box> On Wed, Nov 14, 2018 at 10:19:03PM +0900, Pierre Kim wrote: > One interesting thing that I discovered is that if I just patch the GGSN > to ignore all Error Indication packets(not deleting the PDP context), > data works surprisingly well. I think this is worth investigating indeed. Have we got a redmine issue on it yet? I guess those would be two: a) find out the source of SGSN errors and b) be more tolerant of errors in the GGSN. Possibly b) becomes obsolete when a) is resolved, or maybe b) is even harmful when errors should have implied the end of a PDP context. For a), it would be super interesting to get a pcap / log snippets of the actual error indications attached to the redmine issue. ~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 Wed Nov 14 19:44:59 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Nov 2018 20:44:59 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181114151649.GB44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> Message-ID: <20181114194459.GB16956@my.box> On Wed, Nov 14, 2018 at 04:16:49PM +0100, Stefan Sperling wrote: > A transition to "everyone has +2" would be a far more drastic change > than what I was proposing. I believe this would result in less code > review being done than is being done today. In general, the fact that you can do +2 doesn't mean that you're allowed to do it. The normal case would be: the third reviewer coming along sees that there are already two +1s and then is allowed to vote a +2, by convention / trust. I would like to adopt the +3 scheme, only I think we don't necessarily need IU enforcement of it by an obscure plugin, because we can agree on it between us humans. Whenever someone disregards "+3", that is a potential offense. I could trivially enable +2 within minutes right now. No prolog required, only communication. If that doesn't work out, we can still go for the plugin or revert +2 abilities. What do you think? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ruben.undheim at gmail.com Wed Nov 14 19:49:57 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Wed, 14 Nov 2018 20:49:57 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: > Maybe the trick is to just start going over all structs in libosmocore > and upwards, and see if the problem disappears on big-endian > architectures. I can start on it, when I find some time for it. I've started here: https://salsa.debian.org/debian-mobcom-team/libosmocore/blob/master/debian/patches/0005-Structs-for-big-endian.patch (to prevent duplicated work) Ruben From stsp at stsp.name Thu Nov 15 12:15:48 2018 From: stsp at stsp.name (Stefan Sperling) Date: Thu, 15 Nov 2018 13:15:48 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181114194459.GB16956@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> Message-ID: <20181115121548.GG44110@ted.stsp.name> On Wed, Nov 14, 2018 at 08:44:59PM +0100, Neels Hofmeyr wrote: > On Wed, Nov 14, 2018 at 04:16:49PM +0100, Stefan Sperling wrote: > > A transition to "everyone has +2" would be a far more drastic change > > than what I was proposing. I believe this would result in less code > > review being done than is being done today. > > In general, the fact that you can do +2 doesn't mean that you're allowed to do > it. The normal case would be: the third reviewer coming along sees that there > are already two +1s and then is allowed to vote a +2, by convention / trust. > > I would like to adopt the +3 scheme, only I think we don't necessarily need IU > enforcement of it by an obscure plugin, because we can agree on it between us > humans. Whenever someone disregards "+3", that is a potential offense. > > I could trivially enable +2 within minutes right now. No prolog required, only > communication. If that doesn't work out, we can still go for the plugin or > revert +2 abilities. What do you think? > > ~N I believe that if we're going to use tooling to support a process, then our tooling should be configured to support the process we want. If our tooling is not or cannot be configured as such, we might as well use different tooling. Social conventions will work but only with continuous effort. Try to think of this as somebody who is looking at Osmocom from the outside without any prior knowledge or involvement, and tries to figure out how we work. The easier it is for that person to figure out answers, the better. If gerrit does something else than our process says it should, then gerrit makes things harder for new contributors, not easier. From nhofmeyr at sysmocom.de Thu Nov 15 14:31:11 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 15 Nov 2018 15:31:11 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115121548.GG44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> Message-ID: <20181115143111.GA3486@my.box> On Thu, Nov 15, 2018 at 01:15:48PM +0100, Stefan Sperling wrote: > I believe that if we're going to use tooling to support a process, > then our tooling should be configured to support the process we want. My point is that this tooling supports our process, no pressing need to enforce it to the last detail. > Social conventions will work but only with continuous effort. I don't think that will be a problem. There are countless conventions we enforce by social means alone. Coding style, mailing list etiquette... The effort of communicating how we merge patches will be far less frequent than telling people to not send screenshots of text output to the mailing list, it doesn't happen that often that new patch submitters come along. > The easier it is for that person to figure out answers, the better. Sure, but trying out this scheme without the need to "hack" gerrit is convenient. > If gerrit does something else than our process says it should, > then gerrit makes things harder for new contributors, not easier. If that's really necessary, new people could still get only +1 permissions and everyone that knows what's cooking can get +2? Say, after the fifth patch you get elevated from "known user" to "reviewer" and receive +2 permission. So, my opinion still is we try it with gerrit as it is: - vote with +1. - if there are three +1s, the patch owner may apply +2 and merge. - try this, if it doesn't work consider the plugin. If someone wants to spend effort on installing that plugin, I would be fine with that. I will not be that person because IMHO we don't need it. For me it's quite trivial. I think my opinion is clear now and I will refrain from rephrasing it again. If you agree please say so, so that I can configure gerrit +2 permissions. If you disagree, as far as I'm concerned someone go on and install that plugin. Otherwise we have stalemate and will keep the current scheme. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pespin at sysmocom.de Thu Nov 15 14:39:36 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 15 Nov 2018 15:39:36 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115143111.GA3486@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <20181115143111.GA3486@my.box> Message-ID: <5ec3ce20-7a58-a25f-7019-738365a647f8@sysmocom.de> Hi, while I'd like it to be the opposite, i tend to think you cannot trust human being until they proved you can do so -> I'm against giving +2 to everybody by default. I agree with Stefan and I wouldn't go for a too drastic change, let's first move to something like the approach described initially: 3*+1 or 1*+2can merge a patch. If it makes it easier to deploy it, then also make it 3 points however combined can merge a patch (meaning nobody can merge on its own, despite I think this may affect productivity having some patches merged). 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 msuraev at sysmocom.de Thu Nov 15 14:41:14 2018 From: msuraev at sysmocom.de (Max) Date: Thu, 15 Nov 2018 15:41:14 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115121548.GG44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> Message-ID: Hi. I second this: rules have to be enforced by technical means whenever possible. Social conventions simply don't scale: if we let people just merge it arbitrary than there'll be never-ending stream of "I know I shouldn't have but..." with all sorts of "buts" (I was in a hurry, I was about to leave, I needed for X, etc). It might work fine in a close-knit group but I think the goal is to grow the number of contributions by making it as effortlessly as possible. It's always better than newcomers simply can't do the wrong thing rather than constantly reminding them what is right thing, on which wiki (which inevitably will get outdated) they can read about it etc. Also, I disagree that setting up gerrit this way is a "hack": making votes additive is described in official documentation for gerrit. It's supported by upstream - there's nothing hackish about it. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From nhofmeyr at sysmocom.de Thu Nov 15 15:23:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 15 Nov 2018 16:23:55 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <20181115152355.GB3486@my.box> On Wed, Nov 14, 2018 at 07:06:22PM +0100, Ruben Undheim wrote: > segfault in gcc really!? I have not seen it, but I have only built it > in Debian 10. yes, in osmo-iuh. > we are left with the failures for osmo-msc on mips64el and mipsel (the > low-endian variants of mips). So the test "msc_vlr_test_gsm_ciph" is failing. > Does this tell you anything? Interesting, the only difference is: -- ERROR sending ciphering mode command: rc=-95 +- ERROR sending ciphering mode command: rc=-122 i.e. a mismatching rc gets returned. It's not an error with any practical effect. Aha, could it simply be that the errno are defined differently on this platform? It should be -95 == -ENOTSUP, while we get -122. Weirdly enough, I don't see this line printed at all in my current msc_vlr_test_gsm_ciph output. Ah, I know, because A5/3 was fixed, hence we see no error anymore, since 3117b701c8d4645215896c459d6c608358a0a51b There has been no release after that yet. If you want to stay with that old revision, try branch neels/mipsel of osmo-msc, which I've just pushed, with this patch: http://git.osmocom.org/osmo-msc/commit/?h=neels/mipsel&id=d655d10e98c3909d86423c9c4ca8604f16ea61da Or otherwise wait for Pau's release and rather use those latest revisions. > As long as we know what the fix is, we can backport the fix wherever we want. sure, I forgot the deb packaged patches. > Maybe the trick is to just start going over all structs in libosmocore I thought about scripting it, because editing manually takes forever and is error prone. > Interesting. I did not know about this way of viewing the patches, > although I am behind most of the patches. Please just pull back > whatever you find useful. Ideally, the patch author goes on to submit it on gerrit.osmocom.org :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ruben.undheim at gmail.com Thu Nov 15 17:07:30 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Thu, 15 Nov 2018 18:07:30 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <20181115152355.GB3486@my.box> References: <20181115152355.GB3486@my.box> Message-ID: Hi, > -- ERROR sending ciphering mode command: rc=-95 > +- ERROR sending ciphering mode command: rc=-122 > > i.e. a mismatching rc gets returned. It's not an error with any practical > effect. > > Aha, could it simply be that the errno are defined differently on this > platform? It should be -95 == -ENOTSUP, while we get -122. I will have a look. Thanks for the hint. :D > > Interesting. I did not know about this way of viewing the patches, > > although I am behind most of the patches. Please just pull back > > whatever you find useful. > > Ideally, the patch author goes on to submit it on gerrit.osmocom.org :) Yes, ideally! I have actually done it on gerrit to you guys once before [1]. However, I am interacting with so many different upstream, and everyone has their own way of doing things. Therefore I prefer to just write an email or file an issue, and you can just pick whatever you want. Since you deal with gerrit regularly, it will be much more efficient. (I only have github and salsa in my fingers..) Many patches are not relevant for upstream either. Only when making real bug-fixes (like now for big-endian archs), it makes sense for me to spend time getting them into gerrit myself (and waste time learning how to do it again :D ). Best regards Ruben [1] http://lists.osmocom.org/pipermail/openbsc/2016-May/thread.html#9132 From keith at rhizomatica.org Thu Nov 15 17:43:20 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 15 Nov 2018 18:43:20 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> Message-ID: On 15/11/2018 15:41, Max wrote: > Hi. > > I second this: rules have to be enforced by technical means whenever > possible. wow. It's interesting this should come up right now - I've recently been spending a lot of time reading about, watching documentaries, (last night it was the Bolsheviks!!) and generally studying the whole concept of this machine controlled society we (tech people) are blindly making for ourselves. And it's certainly one in which do not want to live, nor do I want anybody else I care about to live in. As said Neels, I'll refrain from expressing my opinion again after this, so just once more; A "community" that can operate without the technical enforcement of rules will be a more healthy community. The other way will come back and bite you, eventually. > "I know I shouldn't have but..." A little more on topic: I count >30 known users on gerrit. Do we all have +1 ability? Then it wouldn't be hard to see this technical solution just create division, or at the very least consume time of those who have to be vigilantes and -1 some things in time. From stsp at stsp.name Thu Nov 15 18:03:48 2018 From: stsp at stsp.name (Stefan Sperling) Date: Thu, 15 Nov 2018 19:03:48 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115143111.GA3486@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <20181115143111.GA3486@my.box> Message-ID: <20181115180348.GJ44110@ted.stsp.name> On Thu, Nov 15, 2018 at 03:31:11PM +0100, Neels Hofmeyr wrote: > So, my opinion still is we try it with gerrit as it is: > > - vote with +1. > - if there are three +1s, the patch owner may apply +2 and merge. > - try this, if it doesn't work consider the plugin. OK, I see. When phrased like this, your suggestion doesn't sound difficult to realize. So I would be happy to try this. After all, the end result is the same as with my proposal, modulo concerns about giving everyone the power to make a 'Submit' button appear by default. And I don't have any concerns about that. From stsp at stsp.name Thu Nov 15 18:07:34 2018 From: stsp at stsp.name (Stefan Sperling) Date: Thu, 15 Nov 2018 19:07:34 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <5ec3ce20-7a58-a25f-7019-738365a647f8@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <20181115143111.GA3486@my.box> <5ec3ce20-7a58-a25f-7019-738365a647f8@sysmocom.de> Message-ID: <20181115180734.GK44110@ted.stsp.name> On Thu, Nov 15, 2018 at 03:39:36PM +0100, Pau Espin Pedrol wrote: > Hi, > > while I'd like it to be the opposite, i tend to think you cannot trust human > being until they proved you can do so -> I'm against giving +2 to everybody > by default. I don't see any cause for concern there. We have version control. Nobody can undo the main line of history. Mistakes will always be made, and can always be undone. > I agree with Stefan and I wouldn't go for a too drastic change, Indeed, I designed my proposal with minimal changes to the existing process in mind. But it seems like Neels and my own proposal aren't far apart, actually. The only difference is whether our self-enforced boundaries are enforced by technical or social means, really. From msuraev at sysmocom.de Thu Nov 15 18:07:29 2018 From: msuraev at sysmocom.de (Max) Date: Thu, 15 Nov 2018 19:07:29 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> Message-ID: <73e5600d-efde-414a-eb0e-4fa069739e02@sysmocom.de> I think there might be some misunderstanding worth clarifying in here. 15.11.18 18:43, Keith ?????: > ...and generally studying the whole concept > of this machine controlled society we (tech people) are blindly making > for ourselves. And it's certainly one in which do not want to live, nor > do I want anybody else I care about to live in. Right now the rules for merging patches are enforced by Gerrit. What Neels proposes is a model where people manually abide by those rules. I think this change is too drastic and that we should keep existing model, only changing the rules (see $subj) slightly. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From stsp at stsp.name Thu Nov 15 18:19:19 2018 From: stsp at stsp.name (Stefan Sperling) Date: Thu, 15 Nov 2018 19:19:19 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> Message-ID: <20181115181919.GL44110@ted.stsp.name> On Thu, Nov 15, 2018 at 06:43:20PM +0100, Keith wrote: > > On 15/11/2018 15:41, Max wrote: > > Hi. > > > > I second this: rules have to be enforced by technical means whenever > > possible. > > > wow. > > It's interesting this should come up right now - I've recently been > spending a lot of time reading about, watching documentaries, (last > night it was the Bolsheviks!!) and generally studying the whole concept > of this machine controlled society we (tech people) are blindly making > for ourselves. And it's certainly one in which do not want to live, nor > do I want anybody else I care about to live in. But in this case, we make up the rules ourselves. We voluntarily impose mandatory code review upon ourselves because we believe this helps us ship better software at the end of the day. Because we all make mistakes. Contrary to problems with tech in society in general, we don't impose our code review process onto people who aren't directly involved. And it's entirely up to us how far we go with enforcing our self-made rules, by technical means or otherwise. So I don't think this analogy makes sense in this particular case. > As said Neels, I'll refrain from expressing my opinion again after this, > so just once more; A "community" that can operate without the technical > enforcement of rules will be a more healthy community. The community is healthy if this discussion ends up with consensus for some particular code review process we decide to try next. We'll only get there if people keep expressing opinions, listen to each other, and compromise willingly. So please don't stop voicing your opinions. From keith at rhizomatica.org Thu Nov 15 19:08:52 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 15 Nov 2018 20:08:52 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <73e5600d-efde-414a-eb0e-4fa069739e02@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <73e5600d-efde-414a-eb0e-4fa069739e02@sysmocom.de> Message-ID: <1ed6a6c0-23e1-e767-7967-826a3c899b94@rhizomatica.org> On 15/11/2018 19:07, Max wrote: > I think there might be some misunderstanding worth clarifying in here. :) Don't take the fact I happened to reply to you to mean anything.. although, well it's some powerful language, that struck me.. today.. Stefan puts it well though, although I'm thinking the little things we do that are "just" our model for X in tech seem to be bleeding over too much into other areas of life. ?politics and code.. can't have one without the other.. and I am actually also subscribed to more suitable mailing lists for this kind of stuff.. Meanwhile, I'll endeavor to do more code review. :)) From ruben.undheim at gmail.com Thu Nov 15 20:45:38 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Thu, 15 Nov 2018 21:45:38 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <20181115152355.GB3486@my.box> References: <20181115152355.GB3486@my.box> Message-ID: > -- ERROR sending ciphering mode command: rc=-95 > +- ERROR sending ciphering mode command: rc=-122 > > i.e. a mismatching rc gets returned. It's not an error with any practical > effect. > > Aha, could it simply be that the errno are defined differently on this > platform? It should be -95 == -ENOTSUP, while we get -122. Correct guess! In /usr/include/mipsel-linux-gnu/asm/errno.h, EOPNOTSUPP is set to 122. While in /usr/include/asm-generic/errno.h (used on amd64), it is set to 95 I uploaded a fix to Debian: https://salsa.debian.org/debian-mobcom-team/osmo-msc/raw/master/debian/patches/0003-Fix-test-failure-because-of-ENOTSUP-being-different-.patch Ruben From nhofmeyr at sysmocom.de Thu Nov 15 22:25:18 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 15 Nov 2018 23:25:18 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: <20181115152355.GB3486@my.box> Message-ID: <20181115222518.GA2568@my.box> On Thu, Nov 15, 2018 at 06:07:30PM +0100, Ruben Undheim wrote: > Yes, ideally! I have actually done it on gerrit to you guys once > before [1]. However, I am interacting with so many different upstream, Yeah, I understand. We can do it, thanks for all your work! ~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 Fri Nov 16 00:09:44 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Nov 2018 01:09:44 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <20181115152355.GB3486@my.box> References: <20181115152355.GB3486@my.box> Message-ID: <20181116000944.GC2568@my.box> On Thu, Nov 15, 2018 at 04:23:55PM +0100, Neels Hofmeyr wrote: > > Maybe the trick is to just start going over all structs in libosmocore > > I thought about scripting it, because editing manually takes forever and is > error prone. I actually hacked up one of those borderline-insane py scripts to mangle our C code into big-endian-reversed structs. See https://gerrit.osmocom.org/#/c/libosmocore/+/11786 for the script and https://gerrit.osmocom.org/#/c/libosmocore/+/11787 for what it did to libosmocore The script implementation itself is mad and convoluted, of course. How could it be different when handling and mangling C code. It works by looking at all packed structs that have sub-byte ints, and composes a big-endian counterpart. If there already is a big-endian ifdef, it strips it away and takes the little-endian part as authoritative. Non-packed structs are ignored, because we sometimes have weird boolean fields in the form of 'int flag:1;' which don't add up to full bytes. So, we can have auto-generated big-endian structs, and we can also verify in gerrit that they are correct (by runnning the script over the files and erroring if there are any local modifications; not implemented yet). But we get once-off cosmetic changes, to reach a state where running the struct_endianess.py script over the code results in zero changes. A simple example of what the script does is diff --git a/include/osmocom/gprs/protocol/gsm_04_60.h b/include/osmocom/gprs/protocol/gsm_04_60.h index 96e9ab78..5d5fca9a 100644 --- a/include/osmocom/gprs/protocol/gsm_04_60.h +++ b/include/osmocom/gprs/protocol/gsm_04_60.h @@ -7,10 +7,12 @@ #pragma once #include +#include #if OSMO_IS_LITTLE_ENDIAN == 1 /* TS 04.60 10.3a.4.1.1 */ struct gprs_rlc_ul_header_egprs_1 { +#if OSMO_IS_LITTLE_ENDIAN uint8_t r:1, si:1, cv:4, @@ -26,10 +28,20 @@ struct gprs_rlc_ul_header_egprs_1 { spare_hi:1; uint8_t spare_lo:6, dummy:2; +#elif OSMO_IS_BIG_ENDIAN +/* auto-generated from the little endian part above (libosmocore/contrib/struct_endianess.py) */ + uint8_t tfi_hi:2, cv:4, si:1, r:1; + uint8_t bsn1_hi:5, tfi_lo:3; + uint8_t bsn2_hi:2, bsn1_lo:6; + uint8_t bsn2_lo:8; + uint8_t spare_hi:1, pi:1, rsb:1, cps:5; + uint8_t dummy:2, spare_lo:6; +#endif } __attribute__ ((packed)); A more complex example is: Currently struct amr_hdr looks like this, manual big-endian stuff: struct amr_hdr { #if OSMO_IS_BIG_ENDIAN /* Payload Header */ uint8_t cmr:4, /* Codec Mode Request */ pad1:4; /* Table of Contents */ uint8_t f:1, /* followed by another speech frame? */ ft:4, /* coding mode */ q:1, /* OK (not damaged) at origin? */ pad2:2; #elif OSMO_IS_LITTLE_ENDIAN /* Payload Header */ uint8_t pad1:4, cmr:4; /* Table of Contents */ uint8_t pad2:2, q:1, /* OK (not damaged) at origin? */ ft:4, /* coding mode */ f:1; /* followed by another speech frame? */ #endif } __attribute__((packed)); After the script has done its mangling, it will look like this -- the little endian part is unchanged, and the big endian stuff is completely autogenerated: struct amr_hdr { #if OSMO_IS_LITTLE_ENDIAN /* Payload Header */ uint8_t pad1:4, cmr:4; /* Table of Contents */ uint8_t pad2:2, q:1, /* OK (not damaged) at origin? */ ft:4, /* coding mode */ f:1; /* followed by another speech frame? */ #elif OSMO_IS_BIG_ENDIAN /* auto-generated from the little endian part above (libosmocore/contrib/struct_endianness.py) */ uint8_t cmr:4, pad1:4; uint8_t f:1, ft:4, q:1, pad2:2; #endif } __attribute__((packed)); Notice that little endian is on top now, the big-endian part features a comment mentioning the script, and has different formatting. I intuitively added the script in libosmocore/contrib/ and not in osmo-ci, ymmv. I still think libosmocore-specific struct mangling belongs in libosmocore, and not in osmo-ci. (The value string verification script is in osmo-ci, but a programmer wanting to auto-generate a big-endian struct before submitting a patch would prefer to have the script there already, without having to download osmo-ci first). I have pushed a lot of neels/big_endian branches, the libosmocore one is on gerrit already, let's see what the review gets me before submitting the others as well: http://git.osmocom.org/libosmocore/commit/?h=neels/big_endian&id=8670bd025a47d462a7b76a811e66dee42afacc1f http://git.osmocom.org/libosmo-netif/commit/?h=neels/big_endian&id=3c21004bfba30054bf0069c5b4bc27447453178d http://git.osmocom.org/libosmo-sccp/commit/?h=neels/big_endian&id=6470e9577137d3e674d5d433bf27b9543972a420 http://git.osmocom.org/libosmo-abis/commit/?h=neels/big_endian&id=ca3e6bbcfd52d84e2f7dad68f9c1c3c13611ebf7 http://git.osmocom.org/osmo-pcu/commit/?h=neels/big_endian&id=7a99dcaeff6553de107a416b89cf1249fb89dc01 http://git.osmocom.org/osmo-sgsn/commit/?h=neels/big_endian&id=f1620286371b2c463a5d77896d40282ddaf31b36 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ruben.undheim at gmail.com Fri Nov 16 07:18:39 2018 From: ruben.undheim at gmail.com (Ruben Undheim) Date: Fri, 16 Nov 2018 08:18:39 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <20181116000944.GC2568@my.box> References: <20181115152355.GB3486@my.box> <20181116000944.GC2568@my.box> Message-ID: > I actually hacked up one of those borderline-insane py scripts to mangle our C > code into big-endian-reversed structs. > > See > https://gerrit.osmocom.org/#/c/libosmocore/+/11786 for the script and > https://gerrit.osmocom.org/#/c/libosmocore/+/11787 for what it did to libosmocore > > The script implementation itself is mad and convoluted, of course. How could it > be different when handling and mangling C code. Awesome, Neels! This can become a very useful tool. After all structs are fixed, we also have a few places with "ntohs" and its friends to fix. I've gotten quite a lot of test suites to pass now for several of the packages. See here: https://buildd.debian.org/status/package.php?p=Debian-mobcom-maintainers%40lists.alioth.debian.org&comaint=yes However, in some cases I am unsure if I have fixed the problem or if I have just hidden the problem... For instance, this one: - https://sources.debian.org/patches/libosmocore/0.12.1-2/0006-Fix-some-byte-ordering-for-big-endian-architectures.patch/ It makes the test pass. Even more hacky, and probably wrong is this one: - https://browse.dgit.debian.org/osmo-bsc.git/commit/?id=656937f42ab08ee206ddf4cd3c943d36916b0dcc (it also makes the test pass) Could you please have a look at these two patches and see if they just hide the problem, and if they do, what the correct fix is? Best regards Ruben From pespin at sysmocom.de Fri Nov 16 09:00:02 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 16 Nov 2018 10:00:02 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: <20181116000944.GC2568@my.box> References: <20181115152355.GB3486@my.box> <20181116000944.GC2568@my.box> Message-ID: Cool, this kind of scripts will indeed be useful, specially when used in jenkins.sh It would be nice to do following check too: * If a struct has BIG_ENDIAN/LITTLE_ENDIAN ifdefs related to bitfields, then verify it contains the "packed" attribute. Why do you care otherwise about bit fields if you are not planning to send over the network? And if you send them over the network you definetly don't want padding. -- - 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 osmith at sysmocom.de Fri Nov 16 09:47:43 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 16 Nov 2018 10:47:43 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115181919.GL44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <20181115181919.GL44110@ted.stsp.name> Message-ID: <0bfceb2f-ca6b-7279-6efd-2ce3c352c6a4@sysmocom.de> On 11/15/18 7:19 PM, Stefan Sperling wrote: > So please don't stop voicing your opinions. For what it's worth, I would prefer to enforce the rule as well. Even if it does not seem like much effort to explain this workflow to new users, and to ask people to think about the +3 before merging: these things add up, leave room for mistakes and scale badly (as already pointed out in this thread). It's the same with CI that builds code and runs test cases - of course we could trust everybody to do this on their own before publishing patches, but that is not as good as checking it automatically and having proof that the tests really ran through before merging. Best 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 msuraev at sysmocom.de Fri Nov 16 23:10:29 2018 From: msuraev at sysmocom.de (Max) Date: Sat, 17 Nov 2018 00:10:29 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <1a24ca7b-27bf-3c25-1289-1038aa151cd5@sysmocom.de> Hi. 12.11.18 22:35, Ruben Undheim ?????: > Hi, > > Most of the openbsc packages are now up-to-date in Debian! : > https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org On a somewhat related note, here's how the .deb version compares with other distributions: https://repology.org/metapackage/libosmocore/versions Looks pretty good although it's still a long road ahead for Osmocom world domination over majority of distributions :) -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From snehasish.cse at live.com Fri Nov 16 13:36:41 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Fri, 16 Nov 2018 13:36:41 +0000 Subject: Help with silent call In-Reply-To: <20181104191623.GA22559@my.box> References: , <20181104191623.GA22559@my.box> Message-ID: Neel, The APDU that you are referring here is the one used with binary SMS. If so, is then we consider the SMS-PP envelope or the SMS-Deliver approach, in both the cases, we require to know the Ki, Kc and TAR for successful execution of the command(packed in the APDU). How to predict these or any alternative to by-pass this, exists? BR Snehasish ________________________________ From: Neels Hofmeyr Sent: Monday, November 5, 2018 12:46:23 AM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: Help with silent call On Sat, Nov 03, 2018 at 12:06:33PM +0000, Snehasish Kar wrote: > I have read that silent-calls in GSM can be used to make a call to a target > MS and listen to it Not listen to it in terms of audio. You can't eavesdrop on an MS with a slient call. You *can* open a channel and receive measurement reports from it, so that you see which other cells it sees at which receive levels, and how far it is from the current cell (TA). From that you could derive its position. The silent call has been one of the earliest features in Osmocom, but until recently has been broken in osmo-msc. IIUC it is now fixed again in current master, but might not be in a release yet. There's also the APDU a.k.a. the RR App Info (I hope I got the names right), which may or may not contain GPS positioning data that the MS is sending to the core net. In both cases the owner of the MS has no explicit idea that they are sharing any details on their position. ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 19 06:19:32 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:19:32 +0100 Subject: SMS: UCS-2 concatenation with UTF16 emoticons In-Reply-To: <20181112155452.GA9896@my.box> References: <20181112155452.GA9896@my.box> Message-ID: <20181119061932.GH5011@nataraja> On Mon, Nov 12, 2018 at 04:54:52PM +0100, Neels Hofmeyr wrote: > With my commercial operator: > [...] I guess it would make sense to replicate this experiment using a OsmoBTS/BSC on the RAN side but a "commerical core" on the CN side. This way one can take protocol traces of [not only] the Layer3 communication (CP/RP/TP layers) and compare the osmocom vs. non-osmocom signaling. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 19 06:23:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:23:01 +0100 Subject: Femto Access Point provisioning for Osmocom/Sysmocom In-Reply-To: References: Message-ID: <20181119062301.GI5011@nataraja> Hi Mykola, I can only repeat what Neels has been stating: It's great of you to reach out and share your experience. I myself haven't played with such more modern nano3G devices/firmware. However, it's good to see you looking into this and sharing the results. It would be great if you could add your results, config files, etc. to the osmocom wiki and make the information available to the wider community. Please register an account yourself and contact me privately to get edit rights for the wiki. Best regards, and I'm looking forward to any further updates. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 19 06:27:18 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:27:18 +0100 Subject: Failing test cases (and builds) on other architectures in Debian In-Reply-To: References: Message-ID: <20181119062718.GJ5011@nataraja> Hi Ruben, thanks for pointing this out. It has been known to use that Osmocom GSM/3G code doesn't work on big endian systems for quite some time. In the 10 year history of the project, I'm not aware of any user of our software on such systems, or anyone ever having requested support and/or contributed related patches. As our [paid] development resources are still very limited compared to the vast scope of the 3GPP specs, protocols, network elements, etc. it has never been a priority, including now. In the Osmocom project we are most happy to review and merge any related fixes! But in terms of sysmocom dedicating paid engineering time to fixing any of those: It's unlikely going to happen, sorry. I still agree with other responders on this thread that it's useful to document known bugs in our bug tracker, though. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 19 06:30:06 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:30:06 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <20181119063006.GK5011@nataraja> Hi Stefan, On Tue, Nov 13, 2018 at 04:43:50PM +0100, Stefan Sperling wrote: > There has been some face-to-face discussion about Osmocom's code review > process within sysmocom recently. I am posting to this list now with the > consent of everyone involved so far, in order to involve the Osmocom > community at large in this discussion as well. Thanks for getting the discussion going here. > There has been a lack of code review from people who don't have "+2" > super powers in Gerrit. Actually, to be more precise there also has been alack of code review from many people who already had +2 power. I understand your line of thought and your arguments, but let's try to state all the facts :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 19 06:33:09 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:33:09 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> Message-ID: <20181119063309.GL5011@nataraja> Hi Pau, On Tue, Nov 13, 2018 at 05:08:49PM +0100, Pau Espin Pedrol wrote: > I agree with implementing this kind of change, I really like the idea of > getting more people into reviewing and their vote counting so there's no > need for somebody with +2 to merge it. ACK. > The only drawback I see is the fact that if +3 is needed, then a +2 from > some people is now not enough, which can be a pity for patches that can be > merged quickly (cosmetic, logging, etc.) or important fixes which require > quick merge. ACK. That's why I think eventually a +3 will be needed. But I'm happy to give the current proposal a (short) try. If we get a backlog of patches at "+2" stage that don't reach "+3" then we must quickly introduce +3. > Also, for some repos most people don't care bout or don't have much > knowledge about it, for instance the case os myself and osmo-gsm-tester, > where I usually +2 my patches right away or after leaving them under review > for a few hours/days. This would block my development or fix of > setup-related issues. Equally ACK here. It's frequent practise in some projects that lack a wider community. > So good for me, but we need to resolve this kind of details in the proposal > beforehand. Indeed, the +3 "privilege" should be configured from day one, with nobody enjoying it until we see a need for it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 19 06:36:34 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2018 07:36:34 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113171602.GA20444@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <5059b959-67a2-becb-7bce-252c3ab30963@sysmocom.de> <20181113171602.GA20444@my.box> Message-ID: <20181119063634.GM5011@nataraja> Hi Neels, On Tue, Nov 13, 2018 at 06:16:02PM +0100, Neels Hofmeyr wrote: > I think just giving +2 permissions to "everyone" is the easiest and socially > most beautiful solution: rely on social policy rather than enforcing UI. Makes sense to me. At least for the past and current [size of] community I would consider this a very acceptable/workable solution. Maybe we simply go down that route, rather than setting up more complex technical setups? The community will have to pay attention that the etiquette is being followed. > A minor drawback I see is in the UI: I usually want to quickly see in the > overview what patches make sense to take a closer look at now. But even if 10 > people cast a +1, the gerrit UI will only show a "+1" in the overview. Also, if > one of those is a -1, I think it still shows "+1". So I would welcome listing > all the individual votes in the overview list, like "-1,+1x10" -- not sure if > that makes sense to implement in a plugin, probably not. Part of this problem > goes away when a reviewer casts +2, then the overview will show "+2". But we > still lose the "-1" part. A workaround is to always click and open every > individual issue... that then shows each single vote of course. I think this > minor drawback will still exist if we add up votes: not seeing -1s immediately. ACK. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Mon Nov 19 06:58:50 2018 From: admin at manateeshome.com (Pierre Kim) Date: Mon, 19 Nov 2018 15:58:50 +0900 Subject: 3G with Asterisk connection Message-ID: <9341f819-08f6-e96b-334b-4d1b92e755ef@manateeshome.com> Hello, I'm setting up an Asterisk connection with osmo-sip-connector. Initiation of calls works fine, but no sound is getting through. My setup is as follows: Local computer is running all osmo software plus asterisk interface has IP address 192.168.27.49 plus 192.168.27.47 as alias femtocell is at 192.168.27.41 osmo-mgw.cfg mgcp ? bind ip 192.168.27.49 ? rtp port-range 4002 16000 ? rtp bind-ip 192.168.27.47 osmo-sip-connector.cfg sip ? local 192.168.27.47 5069 ? remote 192.168.27.49 5060 osmo-msc.cfg msc ?mgw remote-ip 192.168.27.49 ?mgw remote-port 2427 ?mgw local-port 2728 When I start wireshark it only shows packets flowing between 192.168.27.41(femtocell) and 192.168.27.47(osmo-mgw). No packets to/from Asterisk server, how can I fix this problem? Current documentation on osmo-mgw is quite difficult to understand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at manateeshome.com Mon Nov 19 08:02:22 2018 From: admin at manateeshome.com (Pierre Kim) Date: Mon, 19 Nov 2018 17:02:22 +0900 Subject: 3G data connection loss In-Reply-To: <20181114192401.GA16956@my.box> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> <20181114130544.GB17000@my.box> <354f193c-6f22-f435-0737-3a0ba2798714@manateeshome.com> <20181114192401.GA16956@my.box> Message-ID: <03beb31a-613e-f117-eac3-21d7c3fb0e9a@manateeshome.com> > I think this is worth investigating indeed. Have we got a redmine issue on it > yet? I guess those would be two: a) find out the source of SGSN errors and > b) be more tolerant of errors in the GGSN. > > Possibly b) becomes obsolete when a) is resolved, or maybe b) is even harmful > when errors should have implied the end of a PDP context. > > For a), it would be super interesting to get a pcap / log snippets of the > actual error indications attached to the redmine issue. I've updated the redmine issue with the relevant packet capture. https://osmocom.org/issues/3696 Regards, Pierre From nhofmeyr at sysmocom.de Mon Nov 19 12:54:34 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Nov 2018 13:54:34 +0100 Subject: 3G with Asterisk connection In-Reply-To: <9341f819-08f6-e96b-334b-4d1b92e755ef@manateeshome.com> References: <9341f819-08f6-e96b-334b-4d1b92e755ef@manateeshome.com> Message-ID: <20181119125434.GA3289@my.box> Hi, First of all, the problem you will face with 3G is IuUP. 3G adds, *inside* the RTP payload, another header and also mangles the AMR bits incompatibly, which we do not decode yet. That is why voice calls between 3G works (only because we forward the IuUP between the femto cells directly) and 3G <-> {2G,SIP} do not work. IuUP is supposed to terminate at the MGW. We have a little bit of work started on IuUP, but it is still quite far from done and also has no high priority at the moment. If you have a pressing need you could implement it or sponsor someone to do so. Let me know and I can give you some pointers. Also, you need to set up external MNCC. Your mail hints osmo-sip-connector, so I assume you're doing that, but if you're not seeing *any* packages to/from SIP, then your MSC might still be doing internal MNCC. > No packets to/from Asterisk server, how can I fix this problem? Current > documentation on osmo-mgw is quite difficult to understand. The MGW is told by the MSC what to do, there is nothing you can configure there except the connection where the MSC talks to it. Think of it like a plain dumb switching board, and the operator plugging the cables is the MSC. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Nov 19 13:30:05 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Nov 2018 14:30:05 +0100 Subject: Help with silent call In-Reply-To: References: <20181104191623.GA22559@my.box> Message-ID: <20181119133005.GB3289@my.box> On Fri, Nov 16, 2018 at 01:36:41PM +0000, Snehasish Kar wrote: > Neel, s > The APDU that you are referring here is the one used with binary SMS. No, I'm referring to the RR Application Information message. The one pointer I'm finding now is 3GPP 48.018 3.4.21 Application Procedures and 9.1.53 in the same. All we did with that in Osmocom so far was dump this APDU to the log and the subscriber database, though that was using old openbsc (osmo-nitb). Right now with osmo-bsc / osmo-msc we simply ignore it. I'm not familiar with any details on decoding it. ~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 Nov 19 13:33:01 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Nov 2018 14:33:01 +0100 Subject: 3G data connection loss In-Reply-To: <03beb31a-613e-f117-eac3-21d7c3fb0e9a@manateeshome.com> References: <408c275e-524a-72cb-3774-6258d9a0c2a0@manateeshome.com> <20181114130544.GB17000@my.box> <354f193c-6f22-f435-0737-3a0ba2798714@manateeshome.com> <20181114192401.GA16956@my.box> <03beb31a-613e-f117-eac3-21d7c3fb0e9a@manateeshome.com> Message-ID: <20181119133301.GC3289@my.box> On Mon, Nov 19, 2018 at 05:02:22PM +0900, Pierre Kim wrote: > I've updated the redmine issue with the relevant packet capture. > > https://osmocom.org/issues/3696 Thanks! I hope it will get picked up by someone sooner or later. And of course, if you figure out more details, keep in touch... ~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 Nov 19 14:00:22 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Nov 2018 15:00:22 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181115180734.GK44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <2a48e8dc-df24-bd32-2bb0-009bac1b68b3@sysmocom.de> <20181114151649.GB44110@ted.stsp.name> <20181114194459.GB16956@my.box> <20181115121548.GG44110@ted.stsp.name> <20181115143111.GA3486@my.box> <5ec3ce20-7a58-a25f-7019-738365a647f8@sysmocom.de> <20181115180734.GK44110@ted.stsp.name> Message-ID: <20181119140022.GD3289@my.box> On Thu, Nov 15, 2018 at 07:07:34PM +0100, Stefan Sperling wrote: > Nobody can undo the main line of history. Well, some of us can, since we have direct write permission on the git repositories in gerrit. (And my point is that we don't use that capability due to social convention.) > But it seems like Neels and my own proposal aren't > far apart, actually. The only difference is whether our self-enforced > boundaries are enforced by technical or social means, really. Exactly! ~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 Nov 19 14:04:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Nov 2018 15:04:23 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <20181119140423.GE3289@my.box> I'm losing track of opinions, so I made this poll: https://dudle.inf.tu-dresden.de/voting_on_gerritosmocomorg/ It is easier to see how many would accept what to come to terms with what we want. (If the wording is confusing we can edit the poll.) Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From admin at manateeshome.com Mon Nov 19 14:50:59 2018 From: admin at manateeshome.com (Pierre Kim) Date: Mon, 19 Nov 2018 23:50:59 +0900 Subject: 3G with Asterisk connection In-Reply-To: <20181119125434.GA3289@my.box> References: <9341f819-08f6-e96b-334b-4d1b92e755ef@manateeshome.com> <20181119125434.GA3289@my.box> Message-ID: I see, some information about IuUP certainly wouldn't hurt, for the good of all of us. > Also, you need to set up external MNCC. Your mail hints osmo-sip-connector, so > I assume you're doing that, but if you're not seeing *any* packages to/from > SIP, then your MSC might still be doing internal MNCC. Is there anything else to do other than the -M flag? And to clarify, SIP works normally, even the DTMF signals go through, it's just the RTP packets that are missing. Regards, Pierre From nhofmeyr at sysmocom.de Mon Nov 19 23:34:30 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 20 Nov 2018 00:34:30 +0100 Subject: GSUP protocol manual in HLR, MSC, SGSN Message-ID: <20181119233430.GA18764@my.box> (cross-posting so it doesn't get lost) reading Vadim's patches, I just now invented: https://osmocom.org/issues/3700 "Idea: have a separate GSUP manual" Provide feedback at that issue if you have an opinion... ~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 Tue Nov 20 00:00:20 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 20 Nov 2018 01:00:20 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181119140423.GE3289@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <20181119140423.GE3289@my.box> Message-ID: <20181120000020.GB18764@my.box> On Mon, Nov 19, 2018 at 03:04:23PM +0100, Neels Hofmeyr wrote: > https://dudle.inf.tu-dresden.de/voting_on_gerritosmocomorg/ Intermediate summary: it's a very close run between "social convention only" (3 acks) and "UI enforced +3, no-one has +3 rights" (3 acks plus one '?', say 3.5). Er, should I subtract the red 'x' votes? In that case "UI enforced, no-one has +3" would win 2.5 against 1. Let's wait another few days, maybe more wish to submit their vote. About "no-one has +3", I will dislike not being able to fast-track the odd patch here and there, and will probably use my direct write-to-git permission, instead of waiting and wasting other people's time on, say, whitespace changes. On the poll page, a question was asked by "Anonymous", am hereby taking the discussion back here: > I don't understand why you insist on calling configuration a plugin. There's > no need to install anything which isn't already there. We have to change > configuration according to the documentation. What "plugin" or "installation" > are you referring to? IIUC introducing adding up of +1 votes requires some prolog script to be added/installed/enabled in gerrit. Last time I asked whether anyone had figured out how to do it the answer was a resounding "?". To say it yet over again: whatever it takes, If someone is willing to make gerrit behave that way, fine with me. But I will not be that person. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Tue Nov 20 08:04:24 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 20 Nov 2018 09:04:24 +0100 Subject: SMS: UCS-2 concatenation with UTF16 emoticons In-Reply-To: <20181112155452.GA9896@my.box> References: <20181112155452.GA9896@my.box> Message-ID: <4409769c-ecf3-5104-e9ea-9ec3352da8df@rhizomatica.org> On 12/11/2018 16:54, Neels Hofmeyr wrote: > With my commercial operator: Hi Neels, thanks for doing this test, sorry i got distracted from this and did not reply. > > I sent myself 40 emoticons and at least signal displays them correctly. > > Then I sent 40 and quickly changed the default SMS app back to the stock > Messaging thing to receive the SMS there, and it also shows all 40 intact. > Notably displayed as emoticons, apparently it does support them after all. Yes, probably a keyboard issue, more than the app itself. Signal has it's own built in emoji composer, and some keyboards have weird ways to get to the emoji keyboard - Searching about FP2, I came across this phrase "Just keep pressed the bottom right button (the green one) and the option shows. Then move your finger to the left while still touching the screen.", if that makes any sense to you. Worst case, you could just compose in signal, then copy + paste. No need to switch the App I think. As Harald said, it would be good to test with a commercial core network, but I don't have one :) If you could quickly try this with your (or any) phone next time you have it connected to your Osmocom network, that would confirm it is not just my phones. (I really don't see anything out of the ordinary on my protocol traces.) Given that last time the emojis I posted to ML looked ok in a few MUAs, here's the result of sending some emoji (copied from SMS app to K9 mail - > saved to IMAP draft -> thunderbird. with latest MSC, no SMPP mode: Sent: ???????????????????????????????????????? Rcvd: ????????????????????????????????????????? Thanks! k/ From nhofmeyr at sysmocom.de Tue Nov 20 14:23:34 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 20 Nov 2018 15:23:34 +0100 Subject: 3G with Asterisk connection In-Reply-To: References: <9341f819-08f6-e96b-334b-4d1b92e755ef@manateeshome.com> <20181119125434.GA3289@my.box> Message-ID: <20181120142334.GA29481@my.box> On Mon, Nov 19, 2018 at 11:50:59PM +0900, Pierre Kim wrote: > I see, some information about IuUP certainly wouldn't hurt, for the good > of all of us. /me digs up older post: So far I know of 3GPP TS 25.414, 5.1.3.3.2 RTP Payload: "A single Iu UP PDU, as described in TS 25.415 [24], shall be transported as RTP payload." And 25.415 contains the juicy bits. We have osmo-mgw branch neels/iuup refactoring some RTP packet handling to be able to easily strip/insert an IuUP header with correct checksums etc., and we have libosmocore branch laforge/iu_up implementing a state machine about unshuffling the payload bits. I guess to get a working solution we would need to marry those two branches and fix whatever is still broken/not implemented in there. They are still potentially wildly incompatible. > Is there anything else to do other than the -M flag? And to clarify, SIP I wish someone more familiar with external MNCC would take over here. Anyone? If I were alone on this, I would try to decipher the MGCP messages between MSC and MGW-for-MSC (CRCX, MDCX), and see whether it instructs the MGW to send towards SIP. And look at MSC debug logging. Not sure if that's the easiest way. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From t-openbsc at tobias.org Tue Nov 20 15:01:39 2018 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 20 Nov 2018 16:01:39 +0100 Subject: SMS: UCS-2 concatenation with UTF16 emoticons In-Reply-To: <4409769c-ecf3-5104-e9ea-9ec3352da8df@rhizomatica.org> References: <20181112155452.GA9896@my.box> <4409769c-ecf3-5104-e9ea-9ec3352da8df@rhizomatica.org> Message-ID: <7f7b294f-a58d-6f79-df81-396f5d9216ad@tobi.as> On 20.11.18 09:04, Keith wrote: > As Harald said, it would be good to test with a commercial core network, > but I don't have one :) I don't know if this helps, but I got curious and sent the 40-emoji-message from a phone connected to a commercial network and captured it via SS7. (So no Osmocom involved.) The pcap file is attached (addresses removed). It looks like the 4-byte characters don't get split in half, but the last two bytes get pushed to the next message, and all emojis are received unharmed. One thing I don't get though: where is it even specified that you can use UTF-16 in SMS? Even the latest 23.038 only lists UCS-2. -Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: 20181120_forwardSM_utf16_emojis.pcap Type: application/octet-stream Size: 744 bytes Desc: not available URL: From pespin at sysmocom.de Fri Nov 23 12:19:32 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 23 Nov 2018 13:19:32 +0100 Subject: =?UTF-8?Q?cellmgr-ng_rotten_=28Re=3a_Build_failed_in_Jenkins=3a_mas?= =?UTF-8?Q?ter-cellmgr-ng_=c2=bb_a1=3ddefault=2ca2=3ddefault=2ca3=3ddefault?= =?UTF-8?Q?=2cosmocom-master-debian9_=2354=29?= In-Reply-To: <663594879.808.1542971940788.JavaMail.jenkins@jenkins.osmocom.org> References: <541592031.790.1542885542042.JavaMail.jenkins@jenkins.osmocom.org> <663594879.808.1542971940788.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: Hi all, I started looking at this failure and found out code in this repository is really old, with nobody maintain it (13 months since last commits?). I started by updating the contrib/jenkins.sh to use osmo-build-dep.sh and osmo-clean-workspace.sh like we do in other repos, because i felt it was not building up to date stuff. After updating that script, indeed it seems cellmgr-ng cannot be built against new libosmo-sccp due to some M3UA headers /API changes. There's even a tag during that commit in libosmo-sccp called "old_sua". After that commit, cellmgr-ng fails to build. If I try to build it against "old_sua", still cannot build fine with updated contrib/jenkins.sh script due to missing LIBOSMOSCCP_CFLAGS in tests/Makefile.am, and then still other headers are not found in other places, etc. I stopped at this point because I'm starting to spent too muhch time on this and it seems nobody is using it anyway. Can we disable the build of this project? Does somebody want to take care of it? 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 laforge at gnumonks.org Fri Nov 23 22:12:10 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 23 Nov 2018 23:12:10 +0100 Subject: cellmgr-ng rotten =?iso-8859-1?B?KFJl?= =?iso-8859-1?Q?=3A_Build_failed_in_Jenkins=3A_master-cellmgr-ng_=BB_a1=3D?= =?iso-8859-1?Q?default=2Ca2=3Ddefault=2Ca3=3Ddefault=2Cosmocom-master-deb?= =?iso-8859-1?Q?ian9?= #54) In-Reply-To: References: <541592031.790.1542885542042.JavaMail.jenkins@jenkins.osmocom.org> <663594879.808.1542971940788.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20181123221210.GX5011@nataraja> On Fri, Nov 23, 2018 at 01:19:32PM +0100, Pau Espin Pedrol wrote: > I started looking at this failure and found out code in this repository is > really old, with nobody maintain it (13 months since last commits?). ACK. not that I'm aware of. It started as a project to translate circuit-switched A interfaces of a "BSplus" BTS+BSC combination into SCCPlite over IP. Then various other bits and pieces related to MTP and SS7 had been added, towards the direction of a STP. There may be many other features that I'm not aware of [anymore]. It's one of the many powerful but lesser known/understood Osmocom projects that primarily Holger was working on. To my knowledge there are still some production deployments using it as a M3UA <-> IPA/SCCPlite translator, but there are plans to phase that out and use the "new" osmo-stp from libosmo-sigtran.git instead. > Can we disable the build of this project? I think so. We should also add a related "unmaintained" notice to the README file or related documentation in the git repo, as well as on the wiki. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Mon Nov 26 08:30:11 2018 From: admin at manateeshome.com (Pierre Kim) Date: Mon, 26 Nov 2018 17:30:11 +0900 Subject: nanoBTS fails to start with osmo-bsc Message-ID: <3df957dd-db1c-8a51-0095-6459eca6515c@manateeshome.com> With the newest git repo version of osmo-bsc, my nanoBTS fails to start. I can confirm that they work normally with ip.access softBSC. I thought osmocom Redmine issue #3063 might be relevant and tried setting/unsetting force-combined-si but I am still getting the same result. Attached are the packet capture and bsc config file The following is the log from osmo-bsc: <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002 <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message. <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[0/5]: 168a004 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[1/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[2/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[3/5]: 168a001 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[4/5]: 168a001 is v136d0 <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003 <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1149 (325). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error: . BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1149 (325) -------------- next part -------------- ! ! OsmoBSC (1.3.0.139-75f03) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging print file 1 logging level rll notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level pag notice logging level meas notice logging level msc notice logging level ho notice logging level hodec notice logging level ref notice logging level nat notice logging level ctrl notice logging level filter debug logging level pcu debug logging level lcls notice logging level chan notice logging level ts notice logging level as notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive cs7 instance 0 point-code 0.23.3 network network country code 450 mobile network code 09 encryption a5 1 3 neci 0 paging any use tch 0 bts 0 type nanobts band PCS1900 cell_identity 0 location_area_code 23 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 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode manual codec-support fr hr efr amr amr tch-f modes 1 2 6 7 amr tch-f threshold ms 32 32 32 amr tch-f hysteresis ms 8 8 8 amr tch-f threshold bts 32 32 32 amr tch-f hysteresis bts 8 8 8 amr tch-f start-mode auto amr tch-h modes 1 2 4 5 amr tch-h threshold ms 32 32 32 amr tch-h hysteresis ms 8 8 8 amr tch-h threshold bts 32 32 32 amr tch-h hysteresis bts 8 8 8 amr tch-h start-mode auto gprs mode none force-combined-si trx 0 rf_locked 0 arfcn 600 nominal power 23 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH 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 TCH/F hopping enabled 0 msc 0 ip.access rtp-base 4000 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text codec-list hr3 type normal allow-emergency deny amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden asp-protocol m3ua lcls-mode disabled lcls-codec-mismatch forbidden bsc mid-call-timeout 0 no missing-msc-text -------------- next part -------------- A non-text attachment was scrubbed... Name: nanobts.pcap Type: application/octet-stream Size: 30322 bytes Desc: not available URL: From pespin at sysmocom.de Mon Nov 26 10:34:39 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 26 Nov 2018 11:34:39 +0100 Subject: nanoBTS fails to start with osmo-bsc In-Reply-To: <3df957dd-db1c-8a51-0095-6459eca6515c@manateeshome.com> References: <3df957dd-db1c-8a51-0095-6459eca6515c@manateeshome.com> Message-ID: <76128b96-bd30-65ad-2f9d-163afedbd7a3@sysmocom.de> Hi, First of all, can you please create a ticket with all the information, link it to #3063 and also provide a full log of osmo-bsc with "logging level set-all debug" together with a pcap file and bsc.cfg. > With the newest git repo version of osmo-bsc, my nanoBTS fails to start. > Was it recently working for you with up to date osmocom? Or never got it to work? > I can confirm that they work normally with ip.access softBSC. Would be nice if you could provice a pcap file while using it to see the differences. > > > I thought osmocom Redmine issue #3063 might be relevant and tried > setting/unsetting force-combined-si but I am still getting the same > result. Attached are the packet capture and bsc config file > > The following is the log from osmo-bsc: > > <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002 > <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK > <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message. > <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: > ARI reported sw[0/5]: 168a004 is v136d0 > <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: > ARI reported sw[1/5]: 168a002 is v136d0 > <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: > ARI reported sw[2/5]: 168a002 is v136d0 > <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: > ARI reported sw[3/5]: 168a001 is v136d0 > <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: > ARI reported sw[4/5]: 168a001 is v136d0 > <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is > unreported That looks fine I think. Get attributes fails at BTS level but then it asks at transceiver level and it gets the information. The initial failure is not important. > <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 > STREAM=0x00 > <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003 > <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN > 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 > BTS 0: Failure Event Report: Type=processing failure, Severity=critical > failure, Probable cause=Manufacturer specific values: Fatal software > error, Additional Text=l2_bch.c:1149 > **** > ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) > ** IPA_SW_FATAL_ERROR > ** In task "TRX Proc:L2_BCH" @ (325). > **** > Looks like the BTS doesn't like some type of SI we are sending to it. A fulldebug log of osmo-bsc.cfg would help. I'm right now trying to find in the pcap file were the SI info is sent. BTW, try using following setup, it's the one I did test with. Tell me if you see any change: timeslot 0 phys_chan_config CCCH+SDCCH4 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 PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 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 admin at manateeshome.com Mon Nov 26 13:07:59 2018 From: admin at manateeshome.com (Pierre Kim) Date: Mon, 26 Nov 2018 22:07:59 +0900 Subject: nanoBTS fails to start with osmo-bsc In-Reply-To: <76128b96-bd30-65ad-2f9d-163afedbd7a3@sysmocom.de> References: <3df957dd-db1c-8a51-0095-6459eca6515c@manateeshome.com> <76128b96-bd30-65ad-2f9d-163afedbd7a3@sysmocom.de> Message-ID: <2cd1fab2-c3a7-312a-45a7-78dca929449f@manateeshome.com> Hello, I created a redmine issue here: https://osmocom.org/issues/3707 And the BTS used to work with osmo-nitb before the split, I remember setting it up about a year and half ago. I connected it to softBSC just to make sure that it wasn't a hardware problem. Regards. Pierre On 2018-11-26 ?? 7:34, Pau Espin Pedrol wrote: > Hi, > > First of all, can you please create a ticket with all the information, > link it to #3063 and also provide a full log of osmo-bsc with "logging > level set-all debug" together with a pcap file and bsc.cfg. > > >> With the newest git repo version of osmo-bsc, my nanoBTS fails to start. >> > > Was it recently working for you with up to date osmocom? Or never got > it to work? > >> I can confirm that they work normally with ip.access softBSC. > > Would be nice if you could provice a pcap file while using it to see > the differences. > >> >> >> I thought osmocom Redmine issue #3063 might be relevant and tried >> setting/unsetting force-combined-si but I am still getting the same >> result. Attached are the packet capture and bsc config file >> >> The following is the log from osmo-bsc: >> >> <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port >> 3002 >> <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK >> <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML >> message. >> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: >> ARI reported sw[0/5]: 168a004 is v136d0 >> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: >> ARI reported sw[1/5]: 168a002 is v136d0 >> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: >> ARI reported sw[2/5]: 168a002 is v136d0 >> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: >> ARI reported sw[3/5]: 168a001 is v136d0 >> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: >> ARI reported sw[4/5]: 168a001 is v136d0 >> <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is >> unreported > > That looks fine I think. Get attributes fails at BTS level but then it > asks at transceiver level and it gets the information. The initial > failure is not important. > >> <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 >> STREAM=0x00 >> <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port >> 3003 >> <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN >> 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 >> BTS 0: Failure Event Report: Type=processing failure, Severity=critical >> failure, Probable cause=Manufacturer specific values: Fatal software >> error, Additional Text=l2_bch.c:1149 >> **** >> ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) >> ** IPA_SW_FATAL_ERROR >> ** In task "TRX Proc:L2_BCH" @ (325). >> **** >> > > Looks like the BTS doesn't like some type of SI we are sending to it. > A fulldebug log of osmo-bsc.cfg would help. I'm right now trying to > find in the pcap file were the SI info is sent. > > BTW, try using following setup, it's the one I did test with. Tell me > if you see any change: > ?? timeslot 0 > ??? phys_chan_config CCCH+SDCCH4 > ??? 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 PDCH > ??? hopping enabled 0 > ?? timeslot 7 > ??? phys_chan_config PDCH > ??? hopping enabled 0 > > Regards, > Pau > From allexander.alex at gmail.com Tue Nov 27 08:33:19 2018 From: allexander.alex at gmail.com (Alex) Date: Tue, 27 Nov 2018 09:33:19 +0100 Subject: Info on Alcatel Femtocells Message-ID: Hi to everyone! I'm a new member and I really appreciate the work done here! I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. Probably the femtocell has an internal trusted CA which validates server certs. I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. Has anyone any experience with this kind of HW or just an idea about a possible work around? Thank you and best regards Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Tue Nov 27 17:17:10 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Tue, 27 Nov 2018 18:17:10 +0100 (CET) Subject: Info on Alcatel Femtocells In-Reply-To: References: Message-ID: Hi Alex, Femtocells are provisioned with operator data - certificates/keys to be able to talk to the gateway. Some femtocells use EAP-SIM with an embedded SIM card, others just rely on the configuration. If your femto supports a SIM card you can use a SIM card with a known Ki to connect it to your gateway (strongswan I assume). If however there is no SIM card support in the femtocell then you need to somehow re-provision the device - probably using a proprietary software and method. Sorry, this is probably bad news for you. Kind regards, Domi 2018. nov. 27. d?tummal, 9:33 id?pontban Alex ?rta: > Hi to everyone! > > I'm a new member and I really appreciate the work done here! > > > I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. > > I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. > > Probably the femtocell has an internal trusted CA which validates server certs. > > > I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. > > > Has anyone any experience with this kind of HW or just an idea about a possible work around? > > > Thank you and best regards > > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Nov 27 17:55:20 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 27 Nov 2018 18:55:20 +0100 Subject: HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore! Message-ID: <20181127175520.GA21949@my.box> The adocs and vty reference content from osmo-gsm-manuals.git has been "moved" to the individual project repositories. That means if you apply more .adoc changes to osmo-gsm-manuals.git, we have to port that to the new location. (The content is not yet removed from osmo-gsm-manuals.git, so you might run into believing the move hasn't happened yet.) You can already edit in the individual osmo-bsc,-msc,... repositories, and build with 'configure --enable-manuals'. The jenkins publishing job isn't updated yet, should follow soon. right, osmith? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Tue Nov 27 17:57:40 2018 From: msuraev at sysmocom.de (Max) Date: Tue, 27 Nov 2018 18:57:40 +0100 Subject: HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore! In-Reply-To: <20181127175520.GA21949@my.box> References: <20181127175520.GA21949@my.box> Message-ID: <7e4da51a-4ca6-3d42-752a-1ceb7b4d9807@sysmocom.de> Is the patch removing it from old location available already? 27.11.18 18:55, Neels Hofmeyr ?????: > The content is not yet removed from osmo-gsm-manuals.git, so you might run into > believing the move hasn't happened yet. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From nhofmeyr at sysmocom.de Tue Nov 27 18:13:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 27 Nov 2018 19:13:40 +0100 Subject: osmo-gsm-manuals in project repos: I see no .pdf Message-ID: <20181127181340.GB21949@my.box> Hi Oliver, so I merged the stuff to add the manuals to the individual git repositories, since you said that it works. But when I do --enable-manuals I don't see any PDF files generated. Also a manual 'make pdf' says "nothing to be done". (I probably should have tried it before merging after all) So what am I doing wrong? Alternatively, can you fix it please? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From allexander.alex at gmail.com Tue Nov 27 18:56:47 2018 From: allexander.alex at gmail.com (Alex) Date: Tue, 27 Nov 2018 19:56:47 +0100 Subject: Info on Alcatel Femtocells In-Reply-To: References: Message-ID: Hi, thanks for the answer! This femto seems to have a discrete simcard (it has empty slot accessible from the external). I don't know the setup used by the original operator (TelecomItalia), because I bought it from ebay. I found a possible reset procedure (still to be tested), but I don't think it will "unlock" the board. Now I'm trying to find the UART on the board, but on the testpoints i only see "control" signals and clocks. Nothing seems to be a serial port pattern on my oscilloscope. On this site https://web.archive.org/web/20170707063235/https://wiki.thc.org/vodafone there are some information on a really similar cell (9361 I think) from Vodafone, which has a relly similar IPSEC config, but there ins't any spec. No one tried to disassemble it or do have just the serial pinout on the board? On the other side I've already deployed the CN part (HLR + MSC + SSGN + GSGN + STP + MGW + HNBGW), which seems to be fully operational, but i can't test without a test cell. I also thing the IuH protocol of this femto is little out-of-standard, but from ALU documentation I can't understand the differences with standard IuH. The idea is to implement ALU's IuH variant on HNBGW if i can take traces from a "lab" env, but without the femto it's just impossible. Il giorno mar 27 nov 2018 alle ore 18:17 Tomcs?nyi, Domonkos < domi at tomcsanyi.net> ha scritto: > Hi Alex, > > Femtocells are provisioned with operator data - certificates/keys to be > able to talk to the gateway. > Some femtocells use EAP-SIM with an embedded SIM card, others just rely on > the configuration. If your femto supports a SIM card you can use a SIM card > with a known Ki to connect it to your gateway (strongswan I assume). > If however there is no SIM card support in the femtocell then you need to > somehow re-provision the device - probably using a proprietary software and > method. > Sorry, this is probably bad news for you. > > Kind regards, > Domi > > > 2018. nov. 27. d?tummal, 9:33 id?pontban Alex > ?rta: > > Hi to everyone! > > I'm a new member and I really appreciate the work done here! > > > I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, > but I'm still blocked at the IPSEC tunnel step. > > I've created an IPSEC server with EAP support, but I suspect there is a > problem with my self signed certificate. > > Probably the femtocell has an internal trusted CA which validates server > certs. > > > I din't find the console pins on the board also, so I cannot simply > connect to it and have a look at the system level. > > > Has anyone any experience with this kind of HW or just an idea about a > possible work around? > > > Thank you and best regards > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allexander.alex at gmail.com Tue Nov 27 18:57:22 2018 From: allexander.alex at gmail.com (Alex) Date: Tue, 27 Nov 2018 19:57:22 +0100 Subject: Info on Alcatel Femtocells In-Reply-To: References: Message-ID: Hi, little UP: Vodafone UK and other OpCo like it (VF DE and VF GR I think) made a local femtocell network based on similar platform from ALU. Does anyone know something/ever tried to make something like connecting one of these devs to osmoHNBGW or similar? Thank you and best regards Il giorno mar 27 nov 2018 alle ore 19:56 Alex ha scritto: > Hi, > thanks for the answer! > > This femto seems to have a discrete simcard (it has empty slot accessible > from the external). > > I don't know the setup used by the original operator (TelecomItalia), > because I bought it from ebay. > > I found a possible reset procedure (still to be tested), but I don't think > it will "unlock" the board. > Now I'm trying to find the UART on the board, but on the testpoints i only > see "control" signals and clocks. Nothing seems to be a serial port pattern > on my oscilloscope. > > On this site > https://web.archive.org/web/20170707063235/https://wiki.thc.org/vodafone > there are some information on a really similar cell (9361 I think) from > Vodafone, which has a relly similar IPSEC config, but there ins't any spec. > > No one tried to disassemble it or do have just the serial pinout on the > board? > > On the other side I've already deployed the CN part (HLR + MSC + SSGN + > GSGN + STP + MGW + HNBGW), which seems to be fully operational, but i can't > test without a test cell. > I also thing the IuH protocol of this femto is little out-of-standard, but > from ALU documentation I can't understand the differences with standard IuH. > > The idea is to implement ALU's IuH variant on HNBGW if i can take traces > from a "lab" env, but without the femto it's just impossible. > > Il giorno mar 27 nov 2018 alle ore 18:17 Tomcs?nyi, Domonkos < > domi at tomcsanyi.net> ha scritto: > >> Hi Alex, >> >> Femtocells are provisioned with operator data - certificates/keys to be >> able to talk to the gateway. >> Some femtocells use EAP-SIM with an embedded SIM card, others just rely >> on the configuration. If your femto supports a SIM card you can use a SIM >> card with a known Ki to connect it to your gateway (strongswan I assume). >> If however there is no SIM card support in the femtocell then you need to >> somehow re-provision the device - probably using a proprietary software and >> method. >> Sorry, this is probably bad news for you. >> >> Kind regards, >> Domi >> >> >> 2018. nov. 27. d?tummal, 9:33 id?pontban Alex >> ?rta: >> >> Hi to everyone! >> >> I'm a new member and I really appreciate the work done here! >> >> >> I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with >> osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. >> >> I've created an IPSEC server with EAP support, but I suspect there is a >> problem with my self signed certificate. >> >> Probably the femtocell has an internal trusted CA which validates server >> certs. >> >> >> I din't find the console pins on the board also, so I cannot simply >> connect to it and have a look at the system level. >> >> >> Has anyone any experience with this kind of HW or just an idea about a >> possible work around? >> >> >> Thank you and best regards >> Alex >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Tue Nov 27 22:43:12 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Tue, 27 Nov 2018 23:43:12 +0100 (CET) Subject: Info on Alcatel Femtocells In-Reply-To: References: Message-ID: <2E84A6C6-9615-406E-86DC-09B18D01ED5C@tomcsanyi.net> Hi Alex, I have a couple of those femtocells (Vodafone UK SureSignal versions 1.5 and 2.0). I did some research on them abour 4-5 years ago I think. The SureSignal uses an embedded crypto chip to generate keys IIRC. I also had the chance to have a look at a rooted board for some time (it was lent to me). The THC wiki has pretty much all the info about the board. I also was not able to find any UART or serial port on it when I looked. I wanted to dump the flash but then got busy with other stuff. Maybe the debug fuses are blown in the factory as well. Anyways if you wish to do tests or try out something with the device(s) I can dig them up, they must be somewhere in my cabinet. As far as I remember though the actual femtocell implementation is a closed source binary blob, but strongswan (or maybe openswan? I cannot recall exactly) is used for the IPsec part, terefore I have a source code tree downloaded somewhere as well. Alcatel or Vodafone stayed compliant to GPL so the code was released. If only we were able to reconfigure the strongswan daemon on the device then we could connect it to your network. Provisioning of some parametere (e.g. frequency, Routing Area Code, allowed IMSIs) is done via XML files I think inside the ipsec tunnel. Now back to changing the ipsec configuration: dumping the flash and then changing the config would be a good way to do it, although that would not be a generic solution, but as a pilot it could just work. I am also not sure if there are any cryptographic signatures protecting the firmware, but I would guess probably not. Sorry for the inconsistent rambling this email turned into, I wrote things as they surfaced from the back of my brain, hidden parts of my memory :) Cheers, Domi 2018. nov. 27. d?tummal, 19:57 id?pontban Alex ?rta: > Hi, > little UP: > > Vodafone UK and other OpCo like it (VF DE and VF GR I think) made a local femtocell network based on similar platform from ALU. > > Does anyone know something/ever tried to make something like connecting one of these devs to osmoHNBGW or similar? > > Thank you and best regards > >> Il giorno mar 27 nov 2018 alle ore 19:56 Alex ha scritto: >> Hi, >> thanks for the answer! >> >> This femto seems to have a discrete simcard (it has empty slot accessible from the external). >> >> I don't know the setup used by the original operator (TelecomItalia), because I bought it from ebay. >> >> I found a possible reset procedure (still to be tested), but I don't think it will "unlock" the board. >> Now I'm trying to find the UART on the board, but on the testpoints i only see "control" signals and clocks. Nothing seems to be a serial port pattern on my oscilloscope. >> >> On this site https://web.archive.org/web/20170707063235/https://wiki.thc.org/vodafone there are some information on a really similar cell (9361 I think) from Vodafone, which has a relly similar IPSEC config, but there ins't any spec. >> >> No one tried to disassemble it or do have just the serial pinout on the board? >> >> On the other side I've already deployed the CN part (HLR + MSC + SSGN + GSGN + STP + MGW + HNBGW), which seems to be fully operational, but i can't test without a test cell. >> I also thing the IuH protocol of this femto is little out-of-standard, but from ALU documentation I can't understand the differences with standard IuH. >> >> The idea is to implement ALU's IuH variant on HNBGW if i can take traces from a "lab" env, but without the femto it's just impossible. >> >>> Il giorno mar 27 nov 2018 alle ore 18:17 Tomcs?nyi, Domonkos ha scritto: >>> Hi Alex, >>> >>> Femtocells are provisioned with operator data - certificates/keys to be able to talk to the gateway. >>> Some femtocells use EAP-SIM with an embedded SIM card, others just rely on the configuration. If your femto supports a SIM card you can use a SIM card with a known Ki to connect it to your gateway (strongswan I assume). >>> If however there is no SIM card support in the femtocell then you need to somehow re-provision the device - probably using a proprietary software and method. >>> Sorry, this is probably bad news for you. >>> >>> Kind regards, >>> Domi >>> >>> >>> 2018. nov. 27. d?tummal, 9:33 id?pontban Alex ?rta: >>> >>>> Hi to everyone! >>>> >>>> I'm a new member and I really appreciate the work done here! >>>> >>>> >>>> I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. >>>> >>>> I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. >>>> >>>> Probably the femtocell has an internal trusted CA which validates server certs. >>>> >>>> >>>> I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. >>>> >>>> >>>> Has anyone any experience with this kind of HW or just an idea about a possible work around? >>>> >>>> >>>> Thank you and best regards >>>> >>>> Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Nov 27 23:04:31 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 28 Nov 2018 00:04:31 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <20181127230431.GC21949@my.box> Looking at the dudle, I now see that clearly this is your favorite: "merge at three votes, by enforcing from gerrit: we install a plugin to add up voting, +3 allows to merge, at first no-one has +3 permissions" So, we need a volunteer to try out that prolog snippet Max pointed out: https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_example_13_1_1_2_code_review I'd suggest first in a local sandbox gerrit. We might even have an ansible to setup our gerrit which could be useful to create a testing instance, not sure. If we do, someone please point to it here. If you have it figured out and tested, get access and install it on our production gerrit. Ideal would be a scripted/ansible installation. Also ideal would be to make sure a backup has run recently before you start. The strongest proponents seem to be Max, pau, osmith, daniel. Thanks! Once this is in place, we will probably have a discussion about whether some people get direct +3 permissions (matching the request for another option "some people have +3 permissions" seen in the dudle comments). I'd prefer if this would happen sooner rather than later. Still this week maybe? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From allexander.alex at gmail.com Tue Nov 27 23:32:18 2018 From: allexander.alex at gmail.com (Alex) Date: Wed, 28 Nov 2018 00:32:18 +0100 Subject: Info on Alcatel Femtocells In-Reply-To: <2E84A6C6-9615-406E-86DC-09B18D01ED5C@tomcsanyi.net> References: <2E84A6C6-9615-406E-86DC-09B18D01ED5C@tomcsanyi.net> Message-ID: Hi Domi, it will be fantastic if you can share the results of your research, especially the IPSEC part! Now I'm trying to emulate the secgw on my machine, but it's a black box problem without the serial console. Thank you!!! Il giorno mar 27 nov 2018 alle ore 23:43 Tomcs?nyi, Domonkos < domi at tomcsanyi.net> ha scritto: > Hi Alex, > > I have a couple of those femtocells (Vodafone UK SureSignal versions 1.5 > and 2.0). I did some research on them abour 4-5 years ago I think. > The SureSignal uses an embedded crypto chip to generate keys IIRC. I also > had the chance to have a look at a rooted board for some time (it was lent > to me). The THC wiki has pretty much all the info about the board. > I also was not able to find any UART or serial port on it when I looked. I > wanted to dump the flash but then got busy with other stuff. Maybe the > debug fuses are blown in the factory as well. > Anyways if you wish to do tests or try out something with the device(s) I > can dig them up, they must be somewhere in my cabinet. > As far as I remember though the actual femtocell implementation is a > closed source binary blob, but strongswan (or maybe openswan? I cannot > recall exactly) is used for the IPsec part, terefore I have a source code > tree downloaded somewhere as well. Alcatel or Vodafone stayed compliant to > GPL so the code was released. If only we were able to reconfigure the > strongswan daemon on the device then we could connect it to your network. > Provisioning of some parametere (e.g. frequency, Routing Area Code, allowed > IMSIs) is done via XML files I think inside the ipsec tunnel. > Now back to changing the ipsec configuration: dumping the flash and then > changing the config would be a good way to do it, although that would not > be a generic solution, but as a pilot it could just work. > I am also not sure if there are any cryptographic signatures protecting > the firmware, but I would guess probably not. > > Sorry for the inconsistent rambling this email turned into, I wrote things > as they surfaced from the back of my brain, hidden parts of my memory :) > > Cheers, > Domi > > 2018. nov. 27. d?tummal, 19:57 id?pontban Alex > ?rta: > > Hi, > little UP: > > Vodafone UK and other OpCo like it (VF DE and VF GR I think) made a local > femtocell network based on similar platform from ALU. > > Does anyone know something/ever tried to make something like connecting > one of these devs to osmoHNBGW or similar? > Thank you and best regards > > Il giorno mar 27 nov 2018 alle ore 19:56 Alex > ha scritto: > >> Hi, >> thanks for the answer! >> >> This femto seems to have a discrete simcard (it has empty slot accessible >> from the external). >> >> I don't know the setup used by the original operator (TelecomItalia), >> because I bought it from ebay. >> >> I found a possible reset procedure (still to be tested), but I don't >> think it will "unlock" the board. >> Now I'm trying to find the UART on the board, but on the testpoints i >> only see "control" signals and clocks. Nothing seems to be a serial port >> pattern on my oscilloscope. >> >> On this site >> https://web.archive.org/web/20170707063235/https://wiki.thc.org/vodafone >> there are some information on a really similar cell (9361 I think) from >> Vodafone, which has a relly similar IPSEC config, but there ins't any spec. >> >> No one tried to disassemble it or do have just the serial pinout on the >> board? >> >> On the other side I've already deployed the CN part (HLR + MSC + SSGN + >> GSGN + STP + MGW + HNBGW), which seems to be fully operational, but i can't >> test without a test cell. >> I also thing the IuH protocol of this femto is little out-of-standard, >> but from ALU documentation I can't understand the differences with standard >> IuH. >> >> The idea is to implement ALU's IuH variant on HNBGW if i can take traces >> from a "lab" env, but without the femto it's just impossible. >> >> Il giorno mar 27 nov 2018 alle ore 18:17 Tomcs?nyi, Domonkos < >> domi at tomcsanyi.net> ha scritto: >> >>> Hi Alex, >>> >>> Femtocells are provisioned with operator data - certificates/keys to be >>> able to talk to the gateway. >>> Some femtocells use EAP-SIM with an embedded SIM card, others just rely >>> on the configuration. If your femto supports a SIM card you can use a SIM >>> card with a known Ki to connect it to your gateway (strongswan I assume). >>> If however there is no SIM card support in the femtocell then you need >>> to somehow re-provision the device - probably using a proprietary software >>> and method. >>> Sorry, this is probably bad news for you. >>> >>> Kind regards, >>> Domi >>> >>> >>> 2018. nov. 27. d?tummal, 9:33 id?pontban Alex >>> ?rta: >>> >>> Hi to everyone! >>> >>> I'm a new member and I really appreciate the work done here! >>> >>> >>> I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with >>> osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. >>> >>> I've created an IPSEC server with EAP support, but I suspect there is a >>> problem with my self signed certificate. >>> >>> Probably the femtocell has an internal trusted CA which validates server >>> certs. >>> >>> >>> I din't find the console pins on the board also, so I cannot simply >>> connect to it and have a look at the system level. >>> >>> >>> Has anyone any experience with this kind of HW or just an idea about a >>> possible work around? >>> >>> >>> Thank you and best regards >>> Alex >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmith at sysmocom.de Wed Nov 28 09:05:10 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 28 Nov 2018 10:05:10 +0100 Subject: osmo-gsm-manuals in project repos: I see no .pdf In-Reply-To: <20181127181340.GB21949@my.box> References: <20181127181340.GB21949@my.box> Message-ID: <3fb98e7e-7b5e-4851-dc36-798f62d1ee96@sysmocom.de> Worked for me? I'll look into it right away. On 11/27/18 7:13 PM, Neels Hofmeyr wrote: > Hi Oliver, > > so I merged the stuff to add the manuals to the individual git repositories, > since you said that it works. But when I do --enable-manuals I don't see any > PDF files generated. Also a manual 'make pdf' says "nothing to be done". > > (I probably should have tried it before merging after all) > > So what am I doing wrong? Alternatively, can you fix it please? > > ~N > -- - 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 osmith at sysmocom.de Wed Nov 28 09:12:50 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 28 Nov 2018 10:12:50 +0100 Subject: osmo-gsm-manuals in project repos: I see no .pdf In-Reply-To: <3fb98e7e-7b5e-4851-dc36-798f62d1ee96@sysmocom.de> References: <20181127181340.GB21949@my.box> <3fb98e7e-7b5e-4851-dc36-798f62d1ee96@sysmocom.de> Message-ID: <4cc59d0c-5996-3b1f-38f7-5e18dde5788c@sysmocom.de> Oh, you were probably looking for them in the root directory, right? They get placed in doc/manuals/: $ cd osmo-bsc $ ./configure --enable-manuals $ make $ find -name '*.pdf' ./doc/manuals/osmobsc-vty-reference.pdf ./doc/manuals/osmux-reference.pdf ./doc/manuals/osmobsc-usermanual.pdf ./doc/manuals/aoip-mgw-options.pdf $ cd ../osmo-msc $ ./configure --enable-manuals $ make $ find -name '*.pdf' ./doc/manuals/osmomsc-usermanual.pdf ./doc/manuals/osmomsc-vty-reference.pdf Sorry for the confusion and thanks for merging the patches. I see that you have even adjusted the commit message everywhere. Oliver On 11/28/18 10:05 AM, Oliver Smith wrote: > Worked for me? > > I'll look into it right away. > > > On 11/27/18 7:13 PM, Neels Hofmeyr wrote: >> Hi Oliver, >> >> so I merged the stuff to add the manuals to the individual git repositories, >> since you said that it works. But when I do --enable-manuals I don't see any >> PDF files generated. Also a manual 'make pdf' says "nothing to be done". >> >> (I probably should have tried it before merging after all) >> >> So what am I doing wrong? Alternatively, can you fix it please? >> >> ~N >> > -- - 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 osmith at sysmocom.de Wed Nov 28 09:24:43 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 28 Nov 2018 10:24:43 +0100 Subject: HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore! In-Reply-To: <20181127175520.GA21949@my.box> References: <20181127175520.GA21949@my.box> Message-ID: <2b91ff32-f6a4-e27e-beda-0db81de9257b@sysmocom.de> On 11/27/18 6:55 PM, Neels Hofmeyr wrote: > The adocs and vty reference content from osmo-gsm-manuals.git has been "moved" > to the individual project repositories. That means if you apply more .adoc > changes to osmo-gsm-manuals.git, we have to port that to the new location. > (The content is not yet removed from osmo-gsm-manuals.git, so you might run into > believing the move hasn't happened yet.) > > You can already edit in the individual osmo-bsc,-msc,... repositories, > and build with 'configure --enable-manuals'. Please note that the generated PDFs end up in doc/manuals. > The jenkins publishing job isn't updated yet, should follow soon. > right, osmith? Yes. Progress is documented here: https://osmocom.org/issues/3385 -- - 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 osmith at sysmocom.de Wed Nov 28 09:27:17 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 28 Nov 2018 10:27:17 +0100 Subject: HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore! In-Reply-To: <7e4da51a-4ca6-3d42-752a-1ceb7b4d9807@sysmocom.de> References: <20181127175520.GA21949@my.box> <7e4da51a-4ca6-3d42-752a-1ceb7b4d9807@sysmocom.de> Message-ID: <6a159a09-9edf-4576-e179-152853f8b1ed@sysmocom.de> On 11/27/18 6:57 PM, Max wrote: > Is the patch removing it from old location available already? I'll put up the patches soon. (Pau had requested to make one patch for reach moved dir, not one patch that does it all.) > 27.11.18 18:55, Neels Hofmeyr ?????: >> The content is not yet removed from osmo-gsm-manuals.git, so you might >> run into >> believing the move hasn't happened yet. > -- - 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 osmith at sysmocom.de Wed Nov 28 10:03:59 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 28 Nov 2018 11:03:59 +0100 Subject: HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore! In-Reply-To: <6a159a09-9edf-4576-e179-152853f8b1ed@sysmocom.de> References: <20181127175520.GA21949@my.box> <7e4da51a-4ca6-3d42-752a-1ceb7b4d9807@sysmocom.de> <6a159a09-9edf-4576-e179-152853f8b1ed@sysmocom.de> Message-ID: <31d56e79-6a82-ed86-ab46-612a1d2331f5@sysmocom.de> On 11/28/18 10:27 AM, Oliver Smith wrote: > On 11/27/18 6:57 PM, Max wrote: >> Is the patch removing it from old location available already? > > I'll put up the patches soon. (Pau had requested to make one patch for > reach moved dir, not one patch that does it all.) > Done: https://gerrit.osmocom.org/#/q/topic:move-manuals+status:open -- - 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 allexander.alex at gmail.com Thu Nov 29 18:10:23 2018 From: allexander.alex at gmail.com (Alex) Date: Thu, 29 Nov 2018 19:10:23 +0100 Subject: Info on Alcatel Femtocells In-Reply-To: References: <2E84A6C6-9615-406E-86DC-09B18D01ED5C@tomcsanyi.net> Message-ID: Hi little update(s): I think I've found something on a Russian site about the signaling protocols. I've also found a memory dump of the femto, but there is a major problem: the dump is partial (ALU put 2 memories on the board) and i can only access to the main fs of the system ALU datas and configs are on anoter path (/opt/alu/fbsr and /mnt/mainfs) which mounts the secondary memory, so nothing can be done. Also the SVN at *https://forge.betavine.net/svn/voda-femtocell * is currently offine without any mirror. Does anyone have a backup or a mirror somewhere? Thank you and best regards Il giorno mer 28 nov 2018 alle ore 00:32 Alex ha scritto: > Hi Domi, > it will be fantastic if you can share the results of your research, > especially the IPSEC part! > Now I'm trying to emulate the secgw on my machine, but it's a black box > problem without the serial console. > > Thank you!!! > > > Il giorno mar 27 nov 2018 alle ore 23:43 Tomcs?nyi, Domonkos < > domi at tomcsanyi.net> ha scritto: > >> Hi Alex, >> >> I have a couple of those femtocells (Vodafone UK SureSignal versions 1.5 >> and 2.0). I did some research on them abour 4-5 years ago I think. >> The SureSignal uses an embedded crypto chip to generate keys IIRC. I also >> had the chance to have a look at a rooted board for some time (it was lent >> to me). The THC wiki has pretty much all the info about the board. >> I also was not able to find any UART or serial port on it when I looked. >> I wanted to dump the flash but then got busy with other stuff. Maybe the >> debug fuses are blown in the factory as well. >> Anyways if you wish to do tests or try out something with the device(s) I >> can dig them up, they must be somewhere in my cabinet. >> As far as I remember though the actual femtocell implementation is a >> closed source binary blob, but strongswan (or maybe openswan? I cannot >> recall exactly) is used for the IPsec part, terefore I have a source code >> tree downloaded somewhere as well. Alcatel or Vodafone stayed compliant to >> GPL so the code was released. If only we were able to reconfigure the >> strongswan daemon on the device then we could connect it to your network. >> Provisioning of some parametere (e.g. frequency, Routing Area Code, allowed >> IMSIs) is done via XML files I think inside the ipsec tunnel. >> Now back to changing the ipsec configuration: dumping the flash and then >> changing the config would be a good way to do it, although that would not >> be a generic solution, but as a pilot it could just work. >> I am also not sure if there are any cryptographic signatures protecting >> the firmware, but I would guess probably not. >> >> Sorry for the inconsistent rambling this email turned into, I wrote >> things as they surfaced from the back of my brain, hidden parts of my >> memory :) >> >> Cheers, >> Domi >> >> 2018. nov. 27. d?tummal, 19:57 id?pontban Alex >> ?rta: >> >> Hi, >> little UP: >> >> Vodafone UK and other OpCo like it (VF DE and VF GR I think) made a local >> femtocell network based on similar platform from ALU. >> >> Does anyone know something/ever tried to make something like connecting >> one of these devs to osmoHNBGW or similar? >> Thank you and best regards >> >> Il giorno mar 27 nov 2018 alle ore 19:56 Alex >> ha scritto: >> >>> Hi, >>> thanks for the answer! >>> >>> This femto seems to have a discrete simcard (it has empty slot >>> accessible from the external). >>> >>> I don't know the setup used by the original operator (TelecomItalia), >>> because I bought it from ebay. >>> >>> I found a possible reset procedure (still to be tested), but I don't >>> think it will "unlock" the board. >>> Now I'm trying to find the UART on the board, but on the testpoints i >>> only see "control" signals and clocks. Nothing seems to be a serial port >>> pattern on my oscilloscope. >>> >>> On this site >>> https://web.archive.org/web/20170707063235/https://wiki.thc.org/vodafone >>> there are some information on a really similar cell (9361 I think) from >>> Vodafone, which has a relly similar IPSEC config, but there ins't any spec. >>> >>> No one tried to disassemble it or do have just the serial pinout on the >>> board? >>> >>> On the other side I've already deployed the CN part (HLR + MSC + SSGN + >>> GSGN + STP + MGW + HNBGW), which seems to be fully operational, but i can't >>> test without a test cell. >>> I also thing the IuH protocol of this femto is little out-of-standard, >>> but from ALU documentation I can't understand the differences with standard >>> IuH. >>> >>> The idea is to implement ALU's IuH variant on HNBGW if i can take traces >>> from a "lab" env, but without the femto it's just impossible. >>> >>> Il giorno mar 27 nov 2018 alle ore 18:17 Tomcs?nyi, Domonkos < >>> domi at tomcsanyi.net> ha scritto: >>> >>>> Hi Alex, >>>> >>>> Femtocells are provisioned with operator data - certificates/keys to be >>>> able to talk to the gateway. >>>> Some femtocells use EAP-SIM with an embedded SIM card, others just rely >>>> on the configuration. If your femto supports a SIM card you can use a SIM >>>> card with a known Ki to connect it to your gateway (strongswan I assume). >>>> If however there is no SIM card support in the femtocell then you need >>>> to somehow re-provision the device - probably using a proprietary software >>>> and method. >>>> Sorry, this is probably bad news for you. >>>> >>>> Kind regards, >>>> Domi >>>> >>>> >>>> 2018. nov. 27. d?tummal, 9:33 id?pontban Alex < >>>> allexander.alex at gmail.com> ?rta: >>>> >>>> Hi to everyone! >>>> >>>> I'm a new member and I really appreciate the work done here! >>>> >>>> >>>> I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with >>>> osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. >>>> >>>> I've created an IPSEC server with EAP support, but I suspect there is a >>>> problem with my self signed certificate. >>>> >>>> Probably the femtocell has an internal trusted CA which validates >>>> server certs. >>>> >>>> >>>> I din't find the console pins on the board also, so I cannot simply >>>> connect to it and have a look at the system level. >>>> >>>> >>>> Has anyone any experience with this kind of HW or just an idea about a >>>> possible work around? >>>> >>>> >>>> Thank you and best regards >>>> Alex >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: