February 2017 - OpenBSC - lists.osmocom.org

by OMAR RAMADAN

If the SIP server dies in the middle of a call, osmo-sip-connector is in a bad state and generates a never ending stream of error messages: 58): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f25 It looks like the messages are generated from sofia-sip and I have managed to suppress the messages by setting the environment variable SU_DEBUG < 3: http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_… However, it looks like osmo-sip-connector is clearly in a bad state when this happens and we need a way to detect and release these ghosted calls.

7 years, 2 months

4
15
0 0

Virtual layer 1 - Questions

by Sebastian Stumpf

Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-… Kind Regards, Sebastian Stumpf

7 years, 2 months

2
7
0 0

libosmo-netif failed on both jenkins FreeBSD and xUbuntu_16.04/i586

by Neels Hofmeyr

It seems to be a sporadic failure due to timing. Kicking off the same build on jenkins resulted in success. Can anyone relaunch the OBS build? I'm not too familiar with it... http://jenkins.osmocom.org/jenkins/job/libosmo-netif/ https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Also, it would actually be nice if the opensuse builds also printed all test logs as in osmo-ci/scripts/cat-testlogs.sh -- if anyone knows how and has the time to insert such, that would be great. (git clone https://gerrit.osmocom.org/osmo-ci) Thanks, ~N

7 years, 2 months

2
1
0 0

Handover and load balancing on SysmoBTS 2050

by Keith

Hi list, Hi all. This is quite Rhizomatica, or at least litecel 2050 specific, please excuse me for that. I also don't know, maybe it applies to other use cases. Rhizomatica has one community where an attempt was made to increase coverage at the same time as capacity, by installing two 2050s with a somewhat overlapping coverage area. We have currently plans to do the same in other places. The goal of this email is to try to establish the work needed to be done in order to fix what I outline below, I may just be lacking knowledge in some cases, in other It seems we need to implement some things. I have grabbed fairwaves' meas_json and meas_web and modified a little to give me a visualisation of the neighbour meas reports. So my first doubt is about idle cell reselection on the part of the MS. It doesn't seem to be operating quite as I would imagine it should and I am wondering is there any parameter that might make a difference, such as cell_identity? Is cell reselection hysteresis/offset relevant when handover is disabled? These parameters are not described in the manual. If I understood them I could update that. In the meantime, we seem to be getting reports from users that "the signal is weak" near what I might call the secondary BTS. At the same time, user reports are not terribly reliable. However what seems to be happening is that the MS is camped on the primary BTS, subsequently they have moved away so their handset is showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS that are showing neighbour measurements from the secondary that are more favourable. Of course, I am often seeing messages such as: handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better: Skipping, Handover disabled Obviously, this makes sense, and I am not sure why historically we have handover disabled, I presume it is issues with rtp, although we are using the rtp_proxy. I don't have two BTS so I can't test locally here. Could anybody comment on the state of that? I am assuming that there is no way we can do load balancing unless we first have handover enabled, at the same time it is unclear to me if it will even work with handover. I believe this is called "Traffic Handover" Is this already implemented in the BSC? As in, can the BSC assign a channel on another ARFCN to the MS if the current ARFCN (the one the MS makes the access request on) has no TCH available? I also have a doubt about operation with a Litecel/2050. Obviously you don't really want rescue handover operating between the two BTS that are present in the Litecel as it is the same antenna, and this shouldn't happen anyway as the signal levels should never be sufficiently different, but we do want load balancing handover. I do see "no resources available" log messages, (especially related to the BROKEN channels issue) when one BTS in a litecel has no more capacity but the other does, so it would seem that the BSC is not managing this. Is that correct? Would it be correct to assume that maybe some handover rules are required that would specify: Handover from BTS 0 to BTS 3 but not from BTS 0 to BTS 1? Finally, I have a doubt about the rtp proxy mode. Was it ever discussed to implement SIP Mobility aka re-Invite in order to be able to do BTS-MGW rtp and also handover? This would seem to me to be a good thing to have? k/

7 years, 2 months

5
14
0 0

vlr+hlr: Insert Data

by Neels Hofmeyr

What should we do if the HLR sends no Insert Data? When a subscriber does a Location Updating, the VLR sends a Location Updating request to the HLR. The HLR typically responds with a Location Updating Result as success and, in a *separate* message, sends an Insert Data to the VLR to tell it the subscriber's MSISDN. So it is possible to do a successful Location Updating without being told the MSISDN (as my test verifies). What should the VLR do if it never receives the Insert Data from the HLR? In that case the subscriber is attached but cannot be reached by MSISDN. Should we actively wait for Inser Data and reject the subscriber if not successful? It would be fairly easy to just send the MSISDN along in the Location Updating Result. Why this separate message? Thx, ~N

7 years, 2 months

4
7
0 0

Ki and OPC values change when programming MCC and MNC

by Giselle Gonzalez lopez

Hello, We have already contacted our SIM cards provider (sysmocom), and they have referred us towards this Mailing List. We have purchased sysmoUSIM-SJS1 cards and we are having the following problem when trying to program them: We want to change the MCC and MNC values to the ones of our OpenAirInterface LTE system, and Ki and OPC of the SIM card are changing despite we are not intending for that to happen. The main issue with this behavior is that as we have two sets of Ki and OPC values, when we are going to register the user in the LTE database, we don't know for sure which set of parameters we are supposed to introduce. Here on I'll describe the configuration we are using and the commands introduced when programming the SIM cards: As programming software we are using PySIM. The default parameters of the SIM we are programming are: ADM: 20168462 ICCID: 8988211000000099120 Ki: 5B868E2B30C61190ABEFBA1CA6F6D56F OPC: B3425076F23BA6054557FA359B4F9C0C The parameters we are meaning to program are: MCC: 001 MNC: 01 IMSI: 001010000009912 The command we are using to program in the SIM card is: ./pySim-prog.py -p 0 -a 20168462 -x 001 -y 01 -t sysmoUSIM-SJS1 -i 001010000009912 -s 8988211000000099120 And after programming the card, we are getting this: [image: Imágenes integradas 1] Do you what's the reason why this is happening? Thank you very much for your time Best regards, Giselle Glez

7 years, 2 months

4
8
0 0

OsmoHLR and IPA unit id

by Neels Hofmeyr

I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N

7 years, 2 months

2
2
0 0

Re: OpenBSC Digest, Vol 28, Issue 20

by Rajitha peiris

Hi all I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts Thank you very much Regards Rajitha peiris Sent from my iPhone On Feb 24, 2017, at 9:42 PM, "openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>" <openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>> wrote: Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org> You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org<mailto:openbsc-owner@lists.osmocom.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: Ki and OPC values change when programming MCC and MNC (Holger Freyther) 2. Re: Virtual layer 1 - Questions (Harald Welte) 3. OsmoHLR and IPA unit id (Neels Hofmeyr) 4. Re: Handover and load balancing on SysmoBTS 2050 (Keith) 5. Re: OsmoHLR and IPA unit id (Harald Welte) 6. Re: Handover and load balancing on SysmoBTS 2050 (Keith) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Feb 2017 15:25:56 +0700 From: Holger Freyther <holger(a)freyther.de<mailto:holger@freyther.de>> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: "openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Ki and OPC values change when programming MCC and MNC Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C(a)freyther.de<mailto:31579AC7-F837-49F1-9EDC-C0B8D2CCC85C@freyther.de>> Content-Type: text/plain; charset=us-ascii On 23 Feb 2017, at 09:53, Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> wrote: On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote: --help will tell you defaults for Ki and OPC is to randomize ... Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say right at the top that you normally want to pass -k and -o when calling pysim. After all, none of the other options do that. anyway... "normally".. for the batch mode as used at XC3 events the "normal" is to generate a random KI, you wouldn't want to do that by hand 4k times. :) holger ------------------------------ Message: 2 Date: Thu, 23 Feb 2017 15:41:24 +0100 From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> To: Sebastian Stumpf <sebastian.stumpf87(a)googlemail.com<mailto:sebastian.stumpf87@googlemail.com>> Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>, baseband-devel(a)lists.osmocom.org<mailto:baseband-devel@lists.osmocom.org> Subject: Re: Virtual layer 1 - Questions Message-ID: <20170223144124.mdba7w7avdujy23g@nataraja> Content-Type: text/plain; charset=us-ascii Hi Sebastian, On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote: I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer… good. Also, RACH retransmissions are happening way too quick. Calculating a proper frame number didn't fix the fast retransmissions. They are caused by sending the channel request over the virtual um immediately after getting the rach-request from layer23. Thus also the rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its already transmitted" and will generate the next rach-request for my layer 1. i see. the confirmation should probably be delayed somehow. As a quick intermediate hack you might simply add a timer. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. I think to fix the problem with the quick retransmission , I need some type of scheduling. Because if I queue the incoming uplink-msgs in the bts-virtual-layer1 instead, I don't know when they are processed on the ms side and thus don't know when to send the rach-confirm to layer23... My idea for a simple scheduler would be: -- no timing and timer interrupts on ms side, but just set the current fn in the ms state each time we receive a message on downlink to the fn of the received message, which is accessible in the gsmtap header. yes, that makes sense. -- queue the outgoing uplink messages with their confirm callback to l2 and process all that with a smaller fn than the current fn in the scheduling function. yes, but please keep in mind that the frame number is wrapping every so often, so "smaller" must consider that modulo-arithmetic, or you will (after fn wrap) have pending downlink messages for much higher fn which are not sent as the wrapped fn is now very small. -- calling the scheduling function each time we receive a msg on downlink (so I do not need to handle timer interrupts) yes. I think it is reasonable to not have any actual timers on the ms side and always depend on the frame numbers in the downlink messages from the BTS. After all, in the worst case you have periodic messages like the BCCH messages that can be used to update the fn. I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble caused by the frame number skipping values with the upper incrementation logic. I don't think skips are that problematic. But then, I haven't tried it ;) -- - Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Fri, 24 Feb 2017 06:43:26 +0100 From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> To: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: OsmoHLR and IPA unit id Message-ID: <20170224054326.GB1368(a)my.box<mailto:20170224054326.GB1368@my.box>> Content-Type: text/plain; charset="us-ascii" I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch Type: text/x-diff Size: 2550 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…> ------------------------------ Message: 4 Date: Fri, 24 Feb 2017 16:42:35 +0100 From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>> To: Alexander Chemeris <alexander.chemeris(a)gmail.com<mailto:alexander.chemeris@gmail.com>> Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f(a)rhizomatica.org<mailto:39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org>> Content-Type: text/plain; charset=utf-8 Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array. I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario. I'm wondering what to do with this work. Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right. Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative. I can publish my work on meas_web to github. Keith. ------------------------------ Message: 5 Date: Fri, 24 Feb 2017 16:53:03 +0100 From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: OsmoHLR and IPA unit id Message-ID: <20170224155303.tuidxovd4qbzp5go@nataraja> Content-Type: text/plain; charset=us-ascii Hi Neels, IPA CCM made sense on the Abis interface, where each BTS reports with its unit_id and MAC address. I'm not quite sure how much sense that makes in the core network. I also don't know if existing implementations of e.g. A interface over IPA multiplex actually use it. In terms of future outlook, the MSC/VLR/SGSN should register at the HLR with some kind of identity. In MAP, it is the SCCP Address that is used for this purpose. In absence of SCCP on GSUP, I used the CCM identity as a replacement. However, it is used as an opaque string, so that any GSUP/MAP gateway might simply translate the SCCP address into a string of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply do a strcmp() on the string to match the identity. Sooner or later, OsmoHLR will have to store this identity in the database, e.g. for imlpementing message-waiting-lists of SMSCs in case of MT-SMS from real SMSCs. All-in-all, I think the string approach is not too bad in terms of keeping GSUP simple while having a clan approach to interworkng with MAP. On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote: I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". this is of course not good. I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. A random ID would not be permissible, as it has to be persistent accross MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms working. I would say, why not simply use the same approach as in OsmoBTS, i.e. use the MAC address (together with the MSC or SGSN prefix). The MAC address is unlikely to change frequently or on short notice. For people who know what they're doing, we can have a VTY command to override the identity with a manually-specified string. If that option is not set, the default "(SGSN|MSC)-MAC" is used. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). I don't think we are aiming for anyone to use those protocols on public[ly accessible] networks. There's no message authentication or other cryptographic protection anyway. OAP seems like a funny but futile minor obstacle, but nothing that can provide any reasonable level of security. For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. This should be done in all request-response style procedures, I think. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. Looking up by ID would also work in case meanwhile the old connection has died and a new connection has been established With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. For synchronous responses (i.e. no asynchronous activity in between) this will work. So I think it's an optimization for those cases, and we shouldn't rely on this to always work for all transactions at all time in the future. Rather, we should make sure it works even without that optimization? -- - Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Fri, 24 Feb 2017 17:12:02 +0100 From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>> To: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: <ca4d6dc2-fa43-8eaa-8c39-821939d87e52(a)rhizomatica.org<mailto:ca4d6dc2-fa43-8eaa-8c39-821939d87e52@rhizomatica.org>> Content-Type: text/plain; charset=windows-1252 On 21/02/2017 16:14, Harald Welte wrote: Just a quick response: jolly implemented "traffic handover" aka "load balancing" 3 years ago as part of a branch (I believe for a customer), but unfortunately this never was merged back to master. Reading the commit log, this looks terrific... Meanwhile, we already have all the code for execution of hand-overs in place. We also have dynamic timeslots in place. So the "mechanics" should all be there to add the two missing features from those old branches: a) de-fragmenting of channels (i.e. merging two separate TCH/H into one timeslot, so the other timeslot can be switched to TCH/F or PDCH on demand b) load/traffic based hand-over So essentially everything I was talking about is already implemented! My question then would be, and I understand maybe the answer is not so easily available without a full code review, but Was it unfortunately never merged back to master because Simply no one ever made the effort to do so. OR There were problems with the code, disagreement on the implementation or incompatibilities with other developments etc.. If it's the former, I'll have a go at this. If it is the latter, it's probably beyond my skills. The general strategy I would normally assume is to * switch to half-rate channels with AMR whenever possible * use dynamic channel switching to switch between TCH/H (default) and TCH/F (if neded) Absolutely, I must revisit this one. It was shelved for us due to my understanding a few months ago that if we implemented AMR, then we couldn't also use FR. As that's all now resolved, I can implement, test and report. :-) ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC(a)lists.osmocom.org<mailto:OpenBSC@lists.osmocom.org> https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 20 ***************************************

7 years, 2 months

2
1
0 0

Re: Handover and load balancing on SysmoBTS 2050

by Alexander Chemeris

Hi Holger, On Feb 22, 2017 1:02 AM, "Holger Freyther" <holger(a)freyther.de> wrote: > On 21 Feb 2017, at 21:40, Keith <keith(a)rhizomatica.org> wrote: Hi Keith, > On the question about SIP re-invite, I am talking about operating > without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP > streams at the same time as handover. From what I've read, this is quite > feasable, as part of the SIP spec. > I think this is already considered as part of the development of the > osmo-sip-connector, which is a project I really want to see moving > forward and hope to find time to contribute to over the next few months. yes for the osmo-sip-connector I have ignored the topic of handover. In general I try to see how long I get away with not having to touch the UDP/RTP streams. You don't really need to touch RTP stream if you do re-invite. In case of hand-over the new BTS might send from a different src IP, src Port and will most likely have a new SSRC, timestamp seqno. It is a bit of a question of how "your" PBX will handle it. I can see a couple of outcomes. a.) It has some support for "NAT" handling and will just use the new stream and return packages to the new src IP/src port. It might go back and forth but at some point the old bts will stop sending things. b.) It will accept the new stream but will try to send to the old BTS. The we would have one-way audio. c.) It will reject it as it is a unknown src ip/port. I think for b.) and c.) we will require SIP re-invite but also need to look at the AoIP spec to see if they say how to handle this scenario. But that depends on how the PBX handles this as well. So it means for handover we always need to look at BSC/SIP+PBX and how it is handling SDP/RTP. If I remember correctly, (b) is what's going to happen if a client is following vanilla SIP spec, because changing RTP IP/port requires updating SDP which is done with a re-invite. (a) is a hack supported by many SIP clients, but it may depend not only on PBX, but also on its configuration parameters, on SBCs used on a network, etc So if you want to be nice to the other party and follow the spec, it's better to do re-invite :) Btw, re-invite will need to be implemented anyway if you want to support call hold. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co

7 years, 2 months

3
5
0 0

borken pipe on jenkins

by Neels Hofmeyr

Now I've actually added some monitoring on all opened and closed sockets in the python tests, and it turns out the recent patch had no effect because the tearDown() is overloaded in TestVTYBase. With every running test, another socket is opened and they aren't closed until presumably the test py program exits. "40 sockets open", "41 sockets open", "42 sockets open", ... Found two places where we need to close sockets, and now the number of open sockets stays between 0 and 1. Patches are https://gerrit.osmocom.org/1903 https://gerrit.osmocom.org/1905 Will update the docker for openbsc tests when it's merged, and hopefully we can remove the extra monitoring of tcp sockets soon. ~N

7 years, 2 months

1
0
0 0

sysmo-usim-tool / pySim

by Harald Welte

Hi Sylvain + list, we have developed a sysmoUSIM-SJS1 specific python tool for sim card (re)configuration called sysmo-usim-tool. It is complementary of pySim-prog, in that it is *not* about IMSI/ICCID/MSISDN programming, but more about the features specific to sysmoUSIM-SJS1, such as enabling/disabling the USIM application (and getting a classic SIM), selecting the A3/A8 algorithm (XOR, COMP128vX, MILENAGE), etc. Philipp has committed his code to pmaier/sim branch of pysim-prog. The question is now whether you want this in the same repository or a separate one. The two code-bases share nothing in tems of their implementation. They are completely separate. So it would just be convenience feature for the user not to have to check out two repositories. I'm not quite sure whether to create a new repo or to have it in pySim-prog. Do you (Sylvain, but also generally people on the list) have any preference? The license currently states unintentionally AGPLv3, we'll change that to GPLv2-or-later before a possible merge. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 2 months

3
3
0 0

sanitizer build successful

by Neels Hofmeyr

In case you haven't noticed ... now that the osmo-pcu issue is finally resolved, we've got a successful sanitizer build on Jenkins! :D https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ Still no --enable-sanitize configure switches though, except in libosmocore. To reiterate, I'll gladly do the jenkins config if someone else takes on the --enable-sanitize in our builds, e.g. like in https://gerrit.osmocom.org/974 . ~N

7 years, 2 months

1
0
0 0

the near and further future of osmo-nitb

by Neels Hofmeyr

Hi all, I would like to direct your attention towards upcoming fairly fundamental changes that we would like to make in openbsc.git. The operation of osmo-nitb will need some adjustments that might stump some users at first. Hence, I would like to ask your feedback on this. While these changes open the road forward in exciting ways, to some degree they constitute a code bomb and a point-of-no-return. Let's discuss, to be prepared for it. (1) Near future: We are separating the HLR from OsmoNITB, aka libvlr + OsmoHLR. This gets us asynchronous HLR database access, 3G authentication and one central HLR for both OsmoNITB and OsmoSGSN (at some point also several OsmoNITBs). OsmoNITB will no longer manage its own SQlite subscriber database. OsmoHLR is a separate process that manages subscriber data, which the OsmoNITB as well as the OsmoSGSN will contact using the GSUP protocol. On the OsmoNITB side, libvlr implements a VLR with a brand new finite state machine implementation of handling attach, authentication and ciphering on a subscriber connection. libvlr stores subscriber data solely in RAM. (Note that at first, OsmoNITB will still have an SQlite database file, which will be used for storage of SMS data, only.) The main changes in operating OsmoNITB will be: - A separate osmo-hlr process with its own hlr.db database needs to be run. - The osmo-nitb VTY (telnet localhost 4242) and CTRL interface will no longer allow changing subscriber data; good old commands like 'subscriber create imsi 1234', 'subscriber imsi 1234 authorized 1' and so on will no longer be available. All subscriber management must be done on the OsmoHLR side. Since OsmoHLR so far has no VTY or CTRL API to manage subscribers, that needs to be done via sqlite3 on the hlr.db file (or re-implemented for OsmoHLR). Since this will constitute a profound change in operating an Osmocom CN, it makes sense to think about ways to transition. We're planning to make the VLR+HLR branch the new 'master' branch of openbsc, while keeping the current master on a legacy branch (named something like v1, which implies that the new flavor is Osmocom v2). We do not indend to spend much effort on maintaining the old flavor, though. Ongoing development and new features will happen in the new libvlr+OsmoHLR flavor, only. To take a peek, see the openbsc.git branch 'neels/vlr' and OsmoHLR at http://git.osmocom.org/osmo-hlr/ . (2) Further plans: For Iu and A interfaces (a standalone 3G+2G MSC implementation), we have also worked towards a complete separation of libmsc from libbsc. As a result, we will probably completely replace OsmoNITB with the new OsmoCSCN, meaning "Circuit Switched Core Network", which will be mainly MSC+VLR, talking to OsmoHLR for subscriber data, and to OsmoBSC and/or OsmoHNBGW to manage GERAN (2G) and/or UTRAN (3G) radio services. The main changes in operating an Osmocom CN will be: - Instead of running OsmoNITB, run separate OsmoBSC, OsmoCSCN and OsmoHLR instances. - VTY configuration of the BTS parameters needs to be done on the OsmoBSC level. - Logging on the MSC level will no longer have intimate access to BSC and BTS details. It is thinkable to still offer an OsmoNITB that integrates BSC and MSC+VLR, but the focus is elsewhere. - There will be Iuh (3G) support; IuCS in OsmoCSCN (sysmocom/iu branch), IuPS in OsmoSGSN (already merged to master, 3G Authentication pending). - It will be possible to operate a real A interface towards other standalone BSCs. This will at first stay on the sysmocom/iu branch, and cannot be merged to the master branch before we have a fully operational A interface. To take a peek, see http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wi… Your feedback and opinions on these plans are welcome! ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 2 months

4
7
0 0

logging filters, RFC

by Neels Hofmeyr

Summary: [1] some problems found in the current logging filter implementation. [2]..[7] a long discussion on where we could take Osmocom logging. [2] logging "lifter" instead of a filter [3] setting logging levels for flagged objects [4] multiple log targets and multiple flagged objects [5] FSM instance logging [6] setting the log context [7] VTY logging commands [1] In the VLR development, I'm going to split the gsm_subscriber to a bsc_subscriber and a vlr_subscriber. Hence I need to care about the logging filter code, that e.g. drops all logging except that for a given subscriber. At first I wanted to drop it altogether, but in fact filtering on a given subscriber is an important feature. See https://gerrit.osmocom.org/1685 Looking further into adapting this to two types of subscriber struct being used in the code, I found that in fact the logging filter code looks quite neglected and degraded. - One functional problem is that the constants for BSC_CTX_SUBSCR and GPRS_CTX_BVC actually have the same value: they both resolve to 1, and both thus access the same logging context pointer with conflicting types. openbsc debug.c's filter_fn appears to use both BSC_CTX_SUBSCR and GPRS_CTX_BVC, but GPRS_* are only set in libosmocore/src/gb/ code. Could be justified by osmo-nitb and osmo-sgsn not overlapping much, but I doubt that it's on purpose. - A log target's filter_data[] possibly holds a subscr_get() reference. If a log target is closed, like a VTY closing, the reference count may leak, because there is no filter data tear down that could subscr_put() it back. - log_set_nsvc_filter() and log_set_bvc_filter() are declared in openbsc/debug.h, but the only implementations I can find are *static* in libosmocore/src/gb/gprs_bssgp_vty.c and gprs_ns_vty.c, respectively. - The openbsc/debug.h enum defining LOG_FILTER_* is never used, because it is bascially duplicated in debug.c, where the values are called FLT_* instead. - The BSC_CTX_BTS and BSC_CTX_LCHAN are each set once by a call to log_set_context(), but no filter function ever reads them back out from the context array. So they are utterly unused. Hence in libbsc/libmsc, the *only* logging filter practically used is the IMSI filter. The filter code screams for attention and more safety. I would collect the various constants in a central place in libosmocore to avoid collisions (like ports.h does), and would use the same constant for both... the filter ctx array index: ctx[FLT_CONSTANT] and the bitmask: filter_map & (1 << FLT_CONSTANT) with a static assert to ensure that the filter category constants don't outgrow the filter_data[], ctx[], filter_map sizes. I'd drop unused definitions, add a tear down cb. [2] While talking about logging, I'm thinking back to 33c3 where we had a large active network and might want to highlight a few subscribers in the logging... Any comments on below bold plans to overhaul the logging semantics are welcome. Despite the long discussion, implementation of this should not be a lot of work really. Nevertheless, there are pressing topics in need of attention, and this mail doesn't mean that it will be implemented now. It's a unicorn's dream of where I would take Osmocom logging, and it _might_ be a good time to do it now... If you will, join me on an extensive journey through our logging: So far the logging checking goes like this: 1. If a msg's logging category is disabled, drop the msg. 2. If a msg's logging level surpasses the currently set log level of that category, drop it. otherwise: 3. If filter_all is set (= "don't filter"), log the message; otherwise: 4. If no filter function is set, log the message (in libbsc/libmsc operation, a filter function is always set). If a filter function is set: 5. Ask the filter function whether to log: 5.1 If no IMSI filter is set, drop the message. (!) 5.2 If an IMSI filter is set and the ctx has a different subscriber, drop the message. 5.3 If an IMSI filter is set and it *is* the subscriber, log the message. The result is that in essence, we don't ever see any logging unless we say 'logging filter all 1'. And then, if filter_all is set, the IMSI filter has no further effect. To see logging for a specific IMSI, we set 'logging filter all 0' and set the IMSI filter to the subscriber. In that situation, all logging will cease except for those matching the selected IMSI (assuming that the filter context is always set correctly). Any logging for this IMSI that would be more detailed than the given category's global logging level is still dropped, and parts of the code where the subscriber ctx is not set yet also shows no logging. One could call it a prohibitive logging paradigm. I had a hard time understanding the UI for it: makes sense only when reading the code. My logging vision would be the other way around, more of a logging "lifter". In a general logging landscape, I would like to flag certain subscribers (plural) to stand out from this landscape with a more detailed logging level. For example, I set all categories to level ERROR, but on top allow all MM, RSL and RR logging on INFO level; but for subscribers 1234 and 5678 I also want to see all DEBUG level logs across all (or specifically selected) categories. It would look like this: 1. If there is a logging_lifter function: 1.1 If any items are flagged for more detailed logging, ask the lifter: 1.2 If the logging context is set to a subscriber, and this subscriber is flagged for more detailed logging, log the message; see also [3]. 2. If a msg's logging level is within the currently set general log level of that category, log the message. 3. Otherwise, drop the message. This way the general logging landscape remains freely configurable while certain objects' logging can be made more verbose. [3] A problem with 1.2 is that we would always see all categories' logging in all detail for that subscriber. We could a) set a full category mask per subscriber for complete logging freedom; Instead I'd go for: b) define one global "raised logging" category mask to lift flagged subscribers to, and for each subscriber simply have a boolean flag set to true to make them log on the raised logging levels -- but what about several logging targets? see [4]. [4] So far so good, but there is still this clumsiness in my plan: there can be any number of logging targets. Even if I'd like to highlight subscriber 1234 on my VTY, I don't necessarily want stderr and other VTYs to raise logging for 1234 as well. So if we flagged raised logging in a subscriber struct, we'd basically make it affect all logging targets in the same way. In the current code, I can open N VTY telnets and on each of them show only logging for a selected IMSI, because all logging flags are saved for each logging target. But I *can't* lift more than one subscriber instance to raised logging on *the same* log output, because for each target there is only one IMSI; and I *can't* combine detailed logging of a given IMSI with a general background of normal logging on the same log output, because I have to filter all logging away before I can allow a specific IMSI ('logging filter all 0'). The easiest way to allow multiple subscribers with raised logging on the same log target is to store the "raise-logging" flag with the subscriber instance, but to keep the log targets separate, I would instead have in struct log_target an llist of void* for each filter_data where we can point to N instances we'd like to flag for raised logging. Then, if the current ctx[] matches any of those, use the raised logging levels. (Expecting the list to remain short) This can be filter_fn implementation specific: the filter_data can be used to point at the first llist_head instead of just one subscriber. [5] There's another interesting logging topic: FSM instances. We have the osmo_fsm_inst feature where we can set all logging emitted by an FSM instance to a certain logging level. One "problem" with this is that the entire FSM logs on the same level, and we can only raise or lower all of these messages as one. The implementation is: remember a logging category and a logging level with the FSM instance, and log all messages from the FSM on this category and level. The state transitions and events logged from fsm.c are logged on this logging level. Because I wanted to specifically mark some logging as LOGL_ERROR, I've already broken up that idea by adding the LOGPFSML() macro. It allows passing an explicit logging level instead of using the FSM instance's. I like to think of it like this: the FSM instance's logging level tells the fsm.c code on which level to log state transitions and events (like Debug). The logging I write in my FSM implementation that I want to stand out from the state transitions (read: logging that's more than Debug) should be given more specific logging levels, like any other code we write. We could actually make LOGPFSML() use MAX(fsm_inst.log_level, log_level_arg) so that changing an FSM instance's log level raises all log messaging. One could now think, if I want raised logging for a given subscriber, I could set its FSM instances' logging level so that it prints more logging. But, again this implies the clumsiness like in [4]: the raised logging would be global across all logging targets. In this case, there's no easy way to make the feature log target specific, and neither do we need to... FSM instance specific logging levels, while sounding very nice at first, are a non-feature when taking multiple logging targets into account. The simpler way to show FSM logging for a specific subscriber is to use above suggested features: flag the subscriber for raised logging on a speicific log target and set the raised logging level for DVLR to Debug, relying on the logging ctx to be set correctly when the subscriber's FSMs are active [6]. No need to adjust an FSM instance's logging level individually. So, the log level could also be stored in the osmo_fsm definition instead of each separate osmo_fsm_inst. [6] Setting the log context needs to generally happen in these situations: - message received (e.g. from the MS or HLR) - timer callback called (e.g. state timeout, SMS queue) Particularly for timeouts on FSM instances' states this is a bit tricky. If the fsm.c code triggers the timeout, there isn't a general hook to set the log context to the FSM's subscriber first. The FSM instances that have timeouts set need to also set a specific timer_cb to update the log context and repeat the timeout logging "Timeout of T123" that comes from fsm.c before timer_cb() is called. (That means the timeout logging may be issued twice in some situations, once by fsm.c and once by the FSM implementation's timer_cb after setting the log context to make sure raised logging includes it.) Maybe we can add a pre_timer_cb to osmo_fsm, or teach osmo_fsm to set a specific log context whenever it logs things? Probably not that important. [7] In the VTY, my plan would look like this: logging = e:RSL,RR,n:MM,CC ! replace all levels logging + n:PAG ! set some more logging raised = d:MM,i:CC ! applies to flagged logging contexts logging raised + d:PAG,NM logging raise subscriber (imsi|msisdn|...) 1234 ... logging raise subscriber (imsi|msisdn|...) 1234 not For setting the logging levels, I would like to introduce letters f, e, n, i, d for the log levels (Fatal, Error, Notice, Info, Debug) instead of the level numbers that are "hidden" in logging.h, plus o for Off to disable categories. I would prefer the format: [l:]CAT[,[l:]CAT[,...]] so that a level is followed by N categories to be on this level, possibly followed by another level and another categories list. (i.e. from the current format, swap meaning of ',' and ':', reverse the current <cat>[,<level>] order to [<level>:]<cat> and carry the level over to following categories.) I would also add the 'all' keyword in the logging category parsing: logging = n:all,i:MM,CC,PAG which would put all levels on Notice, except MM, CC and PAG on Info. To avoid confusion with the old 'logging categories' format, I would like to go for '=' and '+' commands (yes, the VTY can handle these). The old 'logging categories' might even co-exist. 'logging = ...' and 'logging + ...' should imply 'logging enable'. The 'logging raised *' sets the logging levels used for flagged subscribers; they should default to d:all, i.e. everything on debug level. 'logging raise *' flags a given subscriber (or what else we want to add later). To remove a raise flag from a subscriber, 'logging no raise *' makes sense, but it is often useful to just recall a previous VTY command and append a keyword, so I'd make it 'logging raise subscriber imsi 1234 not' for convenience. The current 'logging level <CAT> <LVL>' can remain as-is; I would add a 'logging raised level' command. I would completely drop the 'logging filter' commands. But it would still be useful on a VTY to mute logging to get a usable prompt without the need to discard the log target: logging (mute|off) logging (unmute|on) These are shorter and more intuitive than 'logging filter all (0|1)'. The current 'logging filter all everything' command is ambiguous. It sounds like it would aggressively turn on every last logging message. But instead it does the opposite: it can only add a general *restriction* on the logging level for all categories of a log target. Any category that is not enabled will still not log anything. Also, even if a log target has a more detailed level set, the log target's global logging level potentially prevents the detailed logging. So the command should sound more like 'logging restrict all to LEVEL'. It needs a rename, but IMHO we could also just drop it. Turning on every last log message could be done by 'logging = d:all'. Restrictions can be imposed by 'logging + e:RSL,MM,...'. Going back to a previous complex logging setup can be achieved by recalling the previous 'logging = ' commandline. The VTY could print such a paste-back-able line showing the current logging levels, so that going back is just a copy-paste on the VTY. So much for the unicorn's dream. For now, I'll start off with tidying up the things under [1] above. ~N

7 years, 2 months

2
1
0 0

weekly test report (w5 2017)

by Ivaylo Kostov

Hi, Please find BTS test report, week5 2017. BTSes which has been tested with OsmoNITB are: - sysmoBTS1002 - octasic BTS3500 - ettus B200 - nanoBTS model:165G sysmoBTS1002 has been tested with the following 4 channel configurations: 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_PDCH (ip.access style dynamic timeslots) All test cases passed. ---------------------------------------------------- octasic BTS3500 has been tested with the next 2 channel configurations: 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH All test cases passed. ----------------------------------------------------- ettus B200 has been tested with below channel configurations: 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_PDCH (ip.access style dynamic timeslots) All test cases passed. ------------------------------------------------------ During a weekly test of nanoBTS model:165G, an issue has been discovered. It is reported in redmine: https://osmocom.org/issues/1933 Short description: It was found that the initiated voice call drops immediately after B subscriber accepts the call, when nanoBTS (model 165G) and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default voice codec tch-h hr has been selected. Remaining test cases passed. regards, Ivaylo -- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ------------------------------

7 years, 3 months

4
11
0 0

(OPENBSC) osmo-sip-connector and freepbx

by choukoumoun

Hello, I want to connect osmo-sip-connector with and freepbx server installed into another machine. is it possible ? anybody have a file configuration exemple ? Thanks

7 years, 3 months

1
0
0 0

Re: the near and further future of osmo-nitb

by Snehasish Kar

Hi ________________________________ On Wed, Feb 15, 2017 at 09:39:15AM +0000, Snehasish Kar wrote: > A query, can it be now used with an usrp. > Please kindly always post questions to the mailing list and not to individual developers. Thanks. Sorry for that. > It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for. I meant the version of osmo-nitb supporting 3G be used with a USRP ? BR Snehasish

7 years, 3 months

2
2
0 0

Re: osmo-bts-trx error with tch/h

by Vadim Yanitskiy

Just let me know if I can help you somehow. I have SDR based board too. P.S. Please CC me in the further messages. With best regards, Vadim Yanitskiy.

7 years, 3 months

1
0
0 0

[PATCH net-next v2 0/6] gtp: misc improvements

by Andreas Schultz

Hi Pablo, Resent as v2, because I forgot the net-next target. Sorry for noise, I promise I won't forget it again. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP socket (needed for multi APN support). Regards Andreas Andreas Schultz (6): gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context gtp: consolidate gtp socket rx path drivers/net/gtp.c | 564 +++++++++++++++++++++++++++--------------------------- 1 file changed, 280 insertions(+), 284 deletions(-) -- 2.10.2

7 years, 3 months

5
28
0 0

Re: osmo-bts-trx error with tch/h

by Vadim Yanitskiy

Great work Max! I just applied your patch to the libosmocoding, and the problem was solved. Valgrind now says, that everything is ok ;) BTW: did the osmo-bts-trx TCH/H problem solved? With best regards, Vadim Yanitskiy.

7 years, 3 months

2
1
0 0

Re: osmo-bts-trx error with tch/h

by Vadim Yanitskiy

> Is this also covered in gerrit review for some of your patches like 933 > or 1628? Yeah, it's covered by https://gerrit.osmocom.org/#/c/933/ , and this is exactly the reason, why the change isn't ready to merge yet :( Well, some more details: # valgrind --track-origins=yes tests/coding/.libs/lt-coding_test ==27652== Memcheck, a memory error detector ==27652== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==27652== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==27652== Command: tests/coding/.libs/lt-coding_test ==27652== xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F49: ubits2sbits (coding_test.c:48) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F4E: ubits2sbits (coding_test.c:54) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422CCE: osmo_conv_decode_scan (conv.c:394) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422D08: osmo_conv_decode_scan (conv.c:403) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422F91: osmo_conv_decode_flush (conv.c:509) ==27652== by 0x5423235: osmo_conv_decode (conv.c:619) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x4E3D72C: osmo_conv_decode_ber (gsm0503_coding.c:480) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== tch_hr_decode: n_errors=11 n_bits_total=211 ber=0.05 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 Success ==27652== ==27652== HEAP SUMMARY: ==27652== in use at exit: 0 bytes in 0 blocks ==27652== total heap usage: 2,367 allocs, 2,367 frees, 397,488 bytes allocated ==27652== ==27652== All heap blocks were freed -- no leaks are possible ==27652== ==27652== For counts of detected and suppressed errors, rerun with: -v ==27652== ERROR SUMMARY: 7041 errors from 6 contexts (suppressed: 0 from 0) I paid my attention on the "Uninitialised value was created by a stack allocation" warning, and merely used memset() to fill some arrays by 0x00 in the gsm0503_tch_hr_decode(). And... it was the first time when I got successful build on Jenkins! This is the temporary solution: sbit_t iB[912], cB[456], h; ubit_t conv[98], b[112], d[112], p[3]; int i, rv, steal = 0; /** * Fix valgrind warnings: * "Uninitialised value was created by a stack allocation" * "Conditional jump or move depends on uninitialised value(s)" */ memset(iB, 0x00, sizeof(iB)); Then I started to dig deeper into the code, and used memset() one more time: http://pastebin.com/jBJT3q6R This dirty printf based debug led me closer to the problem. We are getting different results (successes and fails) because the gsm0503_tch_burst_map() refers to uninitialized value at iB[353]. Now we need to find out, where is the bug. There are two assumptions: 1) The gsm0503_tch_hr_interleave() doesn't initialize the iB[353]; 2) The gsm0503_tch_burst_map() refers to the value which it shouldn't refer to. With best regards, Vadim Yanitskiy.

7 years, 3 months

2
1
0 0

Error while building osmo-bts for sysmoBTS

by Ivaylo Kostov

Hi, I was following the procedure "Compiling osmo-bts for sysmoBTS" and using poky/1.5.4/sysroots/armv5te-poky-linux-gnueabi During execution of libosmocore project it failed with: ... GEN gsm0503_conv.c Traceback (most recent call last): File "../../utils/conv_gen.py", line 26, in <module> import sys, os, math, argparse ImportError: CC oap.lo No module named argparse Makefile:735: recipe for target 'gsm0503_conv.c' failed make[2]: *** [gsm0503_conv.c] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/home/ivaylo/net/osmo/libosmocore/src/gsm' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/ivaylo/net/osmo/libosmocore' Makefile:327: recipe for target 'all' failed make: *** [all] Error 2 ... I am using: Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 Type "help", "copyright", "credits" or "license" for more information. I think that something is broken. regards, Ivaylo -- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ------------------------------

7 years, 3 months

4
7
0 0

Re: osmo-bts-trx error with tch/h

by Vadim Yanitskiy

Hi Max and others, It seems, I faced similar problem while working on the libosmocoding. Despite the bursts_test in OsmoBTS always pass without any errors, when I merely moved some parts of GSM 05.03 code into a separate library, this test sometimes passes and fails on different machines... Thanks to tnt, who suggested me to use valgrind. Using this great tool and some tricks with memset(), I found, that the gsm0503_tch_burst_map() uses one uninitialized bit from the iB within the tch_hr_encode(). The same things happens in the tch_hr_decode(). I don't know, is it gsm0503_tch_hr_(de)interleave's bug or gsm0503_tch_burst_(un)map's one, we need to check GSM 05.03 specifications. With best regards, Vadim Yanitskiy.

7 years, 3 months

2
1
0 0

Heads-Up on ongoing libosmo-sccp SIGTRAN work

by Harald Welte

Dear all, so far libosmo-sccp had some code with a partial SCCP implementation that date back to the earliest day of OsmoBSC in 2009, done by Holger. It also contained a SUA implementation which (mostly) I did last year in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support. The latter code is already more 'modern' and uses the osmocom primitives (osmo_prim) between the SCCP User (the application) and the SCCP Provider (the library). Those primitives are modelled after the related specifications. What I'm now wokring on is to get those last SUA related patches finally merged in master, and to * add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in a generic way that they can be shared by all SIGTRAN xUA variants * add M3UA while sharing more code between SUA and M3UA * introduce a MTP SAP based on osmo_prim that can be used on top of M3UA * wrap the existing sccp.c code to use the MTP SAP on the lower end and the SCCP User SAP on the upper edge In the above implementations, I am aiming for implementing SGW, ASP and IPSP roles. However, primary focus is on ASP. In the end, we will be able to stack M3UA and SCCP code using primitives, and interact with the SCCP using the exact same primitives and API as we interact with SUA currently. This will give us: * true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin of their code * a way towards 3GPP compliant AoIP, by using the SCCP User SAP from OsmoBSC. This means that we'll also have to add that SCCP User SAP to the SCCPlite/IPA code that OsmoBSC is using for now. While all of the above sounds great, it somehow hurts me that we have already some (partial?) implementations of M3UA in cellmgr-ng (particularly the osmo-stp application). It hurts me that I'm not able to use the code that Holger wrote in recent years, but I still think it's worth-while to do an implementation centered around osmo_prim for layer-boundaries and osmo_fsm for state machines. So my apologies to Holger on this. It's not "Not Invented Here" syndrome, but I think there are reasons to take a different route than the existing code. I'm of course also looking forward to hearing other opinions on that. [... and while I'm working on this, I also think about introducing some generic inter-layer primitive logging code, so we can enable logging of the primitives at a given SAP without the specific SAP implementation having to implement anything, like we do in terms of osmo_fsm logging] Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 3 months

1
0
0 0

accelerate3g5 ML?

by Neels Hofmeyr

Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we could just make it a general osmocom-3G@ mailing list. Alternatively, we could use this list for 3G as well. What's the plan? ~N

7 years, 3 months

2
1
0 0

Re: OpenBSC Digest, Vol 28, Issue 6

by Rajitha peiris

[cid:9b893015-fe6c-4d05-9933-7169f767fc97] ________________________________ From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc(a)lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6 Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov <ikostov(a)sysmocom.de> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Harald Welte <laforge(a)gnumonks.org>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada(a)sysmocom.de> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ------------------------------ ------------------------------ Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte <laforge(a)gnumonks.org> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja> Content-Type: text/plain; charset=us-ascii Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> To: Harald Welte <laforge(a)gnumonks.org> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208234335.GB27422(a)my.box> Content-Type: text/plain; charset="us-ascii" On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N

7 years, 3 months

2
2
0 0

osmo-bts-trx error with tch/h

by Max

Hi. There seems to be peculiar coding error with osmo-bts-trx and usrp b210: ... <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] ... The error seems to: - happen only on 2nd subslot of TCH/H - does not prevent calls establishement - let voice to go through The visible effect though is extra delay for call establishment when BSC allocates next available subslot - see https://projects.osmocom.org/issues/1795 for details. Have anyone else seen this? It could be that tch_hr_decode() screw up bits somehow while trying to decode stolen FACCH bits but the code seems rather arcane. For instance, when calling unmap (it actually just attempts to get hu(B) and hl(B) flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57 correspondingly) potentially stolen bits in the beginning of function, why bursts 0..3 are treated as even and 2..4 as odd? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 3 months

1
0
0 0

Re: OpenBSC Digest, Vol 28, Issue 5

by Rajitha peiris

Hello all can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... thanks regards Rajitha Peiris Sri lanka ________________________________ From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> Sent: Wednesday, February 8, 2017 8:56:30 PM To: openbsc(a)lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 5 Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: MS cannot connect; Location Update Request not received by BTS (Hossein Amini) 2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev (Harald Welte) 3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional (Harald Welte) 4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper (Harald Welte) 5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context (Harald Welte) 6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup (Harald Welte) 7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte) 8. Re: weekly test report (w5 2017) (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Feb 2017 16:45:40 +0330 From: Hossein Amini <hosseinamini2578(a)gmail.com> To: openbsc(a)lists.osmocom.org Subject: Re: MS cannot connect; Location Update Request not received by BTS Message-ID: <CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels(a)hofmeyr.de> wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > >

7 years, 3 months

2
1
0 0

Re: MS cannot connect; Location Update Request not received by BTS

by Hossein Amini

I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels(a)hofmeyr.de> wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > >

7 years, 3 months

1
0
0 0

Downtime due FreeBSD upgrade.

by Holger Freyther

Hi, the machine hosting most of *.osmocom.org is running FreeBSD9.3 which EOLed end of december and I would like to upgrade to FreeBSD10.3. I do not expect many problems but I also don't want to interfere with other peoples work. Even if it is short notice, any objections for Saturday->Sunday night of a European timezone? Otherwise I would pick next Friday->Saturday. regards holger

7 years, 3 months

2
2
0 0

Channel release error when osmo-nitb want execute location update

by Hossein Amini

hi dear I install openbsc, osmosgsn, ggsn, osmo-trx, osmo-bts-trx, osmo-pcu and dependency from master branch step by step from this link. <https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS> but when run osmo-nitb, osmo-trx and osmo-bts-trx, mobile connect to network but no access to network. (I used USRP N210/B210, ubuntu 15.10/16.10 64x) osmo-nitb log: 20170130041914525 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170130041914525 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x05 ta=0 20170130041914525 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170130041914525 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170130041924529 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170130041924529 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170130041924529 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170130041924530 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170130041926530 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170130041926531 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE NITB config: ! ! OpenBSC (0.15.0.646-f1886-dirty) configuration saved from vty !! password foo ! log stderr logging filter all 1 logging color 1 logging print category 1 logging print extended-timestamp 1 logging level all everything logging level rll debug logging level cc debug logging level mm info logging level rr info logging level rsl debug logging level nm debug logging level mncc debug logging level pag debug logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs notice logging level ns info logging level bssgp notice logging level llc notice logging level sndcp notice logging level nat notice logging level ctrl notice logging level smpp notice logging level filter notice logging level ranap debug logging level sua debug 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 ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive ipa bind 127.0.0.1 network network country code 432 mobile network code 70 short name dynch long name dynch auth policy accept-all authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 subscriber-keep-in-ram 0 bts 0 type sysmobts band GSM900 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 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 early-classmark-sending forbidden ip.access unit_id 1800 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr gprs mode gprs gprs 11bit_rach_support_for_egprs 0 gprs routing area 0 gprs network-control-order nc1 gprs cell bvci 1800 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 1800 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 1800 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 127.0.0.1 gprs nsvc 1 nsvci 0 gprs nsvc 1 local udp port 0 gprs nsvc 1 remote udp port 0 gprs nsvc 1 remote ip 0.0.0.0 no force-combined-si trx 0 rf_locked 0 arfcn 0 nominal power 23 max_power_red 0 rsl e1 tei 0 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 PDCH hopping enabled 0 timeslot 5 phys_chan_config PDCH hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 mncc-int default-codec tch-f fr default-codec tch-h hr nitb subscriber-create-on-demand assign-tmsi OSMO-BTS-TRX Config file ! ! OsmoBTS (0.4.0.372-f65b) configuration saved from vty !! ! log stderr logging filter all 1 logging color 0 logging print category 1 logging print extended-timestamp 1 logging level all everything logging level rsl debug logging level oml debug logging level rll notice logging level rr notice logging level meas notice logging level pag info logging level l1c debug logging level l1p info logging level dsp debug logging level pcu notice logging level ho notice logging level trx notice logging level loop notice logging level abis notice logging level rtp notice logging level sum notice logging level lglobal notice logging level llapd debug 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 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive phy 0 osmotrx ip 127.0.0.1 osmotrx fn-advance 20 osmotrx rts-advance 5 osmotrx tx-attenuation oml instance 0 bts 0 band GSM900 ipa unit-id 1800 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 uplink-power-target -75 min-qual-rach 50 min-qual-norm -5 no ms-power-loop timing-advance-loop trx 0 power-ramp max-initial 23000 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 0 Regards

7 years, 3 months

2
1
0 0

Usrp with 3G

by Snehasish Kar

Hi Can 3G be used with USRP? BR Snehasish

7 years, 3 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2017