The main changes are:
- return pointer to the allocated l1ctl_link or NULL,
- accept the talloc context as 'tall_ctx' argument.
Change-Id: I7fe1bc306494ac692c182dcfd2a2d9412929194b
The main changes are:
- return pointer to the allocated trx_instance or NULL,
- extend debug message with TRX address and base port,
- accept the talloc context as 'tall_ctx' argument,
- rename goto label 'error' to 'udp_error',
- rename argument 'port' to 'base_port'.
Change-Id: I39b24afee2f09d6a6c500cfc26ac45f206589c5c
Since Ibff31fb3a958a714c828d0dea7e87d47f778fd80, fake_trx.py does
support multiple transceivers. Let's update its description.
Change-Id: I6e4351693da3a1f7e3eadd8e11971c34044dde20
Since fake_trx.py can handle multiple transceivers, it may be useful
to name transceivers. If transceiver has some name, it will appear
in logging messages, for example:
[INFO] transceiver.py:104 Init transceiver 'BTS@127.0.0.1:5700'
[INFO] transceiver.py:104 Init transceiver 'MS@127.0.0.1:6700'
[INFO] transceiver.py:104 Init transceiver '127.0.0.1:5700/1'
This change additionally assigns names to the both default
transceivers, and extends the '--trx' option with ability
to specify some name, for example:
--trx foo@127.0.0.1:5700 or --trx bar@127.0.0.1:5700/1
--trx ipv6@[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6700
Change-Id: I2f58f02e7819bb008b8aab1a8bf9e0adeb2e44ec
One can confuse TRX control interface with libosmoctrl's one.
TRX toolkit is not using libosmoctrl, and will never do. But,
in order to avoid this confusion, and potential confusion of
DATA interface, let's call them 'TRXC' and 'TRXD' in logging.
Change-Id: I67b1e850094cf8e279777c45c7544886be42a009
Since fake_trx.py can handle multiple transceivers, it makes sense
to print some info in logging messages about transceivers they
belong to. This acvieved by defining __str__() for Transceiver.
Some examples:
[DEBUG] ctrl_if_trx.py:83 (127.0.0.1:5700) Recv POWEROFF cmd
[INFO] ctrl_if_trx.py:85 (127.0.0.1:5700) Stopping transceiver...
[DEBUG] ctrl_if_trx.py:95 (127.0.0.1:5700/1) Recv RXTUNE cmd
[DEBUG] ctrl_if_trx.py:102 (127.0.0.1:5700/1) Recv TXTUNE cmd
[DEBUG] ctrl_if_trx.py:155 (127.0.0.1:5700/1) Ignore CMD SETTSC
[DEBUG] ctrl_if_trx.py:155 (127.0.0.1:5700/1) Ignore CMD SETPOWER
Change-Id: I1f706790a2da226f1418f89d2cfbb55baa6ea624
There should be no code in run() that does initialization,
__init__() is the best place for this. This change allows
to import the Application class from fake_trx.py, and
run it from script (e.g. for testing).
Change-Id: I84969630348a189d237cc98354e568421839a37b
The (BT)SAP (Bluetooth SIM Access Profile) is a part of Bluetooth
specifications, that defines the protocol and procedures that
shall be used to access a smart card (usually GSM SIM) via
a Bluetooth link.
The profile defines two roles:
- Server - the side that has direct access to a smart card.
It acts as a SIM card reader, which assists the Client
in accessing and controlling the smart card.
- Client - the side that accesses and controls the smart card
inside the Server through the connection with Server.
Typical examples of a Server are a simple SIM card holder or
a portable phone in the car environment. A typical example of
a Client is a car phone, which uses a subscription module in
the Server for a connection to the cellular network.
OsmocomBB implements the Client role providing abstract SAP
interface API to the higher layers. Instead of Bluetooth,
a UNIX socket is used to communicate with a Server.
The previous implementation of (BT)SAP interface was incomplete
and hard to maintain. This change (re)implements it almost from
scratch on top of the Osmocom FSM framework.
Besides that, the most significant changes are:
- The implementation is separated into three parts:
- sap_interface.{c|h} - public SAP interface API,
- sap_proto.{c|h} - SAP protocol definition,
- sap_fsm.{c|h} - SAP FSM implementation.
- Both 'sap_message' and 'sap_param' structures follow the
SAP message format definition according to 5.1 and 5.2.
- The message parsing is done more carefully in order to
prevent buffer overflow and NULL-pointer dereference.
- Introduced public API for getting / adding message
parameters, and checking the ResultCode.
- Introduced public API for opening / closing a connection
with the server, powering on / off and resetting the SIM
card, sending ATR and APDU.
- Introduced a call-back for handling the response message.
- Card reader state is also a part of the public API.
The new implementation was tested against softsim [1]. The
only limitation is Server-initiated Release, that allows the
Server to 'ask' a Client to release connection as soon as
communication with the smart card is finished. This is not
implemented (yet), and leads to immediate release.
[1] https://git.osmocom.org/softsim/
Change-Id: I77bb108615bb2c94c441568f195b04e0a5421643
It seems in Ice44e2b22566b3652ef6d43896055963b13ab185 I forgot
to do this, so all measurements triggered by MEASURE command
were incorrect (always noise). Let's fix this!
Change-Id: I155f118b2d3e3b23eb148fe7e2630790f8fcd18c
Since Ice44e2b22566b3652ef6d43896055963b13ab185 is merged, the class
hierarchy has become much more flexible, so it's possible to create
multiple Transceiver / FakeTRX instances and distribute bursts using
a single instance of BurstForwarder.
This change introduces a new command line option, that can be used
to specify additional transceivers. Please note that fake_trx.py
still initializes a pair of BTS and BB transceivers by default.
The new option has the following format:
--trx REMOTE_ADDR:BASE_PORT[/TRX_NUM]
Some examples for IPv4 and IPv6:
--trx 127.0.0.1:5703
--trx [2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6703
If optional TRX_NUM > 0 is specified, e.g.:
--trx 127.0.0.1:5700/1
then this transceiver is considered as a child of another one.
See I7e97b7f32dde7ab74779133e9d7504f1d0fce60c for details.
Change-Id: Ibff31fb3a958a714c828d0dea7e87d47f778fd80
A BTS can (optionally) have more than one transceiver. In this case
additional (let's say child) transceivers basically share the same
clock source of the first transceiver, and being powered on / off
as soon as the first transceiver is powered on / off.
Change-Id: I7e97b7f32dde7ab74779133e9d7504f1d0fce60c
It was discovered that using an empty list as default argument
value does result into the cross-reference, i.e. all instances
of BurstForwarder would reference the same trx_list object.
This is not an expected behaviour, let's fix this.
Change-Id: Id71185de05b0ebc5adb105b10fad2cbde5f800b1
Passing NULL to sap_msg_free() is not only meaningless, but also
would result in NULL pointer dereference. We should call it in
successful case only, so let's fix this.
Change-Id: Icf868c4299e292a17c4b7aad1f9e728ea3653494
Due to a mistake, average RSSI value of received bursts was not
converted to GSM RX level (range 0..63), so trxcon has been
sending incorrect values to the higher layers.
Let's fix this, and also prevent possible division by zero.
Change-Id: Id4659de899411ec1ba1718fdcb40aec562dbfd65
There are several SIM card interfaces, two of which:
- GSM_SIM_TYPE_L1PHY (using built-in SIM reader of the L1 PHY),
- GSM_SIM_TYPE_SAP (using remote reader via (BT)SAP protocol),
can actually deal with a physical SIM card. But, for some reason,
only GSM_SIM_TYPE_L1PHY was considered as such. Let's also get
along with GSM_SIM_TYPE_SAP for the following procedures:
- PIN management and verification,
- FPLMN / LOCI updating,
- A3 authentication.
Change-Id: I4b3080fa7a5332467a449a314ba3cc3a07a9b7df
Since we have two ways to interact with a physical SIM:
- using built-in SIM reader of the L1 PHY (via L1CTL),
- using remote reader via (BT)SAP protocol,
name 'GSM_SIM_TYPE_READER' looks quite confusing. Let's rename it
in order to explicitly indicate the role of L1 PHY.
Change-Id: I0f83f365ed50cfd658fdd3a9d6866ed76c8c4009
Almost all layer23 applications, excluding mobile, have nothing
to do with SAP interface. Moreover, the current implementation
does initialize SAP connection automatically, as soon as the
first message is sent.
Change-Id: I62cc69c06fa15468a55bb0a9d408267d0745174c
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
In I6b9a8b611ea1e9badc4d9ddf13aa9e237028e39a an optional legacy
message coding mode was introduced. Let's add the corresponding
argument to send_msg() and pass it to gen_msg().
Change-Id: I6b9a8b611ea1e9badc4d9ddf13aa9e237028e39a
Some transceivers (e.g. OsmoTRX) have inherited a rudiment from
OpenBTS - two dummy bytes at the end of TRX2L1 messages. Despite
they are absolutely useless, some L1 implementations, such as
trxcon and OpenBTS, still do expect them when checking
the message length.
Let's add an optional (disabled by default) argument to gen_msg(),
that would enable adding those two dummy bytes.
Change-Id: I0cf1314c399411886420176704cadd6e6d84787f
The built-in struct module is already used for toa256 decoding,
so let's use it for toa256 encoding, and TDMA frame number
coding too - no need to (re)implement the wheel!
Change-Id: I10d2e15ac57a0524e9bc1c80ed6a0f6f5a263436
A timeslot can be reconfigured at runtime, this is normal.
We should neither complain nor reject such commands.
Change-Id: I0a69ebceed5aa724093e6d1b23faad8c16705055
False is not iterable, so we should properly handle the case
when parsing of the whole DATA dump was failed (e.g. due to
incorrect offset specified).
Change-Id: I5443efb39bb9d3377290ce7ec5e34016cae0edb2
Found using Flake8, F841 "local variable 'pf_group' is assigned
to but never used". The filtering related options should be
defined in 'pf_group' group, not in 'cnt_group'.
Change-Id: I15d17c134cbbbd54d761113a56c1f83910ab6407
Found using Flake8:
- data_if.py:57:4: F405 'log' may be undefined, or defined
from star imports: data_msg
- clck_gen.py:29:1: F401 'time' imported but unused
- clck_gen.py:30:1: F401 'sys' imported but unused
- trx_sniff.py:28:1: F401 'signal' imported but unused
Change-Id: Id0c42319b445db218b77fd5e99a9a0a89724281d
This change extends DATAInterface class with new methods:
- recv_raw_data() - read raw data from socket;
- recv_l12trx_msg() - read raw data and parse as L12TRX;
- recv_trx2l1_msg() - read raw data and parse as TRX2L1;
which would simplify the further usage of this class.
Change-Id: I761c4e63864622d3882b8f9c80ea43b58f092cb1
It makes much more sense to read data from socket in handle_rx(),
instead of expecting a buffer with received data from caller.
Change-Id: I83479c60c54e36a2a7582714a6043090585957ae
There is no need to (re)define the arguments of UDPLink's constructor.
Let's use non-keyworded variable length argument list (*args).
Change-Id: Ia312a5e15ce88d5f7e8d76c4ea8c93c59d91be5a
Since I8fd2a2ab7784b38bde5ebcfd0359b7e2cb53f5a7, SETTA command
handling was broken, because the range limitation was removed
together with argument parsing. Let's fix this.
Change-Id: If582af3849359866de129504cc5b2dc6d64edbd5
Since we have introduced ApplicationBase class, that are used
by all existing applications, let's merge the copyright
printing helper into it.
Change-Id: I8b70ec2dd08cb2ffed733d2c4e1215b094f8d3d5
Before this change, it was impossible to configure logging
parameters from command line, such as log level and format.
This change introduces the following optional arguments:
--log-level - logging level for stderr (by default, DEBUG);
--log-format - logging message format for stderr;
--log-file-name - enable logging to a given file;
--log-file-level - logging level for file (by default, DEBUG);
--log-file-format - logging message format for file;
which are defined in a new class called ApplicationBase, so
all existing applications should inherit them now.
Change-Id: Ic3b0440cd73946ad444bd7e48feb7a92d45f6488
Both '--bind-addr' and '--burst-type' had the same short '-b'.
Let's use the upper case version for '--burst-type'.
Change-Id: Ib8a46e25cbc6266c3e147582f9e8045362270151
There are multiple advantages of using Python's logging module:
- advanced message formatting (file name, line number, etc.),
- multiple logging targets (e.g. stderr, file, socket),
- logging levels (e.g. DEBUG, INFO, ERROR),
- the pythonic way ;)
so, let's replace multiple print() calls by logging calls,
add use the following logging message format by default:
[%(levelname)s] %(filename)s:%(lineno)d %(message)s
Examples:
[INFO] ctrl_if_bts.py:57 Starting transceiver...
[DEBUG] clck_gen.py:87 IND CLOCK 26826
[DEBUG] ctrl_if_bts.py:71 Recv POWEROFF cmd
[INFO] ctrl_if_bts.py:73 Stopping transceiver...
[INFO] fake_trx.py:127 Shutting down...
Please note that there is no way to filter messages by logging
level yet. This is to be introduced soon, together with argparse.
Change-Id: I7fcafabafe8323b58990997a47afdd48b6d1f357
The randomization of both UL/DL RSSI and ToA values is optional,
and can be configured from the control interface (see both
FAKE_RSSI and FAKE_TOA commands).
The command line options for enabling / disabling the randomization
were redundant, so let's get rid of them and check if the
corresponding treshold value is set.
Change-Id: I6adc13b8989ade2fab895673525c0ca17bf9b3f2
For some reason, the time-slot pass-filtering was only done for
DL bursts, but not for UL bursts. BurstForwarder shall not pass
UL bursts for unconfigured time-slots too.
Let's also print a warning if an UL burst is sent on a not
configured time-slot, i.e. before sending SETSLOT command.
Change-Id: Idb7f5b212e5814aeff8ca8bc875ad066674267cd
Previously it was only possible to configure a single time-slot
that would be pass-filtered by a BurstForwarder instance. In some
applications it would be useful to configure multiple time-slots,
so let's refactor the time-slot pass-filtering algorithm.
Change-Id: Ie1490adaf7a7c62c966aeb60c1898eaf3b5a1e84
Instead of having all configuration variables of BurstForwarder
initialized in the class heading, let's introduce two functions
for initialization (resetting to defaults) of both UL/DL params.
This would allow to reset a BurstForwarder instance from the
control interface in follow-up patches.
Let's also introduce some basic documentation for the class
fields, which were defined in the heading previously.
Change-Id: I6b1bf41cf22f01a7e7ecc91c625fb0d2bf4bfeac
The idea of SETFH command is to instruct transceiver to enable
frequency hopping mode using the following parameters:
CMD SETFH <HSN> <MAIO> <CH1> <CH2> [... <CHN>]
Note: since the length of a CTRL command is limited to 128
symbols (BTW: why?), the amount of channels is also limited.
Change-Id: Id3d44e6a2796f1ce8523a49dedd5d484052a5c7f
This change revives the main idea of:
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
to stop ignoring the VTY bind address from the config file.
Furthermore, it deprecates (and disables) both 'u' and 'v'
command line options, because they are redundant.
Change-Id: I99e0ec1717edd29b3be231be86616cc7effe5d95
The process should be aborted if a non-existing command line
option or an incorrect parameter value is passed.
Change-Id: Ib656ad12f12429ed15dc2a1554901ffa51148ff6
The VTY requisites are always being printed by libosmovty,
there is no need to duplicate this information.
Change-Id: I688f66175ea67d4c6a46819bee7d300ad9ce7cc7
This reverts commit c8de8cb1e1
(Change-Id I32517567847fd5c54b1742f18bf409ff81e316fa by Max),
because several problems were introduced, in particular:
a) Help message of mobile application is broken:
"The VTY IP to telnet to. (default (null))",
"The VTY port number to telnet to. (default 127.0.0.1)".
b) Default VTY bind addres != parsed from the config file.
c) The (vty_ip == NULL) is resolved only when an external
MNCC handler is used, otherwise NULL is passed to
l23_app_init().
Change-Id: Ic63a4eb828ff32d3744886b4f5f6f5019c798620
Previously the vty bind config parameter was always ignored. Fix this by using proper
default value from the config unless it's explicitly set via command-line parameter.
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
Log via LOGP() like the rest of the file instead of fprintf() for
consistency. While at it, also print error cause.
Change-Id: Id205bcd9bdb7c3e4b96493d50be8381a6fa80ac6
Fixes following ASan warning:
git/osmocom-bb/src/host/layer23/src/misc/../common/main.c:146:2: runtime error: null pointer passed as argument 2, which is declared to never be null
The warning however is harmless since in that case, app_len = 0 and thus
size to copy is 0.
Change-Id: I009a5b53f1e5be72ce347d64d3a7cb1d95d37ea3
Unlike the DATA messages, traffic frames may have different length.
Instead of having fixed payload (i.e. TCH frame) length, let's
introduce a flexible array member. This would allow one to
calculate the frame length using the MSGB API.
Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
L1CTL implementation (i.e. l1ctl.c) is not a good place for the
SIM specific stuff. Let's move it to the proper place (i.e. sim.c).
As a bonus, this change fixes a possible problem of loosing the
cached APDUs if two or more L2&3 applications are using a single
LAPDm connection. The APDU buffer is dedicated per MS now.
Change-Id: I564c610e45aa3b630ca5d1ec6bc1cace0dc9c566
Previously the wildcard address (i.e. '0.0.0.0') was hard-coded
as the bind address of TRX interface. Let's make it configurable
by introducing a command line option.
Note that the '--trx-ip' option was deprecated by '--trx-remote',
because it isn't clean whether it is remore or local address. It
still can be used, but was removed from help message.
Change-Id: Ic2f43632cc57bb6f722eba05219e438f97fecb95
Since FakeTRX is a proxy, it basically emulates transceiver for
both osmo-bts-trx and trxcon, hence there are two separate and
independent control interfaces (usually, ports 6701 and 5701).
All simulation commands (see 'FAKE_*') are usually implemented
on both interfaces separately:
- ctrl_if_bb.py - simulation commands affecting Uplink,
- ctrl_if_bts.py - simulation commands affecting Downlink.
This change introduces the 'FAKE_RSSI' command for both CTRL
interfaces in two variations:
- absolute: CMD FAKE_RSSI <BASE> <THRESH>
- relative: CMD FAKE_RSSI <+-BASE_DELTA>
where 'THRESH' affects optional value randomization.
Change-Id: Ic01c31fb0304345dd7337c3ee1c7ee3c2d3e8460
Almost all handlers for received L1CTL messages are also affected
by the bug fixed in I7fe2e00bb45ba07c9bb7438445eededfa09c96f3. In
short, they do verify the length of 'msg->l2h' or 'msg->l3h', but
not the 'msg->l1h'. Let's fix this, and also add missing checks.
Change-Id: I866bb5d97a1cc1b6cb887877bb444b9e3dca977a
As we assign the payload following L1CTL header to 'msg->l1h',
it makes sense to avoid possible naming confusion.
Change-Id: I5d21ca8664b3445f472d3ffde90d0e11805dcb16
The actual L1CTL header is pointed by 'msg->l1h', not 'l2h'!
Since msg->l2h is NULL (because nobody set it), the result of
msgb_l2len() would always be bigger than size of L1CTL header,
as it is calculated in the following way:
return msgb->tail - (uint8_t *)msgb_l2(msgb);
So, in case if 'msg->l2h' is NULL, it turns into:
return msgb->tail - 0;
Change-Id: I7fe2e00bb45ba07c9bb7438445eededfa09c96f3
In l1ctl_recv() we actually expect to 'see' the L1CTL header
instead of the DL info header. Let's fix this.
Change-Id: Ic7d017bef04f3c186565d5dade36959df1019bd8
There is no need to keep the L1CTL header in messages being sent
towards the upper layers, but the L1 info header can be used by
L2&3 to obtain some information, e.g. TDMA frame number.
Change-Id: Id64249f1b7a1c2be578263ba62aa195c452ab7e8
This change extends sched_trx_chan_nr2pchan_config() with Osmocom
specific cbits related to CBCH, so now one can to decode
CBCH channels in dedicated mode (see L1CTL_DM_EST_REQ).
Change-Id: I9347c45638223cac34f4b48eb736e51a5055a36f
According to GSM TS 05.02, there are two ways to enable CBCH:
a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V),
b) replace sub-slot number 2 of SDCCH/8 (comb. VII).
Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0
only, and shall not use frequency hopping. This means that
implementing CBCH support on SDCCH/8 would require much more
efforts than on combined CCCH+SDCCH/4, as in last case CBCH
messages can be received without the need to switch from
idle to dedicated mode.
This change introduces a new ccch_mode item, which should be
used by the higher layers to indicate presence of CBCH channel
on C0/TS0, so the PHY would enable decoding of CBCH messages
on CCCH+SDCCH/4 (case a) in idle mode.
Regarding to CBCH on SDCCH/8 (case b), it makes sense to
extend the 'l1ctl_dm_est_req', so it would be handled in
dedicated mode on request from the higher layers.
Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel
(CBCH) is a downlink only channel, which is used to carry the
short message service cell broadcast (SMSCB). CBCH is optional,
and uses the same physical channel as SDCCH. More precisely,
CBCH replaces sub-slot number 2 of SDCCH channels when enabled.
This change introduces the CBCH enabled multi-frame layouts,
and two separate logical channel types:
- GSM_PCHAN_CCCH_SDCCH4_CBCH (lchan TRXC_SDCCH4_CBCH),
- GSM_PCHAN_SDCCH8_SACCH8C_CBCH (lchan TRXC_SDCCH8_CBCH).
Both logical channels are separately identified using
the following Osmocom specific cbits:
- TRXC_SDCCH4_CBCH - 0x18 (0b11000),
- TRXC_SDCCH8_CBCH - 0x19 (0b11001).
The reason of this separation is that we somehow need to
distinguish between CBCH on C0/TS0, and CBCH on CX/TS0.
Unlike TRXC_SDCCH8_CBCH, TRXC_SDCCH4_CBCH is enabled
automatically (TRX_CH_FLAG_AUTO), so CBCH messages
can be decoded on C0 while being in idle mode.
Change-Id: Iad9905fc3a8a012ff1ada26ff95af384816f9873
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel
(CBCH) is a downlink only channel, which is used to carry the
short message service cell broadcast (SMSCB). CBCH is optional,
and uses the same physical channel as SDCCH. More precisely,
CBCH replaces sub-slot number 2 of SDCCH channels when enabled.
This change introduces the following CBCH related tasks:
- MF_TASK_SDCCH4_CBCH (CBCH on C0/TS0 SDCCH/4),
- MF_TASK_SDCCH8_CBCH (CBCH on SDCCH/8),
which are identified using the following Osmocom specific cbits:
- MF_TASK_SDCCH4_CBCH - 0x18 (0b11000),
- MF_TASK_SDCCH8_CBCH - 0x19 (0b11001).
The only way to enable these tasks at the moment is to send
L1CTL_DM_EST_REQ message with required cbits and tn.
Change-Id: I1d7f02cba1cd8f6527360589d2d2747b6426f78b
The mframe_task2chan_nr() is used to get the channel number
(encoded according to 08.58 Chapter 9.3.1) corresponding to
a given multi-frame task type.
It makes sense to at least print some debug message in cases
when there is no matching channel number for a given task type.
Change-Id: I34587b6c67015513de35d85a7a3291f452ee7f3b
The 'ccch_mode' enum from 'l1ctl_proto.h' to be extended in the
near future in order to reflect persistence of CBCH. Thus it
should be handled in a switch statement.
Change-Id: I75e3b8deac1da296efb178e65ff6992b5c407b80
According to GSM TS 08.58, chapter 9.3.1, channel number 0x08
describes sub-slot number 0 of SDCCH/8+ACCH. This is definitely
wrong. In OsmoBTS we use an Osmocom specific extension for packet
switched channels - 0xc0, so let's use it here too.
Change-Id: I11925408d6e63baf1eac880839ecd717843fba6a
In some conditions it's required to maintain continuous burst
transmission (e.g. on C0). If there is nothing to transmit at
a given moment, either a LAPDm func=UI fill frame,
or a "dummy" Paging Request is used.
In case of 'ccch_scan' application, they are useless.
Let's detect and omit them.
Change-Id: I6ccecb1a78bdac3e467bdc14b7a01afbe17aa53c
By definition, 'ccch_scan' application is intended to be used for
monitoring of CCCH channels on C0/TS0. There is no need to send
RACH requests, therefore there is no need to care about the
mobile allocation from SI1 message.
Most likely, this "dead" code was copy-pasted from mobile
application. Let's clean it up!
Change-Id: I7c2f47cbc825a5e5a50863d842729d3d8408b9dd
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
Enforcing pointer to a 'trx_instance' structure is not flexible,
because it is used as parent talloc context only.
Change-Id: I5ab2ef5cea76f955bf72ef54541b3b75cdc2d23f
Having access to a logical channel state is required by the
follow-up change, which will introduce a separate function
for dequeuing SACCH primitives.
Change-Id: Ibde0acf8e6be224b1007be707a636eaad68c8d36
Unlike xCCH, TCH/H channels are using block diagonal interleaving,
so every single burst carries 57 bits of one traffic frame, and 57
bits of another one. Moreover, unlike TCH/F where both traffic
and FACCH/F frames are interleaved over 8 bursts, a FACCH/H is
interleaved over 6 bursts, while a traffic frame is interleaved
over 4 bursts.
This is why a TCH/H burst transmission can't be initiated on
an arbitrary TDMA frame number. It shall be aligned as of
stated in GSM 05.02, clause 7, table 1.
This change introduces two basic functions:
- sched_tchh_block_map_fn - checks if a TCH/H block transmission
can be initiated / finished on a given frame number
and a given channel type;
- sched_tchh_block_dl_first_fn - calculates TDMA frame number of
the first burst using given frame number of the last burst;
and some auxiliary wrappers to simplify the usage of
sched_tchh_block_map_fn().
Change-Id: Iaf4cb33f1b79df23f8a90c8b14ebe0cd9907fbb9
The 'normal' math operations, such as addition and substraction,
are not applicable for TDMA frame numbers because they may result
in out-of-range values.
Having TDMA frame math helpers in a single place would allow
one to avoid possible out-of-range result mistakes.
Change-Id: Ibb66ba846cc3d6c2eaa88414569e5f3751128047
GSM48_CMODE_SIGN means 'signaling only', so we shall not send
bad frame indications in this state. Instead, it makes sense
to send dummy L2 frames like we do for xCCH channels.
Change-Id: Ie39d53522cafab265099076b3194fa96aff217ba
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
So, let's drop the range limitation.
Change-Id: I8fd2a2ab7784b38bde5ebcfd0359b7e2cb53f5a7
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
This is why a signed 'int8_t' type is used in L1CTL protocol.
No need to limit the range, just forward it to TRX.
Change-Id: I06774b315b8451bf14083da6b2849d6e8594abc8
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
It was discovered that l1ctl_tx_param_req() is using an unsigned
'uint8_t' type for Timing Advance value, while other code and
L1CTL protocol is using signed 'int8_t'. This may result in
distortion of negative values, so let's fix this!
Change-Id: I6ee42b5fa2ca9ebe187f0b933465c49f840a55c2
I am not sure we need the both control commands, as every burst
on DATA interface has a header that includes TX power.
Change-Id: Id14603e71df6dedb5a843bb3e20a320192dbca3d
Let's differentiate between 'expected' unimplemented messages
like L1CTL_NEIGH_PM_REQ and truly unknonw message types.
Change-Id: Id76993056fb514e6fb0242d505205316c61bb965
A BSC may allocate a dedicated channel on any ARFCN, not necessary
on the same one where a mobile station has requested this channel.
For some reason, the ARFCN info of L1CTL_DM_EST_REQ message was
not handled by trxcon. Let's fix this.
Related: OS#3526
Change-Id: I16ed5c64236c159bfa39002b05094c1f6c171f6b
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: I57c724c78dbbbce0546ebe914e370f32c8c89703
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: Iedcec4591cf0fcbd6f956ed022169eae10a9b16e
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: I3ab69a971be555c9f9b5b7a7e5da53008a119504
In the most cases an ARFCN value is stored together with some
flags (e.g. DL/UL flag, DCS flag), so it should be taken into
account e.g. when printing. Let's use the proper naming.
Change-Id: I0b7634c80986dbff9d0da421c6a044cd36c9fd01
There is no need to check the range of timeslot number, which is
decoded from GSM 08.58 channel number (9.3.1) by applying 0x07
mask, because any result of this operation is always within
the correct range.
Change-Id: Ib84417099d303bd3ae3557f48a5c40b812c6cdfc
There is no helptext for the commandline options, which makes it
difficult for new users to use the program.
- Add commandline help
Change-Id: I8d04644342acd64432742f96e32dc9f2e0e91c20
To have bi-directional communication we can pass credentials to the
registry server and now we can register a callback when the registry
is sending data to us.
The callback needs to return if the fd should continue to be selected
as I found no way to push the userdata as parameter on the stack. Lua
code will look like:
local host, port = "www.osmocom.org", 80
local tcp = socket.tcp()
tcp:connect(host, port);
tcp:send("GET / HTTP/1.0\r\n\r\n");
local cb = function()
local s, status, partial = tcp:receive()
print(s)
if status == 'closed' then
tcp:close()
return 0
end
return 1
end
local foo = osmo.register_fd(tcp:getfd(), cb)
Change-Id: I8254bdda1df2f8fe0a5eac894b931e7de5b426df
Address sanitizer triggered when trying to chainload firmware:
==18466==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000027850 at pc 0x7f5b94cfb733 bp 0x7ffe33e1ae30 sp 0x7ffe33e1a5d8
READ of size 1014 at 0x631000027850 thread T0
#0 0x7f5b94cfb732 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
#1 0x563db4293e6e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2 0x563db4293e6e in romload_prepare_block osmocom-bb/src/host/osmocon/osmocon.c:473
#3 0x563db429541f in handle_read_romload osmocom-bb/src/host/osmocon/osmocon.c:959
#4 0x563db429541f in serial_read osmocom-bb/src/host/osmocon/osmocon.c:1168
#5 0x7f5b94722c83 in osmo_fd_disp_fds libosmocore/src/select.c:217
#6 0x7f5b94722f84 in osmo_select_main libosmocore/src/select.c:257
#7 0x563db4293b1c in main osmocom-bb/src/host/osmocon/osmocon.c:1525
#8 0x7f5b942b9b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#9 0x563db4293c79 in _start (prefix/sbin/osmocon+0x1c79)
0x631000027850 is located 0 bytes to the right of 77904-byte region [0x631000014800,0x631000027850)
allocated by thread T0 here:
#0 0x7f5b94d60b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
#1 0x563db4294d65 in read_file osmocom-bb/src/host/osmocon/osmocon.c:314
Change-Id: Ie2955e11dd1af75574536774ef7ddf88ddf1fe8b
virtphy uses UDP multicast to communicate with its osmo-bts-virtual
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.
- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set
Change-Id: Ia1014ac5e0522e77178249cdc6398dec2168bffe
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497
osmocon.c: In function ‘read_file’:
osmocon.c:317:3: warning: ‘fd’ may be used uninitialized in this function
Change-Id: If07c58d5b55c18c05345607064eace02748935f8
Use osmo_clock_gettime() to read the monotonic clock instead
of gettimeofday() which could drift backwards.
This requires switching the scheduler clock from struct timeval
to struct timespec. Expand some variables to 64 bits in order
to keep types used in calculations compatible.
The previous implementation unconditionally subtracted microsecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() for the subtraction
instead which accounts for fractions of a second correctly.
Change-Id: Ic93f90685c6d6dc28dfc4ad48c998e0eac113cf8
Related: OS#3467
This field of the logical channel state structure was not used at
all as there is nothing related to A-bis / RSL in trxcon itself.
Change-Id: Iec1abf777a74cf57deadafa95e2337cba5d02842
When relying on GSM 04.08 channel mode (GSM48_CMODE_*), one should
distinguish between Bm (full rate) and Lm (half rate) channels.
This change prevents the scheduler from generating TCH/F BFI
instead of TCH/H BFI on the corresponding channels.
Change-Id: I4547aa7f6d38637692fef8a0122e85fb52039a46
Instead of passing the information about a logical channel, it
makes sense to pass the pointer to its state where everything
is stored. This approach would allow to avoid adding more
arguments every time, e.g. in case of AMR.
Change-Id: I91fe86fef43aac68776a58c9acc37ef2a9ee8042
Initially it was assumed that FACCH prioritization should be done
in the same way for both TCH/F and TCH/H. Moreover, it was not
possible to confirm this, because TCH/H was (and still) not
implemented yet. But according to the specs:
- unlike FACCH/F, FACCH/H transmissions shall be aligned
within a multiframe, i.e. can only be initiated on
particular frame numbers (see GSM 05.02, clause 7);
- unlike FACCH/F, a FACCH/H frame steals two TCH/F frames;
so the TCH/H (including FACCH/H) primitives should be handled
separately from the TCH/F (including FACCH/F) primitives.
Change-Id: I9b59f60e1cbac8fb8fd557b6c67b5e376c0a6bbb
The previous primitive dequeuing logic (especially for TCH/F
channels) was a bit complicated, and it could not be possible
to reuse the existing code parts in the upcoming implementation
of both TCH/H and FACCH/H channels without changing anything.
In particular, this change introduces two internal functions:
- prim_dequeue_one(), which merely dequeues a primitive
of a given channel type (e.g. TRXC_SDCCH4_0);
- prim_dequeue_tch(), which dequeues either a FACCH,
or a speech TCH primitive of a given channel
type (Lm or Bm).
So the logic of the TCH/F prim dequeuing function has become
cleaner, and the upcoming TCH/H prim dequeuing function, where
FACCH/H prioritization is more complex than FACCH/F, will
reuse the introduced functions.
Change-Id: Ib82ad2480ab1bc6b1df9576eb2bf5acbd398bf66
settings.c: In function ‘gsm_random_imei’:
settings.c:188:26: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(rand + 8, "%07ld", random() % 10000000);
^
settings.c:188:2: note: ‘sprintf’ output between 8 and 9 bytes into a destination of size 8
sprintf(rand + 8, "%07ld", random() % 10000000);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Id949487111235cd4af5ff068f1dce2f4b0801480
settings.c:191:2: warning: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 15 -Wstringop-truncation]
strncpy(set->imeisv, set->imei, 15);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC subscriber.o
CC support.o
CC transaction.o
CC vty_interface.o
CC voice.o
CC mncc_sock.o
CC primitives.o
mncc_sock.c: In function ‘osmo_unixsock_listen’:
mncc_sock.c:318:2: warning: ‘strncpy’ specified bound 108 equals destination size [-Wstringop-truncation]
strncpy(local.sun_path, path, sizeof(local.sun_path));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC script_lua.o
vty_interface.c: In function ‘cfg_gps_device’:
vty_interface.c:1144:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
strncpy(g.device, argv[0], sizeof(g.device));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AR libmobile.a
Change-Id: Id52978f3bf7a8abea62237d7c32f8f87e1bb34a1
gsm322.c:366:22: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(string, "-%d", 110 - rxlev);
^
gsm322.c:366:2: note: ‘sprintf’ output between 3 and 6 bytes into a destination of size 5
sprintf(string, "-%d", 110 - rxlev);
Change-Id: I7b19fef89ba0cb0c1edbdd62c46ad8395e44145b
We use this in the network-side Osmocom projects (CNI) and it's
useful to have the same flags also for the OsmocomBB host software.
Change-Id: I45800c937d665fdbd2dd6b0cee38408f587f1a9f
This change introduces a couple of new CTRL commands for path loss
simulation, in particular a possibility to drop some amount of
bursts according to some TDMA frame period, separately for both
Uplink and Downlink directions.
Examples:
FAKE_DROP 4 - drop 4 consistent (period=1) bursts,
FAKE_DROP 16 2 - drop 16 even bursts (period=2).
Change-Id: Ib210138a03e2377c79875a4ff2f2bb58a43cfa46
Related: OS#3428
This change separates burst preprocessing (i.e. both RSSI and ToA
calculation) from BurstForwarder.transform_msg() because it's not
actually related to the message transformation process.
Change-Id: Ia7ad970593f38d9a9401975eb6dae67cd0c94e11
We used to trust (and still doing this) the messages coming from
L1CTL interface too much, and not to check the primitive length
before passing the payload to the libosmocoding API. As was
discovered and described in OS#3415, sending a L1CTL message
(either DATA_REQ, or TRAFFIC_REQ) with an incorrect length
(lower than expected) may cause heap overflow.
Let's explicitly check a primitive before encoding, and drop it
if its length doesn't match the expected value(s).
Change-Id: I258ee9f6d0124b183b1db23a73f1e523fcea89a8
Fixes: OS#3415
When starting multiple mobile in the same second, the libc random number
generator will be seeded to exactly the same value.
The random bits inside the RACH request(s) will be exactly the same
across multiple mobile and when the channel fails they all pick the same
randomized back-off timing.
Use stronger random numbers and replace all calls to random(2) with
osmo_get_rand_id. Add a fallback to try random().
[v2: Add helper to make sure the result is int and between 0 and
RAND_MAX]
Change-Id: Icdd4be88c62bba1e9d954568e48f0c12a67ac182
The Scapy itself was the actual cause of continuously growing
memory consumption. It was configured to store the captured
packets, what isn't required for this tool.
Change-Id: I0c6d9b76398e148b7febd94aa37aa2fa22d19b3f
It was decided to migrate to osmo_get_rand_id() and use random()
as a fall-back. But there is a critical difference between both
functions: osmo_get_rand_id() fills an input buffer with random
bytes (0x00 - 0xff), while *random() returns a value in range
between 0 and RAND_MAX.
osmo_get_rand_id() was used in a wrong way, so in some cases we
could get a negative value (how about IMEI starting from '-'?),
what isn't expected in many cases and could lead to unexpected
behaviour and segmentation faults...
This reverts commit 6d49b049ee.
Change-Id: I7b2a8a5c63cf64360a824926a2219fd7e419b1bb
Currently Access Burst generated by trxcon
has 8 zero bits at the beginning. According to
the 3GPP 05.02 specification (Chapter 5.2.7
Access burst) custom 8-bit extended tail bits
sequence should be used:
(BN0, BN1, BN2 ... BN7) = (0,0,1,1,1,0,1,0)
After this fix trxcon sets correct 8-bit
sequence at the front of Access burst.
Change-Id: I1f624e783de6c585d2e292965c9e5810b0a4f27d
When starting multiple mobile in the same second, the libc random number
generator will be seeded to exactly the same value.
The random bits inside the RACH request(s) will be exactly the same
across multiple mobile and when the channel fails they all pick the same
randomized back-off timing.
Use stronger random numbers and replace all calls to random(2) with
osmo_get_rand_id. Add a fallback to try random().
Change-Id: Ie0cc64663cd4b90c027b79545dc5d3ac9d87b9dd
Unfortunately current code architecture doesn't support a return path
with an error so tell the caller of L1CTL on the other side that
something's wrong.
Change-Id: Ib9b622dd5c9770c5e97fa58deee124a409544d3b
This can be useful to have bidirectional communication between the
mobile lua script an external control script.
Change-Id: Ib4a5eef611f524f5d21cb6a7f4eace22b8ba60d0
Variables are not removed as they document the commands of the
propietary romloader.
Let's mark them as unused to avoid compilation warnings.
Change-Id: If4c6814ada85956975e687eb43dcfd4ad70b8b94
It disables undesirable signals such as SIGPIPE, which exits the program
if the client connected to osmocon closes the connection and osmocon
writes to the connection fd. After SIGPIPE is disabled, write returns
-EPIPE.
This is required to keep osmocon running for BTS_Tests.ttcn TTCN3 tests.
Change-Id: Id664ca0fadd3a8b3cf4b78bb868b3d78d2354544
Some time ago a broken fix was committed which
then has been reverted again in commit
1724003737.
The purpose of this line is to clear the uplink
flag from the ARFCN. So far this worked because
both gsm_arfcn2band() and gsm_arfcn2freq10()
already do this internally.
Change-Id: Ie8a05ffc0ddec53d7fd6a25e03ea285fb216df29
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Disable storing the SMS on disk. This is useful when scripting mobile.
Keep the default of attempting to store it to disk.
Change-Id: I6353447343d98ebaa5e12ab63f995750f81c8500
It seems the original code didn't allocate \0 for the string. Just use
talloc_asprintf and get a new string...
Change-Id: I8ffb50b04d2d6196caf0231711f3467abc8c5ea5
When no cell was found during the PLMN search the camp on any cell
state will be entered. LUs are prevented in this state and it will be
left after the start_any_timer has timedout. Even if camping on the
home network the state will not be left before the expiry of the timer.
For systematic tests this is producing a too high upper bound. Make it
configurable so we can succeed with a UL more quickly.
Change-Id: I25bc985cd4360d5e37d05a7b16b39eefb75ce20f
GSMTAP support is already merged to the mainline, while the status
of SMSCB support is unknown. In any case, OsmocomBB is not a good
place for storing the patches for Wireshark, so let's remove them.
Change-Id: I448dc5a3dba3ecc6fc041861239dc23cca72b70b
The main problem here is that the existing implementatin missing the L1
header in this message. A SACCH message doesn't have a 23byte LAPDm
message, but only a 21 byte LAPDm message prefixed by a 2-byte Layer1
header. So on the receiver in the BTS, right now the first two bytes of
the UL SACCH frame are misinterpreted as L1 header.
This it what causes RLL ERROR INDICATION on the Abis side, which is why
our BTS_Tests fail.
Change-Id: Id7776bf3604d0e8a32e04547e01b8bd377903272
Related: OS#3170
In order to be able to introspect not only the root application
context, but also all other contexts, e.g. allocated within
libosmocore or other libraries, let's enable tracking the
use of NULL contexts using the corresponding talloc API.
Change-Id: Id21cd5ee340def443f7a5d0b2b8f37f41188dd87
This is useless, and prevents us from finding potential memory
leaks at exit. Let's print talloc report instead of that.
Change-Id: Ibf04942070d654e97c3ed77d69ab19e44602758c
The osmo_init_logging() doesn't allow to specify a talloc context
for libosmocore logging subsystem, so this is why the new version
was introduced. Let's use it.
Change-Id: I06c4a1f7f839f774bc428e89cfac30132bae904d
Previous hardcoded default of 0.0.0.0 was inappropiate in some
scenarios, as it sets the SRC addr of the packets sent through the
socket based on the routing.
For instance, if iface IF1 has assigned two IP addresses A and B,
A being the first addr of the interface, and osmo-bts-trx is
configured with "osmotrx ip local A" and "osmotrx ip remote B",
the following happens:
CMD POWER OFF src=A:5801 dst=B:5701
RSP POWER OFF src=A:5701 dst=A:5701 <-- A is assigned as src addr.
But osmo-bts-trx is waiting for packets from B:5701, and the packet
is dropped with ICMP Unreachable. If addr binding is forced in
fake_trx to B, then everthing's fine.
Let's extend the UDPLink in order to allow manual, but optional
setting of bind address, and add a corresponding cmdline
argument to all executables.
Change-Id: I7be18fef40967fb7551f4115f22cbbd9cdb0840d
the initial tch_mode is not always 0 (signalling) but can very well
be directly a codec mode, if the initial activation of the channel
is in speech mode as opposed to signalling
Change-Id: I96e4c89da1165e9c5287d863e0e65d811460c606
According to TS 144.006, section 5.2, the first octet containing
fill bits shall be set to the binary value "00101011" == 0x2b.
Change-Id: I8f0304bf84613a2dc07cb78aff0cb8bb4c5adf6c
Previously, TCH frames coming from L1 were reordered to the RTP
format. Moreover, the implementation had a few problems:
- L1CTL is not the best place for such manipulations;
- payloads with other than FR codec were corrupted.
Let's use RTP-ordered payloads on the L1CTL interface,
performing TCH frame reordering at the firmware.
Please note, that actual FR reordering was moved to the firmware
as is, without any codec determination. This could be fixed in
a separate change.
Change-Id: I81ec8ed3c9e72a62b22c1720c299cdc68b733cf1
Previously, the L1CTL_CRYPTO_REQ message contained only a ciphering
algorithm and actual Kc key to be used. The key length was
calculated manually using the MSGB API.
Let's avoid manual calculations here, as it may cause unexpected
behavior if the message structure is changed. Also, let's fill
the UL header with minimal information about a channel, which
is going to be encrypted.
Change-Id: I5fab079907c5276322d3ec2b46cab81f10c7ed09
This toolkit has branched out into several different tools for
TRX interface hacking, and creating a virtual Um-interface
(FakeTRX) is only one of its potential applications.
Change-Id: I56bcbc76b9c273d6b469a2bb68ddc46f3980e835
There is no need to manually put the license header as a variable
in each application in order to print it. Let's use a common one.
Change-Id: I1a6e8716a9069e7ade3ae15f2c04fd45d18e223c
We shall always send traffic frame indications, even if received
frame is incomplete or decoding was failed. This is required
for proper Measurement Reporting.
Change-Id: I99e134699796c7075299459e96b2f2d462636619
We shall always send data frame indications, even if received
frame is incomplete or decoding was failed. This is required
for proper Measurement Reporting.
Change-Id: I7beee7e797f488d04c3b59bee9501ce823717092
Since this change, each lchan handler shall manually indicate
a type of both message indications and confirmations.
Change-Id: I02e0b87d61c127d2f6f5b9532909af78332bf707
- change 'l1ctl_tx_data_ind' symbol to 'l1ctl_tx_dt_ind' in
order to indicate that it's used for both DATA and TRAFFIC;
- introduce a 'traffic' flag, which is used to define either
TRAFFIC or DATA indication type;
- pass L2 payload and its length separately from the
Downlink info header.
Change-Id: I9fe65ee9b2d772576b86b7bc85d53518530d1579
- change 'l1ctl_tx_data_conf' symbol to 'l1ctl_tx_dt_conf' in
order to indicate that it's used for both DATA and TRAFFIC;
- introduce a 'traffic' flag, which is used to define either
TRAFFIC or DATA confirmation type;
Change-Id: Iedd569086a264dc7d8740abea5c6e5ca21e299f6
Both functions are almost identical, and the only difference is
the message type they set. Let's combine them into a single
function and introduce a 'traffic' flag, which can be
used to define a message type.
Change-Id: I288f5d7b6cd242c4793973dcb3d2b1b6925d61a7
Each L1CTL message gets its own length pushed in front before
sending. This isn't specified in the 'l1ctl_proto.h', but
assumed in the code. Let's clarify this.
Change-Id: I118d00613aeaf5ff0bad1188fa5f7450d4ca8122
There are two types of L1CTL messages: received and to be
transmitted. Let's use proper names to indicate this.
Change-Id: I7c17687579282fa389bca35dc7edbc3582e55701
If at the moment of transmission there are no frames in TX buffer,
then either a dummy LAPDm frame (0x01, 0x03, 0x01, 0x2b ...) or a
silence frame (depending on a codec in use) shall be transmitted.
This is required for proper measurements on the BTS side.
Change-Id: Ie590990f2274ea476678f6b2079f90eeadab6501
This new flag is intended to indicate that continuous burst
transmission is assumed on particular logical channel. In other
words, if a logical channel has this flag, but there is nothing
to transmit in a TX buffer, then either a dummy LAPDm frame or
a silence frame shall be sent.
Change-Id: I25fcf9eeb787ffe5378d92532439e67d7d42fa65
The sched_frame_clck_cb() is responsible for UL burst transmission.
Iterating over each timeslot, it chooses a proper lchan handler
according to a current frame number and a multiframe layout in use,
takes a L2 UL frame from a TX buffer, and finally calls the chosen
handler in order to to encode and transmit a taken frame.
A handler should be called only for activated logical channels...
but for some long time, there was a bug, so each lchan was
processed, including inactive ones. It's time to fix this.
Change-Id: I33e3ecc14be3ae64dfd02789c7f0970c945582c9
The llist_for_each_entry_safe() should be used instead of the
llist_for_each_entry(), because it's safe against removal
of llist entry.
Found using Valgrind's memcheck tool.
Change-Id: I65234971ec152df038c5388da537a503060c215b
Since it is not required to specify a bind port to the UDPLink
constructor manually, let's use a random one by default, and
also allow user to set it from command line.
Change-Id: Ib4965ebeec83d9a99b2f026156eb5f5cb20875bf
This allows one to obtain a random available port from the
OS, instead of enforcing to pick a static value manually.
Change-Id: Ie8b60134239c5447d0b4373c6cca2f3a6ee3ec73
Previously, we used to check if all arguments of a command are
numeric. This was done in a wrong way, so parsing a *valid*
command with at least one negative argument could fail.
Let's remove this check, allowing the command handlers to
deal with argument types themselves.
Change-Id: If31295274a09102c414b5a7aec5dd85d88b2e514
There's no need to express ToA value as a float. Let's turn it into
an int16_t with 1/256 symbol period accuracy throughout the code to
avoid both float arithmetic as well as loosing any precision.
Inspired by Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec.
Change-Id: I99c0f38db08a530d5846c474aba352aa0b68fe86
The command line help states '-i' is for 'TRX IP address', which is
the remote IP address at which the TRX is to be found. Hoewever, it
was used as the local (bind) IP address of the socket used towards
the TRX. This is my attempt at fixing this. A more complete solution
probably allows to specify both local (bind) and remote (connect)
address, just to be clear.
Change-Id: If0252b15e9c7942687c6dc470951d777f7af651c
In theory, the maximum TA value is 63 symbols, i.e. 63*256 in this
context. However, our test cases want to test the BTS behavior is
correct if ever a larger timing offset is reported from TRX to the BTS,
to ensure it is rejected in the BTS. Let's hence increase the values
to rather large min/max limits. We could also remove them completely.
Change-Id: I691d081256e8c6d18ef2836299ed8f7d502da3ee
Now that ctrl_if.py is capable of sending back the response to where
the command originated from, we can just as well send a positive
response back after executing the related commands.
Change-Id: Icba138835149a7264f4db3a6b05f54ca501c4d54
fake_trx is using locally bound and not connected UDP sockets for
control commands.
When we receive a control command, we should not simply send the
response to the default destination, but send it back to the exact
ip+prt from which the command originated. This ensures correct routing
of responses even in case multiple programs are interfacing concurrently
with a control socket.
Change-Id: I24a0bba6eed059b101af95dac7d059f34dd715fc
If field randomization is disabled, Timing Advance value
indicated by MS would be ignored. Let's fix this by
separating the TA calculation code.
Change-Id: If43d5823fc33efc2f1649ea941ab6f619bb6f5e7
FAKE_TOA is an auxilary CTRL command, which may be used to update
the ToA (Timing of Arrival) value of forwarded bursts at runtime.
This is useful for testing the measurement processing
code in OsmoBTS.
The command is implemented for both BTS and BB CTRL interfaces
in two absolute and relative forms:
CMD FAKE_TOA <BASE> <THRESH>
CMD FAKE_TOA <+-BASE_DELTA>
The first form overwrites both ToA value and its treshold.
The second one is relative, and applies a delta
to the current ToA value.
The command affects Downlink bursts if sent on BTS CTRL
interface, and Uplink bursts if sent on the BB CTRL.
Change-Id: Ia23becec4104d47e7b22350db67b8834d6f1ad1b
By default, both RSSI and ToA fields randomization is disabled.
Let's add command line options, which allow one to enable it.
Change-Id: Ieac63cc3aadef397906479a6179ba54a53a5311a
Both RSSI and ToA fields randomization is only required in some
specific test / use cases, so let's disable it by default.
Change-Id: I94835a840b6239f2c05197292825cb26977d0216
In order to be able to simulate and randomize both RSSI and ToA
values for Uplink and Downlink separately, let's calculate them
in separate methods of the BurstForwarder.
Change-Id: Ia2031f22f2b549c799c782d0c8c8d0691fb6f18c
Timing Advance value is a timing correction value, indicated by
the network to MS, which is used to compensate UL signal delay.
In other words, the network instructs a phone to transmit bursts
N=TA symbol periods earlier than expected.
Since we are in virtual environment, let's use TA value to
calculate the ToA (Timing of Arrival) value for BTS.
Change-Id: Ie5833a9f221587bbcac10f0b223ead9c1cbda72b
This change implements ToA (Timing of Arrival) parsing, which
was missing in the DATAMSG_TRX2L1. Since we use integer math,
a ToA value is represented in units of 1/256 symbol periods.
Change-Id: Ib11482c06b977c4cf01b0644f5845a2e49d059fb
In order to avoid both float arithmetic as well as loosing any
precision, let's use integer math fot ToA (Timing of Arrival),
i.e. let's express ToA values in units of 1/256 symbol periods.
Change-Id: I56b88740f4d782ac7591fc096d1969514784a4e1
There are no message specific initialization parts, excepting
the header specific fields setting. Let's us a common constructor,
dropping custom fields from its arguments.
Change-Id: I13a3e4b2f6a1f443ebe7d809df62736e3c43f56f
There is no 'file' type in Python3 anymore, so let's reverse the
condition in DATADumpFile constructor. Also, the tag definition
was incorrect: both '\x01' and b'\x01' aren't the same.
Change-Id: Ib00c7f0bd5871fcfce931a4bfa501ae5bf797c45
In Python3 a range has it's own type, so its comparasion with
a list is incorrect. Let's explicitly convert both bit ranges
to lists in the bit conversation tests.
Change-Id: I98c40d3d63cbcdc3e5dc840ebf8d7310c5c08e56
As the DATAMSG classes were introduced, let's use them.
This approach abstracts one from dealing with raw bytes.
Also, now BurstForwarder randomizes both RSSI and ToA values,
as this feature is supported from-the-box by the DATAMSG_TRX2L1.
Change-Id: Ib15018eab749150e244914dab4b6e433ce0c9209
This change introduces two new methods, which allow to perform
L12TRX <-> TRX2L1 message type transformations.
Change-Id: Ic99cf74baa1864bf20a8fc0fc025604bc160084c
Setting this option allows one to reuse existing connections,
for example, by injecting CTRL commands or DATA bursts into
existing connections between fake_trx.py and trxcon.
Change-Id: I0882c76affa9a668a12d10967081054d2b666ed1
Previously it was required to call the UDPLink.shutdown() method
manually in order to close a socket. Let's do this automatically
using the destructor of UDPLink.
Change-Id: I59c3dc61ec58cd9effeb789947d28fd602ca91f4
In order to avoid clashes with OsmoTRX, which may be also
running on the same host, let's use a different port range
starting from 6700 by default.
This idea was introduced as a result of OS#2984.
Change-Id: I66b5f25aaba3b836448ed29839c39869b5622bed
Related: OS#2984
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Steve Markgraf