The rsl_dec_chan_nr() may fail to decode RSL channel number, so
variables ch_type/chan_ss/chan_ts would remain uninitialized.
Change-Id: I9ab18bdaf41a29fcd32a7060668ef9db07b8cf7e
Related: OS#5599
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I73be012c01c0108fb6951dbff91d50eb19b40c51
It's not clear why do we get frames with unexpected length, but
we definitely should not crash. Just log and ignore them.
Change-Id: I85392becbffdb3ba7365decfd8f3769abe3c02c7
Related: OS#5171
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
As Dieter points out, this drastically improves the resiliance to high
receive levels on the C155. We cannot blindly assume a received signal
level of -85 dBm if the BTS is 2m away and we actually receive -40 dBm.
This patch extends the L1CTL_FBSB_REQ data structure in layer 1 with the
respective field, as well as the l1ctl_tx_fbsb_req() API function called
from the various layer23 apps.
"mobile" and "bcch_scan" already did a PM request and thus know the
expected signal power. "ccch_scan" and "cbch_sniff" apparently don't
do, so the -85 dBm constant is now hardcoded into the host-side source
code there, and should probably be fixed in a follow-up patch.
Since libosmocore already has LAPDm implementation, we don't need the
local copy of LAPDm code anymore.
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Decode the immediate assignment and print the messages as a
notice, ignore the Notification for voice group services and
use a magic number for SI 2quater that I could not find in my
version of the spec.
Stop using fprintf to print the System Information number of the
data we get. For the check use LOGP with LOGL_ERROR. There is
little use in this information.
Make the ccch_scan only look at the immediate assignment
but do not follow it. The old behavior was dangerous as
it could interfere with the real receiver of the channel.
Vadim Yanitskiy
Vadim Yanitskiy
Oliver Smith
Martin Hauke
Harald Welte
Steve Markgraf