|Age||Commit message (Collapse)||Author||Files||Lines|
Attribute trx_remote_ip is actually using IPv4 validate type, thus this
validate type is not needed.
Algorithm to use to generate response for the challenge during
authentication time is hardcoded in the sim card and cannot be easily
changed. Thus specify in the config of each modem the algorithm used by
the SIM Card. This attribute is used add subscriber_add() time, when the
IMSI, KI and algorithm to use in the MSC to authenticate a given
subscriber is stored in the database. This way we can easily set up
a specific algorithm for each SimCard/Modem, in case different SimCards
are configured with different algorithms.
This can be used to specificially test different algorithms too. For
instance, let's imagine we have 2 simcards, one configured to use comp128v1
and another one with xor, and we create a test which ckecks that XOR is
algo is working fine. We don't want to accidentally select the modem
with comp128v1 in this case. Thus we can use this attribute to create a
scenario file matching 'auth_algo: xor' to ensure always the correct
modem is picked.
We may want to support running a device which runs its own TRX
(osmo-trx or different implementation). Furthermore, this TRX may be
available in some specific hwardare rather than on the main unit.
This makes it easy to configure OsmoBtsTrx to launch it's own
osmo-trx or not. In case it is launched, all IPs are configured correctly
to ensure connection can be established.
Before this commit, osmo-trx was binding to 127.0.0.1. Now we can
support multiple osmo-trx being launched on the main unit.
With the recent fix of the junit report related issues, another issue arose:
the 'with log.Origin' was changed to disallow __enter__ing an object twice to
fix problems, now still code would fail because it tries to do 'with' on the
same object twice. The only reason is to ensure that logging is associated with
a given object. Instead of complicating even more, implement differently.
Refactor logging to simplify use: drop the 'with Origin' style completely, and
instead use the python stack to determine which objects are created by which,
and which object to associate a log statement with.
The new way: we rely on the convention that each class instance has a local
'self' referencing the object instance. If we need to find an origin as a new
object's parent, or to associate a log message with, we traverse each stack
frame, fetching the first local 'self' object that is a log.Origin class
How to use:
Simply call log.log() anywhere, and it finds an Origin object to log for, from
the stack. Alternatively call self.log() for any Origin() object to skip the
Create classes as child class of log.Origin and make sure to call
super().__init__(category, name). This constructor will magically find a parent
Origin on the stack.
When an exception happens, we first escalate the exception up through call
scopes to where ever it is handled by log.log_exn(). This then finds an Origin
object in the traceback's stack frames, no need to nest in 'with' scopes.
Hence the 'with log.Origin' now "happens implicitly", we can write pure natural
python code, no more hassles with scope ordering.
Furthermore, any frame can place additional logging information in a frame by
calling log.ctx(). This is automatically inserted in the ancestry associated
with a log statement / exception.
The "Affero" nature makes sense for the Osmocom network components like
BSC, SGSN, etc. as they are typically operated to provide a network
For testing, this doesn't make so much sense as it is difficult to
imagine people creating a business out of offering to run test cases on
an end-to-end Osmocom GSM network. So let's drop the 'Affero' here.
All code is so far developed by sysmocom staff, so as Managing Director
of sysmocom I can effect such a license change unilaterally.
code bomb implementing the bulk of the osmo-gsm-tester