From holger at freyther.de  Thu Jan  3 11:01:39 2019
From: holger at freyther.de (Holger Freyther)
Date: Thu, 3 Jan 2019 11:01:39 +0000
Subject: Scaling up virtual bts tests for the BTS test - how I hold it
 wrong?
In-Reply-To: <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de>
References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de>
 <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de>
Message-ID: <A42B037C-3B77-4A50-AF58-0F8A79EC7750@freyther.de>



> On 30. Dec 2018, at 23:21, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
> 
> Hi Holger,

Hey Pau,

thank you for the instant response!


> One can similarly do the same to request allocation of 100 sysmoBTS:
> 
> bts:
> - type: osmo-bts-sysmo
>  times: 100


ah great! That's a good interim solution.



> I'd like to be able to specifcy pools of objects in resources.conf so we don't need to add 1 line per object there. In the case of IP addresses, specifying a subnet range and let osmo-gsm-tester to expand that into a set of objects at runtime.

+1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool



>> * register_default_mass.py:
>>   I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable.
> 
> Yeah for now the way to do it is to ask for one until you get the specific exception thrown when there's no more objects of that type or matching the specifications. Fine for me to add more APIs to fetch this kind of information more easily.

There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like:

hlr:                             <- define a HLR. Multiple might be possible
  -subs:
   times: 100000
   pool:                          <- define IMSI/MSISDN pool
     -name: Foo
      imsi_start: XXXX
      msisdn_start: XXXX
      kind: draw_at_random
      times: 10k
hlr:
  ...

msc:                           <- MSCs connecting to it? High level or scope to HLR?
    type: nitb
    bsc:                       <- BSCs connecting to (void if NITB is used)
     times: 5
     -bts:                     <- BTSs
       type: 		       <- ...

virtual_mobiles:	       <- borrowing from the HLRs?       
    ...

What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable.

One benefit is that the same test would work for both NITB and BSC/MSC.



>> * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool.
> 

> So you could specify manually a different ARFCN for each bts (number of elements in object modifiers must match number of elements in the resources in suite.conf). Let's say you want 3 BTS with 3 differnet arfcn, 2 of them in 1800 band and 1 in 900 band:


I will give it a try. Please be aware that ARFCNs do not uniquely identify a band.



>> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
> 
> Unfortunately these kind of capacities are so far fixed by the suite.conf. If you want to do tests with different numbers, you can manually change the "times" attribute in there, or put a big number and only use a subset of them when running the test in the suite.


I am thinking of a xpath like command line parameter

--suite_override=hlr[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].bts.times=100


what do you think?

	holger

From pespin at sysmocom.de  Thu Jan  3 15:13:04 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 3 Jan 2019 16:13:04 +0100
Subject: Scaling up virtual bts tests for the BTS test - how I hold it
 wrong?
In-Reply-To: <A42B037C-3B77-4A50-AF58-0F8A79EC7750@freyther.de>
References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de>
 <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de>
 <A42B037C-3B77-4A50-AF58-0F8A79EC7750@freyther.de>
Message-ID: <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de>

Hi Holger,


>> I'd like to be able to specifcy pools of objects in resources.conf so we don't need to add 1 line per object there. In the case of IP addresses, specifying a subnet range and let osmo-gsm-tester to expand that into a set of objects at runtime.
> 
> +1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool

No timeline since I could workaround that myself so far by adding new IP 
addresses manually. I tend to implement this kind of new features only 
once I find I am really blocked or constrained by previous system when 
trying to add new kind of tests (or more complex ones).


> There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like:
> 
> hlr:                             <- define a HLR. Multiple might be possible
>    -subs:
>     times: 100000
>     pool:                          <- define IMSI/MSISDN pool
>       -name: Foo
>        imsi_start: XXXX
>        msisdn_start: XXXX
>        kind: draw_at_random
>        times: 10k
> hlr:
>    ...
> 
> msc:                           <- MSCs connecting to it? High level or scope to HLR?
>      type: nitb
>      bsc:                       <- BSCs connecting to (void if NITB is used)
>       times: 5
>       -bts:                     <- BTSs
>         type: 		       <- ...
> 
> virtual_mobiles:	       <- borrowing from the HLRs?
>      ...
> 
> What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable.
> 
> One benefit is that the same test would work for both NITB and BSC/MSC.
> 

TBH I don't like the idea of making the suite/scenario yml file 
structure a lot more complex, I think current status is quite complex 
and makes it already difficult to gasp how to put everything together.

The kind of stuff that you intend to do here can already be done far 
more easily by using (or extending) the python test API. That's mostly 
what the test does anyway: Setting up a specific topology with a 
pre-allocated sub-set of objects, and then do some actions on that.

If you require several similar tests but with different number of 
objects, you can abstract that by using the "lib" feature of a suite. 
See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its 
users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py



> 
> I will give it a try. Please be aware that ARFCNs do not uniquely identify a band.

Yes, that's why in osmo-gsm-tester initial work around this topic 
expects an arfcn to be actually a dictionary with ARFCN+BAND iirc.

> 
> 
> 
>>> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
>>
>> Unfortunately these kind of capacities are so far fixed by the suite.conf. If you want to do tests with different numbers, you can manually change the "times" attribute in there, or put a big number and only use a subset of them when running the test in the suite.
> 
> 
> I am thinking of a xpath like command line parameter
> 
> --suite_override=hlr[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].bts.times=100
> 

This kind of feature is similar to what scenarios provide already. The 
issue is still though that in order to sanely combine and override yml 
cfg files (lists, tuples, dictionaries, etc.) we require some 
restrictions in order to make it "sane" and usable for most cases.
For instance right now we handle lists of "non-complex" attributes 
(integers, strings, etc.) as sets when combining them, but we expect 
lists of dictionaries to be the same size when merging them to have 
meaningful result (so order of items in list is important when combining 
or overwriting them).

Lists of objects are expanded before merging suites and scenarios, so 
the "times" attribute is removed and item put in place in the list 
before combine() and override() operations are done.

You may want to look at git history to understand reasons behind current 
system.

Maybe one could use scenario modifiers to change the amount of objects 
from the suite.conf, that's something to explore, but I'd need to invest 
some time testing and reading the code too. IIRC summary is that regular 
suite.conf + scenarios are merged using combine(), while scenario 
modifiers are merged using override().

Something like
[suite.conf]
   bts:
   - times: 1

[mod-num-bts.cfg]
modifiers:
   bts:
   - times: 2

I think to that in order to override() you also need same list size, due 
to sanity checks. We could perhaps add a new "section" in scenarios 
which overpasses these checks, let's call it "appends" or whatever, 
which let's you add new requires resources to the suite.

These are my 5cents, not an ultimate answer but just some advises and ideas.

Regards,
Pau

-- 
- 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 holger at freyther.de  Fri Jan  4 02:36:11 2019
From: holger at freyther.de (Holger Freyther)
Date: Fri, 4 Jan 2019 02:36:11 +0000
Subject: Declaratively describing network topology (WAS Re: Scaling up virtual
 bts tests for the BTS test - how I hold it wrong?)
In-Reply-To: <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de>
References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de>
 <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de>
 <A42B037C-3B77-4A50-AF58-0F8A79EC7750@freyther.de>
 <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de>
Message-ID: <BE187938-E67F-42D7-9CEB-F64E98C9D1DD@freyther.de>



> On 3. Jan 2019, at 15:13, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
> 

Hi!

let me spin this into a new thread.


>> What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable.
>> One benefit is that the same test would work for both NITB and BSC/MSC.
> 
> TBH I don't like the idea of making the suite/scenario yml file structure a lot more complex, I think current status is quite complex and makes it already difficult to gasp how to put everything together.
> 
> The kind of stuff that you intend to do here can already be done far more easily by using (or extending) the python test API. That's mostly what the test does anyway: Setting up a specific topology with a pre-allocated sub-set of objects, and then do some actions on that.

SCNR. This sounds too much like "just write more code". ;)


> If you require several similar tests but with different number of objects, you can abstract that by using the "lib" feature of a suite. See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py

The number of "objects" is secondary. Let's say 40k subscribers, 256 BSCs, 512 BTS. The numbers are constant but there are many ways a network can be organized. And many present a nice problem/failure potential for our software stack.

But what I want to stretch here. The topology does not matter to the success criteria (99% of subs manage to do X within Y units of time) or execution of the test (start mobiles and ask them to do stuff). If the topology does not matter, why would I want to change the test code?

I want the suite to give me a configured network and then use the functional identities (e.g. connect to the SMPP interfaces, etc). If it is in a suite.conf, topology.conf or a RPC call is secondary to me.

Does this change anything for you?

holger

From dechaoforever at 163.com  Mon Jan  7 00:11:22 2019
From: dechaoforever at 163.com (dechaoforever)
Date: Mon, 7 Jan 2019 08:11:22 +0800 (GMT+08:00)
Subject: How osmocom-bb(mobile app) display non-english character SMS
Message-ID: <18a02816.26b.16825a64f83.Coremail.dechaoforever@163.com>

Hi ALL.
Last weekend I compiled osmocom-bb and now I can send English SMS from one peer to another by using its app 'mobile'. But how to make it possible if I want to send SMS including non-English character, like below.
??
?????
?????.
??????
I will be appreciated if you can help me.



-----------------
from dechao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20190107/e80fb600/attachment.htm>

From laforge at gnumonks.org  Mon Jan  7 13:43:28 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 Jan 2019 14:43:28 +0100
Subject: How osmocom-bb(mobile app) display non-english character SMS
In-Reply-To: <18a02816.26b.16825a64f83.Coremail.dechaoforever@163.com>
References: <18a02816.26b.16825a64f83.Coremail.dechaoforever@163.com>
Message-ID: <20190107134328.GR17214@nataraja>

Hi dechao,

On Mon, Jan 07, 2019 at 08:11:22AM +0800, dechaoforever wrote:
> Last weekend I compiled osmocom-bb and now I can send English SMS from one peer to another by using its app 'mobile'. But how to make it possible if I want to send SMS including non-English character, like below.

You will have to implement support for UCS-2 character set based SMS to OsmocomBB, I think
nobody has implemented this so far.

We are very much looking forward to receiving and merging any related patches!

Thanks,
	Harald

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


From laforge at gnumonks.org  Sat Jan 12 10:00:51 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 12 Jan 2019 11:00:51 +0100
Subject: Fwd: OSMOCOM-BB HandOver
In-Reply-To: <CAOzNDt3Ut-pC=m9STjXtXx18dNaN=CPAAP8-NvwQgQFmCctPHw@mail.gmail.com>
References: <CAOzNDt0ZZS5iEewzCqcvZkVdryfapxa7QiERQDnbu9dpzt6z5g@mail.gmail.com>
 <4B0B2FB7-BDA7-428F-B9DA-C0AE28F2C912@gnumonks.org>
 <CAOzNDt36ksi_xwUHiX1NeCBi=Ow+_wd9ttY2YS_7FAxsghtXCA@mail.gmail.com>
 <CAOzNDt082bvky1RW7J268=BjZ3jYKf6BpXQbs=qNwnuWyAu9Mg@mail.gmail.com>
 <02ad8a41-0952-91ca-4723-c924c6bdc635@sysmocom.de>
 <CAOzNDt3Ut-pC=m9STjXtXx18dNaN=CPAAP8-NvwQgQFmCctPHw@mail.gmail.com>
Message-ID: <20190112100051.GZ606@nataraja>

Dear Muhammad,

On Tue, Dec 19, 2017 at 04:31:58PM +0500, Muhammad Awais Aslam wrote:
>   Hi,  Sorry for being so late for replying to this email. The person who
> was working with us on the handover code had left and we were not in the
> position to upload the code at that time. I have uploaded the code now on
> gerrit for review. I hope we would get some help to complete the handover
> implementation in osmocombb.
> 
> Link to the uploaded code is: https://gerrit.osmocom.org/#/c/5490/

Thanks againf or your submission.

It's saddening me that you've been one of the few people substantially working
on OsmocomBB in recent years, but yet the wider community is not able to benefit
from your work, as the code review has stopped at its very early stage one year ago.

Open Source projects *only* exist because people take the effort of contributing
to them.  And contribution doesn't mean simply to put some code somewhere, but to
work with the community and the maintainers to bring the code into merge-able form.

After more than one year has passed since your submission to gerrit, I
would like to encourage you to take some time to clean the patches up
and bring them into merge-able form.

Thanks again.

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


From axilirator at gmail.com  Mon Jan 14 03:42:05 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 14 Jan 2019 10:42:05 +0700
Subject: Google Summer of Code 2019
Message-ID: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>

Dear Osmocom community,

starting from 16th of January (until 7th of February) we can apply
Google Summer of Code as an Open source mentor organization. Many
well-known projects, such as Debian, FFmpeg, Apache, Git, GCC,
GNURadio and others, have been participating last year.

Personally, I think it's a great opportunity to move some of our
projects forward. I would like to know your opinions about this
idea, should we participate? I would be happy to be a mentor.

With best regards,
Vadim Yanitskiy.


From nhofmeyr at sysmocom.de  Mon Jan 14 13:38:55 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 14 Jan 2019 14:38:55 +0100
Subject: Google Summer of Code 2019
In-Reply-To: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>
References: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>
Message-ID: <20190114133855.GA19041@my.box>

On Mon, Jan 14, 2019 at 10:42:05AM +0700, Vadim Yanitskiy wrote:
> starting from 16th of January (until 7th of February) we can apply
> Google Summer of Code as an Open source mentor organization. Many

I think we had a GSoC trainee once.
What does it take to participate? Maybe you can simply organise this?

> Personally, I think it's a great opportunity to move some of our
> projects forward.

I'm not so sure about quality forward pushing coming from GSoC.
But why not.

~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/baseband-devel/attachments/20190114/cc06f059/attachment.bin>

From laforge at gnumonks.org  Tue Jan 15 16:13:49 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Jan 2019 17:13:49 +0100
Subject: Google Summer of Code 2019
In-Reply-To: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>
References: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>
Message-ID: <20190115161349.GP11166@nataraja>

Hi Vadim,

On Mon, Jan 14, 2019 at 10:42:05AM +0700, Vadim Yanitskiy wrote:
> starting from 16th of January (until 7th of February) we can apply
> Google Summer of Code as an Open source mentor organization. 

Thanks.  It's something that I've been pondering several times in the
past, too.  I know Holger did it once for Osmocom in the past, AFAIR,
and in netfilter (where I was involved before) we also participated
in GSoC.

The results were - as any results from new developers - mixed.  But
I think it's a good opportunity to get new people involved in the project.

> Personally, I think it's a great opportunity to move some of our
> projects forward. I would like to know your opinions about this
> idea, should we participate? I would be happy to be a mentor.

I think it's a good idea and I'd support it.  I just know that given the
many projects I'm already way too late with and overloaded, I will not
be able to personally mentor a GSoC student.

So I'm happy to help with formailtiies, etc. - but that's about it, sorry.

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


From akita at qmail.qcc.edu  Sun Jan 20 23:51:37 2019
From: akita at qmail.qcc.edu (Andi Kita)
Date: Sun, 20 Jan 2019 18:51:37 -0500
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
Message-ID: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>

sched_clck.o: In function `sched_clck_tick':
/home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:64: undefined
reference to `osmo_clock_gettime'
sched_clck.o: In function `sched_clck_handle':
/home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:123: undefined
reference to `osmo_clock_gettime'

Any help is appreciated. Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20190120/1f7738b2/attachment.htm>

From axilirator at gmail.com  Mon Jan 21 02:08:30 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 21 Jan 2019 09:08:30 +0700
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
Message-ID: <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>

Hello,

> undefined reference to `osmo_clock_gettime'

it seems you're using an ancient version of libosmocore.
Please upgrade to the current master and try again.

With best regards,
Vadim Yanitskiy.


From axilirator at gmail.com  Mon Jan 21 02:20:05 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 21 Jan 2019 09:20:05 +0700
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
Message-ID: <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>

> It is the same version of libosmocore that comes with osmocombb.

https://osmocom.org/projects/baseband/wiki/Software_Getting_Started#Dependencies-for-the-host

> For osmocomBB, as for several other osmocom projects, you will also need libosmocore.
> Note: Although libosmocore is included when getting osmocom-bb from the git repository,
> you have to install it separately. The libosmocore subtree is only used to compile the
> embedded ARM version of libosmocore.

With best regards,
Vadim Yanitskiy.


From akita at qmail.qcc.edu  Mon Jan 21 02:43:27 2019
From: akita at qmail.qcc.edu (Andi Kita)
Date: Sun, 20 Jan 2019 21:43:27 -0500
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
 <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
Message-ID: <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>

satel at satel-HP-Pavilion-Notebook:/home/imsicatcher/osmocom-bb/src/shared$
sudo ./update-libosmocore.sh
remote: Counting objects: 7821, done.
remote: Compressing objects: 100% (4516/4516), done.
remote: Total 7821 (delta 5871), reused 4635 (delta 3282)
Receiving objects: 100% (7821/7821), 1.36 MiB | 1.01 MiB/s, done.
Resolving deltas: 100% (5871/5871), completed with 271 local objects.
>From git://git.osmocom.org/libosmocore
 * branch            master     -> FETCH_HEAD
Auto-merging src/shared/libosmocore/src/vty/vty.c
Auto-merging src/shared/libosmocore/src/vty/logging_vty.c
CONFLICT (content): Merge conflict in
src/shared/libosmocore/src/vty/logging_vty.c
Removing src/shared/libosmocore/src/talloc.c
Auto-merging src/shared/libosmocore/src/gb/gprs_ns_vty.c
CONFLICT (content): Merge conflict in
src/shared/libosmocore/src/gb/gprs_ns_vty.c
Auto-merging src/shared/libosmocore/src/gb/gprs_bssgp_vty.c
CONFLICT (content): Merge conflict in
src/shared/libosmocore/src/gb/gprs_bssgp_vty.c
Auto-merging src/shared/libosmocore/src/counter.c
Auto-merging src/shared/libosmocore/include/osmocom/gsm/gsm48_ie.h
Auto-merging src/shared/libosmocore/include/osmocom/core/linuxlist.h
Removing src/shared/libosmocore/doc/vty/merge_doc.xsl
Removing src/shared/libosmocore/debian/patches/debian-changes-0.1.17-1
Removing src/shared/libosmocore/debian/libosmocore-dev.dirs
Removing src/shared/libosmocore/debian/libosmocore-dbg.install
Removing src/shared/libosmocore/debian/libosmocore-dbg.dirs
Removing src/shared/libosmocore/debian/docs
Automatic merge failed; fix conflicts and then commit the result.


On Sun, Jan 20, 2019, 9:20 PM Vadim Yanitskiy <axilirator at gmail.com wrote:

> > It is the same version of libosmocore that comes with osmocombb.
>
>
> https://osmocom.org/projects/baseband/wiki/Software_Getting_Started#Dependencies-for-the-host
>
> > For osmocomBB, as for several other osmocom projects, you will also need
> libosmocore.
> > Note: Although libosmocore is included when getting osmocom-bb from the
> git repository,
> > you have to install it separately. The libosmocore subtree is only used
> to compile the
> > embedded ARM version of libosmocore.
>
> With best regards,
> Vadim Yanitskiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20190120/bea1a955/attachment.htm>

From akita at qmail.qcc.edu  Mon Jan 21 03:47:26 2019
From: akita at qmail.qcc.edu (Andi Kita)
Date: Sun, 20 Jan 2019 22:47:26 -0500
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
 <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
 <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>
Message-ID: <CAFhpUpR1-Eoa6AS=gYHzaGj3+4HCT13vF=NyQFyM3EHm9OdYrg@mail.gmail.com>

I had to commit my changes so that's why. After I committed my changes. It
worked. But now its lookig for talloc.h but after doing apt-get install
libtalloc-dev it has not found it yet. But I would give it a try tomorrow
when I manually compile talloc.

On Sun, Jan 20, 2019, 9:43 PM Andi Kita <akita at qmail.qcc.edu wrote:

> satel at satel-HP-Pavilion-Notebook:/home/imsicatcher/osmocom-bb/src/shared$
> sudo ./update-libosmocore.sh
> remote: Counting objects: 7821, done.
> remote: Compressing objects: 100% (4516/4516), done.
> remote: Total 7821 (delta 5871), reused 4635 (delta 3282)
> Receiving objects: 100% (7821/7821), 1.36 MiB | 1.01 MiB/s, done.
> Resolving deltas: 100% (5871/5871), completed with 271 local objects.
> From git://git.osmocom.org/libosmocore
>  * branch            master     -> FETCH_HEAD
> Auto-merging src/shared/libosmocore/src/vty/vty.c
> Auto-merging src/shared/libosmocore/src/vty/logging_vty.c
> CONFLICT (content): Merge conflict in
> src/shared/libosmocore/src/vty/logging_vty.c
> Removing src/shared/libosmocore/src/talloc.c
> Auto-merging src/shared/libosmocore/src/gb/gprs_ns_vty.c
> CONFLICT (content): Merge conflict in
> src/shared/libosmocore/src/gb/gprs_ns_vty.c
> Auto-merging src/shared/libosmocore/src/gb/gprs_bssgp_vty.c
> CONFLICT (content): Merge conflict in
> src/shared/libosmocore/src/gb/gprs_bssgp_vty.c
> Auto-merging src/shared/libosmocore/src/counter.c
> Auto-merging src/shared/libosmocore/include/osmocom/gsm/gsm48_ie.h
> Auto-merging src/shared/libosmocore/include/osmocom/core/linuxlist.h
> Removing src/shared/libosmocore/doc/vty/merge_doc.xsl
> Removing src/shared/libosmocore/debian/patches/debian-changes-0.1.17-1
> Removing src/shared/libosmocore/debian/libosmocore-dev.dirs
> Removing src/shared/libosmocore/debian/libosmocore-dbg.install
> Removing src/shared/libosmocore/debian/libosmocore-dbg.dirs
> Removing src/shared/libosmocore/debian/docs
> Automatic merge failed; fix conflicts and then commit the result.
>
>
> On Sun, Jan 20, 2019, 9:20 PM Vadim Yanitskiy <axilirator at gmail.com wrote:
>
>> > It is the same version of libosmocore that comes with osmocombb.
>>
>>
>> https://osmocom.org/projects/baseband/wiki/Software_Getting_Started#Dependencies-for-the-host
>>
>> > For osmocomBB, as for several other osmocom projects, you will also
>> need libosmocore.
>> > Note: Although libosmocore is included when getting osmocom-bb from the
>> git repository,
>> > you have to install it separately. The libosmocore subtree is only used
>> to compile the
>> > embedded ARM version of libosmocore.
>>
>> With best regards,
>> Vadim Yanitskiy.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20190120/1ad31bca/attachment.htm>

From axilirator at gmail.com  Mon Jan 21 04:04:51 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 21 Jan 2019 11:04:51 +0700
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAFhpUpR1-Eoa6AS=gYHzaGj3+4HCT13vF=NyQFyM3EHm9OdYrg@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
 <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
 <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>
 <CAFhpUpR1-Eoa6AS=gYHzaGj3+4HCT13vF=NyQFyM3EHm9OdYrg@mail.gmail.com>
Message-ID: <CAPEnp=ZYaWEQghwO5FZgfj7+TtYfvg=pMpFc1inG+Q0Dum4iaA@mail.gmail.com>

> /home/imsicatcher/osmocom-bb/src/shared$ sudo ./update-libosmocore.sh

Where have you found this?!?

AFAIR, the wiki clearly states how to install libosmocore, and there was
nothing written about this script. Please read the wiki carefully first.

With best regards,
Vadim Yanitskiy.


From akita at qmail.qcc.edu  Mon Jan 21 04:21:52 2019
From: akita at qmail.qcc.edu (Andi Kita)
Date: Sun, 20 Jan 2019 23:21:52 -0500
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAPEnp=ZYaWEQghwO5FZgfj7+TtYfvg=pMpFc1inG+Q0Dum4iaA@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
 <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
 <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>
 <CAFhpUpR1-Eoa6AS=gYHzaGj3+4HCT13vF=NyQFyM3EHm9OdYrg@mail.gmail.com>
 <CAPEnp=ZYaWEQghwO5FZgfj7+TtYfvg=pMpFc1inG+Q0Dum4iaA@mail.gmail.com>
Message-ID: <CAFhpUpRt-V+5PwXt+t_CmV8s29grBF1-1m99S-uKH3qjriQ4YA@mail.gmail.com>

When you download osmocombb is in the shared directory. I am surprised you
never seen it.

On Sun, Jan 20, 2019, 11:05 PM Vadim Yanitskiy <axilirator at gmail.com wrote:

> > /home/imsicatcher/osmocom-bb/src/shared$ sudo ./update-libosmocore.sh
>
> Where have you found this?!?
>
> AFAIR, the wiki clearly states how to install libosmocore, and there was
> nothing written about this script. Please read the wiki carefully first.
>
> With best regards,
> Vadim Yanitskiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20190120/3cec6d5e/attachment.htm>

From axilirator at gmail.com  Mon Jan 21 04:42:57 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Mon, 21 Jan 2019 11:42:57 +0700
Subject: I have a problem compiling osmocombb in Ubuntu 14.04
In-Reply-To: <CAFhpUpRt-V+5PwXt+t_CmV8s29grBF1-1m99S-uKH3qjriQ4YA@mail.gmail.com>
References: <CAFhpUpTOi4V5rxq6gaNJDPj61YFgLH=Ztj6HxzJpiTtsnDa9=w@mail.gmail.com>
 <CAPEnp=bgS2zLeVef1mC6cw6WZpzW47vh_JK-mnfmEbuohn3suw@mail.gmail.com>
 <CAFhpUpTgwRG-viwUN9yzSp9oUvraxjM+DF+sYZ4XH5Wg1So28Q@mail.gmail.com>
 <CAPEnp=aA4JLPwbiPPNnRMPSxFiqG_-tHfA4h1qrg2=t2uLYaFA@mail.gmail.com>
 <CAFhpUpTcazHEO65W7Z3r-4eHqKfS-0Ormmx_25LRXMoL1k+PHg@mail.gmail.com>
 <CAFhpUpR1-Eoa6AS=gYHzaGj3+4HCT13vF=NyQFyM3EHm9OdYrg@mail.gmail.com>
 <CAPEnp=ZYaWEQghwO5FZgfj7+TtYfvg=pMpFc1inG+Q0Dum4iaA@mail.gmail.com>
 <CAFhpUpRt-V+5PwXt+t_CmV8s29grBF1-1m99S-uKH3qjriQ4YA@mail.gmail.com>
Message-ID: <CAPEnp=YDMwepndEykJ3f_L9G=pcr8B8ffUkJE_=EuLZFrqypVA@mail.gmail.com>

> I am surprised you never seen it.

I am aware of this script. The question is why you decided to use it.
If it's mentioned somewhere in the wiki, we should clarify its purpose,
and prevent others from using it. Probably, also makes sense to
remove it from the repository.

Please see: https://osmocom.org/projects/libosmocore/wiki/Libosmocore

With best regards,
Vadim Yanitskiy.


From holger at freyther.de  Tue Jan 22 15:16:18 2019
From: holger at freyther.de (Holger Freyther)
Date: Tue, 22 Jan 2019 15:16:18 +0000
Subject: Declaratively describing network topology (WAS Re: Scaling up
 virtual bts tests for the BTS test - how I hold it wrong?)
In-Reply-To: <BE187938-E67F-42D7-9CEB-F64E98C9D1DD@freyther.de>
References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de>
 <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de>
 <A42B037C-3B77-4A50-AF58-0F8A79EC7750@freyther.de>
 <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de>
 <BE187938-E67F-42D7-9CEB-F64E98C9D1DD@freyther.de>
Message-ID: <0FC29A3C-238E-4759-8E42-2C2677958BC0@freyther.de>



> On 4. Jan 2019, at 02:36, Holger Freyther <holger at freyther.de> wrote:
> 


Hey Pau!

Please take your time to respond to this. I understand that this will stall for some time now.

> 
> Does this change anything for you?


When looking at the p4[1][2] examples I noticed they are in a similar situation. E.g. when building a network of 100 switches, it doesn't say how they are connected (I would make it one big loop).

I think we are in a similar situation and have a need to define topology (without having to rewrite the test).

In the interim I will make sure we can execute our single test properly.

holger




[1] A language to program network flow/switches.
[2] https://github.com/p4lang/tutorials/blob/dc08948a344c6ff26af47d2a2447800cab94ab49/exercises/load_balance/topology.json