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
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Steve Markgraf