Currently the size of the IMSI pointer is used instead of the size of
the talloc'ed buffer.
This commit changes the call to gsm48_mi_to_string to use the same
value that has been used with talloc_zero_size(). The length is
changed to 17 since that value is used for GSM_IMSI_LENGTH in
openbsc.
Fixes: Coverity CID 1040663
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp_bss.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gb/gprs_bssgp_bss.c b/src/gb/gprs_bssgp_bss.c
index 962bf2e..3a9012e 100644
--- a/src/gb/gprs_bssgp_bss.c
+++ b/src/gb/gprs_bssgp_bss.c
@@ -34,6 +34,8 @@
#include "common_vty.h"
+#define GSM_IMSI_LENGTH 17
+
uint8_t *bssgp_msgb_tlli_put(struct msgb *msg, uint32_t tlli)
{
uint32_t _tlli = htonl(tlli);
@@ -498,8 +500,8 @@ int bssgp_rx_paging(struct bssgp_paging_info *pinfo,
if (!TLVP_PRESENT(&tp, BSSGP_IE_IMSI))
goto err_mand_ie;
if (!pinfo->imsi)
- pinfo->imsi = talloc_zero_size(pinfo, 16);
- gsm48_mi_to_string(pinfo->imsi, sizeof(pinfo->imsi),
+ pinfo->imsi = talloc_zero_size(pinfo, GSM_IMSI_LENGTH);
+ gsm48_mi_to_string(pinfo->imsi, GSM_IMSI_LENGTH,
TLVP_VAL(&tp, BSSGP_IE_IMSI),
TLVP_LEN(&tp, BSSGP_IE_IMSI));
--
1.9.1
Here are a bunch of buildsystem tweaks for openbsc. I'm not sure
whether it is warranted to group them as a patch series, as they are
(should be) independent of each other.
The code to do that doesn't belong to the control interface, so abstract it
out
to a separate function gsm_bts_set_system_infos().
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Changes:
* Apply change even if the supplied value is odd, just warn that it is
rounded.
Previously the value was not set at all, which may have lead to a
situation when
a user thinks the BTS operating at low power, while it is running full
power.
* Apply change even if the supplied value is higher than the 24dB maximum
suggested by the standard, just warn about this.
UmSITE and probably other SDR based BTS support much wider power
regulation range.
* Apply change to the BTS over OML immediately.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
The msgb will always have these bytes but it is better practice
to verify that the message really has space for the two bytes.
---
openbsc/src/osmo-bsc_nat/bsc_nat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c
index 4357485..537001e 100644
--- a/openbsc/src/osmo-bsc_nat/bsc_nat.c
+++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c
@@ -1185,7 +1185,7 @@ exit:
send_reset_ack(bsc);
} else if (parsed->ipa_proto == IPAC_PROTO_IPACCESS) {
/* do we know who is handling this? */
- if (msg->l2h[0] == IPAC_MSGT_ID_RESP) {
+ if (msg->l2h[0] == IPAC_MSGT_ID_RESP && msgb_l2len(msg) > 2) {
struct tlv_parsed tvp;
int ret;
ret = ipa_ccm_idtag_parse(&tvp,
--
2.3.5
Hi,
sorry for the delay from OsmoDevCon to now. Attached is what I proposed in a customer
project a long time ago. The idea was to register for traps, version them with vX in the
variable name and then send traps as JSON document.
holger
Dear list,
I recently integrated nanoBTS under OpenBSC. They work fine, but I encountered the following limitations.
1. Dynamic PDCH/TCH switching is allowed to be configured, but not working. The timeslots are stuck in TCH/F mode and never converted to PDCH. Is there any trick I need to do other than setting the channel type to TCH/F_PDCH?
2. No matter what I do, the BTS only schedules one uplink timeslot. If I understand it correctly, the PCU implementation in this case is inside the NanoBTS. Is there a way to change for example an NVRAM parameter to allow a more balanced UL/DL timeslot ratio?
3. Multi-TRX setup: it is quite a limitation that you cannot use any timeslots as PDCH in a multi-TRX setup on the secondary or third carriers at all. I don't think there is any solution to that, but it worth noting.
I hope someone can point me in the right direction with dyn PDCH switching and the single UL TS issue.
Thanks!
Regards,
Csaba