From laforge at osmocom.org  Sun Dec  1 13:40:33 2019
From: laforge at osmocom.org (Harald Welte)
Date: Sun, 1 Dec 2019 14:40:33 +0100
Subject: OsmoDevCon 2020 registration
Message-ID: <20191201134033.GB1292548@nataraja>

Dear fellow Osmocom developers,

I would like to invite all developers and contributors to Osmocom [sub]projects
to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin).

For details known so far, please check
	http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020

Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested
in case you would like to attend.  Registering early allows proper
planning.  Thanks!

Looking forward to meeting old and new Osmocom developers in April 2020.

Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191201/1dce7788/attachment.bin>

From laforge at osmocom.org  Tue Dec  3 16:20:33 2019
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 3 Dec 2019 17:20:33 +0100
Subject: distributed GSM / some thoughts
Message-ID: <20191203162033.GI1402446@nataraja>

Hi Oliver, Neels, community,

I had some comments on the D-GSM work that didn't really fit directly to
the gerrit code review, and I thought I'd post it here.


== DNS zone / .msisdn suffix ===

One question I had was regarding the use of the .{msisdn,imsi} TLD.  I would argue
it is probably besser to use something that fits within the existing DNS hierarchy
without contesting IANA's authority on gTLDs.

Historically, ETSI/3GPP made the mistake of using ".gprs" for resolving APNs
on the GRX.  This was later changed to something with 3gppnetwork.com or the like,
hwere that domain would actually be registered by 3GPP with normal domain registrars,
but without any publicly accessible zone records.  This way the name is reserved
in the public hierarchy and no risk of clashes.

I'm not sure how much of a concern this is to us, given that our use
case is much more niche than the GRX.  However, the "cost" is probably
rather small to change this to something like
.{msisdn,imsi}.dgsm.osmocom.org ?  Sure, the packets will get larger by
a few bytes, but given all the other overhead I think it's not really
going to have any impact?

What are your thoughts on that?


== MSISDN format ==

Another thought is whether or not there are any concerns regarding the
MSISDN format.  Historically, this is one of the weaknesses of OsmoMSC,
inherited from the OpenBSC days where we just thought in terms of PBX
extension numbers.  In reality, a MSISDN consist of a TON (type of
number), NPI (numbering plan indicator) and the related digits.  IIRC,
in the TON one can also specify if it's supposed to be national or
international, i.e. if it's prefixed with the country code or not.

It would be great to make sure that the format used in the mDNS queries
is somewhat standardized, if not at least only by the documentation
requiring that all queries should be done in fully qualfiied form with
country code present.   NPI is sort-of bogus as IMOH E.164 is the only
one applicable for MSISDN.

Any thoughts?


== The use of 'age' vs. absolute timestamp ==

In my original D-GSM idas I always thought we'd send an absolute UTC
timestamp when a given HLR/MSC has ever seen that subscriber.  The idea
here being that any rural GSM network will have some kind of GNSS
recevier for clock stability in the BTS anyway, and one can hence assume
that timestamps are synchronized.

The advantage of a relative 'age' is obvious: You don't care about the
absolute clock value being correct anymore.  The potential downside is
that propagation delay might matter.  If you have a rather slow / loaded
geostationary sattelite link from one village, but a faster terrestrial
link from another village, the 'age' will be ambiguous while an absolute
timesetamp wouldn't have that.

Given that the delays we're talking about are probably all sub-second or
maybe possible about 1s, it's probably not a problem.


== GSUP keepalives / connection loss detection ==

In the presence of unreliable back-haul mesh between villages, the GSUP
connection can also not be seen as reliable.  We would expect to see TCP
stalls due to packet loss, etc.

Have you considered this in your implementation and/or done any testing
based on simulated lossy networks to ensure we properly use either TCP
keepalives or IPA application-level PING/PONG to detect lost connections
and recover from such situations (by closing the old and
re-establishing)?

Unreliable networks can be easily simulated by Linux built-in 'tc netem'
for providing configurable packet loss / latency / jitter.

I also saw some comments / code related to "if a second connection using
the same IPA ID arrives, we're screwed" (paraphrasing here).   I would
expect this not to be uncommon even if every MSC/HLR out there is
configred correctly exactly because e.g .the remote MSC/HLR has already
decided that the TCP/GSUP is dead and starts to reconnect by performing
a local-end release, while the "local" MSC/HLR still thinks the old
connection is alive.  If the old connection "wins" (i.e. is preferred)
I see potential trouble here.

Situations like that probably warrant some carefully designed tests to
create exactly those situations.


Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Wed Dec  4 13:36:43 2019
From: keith at rhizomatica.org (Keith)
Date: Wed, 4 Dec 2019 14:36:43 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <20191203162033.GI1402446@nataraja>
References: <20191203162033.GI1402446@nataraja>
Message-ID: <346ce963-be98-68c0-cb69-0127aba26e59@rhizomatica.org>


On 03/12/2019 17:20, Harald Welte wrote:
> Hi Oliver, Neels, community,
>
> I had some comments on the D-GSM work that didn't really fit directly to
> the gerrit code review, and I thought I'd post it here.

Hi as well.

I add some short comments inline (disclaimer, I'm not fully up to speed
with the code)

>
> == DNS zone / .msisdn suffix ===
>
> One question I had was regarding the use of the .{msisdn,imsi} TLD.  I would argue
> it is probably besser to use something that fits within the existing DNS hierarchy
> without contesting IANA's authority on gTLDs.

I'd vote for, if at all possible, not making any link to/dependency on
DNS hierarchy.


> == The use of 'age' vs. absolute timestamp ==
>
> In my original D-GSM idas I always thought we'd send an absolute UTC
> timestamp when a given HLR/MSC has ever seen that subscriber.  The idea
> here being that any rural GSM network will have some kind of GNSS
> recevier for clock stability in the BTS anyway, and one can hence assume
> that timestamps are synchronized.
I'd vote for a configurable option or an (abs/rel) flag in the mslookup
request. I would not want this implementation to stall a 1st release though.
>
> The advantage of a relative 'age' is obvious: You don't care about the
> absolute clock value being correct anymore.  The potential downside is
> that propagation delay might matter.  If you have a rather slow / loaded
> geostationary sattelite link from one village, but a faster terrestrial
> link from another village, the 'age' will be ambiguous while an absolute
> timesetamp wouldn't have that.

It's true, and it's also possible that we might have geographically
close villages, (making cases of fast LAC switching probable) at the
same time as having a satellite link in one of both of these villages.

My personal preference is that the community GSM operator should also
manage (in as much as possible) the terrestrial links and where
possible, ensure existence of those between geographically close
communities, but reality is.. confounding on many levels.

>
> Given that the delays we're talking about are probably all sub-second or
> maybe possible about 1s, it's probably not a problem.

Agreed. I would add, it's my intention that whenever there is this kind
of doubt about the actual location of a MS when an incoming call needs
to be delivered, at the (SIP side) we would simply bridge the call to
both locations anyway, resulting in paging on both villages, and the
first to pick up wins.

> == GSUP keepalives / connection loss detection ==
>
> In the presence of unreliable back-haul mesh between villages, the GSUP
> connection can also not be seen as reliable.  We would expect to see TCP
> stalls due to packet loss, etc.

We don't envisage a separation between MSC and HLR over unreliable
back-haul, but I think I'm missing something here. (I still need to
actually implement a local setup and observe)






From nhofmeyr at sysmocom.de  Wed Dec  4 13:52:06 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Dec 2019 14:52:06 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <20191203162033.GI1402446@nataraja>
References: <20191203162033.GI1402446@nataraja>
Message-ID: <20191204135206.GA20597@my.box>

On Tue, Dec 03, 2019 at 05:20:33PM +0100, Harald Welte wrote:
> == DNS zone / .msisdn suffix ===
> 
> .{msisdn,imsi}.dgsm.osmocom.org ?  Sure, the packets will get larger by

sure, we can do that.  An idea is to do that merely on the DNS encoding, and
strip it off to have only *.imsi in the mslookup client? (If we add other
methods, we might not use the domain kind of representation at all there)

> == MSISDN format ==
> 
> Another thought is whether or not there are any concerns regarding the
> MSISDN format.  Historically, this is one of the weaknesses of OsmoMSC,
> inherited from the OpenBSC days where we just thought in terms of PBX
> extension numbers.  In reality, a MSISDN consist of a TON (type of
> number), NPI (numbering plan indicator) and the related digits.  IIRC,
> in the TON one can also specify if it's supposed to be national or
> international, i.e. if it's prefixed with the country code or not.
> 
> It would be great to make sure that the format used in the mDNS queries
> is somewhat standardized, if not at least only by the documentation
> requiring that all queries should be done in fully qualfiied form with
> country code present.   NPI is sort-of bogus as IMOH E.164 is the only
> one applicable for MSISDN.
> 
> Any thoughts?

So far it just works (TM) ... we reflect the MSISDNs saved in the HLR DB 1:1,
not sure what a TON representation might change about that.

It always passes through the MSC and SIP first.
If it's any consolation, the PBX gets the TON in the SIP INVITE (if it does),
and it could choose to treat numbers in any fashion. For mslookup to work
though, the MSISDN must reflect whatever we find in the HLR database. If that
is unable to reflect a TON (like it currently is unable to) then handling
non-naive MSISDNs would have to happen in the SIP dialplan anyway.
As soon as a given string is becomes parseable by an mslookup server, i.e. say
we implement some +123 notation in osmo-hlr, then it would suddenly start to
work out. mslookup itself doesn't care much about the msisdn, but I think we do
call osmo_msisdn_str_valid() on it. That could change easily, point being it
really is an arbitrary string (without dots) that gets sent as MSISDN.

> == The use of 'age' vs. absolute timestamp ==
> 
> Given that the delays we're talking about are probably all sub-second or
> maybe possible about 1s, it's probably not a problem.

I went through the same thoughts. When I do a first attach to a site, I find it
expected that a caller might not reach me for five more seconds.  If it is even
that much, ever.

So I favored the elegance of 'age' vs absolute timestamp, because an entire
timezone/clockdrift/faulty GPS receiver family of problems simply vanishes
completely.

> == GSUP keepalives / connection loss detection ==
> 
> In the presence of unreliable back-haul mesh between villages, the GSUP
> connection can also not be seen as reliable.  We would expect to see TCP
> stalls due to packet loss, etc.
> 
> Have you considered this in your implementation and/or done any testing
> based on simulated lossy networks to ensure we properly use either TCP
> keepalives or IPA application-level PING/PONG to detect lost connections
> and recover from such situations (by closing the old and
> re-establishing)?
> 
> Unreliable networks can be easily simulated by Linux built-in 'tc netem'
> for providing configurable packet loss / latency / jitter.
> 
> I also saw some comments / code related to "if a second connection using
> the same IPA ID arrives, we're screwed" (paraphrasing here).   I would
> expect this not to be uncommon even if every MSC/HLR out there is
> configred correctly exactly because e.g .the remote MSC/HLR has already
> decided that the TCP/GSUP is dead and starts to reconnect by performing
> a local-end release, while the "local" MSC/HLR still thinks the old
> connection is alive.  If the old connection "wins" (i.e. is preferred)
> I see potential trouble here.
> 
> Situations like that probably warrant some carefully designed tests to
> create exactly those situations.

We haven't tested this at all.
Should become an issue on redmine.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191204/0b866d7d/attachment.bin>

From laforge at osmocom.org  Wed Dec  4 19:46:01 2019
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 4 Dec 2019 20:46:01 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <346ce963-be98-68c0-cb69-0127aba26e59@rhizomatica.org>
References: <20191203162033.GI1402446@nataraja>
 <346ce963-be98-68c0-cb69-0127aba26e59@rhizomatica.org>
Message-ID: <20191204194601.GI1402446@nataraja>

Hi Keith,

On Wed, Dec 04, 2019 at 02:36:43PM +0100, Keith wrote:

> > == DNS zone / .msisdn suffix ===
> >
> > One question I had was regarding the use of the .{msisdn,imsi} TLD.  I would argue
> > it is probably besser to use something that fits within the existing DNS hierarchy
> > without contesting IANA's authority on gTLDs.
> 
> I'd vote for, if at all possible, not making any link to/dependency on
> DNS hierarchy.

I'm not suggesting a dependency.  You can always operate whatever DNS or mDNS on whatever
domain names in a network under your control.   I just think it might be smart
to try to avoid using a global namespace that more "authoritive" users might
use for something else in the future, who knows.

The D-GSM mDNS will work irrespective of the public DNS system as we know it.

> > == GSUP keepalives / connection loss detection ==
> >
> > In the presence of unreliable back-haul mesh between villages, the GSUP
> > connection can also not be seen as reliable.  We would expect to see TCP
> > stalls due to packet loss, etc.
> 
> We don't envisage a separation between MSC and HLR over unreliable
> back-haul, but I think I'm missing something here. (I still need to
> actually implement a local setup and observe)

In an inbound roaming situation, you have the MSC (VPLMN) in one village and the
"authoritative" HLR for that subscriber (HPLMN) in another village.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Wed Dec  4 19:50:33 2019
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 4 Dec 2019 20:50:33 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <20191204135206.GA20597@my.box>
References: <20191203162033.GI1402446@nataraja> <20191204135206.GA20597@my.box>
Message-ID: <20191204195033.GJ1402446@nataraja>

Hi Neels,

On Wed, Dec 04, 2019 at 02:52:06PM +0100, Neels Hofmeyr wrote:
> On Tue, Dec 03, 2019 at 05:20:33PM +0100, Harald Welte wrote:
> > == DNS zone / .msisdn suffix ===
> > 
> > .{msisdn,imsi}.dgsm.osmocom.org ?  Sure, the packets will get larger by
> 
> sure, we can do that.  An idea is to do that merely on the DNS encoding, and
> strip it off to have only *.imsi in the mslookup client? (If we add other
> methods, we might not use the domain kind of representation at all there)

good idea.  It could also be a global config setting somewhere of whatever suffix
is added after the .imsi/.msisdn, defaulting to the osmocom example.

> We haven't tested this at all.
> Should become an issue on redmine.

Will you create them accordingly?  As indicated, I think it's [at least] two differen
levels;
a) ensuring that keepalive on either TCP or IPA is enabled and works, and
b) creating situations where the same peer establishes a second new connection
   while the old one is still not torn down (timeout not expired yet, FIN packets
   lost, ...)

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Thu Dec  5 11:11:29 2019
From: keith at rhizomatica.org (Keith)
Date: Thu, 5 Dec 2019 12:11:29 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <20191204194601.GI1402446@nataraja>
References: <20191203162033.GI1402446@nataraja>
 <346ce963-be98-68c0-cb69-0127aba26e59@rhizomatica.org>
 <20191204194601.GI1402446@nataraja>
Message-ID: <03b5480c-f811-ae4b-d7be-3163b02fa0fe@rhizomatica.org>


On 04/12/2019 20:46, Harald Welte wrote:
>
>> We don't envisage a separation between MSC and HLR over unreliable
>> back-haul, but I think I'm missing something here. (I still need to
>> actually implement a local setup and observe)
> In an inbound roaming situation, you have the MSC (VPLMN) in one village and the
> "authoritative" HLR for that subscriber (HPLMN) in another village.
>
Ah, indeed. I do need to setup and play with this. In my head, I was
imagining that an IMSI attach request triggers an mslookup (broadcast)
and that the response message contains what the VLR (msc) needs. I
wasn't imagining TCP connections relating to core GSM over the
unreliable IP network.

I'm wary of TCP. I'm no expert in all the things that can be tuned, so
maybe there's a solution I'm unaware of?

If not, I don't like tcp over tinc-vpn at all where the underlying IP
connection is unreliable. Things tend to stall for a long time. This is
precisely the main problem I was seeing with multi-master distributed
databases. They work fine in theory in a data centre, but add severe
packet loss and it all falls down.

I'm quite possibly still missing something?

Thanks!

k.





From grgrehreher at gmail.com  Sun Dec  8 17:52:13 2019
From: grgrehreher at gmail.com (ah med)
Date: Sun, 8 Dec 2019 18:52:13 +0100
Subject: limesdr mini - osmo cni
Message-ID: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>

HI

I just tried to use limesd mini  with osmocom cni and i used this script to
launch all the items :

#!/bin/sh cmd="${1:-start}" set -ex systemctl $cmd
<https://twitter.com/search?q=%24cmd&src=cashtag_click> osmo-hlr osmo-msc
osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-pcu
osmo-trx-lms osmo-bts-trx

everything seems work fine,only the osmo-trx-lms :

 osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94
> [tid=140437169072832] Reference clock 40.00 MHz
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DDEV <0002>
> LMSDevice.cpp:192 [tid=140437169072832] Init LMS device
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99
> [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06
> RF=3.46667e+07
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000> Threads.cpp:117
> [tid=140437098583808] Thread 140437098583808 (task 8127) set name:
> CtrlService0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1
> channel(s)
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
> 0'
>


i am using the default .cfg files !


Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191208/ad0dec2b/attachment.htm>

From pespin at sysmocom.de  Mon Dec  9 10:00:30 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 9 Dec 2019 11:00:30 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
Message-ID: <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>

Hi,

can you explain which problem are you experiencing? in a detailed way, 
as well as versions you are using, etc.

-- 
- Pau Espin Pedrol <pespin at 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


From grgrehreher at gmail.com  Mon Dec  9 17:59:09 2019
From: grgrehreher at gmail.com (ah med)
Date: Mon, 9 Dec 2019 18:59:09 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
Message-ID: <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>

HI

- limesdr mini + osmocom cni

1- I installed osmocom cni using the apt-get install ...

2- osmo-hlr ,msc,pcu ...and others works fine !

the problem is with
osmo-trx-lms,this is what i get  :

 osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94
> [tid=140437169072832] Reference clock 40.00 MHz
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DDEV <0002>
> LMSDevice.cpp:192 [tid=140437169072832] Init LMS device
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99
> [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06
> RF=3.46667e+07
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000> Threads.cpp:117
> [tid=140437098583808] Thread 140437098583808 (task 8127) set name:
> CtrlService0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1
> channel(s)
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
> 0'
>


i am using the default .cfg files  +  all thos services :
#!/bin/sh cmd="${1:-start}" set -ex systemctl $cmd
<https://twitter.com/search?q=%24cmd&src=cashtag_click> osmo-hlr osmo-msc
osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-pcu
osmo-trx-lms osmo-bts-trx

seems that the BTS won't work!

this is the output for osmo-bts-trx :


<0017> control_if.c:911 CTRL at 127.0.0.1 4238
>  osmo-bts-trx[6675]: <0010> telnet_interface.c:104 Available via telnet
> 127.0.0.1 4241
>  osmo-bts-trx[6675]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
> mode, OML connecting to 192.168.122.1:3002
>  osmo-bts-trx[6675]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>


Regards.

Le lun. 9 d?c. 2019 ? 11:00, Pau Espin Pedrol <pespin at sysmocom.de> a ?crit :

> Hi,
>
> can you explain which problem are you experiencing? in a detailed way,
> as well as versions you are using, etc.
>
> --
> - Pau Espin Pedrol <pespin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191209/45354a00/attachment.htm>

From pespin at sysmocom.de  Mon Dec  9 20:21:44 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 9 Dec 2019 21:21:44 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
Message-ID: <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>

Hi,

why do you say it doesn't work? what's not working? which osmocom 
repositories are you using, nightly or latest?

Please write detailed descriptions on what's failing rather than simply 
writing "it doesn't work", otherwise nobody will be able nor interested 
in helping you.

-- 
- Pau Espin Pedrol <pespin at 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


From grgrehreher at gmail.com  Mon Dec  9 20:39:50 2019
From: grgrehreher at gmail.com (ah med)
Date: Mon, 9 Dec 2019 21:39:50 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
Message-ID: <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>

Hi

Ok,let's start with the installation !
setup : Limedsdr mini + ubuntu 18:04 + osmocm cni latest build

1- i used the Ubuntu latest build :

-
https://download.opensuse.org/repositories/network:/osmocom:/latest/xUbuntu_18.04/

2- i just installed all the required Programs using apt-get install command
such as osmo-hlr ,osmo,msc etc...

3- i used this script to run the osmocom cni :

#!/bin/sh
> cmd="${1:-start}"
> set -ex
> systemctl $cmd osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp
> osmo-bsc osmo-hnbgw osmo-bts-trx osmo-trx-lms
>


4- then by running ./osmo-all status i found that all programs work fine
without any errors,only for osmo-trx-lms ,i just got this :


> osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94
> [tid=140437169072832] Reference clock 40.00 MHz
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DDEV <0002>
> LMSDevice.cpp:192 [tid=140437169072832] Init LMS device
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99
> [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06
> RF=3.46667e+07
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000> Threads.cpp:117
> [tid=140437098583808] Thread 140437098583808 (task 8127) set name:
> CtrlService0
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
> osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1
> channel(s)
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
> 0'
>



and for osmo-bts-trx :


<0017> control_if.c:911 CTRL at 127.0.0.1 4238
>  osmo-bts-trx[6675]: <0010> telnet_interface.c:104 Available via telnet
> 127.0.0.1 4241
>  osmo-bts-trx[6675]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
> mode, OML connecting to 192.168.122.1:3002
>  osmo-bts-trx[6675]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>


also,by using my phone,i can't find the created network  and so the problem
is the limesdr mini (osmo-trx-lms) or the osmo-bts-trx .

for the confihuration files,i used the default .cfg files for all programs .

did i missed any thing ?

PS : i just tried the osmocm cni with Raspberry and i got the same problem .


Regards.

Le lun. 9 d?c. 2019 ? 21:21, Pau Espin Pedrol <pespin at sysmocom.de> a ?crit :

> Hi,
>
> why do you say it doesn't work? what's not working? which osmocom
> repositories are you using, nightly or latest?
>
> Please write detailed descriptions on what's failing rather than simply
> writing "it doesn't work", otherwise nobody will be able nor interested
> in helping you.
>
> --
> - Pau Espin Pedrol <pespin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191209/f2e6e646/attachment.htm>

From djks74 at gmail.com  Tue Dec 10 07:13:29 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 10 Dec 2019 14:13:29 +0700
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
Message-ID: <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>

Hi ahmed,.
You cannot use default,  find and follow on some user link if you can.

You need to give us more details.

Thanks.

regards,
Sandi / DUO

On Tue, Dec 10, 2019, 03:40 ah med <grgrehreher at gmail.com> wrote:

> Hi
>
> Ok,let's start with the installation !
> setup : Limedsdr mini + ubuntu 18:04 + osmocm cni latest build
>
> 1- i used the Ubuntu latest build :
>
> -
> https://download.opensuse.org/repositories/network:/osmocom:/latest/xUbuntu_18.04/
>
> 2- i just installed all the required Programs using apt-get install
> command such as osmo-hlr ,osmo,msc etc...
>
> 3- i used this script to run the osmocom cni :
>
> #!/bin/sh
>> cmd="${1:-start}"
>> set -ex
>> systemctl $cmd osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp
>> osmo-bsc osmo-hnbgw osmo-bts-trx osmo-trx-lms
>>
>
>
> 4- then by running ./osmo-all status i found that all programs work fine
> without any errors,only for osmo-trx-lms ,i just got this :
>
>
>> osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94
>> [tid=140437169072832] Reference clock 40.00 MHz
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:03 2019 DDEV <0002>
>> LMSDevice.cpp:192 [tid=140437169072832] Init LMS device
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
>> LMSDevice.cpp:99 [tid=140437169072832] Sample Rate: Min=100000
>> Max=3.072e+07 Step=0
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
>> LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DDEV <0002>
>> LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06
>> RF=3.46667e+07
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
>> LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
>> Threads.cpp:117 [tid=140437098583808] Thread 140437098583808 (task 8127)
>> set name: CtrlService0
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:04 2019 DMAIN <0000>
>> osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1
>> channel(s)
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
>> 0'
>>
>
>
>
> and for osmo-bts-trx :
>
>
> <0017> control_if.c:911 CTRL at 127.0.0.1 4238
>>  osmo-bts-trx[6675]: <0010> telnet_interface.c:104 Available via telnet
>> 127.0.0.1 4241
>>  osmo-bts-trx[6675]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
>> mode, OML connecting to 192.168.122.1:3002
>>  osmo-bts-trx[6675]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>>
>
>
> also,by using my phone,i can't find the created network  and so the
> problem is the limesdr mini (osmo-trx-lms) or the osmo-bts-trx .
>
> for the confihuration files,i used the default .cfg files for all programs
> .
>
> did i missed any thing ?
>
> PS : i just tried the osmocm cni with Raspberry and i got the same problem
> .
>
>
> Regards.
>
> Le lun. 9 d?c. 2019 ? 21:21, Pau Espin Pedrol <pespin at sysmocom.de> a
> ?crit :
>
>> Hi,
>>
>> why do you say it doesn't work? what's not working? which osmocom
>> repositories are you using, nightly or latest?
>>
>> Please write detailed descriptions on what's failing rather than simply
>> writing "it doesn't work", otherwise nobody will be able nor interested
>> in helping you.
>>
>> --
>> - Pau Espin Pedrol <pespin at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191210/bfb3b8ab/attachment.htm>

From osmith at sysmocom.de  Fri Dec 13 16:00:49 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Fri, 13 Dec 2019 17:00:49 +0100
Subject: distributed GSM / some thoughts
In-Reply-To: <20191204195033.GJ1402446@nataraja>
References: <20191203162033.GI1402446@nataraja>
 <20191204135206.GA20597@my.box> <20191204195033.GJ1402446@nataraja>
Message-ID: <ed1a52a4-9405-606b-61fc-62134a2672c7@sysmocom.de>

Hey all,

On 12/4/19 8:50 PM, Harald Welte wrote:
> On Wed, Dec 04, 2019 at 02:52:06PM +0100, Neels Hofmeyr wrote:
>> On Tue, Dec 03, 2019 at 05:20:33PM +0100, Harald Welte wrote:
>>> == DNS zone / .msisdn suffix ===
>>>
>>> .{msisdn,imsi}.dgsm.osmocom.org ?  Sure, the packets will get larger by
>> sure, we can do that.  An idea is to do that merely on the DNS encoding, and
>> strip it off to have only *.imsi in the mslookup client? (If we add other
>> methods, we might not use the domain kind of representation at all there)
> good idea.  It could also be a global config setting somewhere of whatever suffix
> is added after the .imsi/.msisdn, defaulting to the osmocom example.
> 

this is now implemented, see:
https://osmocom.org/issues/4309

Regards,
Oliver

-- 
- Oliver Smith <osmith at sysmocom.de>            https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From pespin at sysmocom.de  Tue Dec 17 12:41:55 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Tue, 17 Dec 2019 13:41:55 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
Message-ID: <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>

Hi Sandi,

why do you say the defaults won't work? They should in general. Can you 
please share what's exactly wrong with default config files?

Ahmed: You keep providing the same information with no real detail on 
what's your setup and what's not working. The log messages you shared 
seem fine to me. Unless you really investigate yourself a bit what's not 
working and provide detailed information about it, nobody will be able 
to support you.

Regards,

-- 
- Pau Espin Pedrol <pespin at 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


From djks74 at gmail.com  Tue Dec 17 14:01:57 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 17 Dec 2019 21:01:57 +0700
Subject: limesdr mini - osmo cni
In-Reply-To: <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
Message-ID: <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>

Hi Pespin,
Im sorry,  i might miss things if the default config has been updated?

Sorry to say in previous email,  cause my first experience is not working
with default which is long time ago in some case...  When i learning to
build the system.

At that time might be.. .  But thats long time ago.  I remember its though
for me to make the system is running for newbie....

Once again im so sorry!  Hehehe...


regards,
Sandi / DUO

On Tue, Dec 17, 2019, 19:41 Pau Espin Pedrol <pespin at sysmocom.de> wrote:

> Hi Sandi,
>
> why do you say the defaults won't work? They should in general. Can you
> please share what's exactly wrong with default config files?
>
> Ahmed: You keep providing the same information with no real detail on
> what's your setup and what's not working. The log messages you shared
> seem fine to me. Unless you really investigate yourself a bit what's not
> working and provide detailed information about it, nobody will be able
> to support you.
>
> Regards,
>
> --
> - Pau Espin Pedrol <pespin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191217/cf56bea9/attachment.htm>

From grgrehreher at gmail.com  Tue Dec 17 19:55:23 2019
From: grgrehreher at gmail.com (ah med)
Date: Tue, 17 Dec 2019 20:55:23 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
Message-ID: <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>

HI

Thanks for the reply!

the problem it's that i can't see the network using my phone,neither on
band 1800 or 900 !

 osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
> 0'
>

as you see, for the air interface,the program is sending  a  'POWEROFF'
command to the limesdrmini ! means that limesdr can't act as a bts
correctly!right ?
is there any way to dig more into the cause of this behavior ? the only log
i can see is from the systemctl !

as i sadi before,i am using all those components for my network :
osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw
osmo-bts-trx osmo-trx-lms


Thanks.

Le mar. 17 d?c. 2019 ? 15:02, Sandi Suhendro <djks74 at gmail.com> a ?crit :

> Hi Pespin,
> Im sorry,  i might miss things if the default config has been updated?
>
> Sorry to say in previous email,  cause my first experience is not working
> with default which is long time ago in some case...  When i learning to
> build the system.
>
> At that time might be.. .  But thats long time ago.  I remember its though
> for me to make the system is running for newbie....
>
> Once again im so sorry!  Hehehe...
>
>
> regards,
> Sandi / DUO
>
> On Tue, Dec 17, 2019, 19:41 Pau Espin Pedrol <pespin at sysmocom.de> wrote:
>
>> Hi Sandi,
>>
>> why do you say the defaults won't work? They should in general. Can you
>> please share what's exactly wrong with default config files?
>>
>> Ahmed: You keep providing the same information with no real detail on
>> what's your setup and what's not working. The log messages you shared
>> seem fine to me. Unless you really investigate yourself a bit what's not
>> working and provide detailed information about it, nobody will be able
>> to support you.
>>
>> Regards,
>>
>> --
>> - Pau Espin Pedrol <pespin at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191217/b5b55a57/attachment.htm>

From djks74 at gmail.com  Tue Dec 17 20:01:14 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 18 Dec 2019 03:01:14 +0700
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
Message-ID: <CANWiJYiuVpujAyxJdSV7TAcoPTcwKO3hYTcx_78QhDfMF+PG=g@mail.gmail.com>

Hi Ahmed,
If you were trying to build 2G network,  then you dont need osmo-hnbgw.

Make sure you read the wiki.

Try finding for what u need as 2g or 3g?

regards,
Sandi / DUO

On Wed, Dec 18, 2019, 02:55 ah med <grgrehreher at gmail.com> wrote:

> HI
>
> Thanks for the reply!
>
> the problem it's that i can't see the network using my phone,neither on
> band 1800 or 900 !
>
>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
>> 0'
>>
>
> as you see, for the air interface,the program is sending  a  'POWEROFF'
> command to the limesdrmini ! means that limesdr can't act as a bts
> correctly!right ?
> is there any way to dig more into the cause of this behavior ? the only
> log i can see is from the systemctl !
>
> as i sadi before,i am using all those components for my network :
> osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc
> osmo-hnbgw osmo-bts-trx osmo-trx-lms
>
>
> Thanks.
>
> Le mar. 17 d?c. 2019 ? 15:02, Sandi Suhendro <djks74 at gmail.com> a ?crit :
>
>> Hi Pespin,
>> Im sorry,  i might miss things if the default config has been updated?
>>
>> Sorry to say in previous email,  cause my first experience is not working
>> with default which is long time ago in some case...  When i learning to
>> build the system.
>>
>> At that time might be.. .  But thats long time ago.  I remember its
>> though for me to make the system is running for newbie....
>>
>> Once again im so sorry!  Hehehe...
>>
>>
>> regards,
>> Sandi / DUO
>>
>> On Tue, Dec 17, 2019, 19:41 Pau Espin Pedrol <pespin at sysmocom.de> wrote:
>>
>>> Hi Sandi,
>>>
>>> why do you say the defaults won't work? They should in general. Can you
>>> please share what's exactly wrong with default config files?
>>>
>>> Ahmed: You keep providing the same information with no real detail on
>>> what's your setup and what's not working. The log messages you shared
>>> seem fine to me. Unless you really investigate yourself a bit what's not
>>> working and provide detailed information about it, nobody will be able
>>> to support you.
>>>
>>> Regards,
>>>
>>> --
>>> - Pau Espin Pedrol <pespin at 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191218/84e9b2ce/attachment.htm>

From grgrehreher at gmail.com  Tue Dec 17 20:06:00 2019
From: grgrehreher at gmail.com (ah med)
Date: Tue, 17 Dec 2019 21:06:00 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CANWiJYiuVpujAyxJdSV7TAcoPTcwKO3hYTcx_78QhDfMF+PG=g@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
 <CANWiJYiuVpujAyxJdSV7TAcoPTcwKO3hYTcx_78QhDfMF+PG=g@mail.gmail.com>
Message-ID: <CACWm40=RqOKke-oRcnH4igikMaEFSb1PGfPEuW413Vv1dXTyAw@mail.gmail.com>

Thanks again for your help!
Yes,right now I am working on the 2G network!

For the osmo-hnbgw,I already don't use it!

I will try to find the problem myself and let you know if there is any
problem.

Have a nice day.

Regards.

On Tue, Dec 17, 2019, 21:01 Sandi Suhendro <djks74 at gmail.com> wrote:

> Hi Ahmed,
> If you were trying to build 2G network,  then you dont need osmo-hnbgw.
>
> Make sure you read the wiki.
>
> Try finding for what u need as 2g or 3g?
>
> regards,
> Sandi / DUO
>
> On Wed, Dec 18, 2019, 02:55 ah med <grgrehreher at gmail.com> wrote:
>
>> HI
>>
>> Thanks for the reply!
>>
>> the problem it's that i can't see the network using my phone,neither on
>> band 1800 or 900 !
>>
>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>>>  osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
>>> 0'
>>>
>>
>> as you see, for the air interface,the program is sending  a  'POWEROFF'
>> command to the limesdrmini ! means that limesdr can't act as a bts
>> correctly!right ?
>> is there any way to dig more into the cause of this behavior ? the only
>> log i can see is from the systemctl !
>>
>> as i sadi before,i am using all those components for my network :
>> osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc
>> osmo-hnbgw osmo-bts-trx osmo-trx-lms
>>
>>
>> Thanks.
>>
>> Le mar. 17 d?c. 2019 ? 15:02, Sandi Suhendro <djks74 at gmail.com> a ?crit :
>>
>>> Hi Pespin,
>>> Im sorry,  i might miss things if the default config has been updated?
>>>
>>> Sorry to say in previous email,  cause my first experience is not
>>> working with default which is long time ago in some case...  When i
>>> learning to build the system.
>>>
>>> At that time might be.. .  But thats long time ago.  I remember its
>>> though for me to make the system is running for newbie....
>>>
>>> Once again im so sorry!  Hehehe...
>>>
>>>
>>> regards,
>>> Sandi / DUO
>>>
>>> On Tue, Dec 17, 2019, 19:41 Pau Espin Pedrol <pespin at sysmocom.de> wrote:
>>>
>>>> Hi Sandi,
>>>>
>>>> why do you say the defaults won't work? They should in general. Can you
>>>> please share what's exactly wrong with default config files?
>>>>
>>>> Ahmed: You keep providing the same information with no real detail on
>>>> what's your setup and what's not working. The log messages you shared
>>>> seem fine to me. Unless you really investigate yourself a bit what's
>>>> not
>>>> working and provide detailed information about it, nobody will be able
>>>> to support you.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> - Pau Espin Pedrol <pespin at 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191217/017f9768/attachment.htm>

From pespin at sysmocom.de  Tue Dec 17 21:03:40 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Tue, 17 Dec 2019 22:03:40 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
Message-ID: <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>



On 12/17/19 8:55 PM, ah med wrote:
> the problem it's that i can't see the network using my phone,neither on 
> band 1800 or 900 !
> 
>      ?osmo-trx-lms[7995]: Sun Dec ?8 18:02:05 2019 DTRXCTRL <0001>
>     Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
>      ?osmo-trx-lms[7995]: Sun Dec ?8 18:02:05 2019 DTRXCTRL <0001>
>     Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP
>     POWEROFF 0'
> 
> 
> as you see, for the air interface,the program is sending? a? 'POWEROFF' 
> command to the limesdrmini ! means that limesdr can't act as a bts 
> correctly!right ?

As I said, it's expected that the BTS upon connecting to osmo-trx first 
sends a POWEROFF command to make sure the TRX is stopped, in a "known" 
state. Once there, it configures it and finally turns it on with "POWERON".

> is there any way to dig more into the cause of this behavior ? the only 
> log i can see is from the systemctl !

Please read the wiki and the user manuals to learn the basics on how to 
operate the osmocom software. Specially how to access the VTY and 
configure it as well as get logging information.
https://ftp.osmocom.org/docs/latest/

-- 
- Pau Espin Pedrol <pespin at 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


From grgrehreher at gmail.com  Tue Dec 24 17:33:47 2019
From: grgrehreher at gmail.com (ah med)
Date: Tue, 24 Dec 2019 18:33:47 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
 <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>
Message-ID: <CACWm40ndiqsttHWZzRp2yP=4Z9kTGoSXg4M53o6wpgc7eiTJ+A@mail.gmail.com>

HI all,

Just found that theproblem is with the osmo-bts-trx :

journalctl -f -u osmo-bts-trx.service

<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
>  osmo-bts-trx[26145]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
> mode, OML connecting to 192.168.122.1:3002
>  osmo-bts-trx[26145]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>  osmo-bts-trx[26145]: <000b> trx_if.c:173 phy0.0: No satisfactory response
> from transceiver(CMD POWEROFF)
>  osmo-bts-trx[26145]: <0009> pcu_sock.c:929 PCU socket connected to
> external PCU
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
> Sending PCU version report to BSC: 0.7.0
>  osmo-bts-trx[26145]: <000d> abis.c:144 Signalling link down
>  osmo-bts-trx[26145]: <0001> bts.c:285 Shutting down BTS 0, Reason Abis
> close
>  osmo-bts-trx[26145]: Shutdown timer expired
>  osmo-bts-trx[26145]: ((*))
>  osmo-bts-trx[26145]:   |
>  osmo-bts-trx[26145]:  / \ OsmoBTS
>  systemd[1]: osmo-bts-trx.service: Main process exited, code=exited,
> status=42/n/a
>  systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'.
>  systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling
> restart.
>  systemd[1]: osmo-bts-trx.service: Scheduled restart job, restart counter
> is at 1.
>

the problem is with "Signalling link down" and " osmo-bts-trx[26145]:
<0001> bts.c:285 Shutting down BTS 0, Reason Abis close"

i tried to verif the unit-id for both osmo-btstrx and osmo-bsc and found
that it's the same!
still can't figure why the abis close.

for the config files :

osmo-bts-trx.cfg:
https://pastebin.com/wgBxXN6G

osmo-bsc.cfg :
https://pastebin.com/jh81aKrM

Setup :
osmocom CNI latest build for ubuntu 18.04 + limesdr mini

Thanks!



Le mar. 17 d?c. 2019 ? 22:03, Pau Espin Pedrol <pespin at sysmocom.de> a
?crit :

>
>
> On 12/17/19 8:55 PM, ah med wrote:
> > the problem it's that i can't see the network using my phone,neither on
> > band 1800 or 900 !
> >
> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> >     Transceiver.cpp:773 [tid=140437098583808][chan=0] command is
> 'POWEROFF'
> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
> >     Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP
> >     POWEROFF 0'
> >
> >
> > as you see, for the air interface,the program is sending  a  'POWEROFF'
> > command to the limesdrmini ! means that limesdr can't act as a bts
> > correctly!right ?
>
> As I said, it's expected that the BTS upon connecting to osmo-trx first
> sends a POWEROFF command to make sure the TRX is stopped, in a "known"
> state. Once there, it configures it and finally turns it on with "POWERON".
>
> > is there any way to dig more into the cause of this behavior ? the only
> > log i can see is from the systemctl !
>
> Please read the wiki and the user manuals to learn the basics on how to
> operate the osmocom software. Specially how to access the VTY and
> configure it as well as get logging information.
> https://ftp.osmocom.org/docs/latest/
>
> --
> - Pau Espin Pedrol <pespin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191224/5b869f23/attachment.htm>

From djks74 at gmail.com  Tue Dec 24 18:03:31 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 25 Dec 2019 01:03:31 +0700
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40ndiqsttHWZzRp2yP=4Z9kTGoSXg4M53o6wpgc7eiTJ+A@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
 <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>
 <CACWm40ndiqsttHWZzRp2yP=4Z9kTGoSXg4M53o6wpgc7eiTJ+A@mail.gmail.com>
Message-ID: <CANWiJYii1FEf--9AoqmJUNr_i8Pcm-pk9zmpW-PQmWMbLiqoTw@mail.gmail.com>

Signaling link down appear because OML not connecting,
have you try use oml remote-ip 127.0.0.1  ?

You running on the same computer for the CNI right?

On Wed, Dec 25, 2019 at 12:33 AM ah med <grgrehreher at gmail.com> wrote:

> HI all,
>
> Just found that theproblem is with the osmo-bts-trx :
>
> journalctl -f -u osmo-bts-trx.service
>
> <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
>>  osmo-bts-trx[26145]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
>> mode, OML connecting to 192.168.122.1:3002
>>  osmo-bts-trx[26145]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>>  osmo-bts-trx[26145]: <000b> trx_if.c:173 phy0.0: No satisfactory
>> response from transceiver(CMD POWEROFF)
>>  osmo-bts-trx[26145]: <0009> pcu_sock.c:929 PCU socket connected to
>> external PCU
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>> Sending PCU version report to BSC: 0.7.0
>>  osmo-bts-trx[26145]: <000d> abis.c:144 Signalling link down
>>  osmo-bts-trx[26145]: <0001> bts.c:285 Shutting down BTS 0, Reason Abis
>> close
>>  osmo-bts-trx[26145]: Shutdown timer expired
>>  osmo-bts-trx[26145]: ((*))
>>  osmo-bts-trx[26145]:   |
>>  osmo-bts-trx[26145]:  / \ OsmoBTS
>>  systemd[1]: osmo-bts-trx.service: Main process exited, code=exited,
>> status=42/n/a
>>  systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'.
>>  systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling
>> restart.
>>  systemd[1]: osmo-bts-trx.service: Scheduled restart job, restart counter
>> is at 1.
>>
>
> the problem is with "Signalling link down" and " osmo-bts-trx[26145]:
> <0001> bts.c:285 Shutting down BTS 0, Reason Abis close"
>
> i tried to verif the unit-id for both osmo-btstrx and osmo-bsc and found
> that it's the same!
> still can't figure why the abis close.
>
> for the config files :
>
> osmo-bts-trx.cfg:
> https://pastebin.com/wgBxXN6G
>
> osmo-bsc.cfg :
> https://pastebin.com/jh81aKrM
>
> Setup :
> osmocom CNI latest build for ubuntu 18.04 + limesdr mini
>
> Thanks!
>
>
>
> Le mar. 17 d?c. 2019 ? 22:03, Pau Espin Pedrol <pespin at sysmocom.de> a
> ?crit :
>
>>
>>
>> On 12/17/19 8:55 PM, ah med wrote:
>> > the problem it's that i can't see the network using my phone,neither on
>> > band 1800 or 900 !
>> >
>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> >     Transceiver.cpp:773 [tid=140437098583808][chan=0] command is
>> 'POWEROFF'
>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>> >     Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP
>> >     POWEROFF 0'
>> >
>> >
>> > as you see, for the air interface,the program is sending  a  'POWEROFF'
>> > command to the limesdrmini ! means that limesdr can't act as a bts
>> > correctly!right ?
>>
>> As I said, it's expected that the BTS upon connecting to osmo-trx first
>> sends a POWEROFF command to make sure the TRX is stopped, in a "known"
>> state. Once there, it configures it and finally turns it on with
>> "POWERON".
>>
>> > is there any way to dig more into the cause of this behavior ? the only
>> > log i can see is from the systemctl !
>>
>> Please read the wiki and the user manuals to learn the basics on how to
>> operate the osmocom software. Specially how to access the VTY and
>> configure it as well as get logging information.
>> https://ftp.osmocom.org/docs/latest/
>>
>> --
>> - Pau Espin Pedrol <pespin at 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
>>
>

-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191225/08dcf54d/attachment.htm>

From grgrehreher at gmail.com  Tue Dec 24 18:14:09 2019
From: grgrehreher at gmail.com (ah med)
Date: Tue, 24 Dec 2019 19:14:09 +0100
Subject: limesdr mini - osmo cni
In-Reply-To: <CANWiJYii1FEf--9AoqmJUNr_i8Pcm-pk9zmpW-PQmWMbLiqoTw@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
 <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>
 <CACWm40ndiqsttHWZzRp2yP=4Z9kTGoSXg4M53o6wpgc7eiTJ+A@mail.gmail.com>
 <CANWiJYii1FEf--9AoqmJUNr_i8Pcm-pk9zmpW-PQmWMbLiqoTw@mail.gmail.com>
Message-ID: <CACWm40=BogFK0-XYgj=1M0_hV0ZuMD0Za6KrhN-W55-1T30mFg@mail.gmail.com>

It's working.

now i can see the network after changing the remote ip from 192.168.122.1
to localhost !
just missed to change it as you said!
i will try to provide a working config for other users ASAP !

thanks!

Le mar. 24 d?c. 2019 ? 19:03, Sandi Suhendro <djks74 at gmail.com> a ?crit :

> Signaling link down appear because OML not connecting,
> have you try use oml remote-ip 127.0.0.1  ?
>
> You running on the same computer for the CNI right?
>
> On Wed, Dec 25, 2019 at 12:33 AM ah med <grgrehreher at gmail.com> wrote:
>
>> HI all,
>>
>> Just found that theproblem is with the osmo-bts-trx :
>>
>> journalctl -f -u osmo-bts-trx.service
>>
>> <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
>>>  osmo-bts-trx[26145]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
>>> mode, OML connecting to 192.168.122.1:3002
>>>  osmo-bts-trx[26145]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>>>  osmo-bts-trx[26145]: <000b> trx_if.c:173 phy0.0: No satisfactory
>>> response from transceiver(CMD POWEROFF)
>>>  osmo-bts-trx[26145]: <0009> pcu_sock.c:929 PCU socket connected to
>>> external PCU
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>> Sending PCU version report to BSC: 0.7.0
>>>  osmo-bts-trx[26145]: <000d> abis.c:144 Signalling link down
>>>  osmo-bts-trx[26145]: <0001> bts.c:285 Shutting down BTS 0, Reason Abis
>>> close
>>>  osmo-bts-trx[26145]: Shutdown timer expired
>>>  osmo-bts-trx[26145]: ((*))
>>>  osmo-bts-trx[26145]:   |
>>>  osmo-bts-trx[26145]:  / \ OsmoBTS
>>>  systemd[1]: osmo-bts-trx.service: Main process exited, code=exited,
>>> status=42/n/a
>>>  systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'.
>>>  systemd[1]: osmo-bts-trx.service: Service hold-off time over,
>>> scheduling restart.
>>>  systemd[1]: osmo-bts-trx.service: Scheduled restart job, restart
>>> counter is at 1.
>>>
>>
>> the problem is with "Signalling link down" and " osmo-bts-trx[26145]:
>> <0001> bts.c:285 Shutting down BTS 0, Reason Abis close"
>>
>> i tried to verif the unit-id for both osmo-btstrx and osmo-bsc and found
>> that it's the same!
>> still can't figure why the abis close.
>>
>> for the config files :
>>
>> osmo-bts-trx.cfg:
>> https://pastebin.com/wgBxXN6G
>>
>> osmo-bsc.cfg :
>> https://pastebin.com/jh81aKrM
>>
>> Setup :
>> osmocom CNI latest build for ubuntu 18.04 + limesdr mini
>>
>> Thanks!
>>
>>
>>
>> Le mar. 17 d?c. 2019 ? 22:03, Pau Espin Pedrol <pespin at sysmocom.de> a
>> ?crit :
>>
>>>
>>>
>>> On 12/17/19 8:55 PM, ah med wrote:
>>> > the problem it's that i can't see the network using my phone,neither
>>> on
>>> > band 1800 or 900 !
>>> >
>>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>> >     Transceiver.cpp:773 [tid=140437098583808][chan=0] command is
>>> 'POWEROFF'
>>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>> >     Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP
>>> >     POWEROFF 0'
>>> >
>>> >
>>> > as you see, for the air interface,the program is sending  a
>>> 'POWEROFF'
>>> > command to the limesdrmini ! means that limesdr can't act as a bts
>>> > correctly!right ?
>>>
>>> As I said, it's expected that the BTS upon connecting to osmo-trx first
>>> sends a POWEROFF command to make sure the TRX is stopped, in a "known"
>>> state. Once there, it configures it and finally turns it on with
>>> "POWERON".
>>>
>>> > is there any way to dig more into the cause of this behavior ? the
>>> only
>>> > log i can see is from the systemctl !
>>>
>>> Please read the wiki and the user manuals to learn the basics on how to
>>> operate the osmocom software. Specially how to access the VTY and
>>> configure it as well as get logging information.
>>> https://ftp.osmocom.org/docs/latest/
>>>
>>> --
>>> - Pau Espin Pedrol <pespin at 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
>>>
>>
>
> --
> Best Regards,
> Sandi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191224/85afa22c/attachment.htm>

From djks74 at gmail.com  Tue Dec 24 18:16:19 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Wed, 25 Dec 2019 01:16:19 +0700
Subject: limesdr mini - osmo cni
In-Reply-To: <CACWm40=BogFK0-XYgj=1M0_hV0ZuMD0Za6KrhN-W55-1T30mFg@mail.gmail.com>
References: <CACWm40kUhwkHujsGkyHtEjkWGGRu6sJFhFKhEhERQ7giq-egYw@mail.gmail.com>
 <2854c70f-3851-b7d6-9fcd-69f2687edfaf@sysmocom.de>
 <CACWm40kO0NyCJrrtbSZ3jrEZD28LrRJgbUE5HBF9jeLr6NuVwA@mail.gmail.com>
 <7ab5f9b5-48a8-6cd8-ccb6-397890450e5e@sysmocom.de>
 <CACWm40km_Kx5SK-WCQxXH7r+w7YkzNaOzZ=QMcBLEnVVQvvWNA@mail.gmail.com>
 <CANWiJYjmGpO7bYb1H-HyF0YoERpBi7n2CC7VYe8yC5oQYzYZQQ@mail.gmail.com>
 <1d19f685-4ecf-d1fb-8833-ec8b4c8cbb9a@sysmocom.de>
 <CANWiJYjoL-ZVD9yYKWZeUPV+0BkmmakU8dUHMC+CHv3Q-C0n1g@mail.gmail.com>
 <CACWm40=YZ7vAY0xwYdZMYZuWE+J+h_SyB=jmUWsS4_hL0GpVFw@mail.gmail.com>
 <59d29471-161f-760c-36a2-f1ff25124bb5@sysmocom.de>
 <CACWm40ndiqsttHWZzRp2yP=4Z9kTGoSXg4M53o6wpgc7eiTJ+A@mail.gmail.com>
 <CANWiJYii1FEf--9AoqmJUNr_i8Pcm-pk9zmpW-PQmWMbLiqoTw@mail.gmail.com>
 <CACWm40=BogFK0-XYgj=1M0_hV0ZuMD0Za6KrhN-W55-1T30mFg@mail.gmail.com>
Message-ID: <CANWiJYjznAD=aXn85RSsQMayNWoxFbgu6CEJB=jh9TDqLCL5=A@mail.gmail.com>

You are welcome. :-)

On Wed, Dec 25, 2019 at 1:14 AM ah med <grgrehreher at gmail.com> wrote:

> It's working.
>
> now i can see the network after changing the remote ip from 192.168.122.1
> to localhost !
> just missed to change it as you said!
> i will try to provide a working config for other users ASAP !
>
> thanks!
>
> Le mar. 24 d?c. 2019 ? 19:03, Sandi Suhendro <djks74 at gmail.com> a ?crit :
>
>> Signaling link down appear because OML not connecting,
>> have you try use oml remote-ip 127.0.0.1  ?
>>
>> You running on the same computer for the CNI right?
>>
>> On Wed, Dec 25, 2019 at 12:33 AM ah med <grgrehreher at gmail.com> wrote:
>>
>>> HI all,
>>>
>>> Just found that theproblem is with the osmo-bts-trx :
>>>
>>> journalctl -f -u osmo-bts-trx.service
>>>
>>> <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
>>>>  osmo-bts-trx[26145]: <0012> input/ipaccess.c:897 enabling ipaccess BTS
>>>> mode, OML connecting to 192.168.122.1:3002
>>>>  osmo-bts-trx[26145]: <000b> trx_if.c:1155 phy0.0: Open transceiver
>>>>  osmo-bts-trx[26145]: <000b> trx_if.c:173 phy0.0: No satisfactory
>>>> response from transceiver(CMD POWEROFF)
>>>>  osmo-bts-trx[26145]: <0009> pcu_sock.c:929 PCU socket connected to
>>>> external PCU
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff):
>>>> Sending PCU version report to BSC: 0.7.0
>>>>  osmo-bts-trx[26145]: <000d> abis.c:144 Signalling link down
>>>>  osmo-bts-trx[26145]: <0001> bts.c:285 Shutting down BTS 0, Reason Abis
>>>> close
>>>>  osmo-bts-trx[26145]: Shutdown timer expired
>>>>  osmo-bts-trx[26145]: ((*))
>>>>  osmo-bts-trx[26145]:   |
>>>>  osmo-bts-trx[26145]:  / \ OsmoBTS
>>>>  systemd[1]: osmo-bts-trx.service: Main process exited, code=exited,
>>>> status=42/n/a
>>>>  systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'.
>>>>  systemd[1]: osmo-bts-trx.service: Service hold-off time over,
>>>> scheduling restart.
>>>>  systemd[1]: osmo-bts-trx.service: Scheduled restart job, restart
>>>> counter is at 1.
>>>>
>>>
>>> the problem is with "Signalling link down" and " osmo-bts-trx[26145]:
>>> <0001> bts.c:285 Shutting down BTS 0, Reason Abis close"
>>>
>>> i tried to verif the unit-id for both osmo-btstrx and osmo-bsc and found
>>> that it's the same!
>>> still can't figure why the abis close.
>>>
>>> for the config files :
>>>
>>> osmo-bts-trx.cfg:
>>> https://pastebin.com/wgBxXN6G
>>>
>>> osmo-bsc.cfg :
>>> https://pastebin.com/jh81aKrM
>>>
>>> Setup :
>>> osmocom CNI latest build for ubuntu 18.04 + limesdr mini
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Le mar. 17 d?c. 2019 ? 22:03, Pau Espin Pedrol <pespin at sysmocom.de> a
>>> ?crit :
>>>
>>>>
>>>>
>>>> On 12/17/19 8:55 PM, ah med wrote:
>>>> > the problem it's that i can't see the network using my phone,neither
>>>> on
>>>> > band 1800 or 900 !
>>>> >
>>>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>>> >     Transceiver.cpp:773 [tid=140437098583808][chan=0] command is
>>>> 'POWEROFF'
>>>> >       osmo-trx-lms[7995]: Sun Dec  8 18:02:05 2019 DTRXCTRL <0001>
>>>> >     Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP
>>>> >     POWEROFF 0'
>>>> >
>>>> >
>>>> > as you see, for the air interface,the program is sending  a
>>>> 'POWEROFF'
>>>> > command to the limesdrmini ! means that limesdr can't act as a bts
>>>> > correctly!right ?
>>>>
>>>> As I said, it's expected that the BTS upon connecting to osmo-trx first
>>>> sends a POWEROFF command to make sure the TRX is stopped, in a "known"
>>>> state. Once there, it configures it and finally turns it on with
>>>> "POWERON".
>>>>
>>>> > is there any way to dig more into the cause of this behavior ? the
>>>> only
>>>> > log i can see is from the systemctl !
>>>>
>>>> Please read the wiki and the user manuals to learn the basics on how to
>>>> operate the osmocom software. Specially how to access the VTY and
>>>> configure it as well as get logging information.
>>>> https://ftp.osmocom.org/docs/latest/
>>>>
>>>> --
>>>> - Pau Espin Pedrol <pespin at 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
>>>>
>>>
>>
>> --
>> Best Regards,
>> Sandi
>>
>>

-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191225/1b89c80a/attachment.htm>

From garrett.allen1990 at gmail.com  Tue Dec 31 02:20:02 2019
From: garrett.allen1990 at gmail.com (Garrett Allen)
Date: Tue, 31 Dec 2019 02:20:02 +0000
Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!!
Message-ID: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>

Hi All

I've used osmo-bsc in non standalone mode ie seperate components and all
works fine voice and sms work as should. However when introducing. sip
connector with asterisk the handsets will not make voice calls they just
constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
on raspbian 10 below is Asterisk config. Any help would be appreciated.

Gar

[GSM]
type=friend
host=127.0.0.1
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=gsm
context=gsmsubscriber
port=5062
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191231/db28725a/attachment.htm>

From djks74 at gmail.com  Tue Dec 31 11:13:43 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 31 Dec 2019 18:13:43 +0700
Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!!
In-Reply-To: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>
References: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>
Message-ID: <CANWiJYj-24s0hS2sYTFcqbRT9EnrqPkLaNOZt25ToyM8QsKECA@mail.gmail.com>

Have you try adding :

nat=yes

???

:)

regards,
Sandi / DUO

On Tue, Dec 31, 2019, 09:20 Garrett Allen <garrett.allen1990 at gmail.com>
wrote:

> Hi All
>
> I've used osmo-bsc in non standalone mode ie seperate components and all
> works fine voice and sms work as should. However when introducing. sip
> connector with asterisk the handsets will not make voice calls they just
> constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
> on raspbian 10 below is Asterisk config. Any help would be appreciated.
>
> Gar
>
> [GSM]
> type=friend
> host=127.0.0.1
> dtmfmode=rfc2833
> canreinvite=no
> disallow=all
> allow=gsm
> context=gsmsubscriber
> port=5062
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191231/9b913c70/attachment.htm>

From garrett.allen1990 at gmail.com  Tue Dec 31 14:23:48 2019
From: garrett.allen1990 at gmail.com (Garrett Allen)
Date: Tue, 31 Dec 2019 14:23:48 +0000
Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!!
In-Reply-To: <CANWiJYj-24s0hS2sYTFcqbRT9EnrqPkLaNOZt25ToyM8QsKECA@mail.gmail.com>
References: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>
 <CANWiJYj-24s0hS2sYTFcqbRT9EnrqPkLaNOZt25ToyM8QsKECA@mail.gmail.com>
Message-ID: <CAGpPSTTca-s_O=dJNzXoTB6bpaakCDdZkG313HDkgRcP2qGv6A@mail.gmail.com>

Unfortunately it made no difference adding nat=yes to the asterisk config.

On Tue, 31 Dec 2019, 11:13 Sandi Suhendro, <djks74 at gmail.com> wrote:

> Have you try adding :
>
> nat=yes
>
> ???
>
> :)
>
> regards,
> Sandi / DUO
>
> On Tue, Dec 31, 2019, 09:20 Garrett Allen <garrett.allen1990 at gmail.com>
> wrote:
>
>> Hi All
>>
>> I've used osmo-bsc in non standalone mode ie seperate components and all
>> works fine voice and sms work as should. However when introducing. sip
>> connector with asterisk the handsets will not make voice calls they just
>> constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
>> on raspbian 10 below is Asterisk config. Any help would be appreciated.
>>
>> Gar
>>
>> [GSM]
>> type=friend
>> host=127.0.0.1
>> dtmfmode=rfc2833
>> canreinvite=no
>> disallow=all
>> allow=gsm
>> context=gsmsubscriber
>> port=5062
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191231/05fd974d/attachment.htm>

From djks74 at gmail.com  Tue Dec 31 16:16:41 2019
From: djks74 at gmail.com (Sandi Suhendro)
Date: Tue, 31 Dec 2019 23:16:41 +0700
Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!!
In-Reply-To: <CAGpPSTTca-s_O=dJNzXoTB6bpaakCDdZkG313HDkgRcP2qGv6A@mail.gmail.com>
References: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>
 <CANWiJYj-24s0hS2sYTFcqbRT9EnrqPkLaNOZt25ToyM8QsKECA@mail.gmail.com>
 <CAGpPSTTca-s_O=dJNzXoTB6bpaakCDdZkG313HDkgRcP2qGv6A@mail.gmail.com>
Message-ID: <CANWiJYjVfdSHq-zrQ5gDWe13D3Z1vFM+M8iY-S11YiAzVhBkUQ@mail.gmail.com>

Can you describe more your configuration and setup with asterisk? your sip
connector settings, etc.. ?
Sip.conf, sip-custom-contexts, extensions.conf  ?

You said it it works when using osmo-mgw for voice?

On Tue, Dec 31, 2019 at 9:24 PM Garrett Allen <garrett.allen1990 at gmail.com>
wrote:

> Unfortunately it made no difference adding nat=yes to the asterisk config.
>
> On Tue, 31 Dec 2019, 11:13 Sandi Suhendro, <djks74 at gmail.com> wrote:
>
>> Have you try adding :
>>
>> nat=yes
>>
>> ???
>>
>> :)
>>
>> regards,
>> Sandi / DUO
>>
>> On Tue, Dec 31, 2019, 09:20 Garrett Allen <garrett.allen1990 at gmail.com>
>> wrote:
>>
>>> Hi All
>>>
>>> I've used osmo-bsc in non standalone mode ie seperate components and all
>>> works fine voice and sms work as should. However when introducing. sip
>>> connector with asterisk the handsets will not make voice calls they just
>>> constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
>>> on raspbian 10 below is Asterisk config. Any help would be appreciated.
>>>
>>> Gar
>>>
>>> [GSM]
>>> type=friend
>>> host=127.0.0.1
>>> dtmfmode=rfc2833
>>> canreinvite=no
>>> disallow=all
>>> allow=gsm
>>> context=gsmsubscriber
>>> port=5062
>>>
>>>

-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191231/b41a17f5/attachment.htm>

From garrett.allen1990 at gmail.com  Tue Dec 31 22:34:04 2019
From: garrett.allen1990 at gmail.com (Garrett Allen)
Date: Tue, 31 Dec 2019 22:34:04 +0000
Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!!
In-Reply-To: <CANWiJYjVfdSHq-zrQ5gDWe13D3Z1vFM+M8iY-S11YiAzVhBkUQ@mail.gmail.com>
References: <CAGpPSTTr3WJ4vQfjROVDtZNxgBf0on=imHzyGcfDEdoPWtciVg@mail.gmail.com>
 <CANWiJYj-24s0hS2sYTFcqbRT9EnrqPkLaNOZt25ToyM8QsKECA@mail.gmail.com>
 <CAGpPSTTca-s_O=dJNzXoTB6bpaakCDdZkG313HDkgRcP2qGv6A@mail.gmail.com>
 <CANWiJYjVfdSHq-zrQ5gDWe13D3Z1vFM+M8iY-S11YiAzVhBkUQ@mail.gmail.com>
Message-ID: <CAGpPSTT05ebjPC8ADZf407WwsYVPBSYagTndLh-xcE1E39Yw6g@mail.gmail.com>

Yes all works fine when not launching the setup with asterisk the MGW can
route calls just fine. Below are the configs for sip-custom-contexts.conf
and extensions.conf

[GSM]
type=friend
host=127.0.0.1
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=gsm
context=gsmsubscriber
port=5062

extensions.conf is quite large so i will omit all that was there by default
and included is what i have added directly to the end of the file

[gsmsubscriber]
exten=>_xxxxx,1,Dial(SIP/GSM/${EXTEN})
exten=>_XXXXX,n,Playback(vm-nobodyavail)
exten=>_xxxxx,n,HangUp

sip.conf is again default with just this library include at the end of the
file

#include sip-custom-contexts.conf

Thanks for the assistance





nat=yes

On Tue, 31 Dec 2019 at 16:16, Sandi Suhendro <djks74 at gmail.com> wrote:

> Can you describe more your configuration and setup with asterisk? your sip
> connector settings, etc.. ?
> Sip.conf, sip-custom-contexts, extensions.conf  ?
>
> You said it it works when using osmo-mgw for voice?
>
> On Tue, Dec 31, 2019 at 9:24 PM Garrett Allen <garrett.allen1990 at gmail.com>
> wrote:
>
>> Unfortunately it made no difference adding nat=yes to the asterisk config.
>>
>> On Tue, 31 Dec 2019, 11:13 Sandi Suhendro, <djks74 at gmail.com> wrote:
>>
>>> Have you try adding :
>>>
>>> nat=yes
>>>
>>> ???
>>>
>>> :)
>>>
>>> regards,
>>> Sandi / DUO
>>>
>>> On Tue, Dec 31, 2019, 09:20 Garrett Allen <garrett.allen1990 at gmail.com>
>>> wrote:
>>>
>>>> Hi All
>>>>
>>>> I've used osmo-bsc in non standalone mode ie seperate components and
>>>> all works fine voice and sms work as should. However when introducing. sip
>>>> connector with asterisk the handsets will not make voice calls they just
>>>> constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
>>>> on raspbian 10 below is Asterisk config. Any help would be appreciated.
>>>>
>>>> Gar
>>>>
>>>> [GSM]
>>>> type=friend
>>>> host=127.0.0.1
>>>> dtmfmode=rfc2833
>>>> canreinvite=no
>>>> disallow=all
>>>> allow=gsm
>>>> context=gsmsubscriber
>>>> port=5062
>>>>
>>>>
>
> --
> Best Regards,
> Sandi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20191231/ee1ca1e5/attachment.htm>

From circle at ccc-ffm.de  Wed Dec  4 11:59:35 2019
From: circle at ccc-ffm.de (circle)
Date: Wed, 04 Dec 2019 11:59:35 -0000
Subject: [osmocom-event-orga] 36c3: GSM base stations wanted - Handing out
 1 NanoBTS
Message-ID: <731d9762-e835-a029-b3b7-883c7ddd434e@ccc-ffm.de>

Hey,

yes, I ll drop one NanoBTS in Berlin, at Afra or Sysmocom before the first day of the conference.
Im not sure, if Ill be able to do so this week.

It actually belongs to Sysmocom / Harald.



Best regards,
circle

------

Dear all,

36c3 is going to happen soon, and as usually we're planing to setup
our own GSM/UMTS network (LTE is to be discussed). While we do have
enough UMTS NodeB units, we're looking for heroes who could sacrifice
their GSM base stations (preferably sysmoBTS or nanoBTS) for the
duration of the congress. Note that we're not considering SDRs (unless
somebody with a strong aspiration wants to ensure proper clock
distribution, filtering, power amplification, etc).

Please let us know 1) how many (and what kind of) units we could
borrow from you, 2) can you bring them to Leipzig before the first
day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?).
Thanks!

On behalf of the GSM team,
Vadim Yanitskiy.