Commit osmo-msc 27b40c601c41fde70446ad553629494234c07662 removes this
option from default configuration as it is really not used in osmo-msc,
it comes from osmo-nitb times.
Change-Id: Iac1948113514414e7573f3bbfb3ce82e6c49adb6
The Osmo MS driver is launching many many processes and I would
like to use the logging framework for the code as well.
Unfortunately the inspect/traceback code will use a linecache which
will execute stat(2) on one or more python files.
Related: OS#2927
Change-Id: I8f6bacadcf74d3aa25db1e1f41644f64aa19cf92
This reverts commit 4a22ac7d2c.
Issue has been fixed in OS#2354, osmo-msc
1e67fea7ba5c6336066b78f98a28ab33b05c36c4.
Change-Id: I83d857c639db35abcd05bc87db9962d092c10eca
There are plenty of VTY commands that were inherited from OsmoNITB,
but which make no sense in a BSC. Upstream OsmoBSC has removed them in
change-ids Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38,
c499e5c62e9bef0db219e4658ffeb3292d6e6a5b and
8311a81bae85618302273c3f769275893161a7d7
Change-Id: I79ff48983d9cb7b875c1859870d5e3bce2c0ef22
Since libosmocore doesn't support XOR at all, it seems weird to use it in the
test, even though it's just a selftest without libosmocore involved...
Change-Id: I51edec255e7ef277907817b3187c2f492465467f
So far the resources.conf says we're using XOR, but we wrongly map 'xor' to 1,
which is actually comp128v1 in enum osmo_auth_algo from libosmocore (which
osmo-hlr uses to interpret the numbers from the hlr.db).
This explains why our "xor" tests are succeeding even though libosmocore
doesn't support XOR at all: we were using comp128v1 all the while.
Fix the auth algo mapping:
- define correct mappings, copying enum osmo_auth_algo, in util.py
- add a function to get the enum value from name, in util.py
- use this in osmo_hlr.py
Change subscriber_add() API to take the algorithm string instead of a number.
The number is libosmocore internal and we should not expose it within our API
beyond above dict. There are no callers using this parameter yet anyway.
Adjust resources.conf to indicate COMP128v1 which we are actually using and
which means we're still using algorithm number 1 after this change.
BTW, osmo-nitb uses the ctrl interface which interprets the names, so is not
vulnerable to mapping wrong numbers and needs no fix. (If osmo-hlr featured
similar CTRL, which it doesn't yet, this code could be more robust.)
Related: OS#2758
Change-Id: I7a6ce92468a6ae46136ad4f62381da261fd196c8
osmo-ggsn requires a link-local IPv6 address to be added to the
tun interface, otherwise the apn will not be configured correctly and it
won't be able to allocate addresses from the ipv6 pool later on.
Some OS don't support autoconfiguring link-local IPv6 addresses when the
interface is brought up (some linux versions are known to fail at it).
This is the case for our Prod osmo-gsm-tester setup (running debian8
with kernel 3.16.51).
Make sure we configure correctly the interface by forcing osmo-ggsn to
set on the interface and use a specific IPv6 link-local address. This is
done by using the "ipv6 link-local" vty cmd in osmo-ggsn.
After this modification, we can re-enable ipv6 gprs context creation as
it will work in Prod setup.
Related: OS#2746
Change-Id: Ib291c02a3c57a4189f9c4b1b856109be97ad2a34
Commit c9817a50ff moved code from
different BTS into a shared base class, and create_pcu method was
created to be implemented by subclasses to get a new pcu object.
However, parameters where wrongly copied over from pcu() method during
refactoring. create_pcu() has no parameters.
Change-Id: I1e95f2e658a870f86dd9d9d25f446b8efa4107a4
A lot of code can be shared by all osmocom related BTS we currently use
(sysmo, octphy, trx). This commits moves all this easily shareable code
to an abstract class OsmoBts which all (osmocom) BTS use.
Some bits of code do not apply for osmo-bts-sysmo but it's still shared
by BTS running in the main unit (octphy, trx), for instance the pcu
socket handling. Those are put together in OsmoBtsMainUnit.
This way we have:
log.Origin<-OsmoBts<-OsmoBtsMainUnit<-OsmoBtsOctphy
log.Origin<-OsmoBts<-OsmoBtsMainUnit<-OsmoBtsTrx
log.Origin<-OsmoBts<-OsmoBtsSysmo
Also take the chance to categorize the different APIs in the new
abstract class based on their use and scope.
Some code changes while moving which were required:
- A new protected abstract API "create_pcu", which returns an object of
"pcu" interface. Subclasses implement this API returning either a
PcySysmo or a PcuOsmo object. This is needed to abstract the pcu()
getter into the base class.
- For BTS running in the main unit, pcu_sk_tmp_dir object is allocated
when first used (API pcu_socket_path()) instead of doing it in the
constructor. This is moved into OsmoBtsMainUnit
Change-Id: I86db35a7f2497d37360b2c56affa8bf6bf704ee2
osmo-ggsn is failing to create tun ipv6 device in Prod main unit.
Afterwards, as the iface is not created, it cannot find its link-local
ip and it doesn't configure the ipv6 pool. Later on, when an ipv4v6 ctx
is requested, it fails because apn doesn't support ipv6 (because the
pool is not created).
Related: OS#2746
Change-Id: I018c525a8a3d108233740ee1376b2671fefbbb59
This is a temporary workaround to be able to test gprs signalling until
we set up all required bits to run osmo-ggsn in its own namespace.
Change-Id: I0a3ce16218f0274e0be09bbf2881bc21636acdf9
Otherwise osmo-ggsn tries to allocate one IP of each type but fails
because the other APNs are ipv4-only or ipv6-only.
Change-Id: I53baa63dc1b83616a35af182cb6f56ee3d7fe38b
This reverts commit 31b7f0f9de.
EC20 actually supports the feature. I was wrong mainly due to 2 reasons:
- I somehow failed to set the modem Online before checking for the
interface, and in that case it is not shown.
- The test I saw failing in prod is due to /gobi_0 being actually a
gobi2000 there, and the once failing was actually the gobi2000 and not
the EC20.
Change-Id: I31ad35b718e20168a75930498901015ca2015a52
At least the signalling support we are currently running, so let's add
the gprs feature to them as they can be used to run the current tests.
Change-Id: I04459786ba76813ebaa7867bcc86afb4fa9700b9
As the interface never appears, tests using the modem fail because we
wait for all the interfaces to be available based on the features
attribute.
Change-Id: I68fcf2b9083966ad42940e1629abe2a1a6b74095
It's difficult to know which path is which, and actually in the prod env
gobi_0 is given to gobi 2000 instead of EC20, which means the attributes
would be applying to the wrong resource.
Change-Id: If17ff9f3d9c4c74bf0aa7966b1dd2f878175a8f0
Only GPRS signalling setup is supported so far by osmo-gsm-tester, thus
we don't test sending data yet here, but at least we can already test
pdp context activation.
This test will be extended to run ping once we support setting up the
GPRS data plane in osmo-gsm-tester.
Change-Id: I8695029cb7a43cd48f650c88f38b4c054da0bc6b
Up to this point we can test signalling plane: attaching to GPRS network and activating a
context.
Data plane (sending IP packets through the network) is still not
implemented as it requires setting up the network interface provided by
ofono as well as routing, and most probably move osmo-ggsn to its own
network namespace.
Change-Id: I605ba1bb1103a045a9b5d0e7215c05dfc1fe575f
This is required to start osmo-pcu after osmo-bts is already setup and
activated. Otherwise osmo-pcu ends after connecting to socket with:
"pcu_l1_if.cpp:416 BTS not available"
Change-Id: I7209589f60bda63094336e417638906be5e273c4
In 3b18044859df15ffd2ad4c3e5c3d2c94a2923eb9 this command
has been dropped and is no longer recognized.
Change-Id: I98546e36f8c809e8066fe0cc0d80d0ae3276473f
authentication is firmly VLR land and must go away from bsc. That option
is a leftover from nitb. It will be removed at some point.
Change-Id: I3bb4189b33173245116018e437e113c6c1226639
As of osmo-bsc ad47f7108aff5438bd2c6f7c0e898f4aa3b66fbe, this command
has been dropped and is no longer recognized.
Change-Id: Id97074195f045e6872a1a7030671a06259c9ec31
Also make sure we power off the modem during cleanup, to make sure we
set it offline (and in the future, we also detach GPRS).
Change-Id: I47845f36864d494be474fdd447a4e9e0cbed1abd
* We want to add more interfaces to this list when we add more features
(such as waiting for ConnectionManager if we want to use GPRS).
* We want to require some ifaces only if we are planning to use those
features in osmo-gsm-tester (driven by config features attribute set to
the modem in resources.conf).
* Previous usage during shutdown was wrong, as it was waiting for any of
them to be down to continue instead of waiting for all of them to be
down.
Change-Id: I56a289360018aa56fe25b3dd328ffe9194b65f6b
Pau Espin
Holger Hans Peter Freyther
Harald Welte