Hi list,
I tend to use vim's :make command so that it takes me to the positions of
warnings and errors automatically. However, when hacking on osmo-iuh, I
sometimes get dozens of these irritating warning chunks:
[[[
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: ‘struct Member’ declared inside parameter list
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
^
/usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: its scope is only this definition or declaration, which is probably not what you want
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
^
/usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^
]]]
The cause are numerous instances of code like:
[[[
/* CriticalityDiagnostics-IE-List */
typedef struct CriticalityDiagnostics_IE_List {
A_SEQUENCE_OF(struct Member {
Criticality_t iECriticality;
ProtocolIE_ID_t iE_ID;
TypeOfError_t typeOfError;
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
/*
* This type is extensible,
* possible extensions are below.
*/
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} ) list;
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} CriticalityDiagnostics_IE_List_t;
]]]
"...which is probably not what you want".
Turns out it kinda is what I want, I just don't want these warnings :P
Filtering proper error messages from this mess is hard.
Any idea to get rid of these warnings would speed up my dev cycle
dramatically...
Short of refactoring the way these A_SEQUENCE_OF() get generated.
I guess the struct should rather be first declared with a unique name and
then only the type name should be used in A_SEQUENCE_OF(). i.e. not like
osmo-iuh/include/osmocom/rua/RUA_CriticalityDiagnostics-IE-List.h:
A_SEQUENCE_OF(struct Member {...
but like:
osmo-iuh/include/osmocom/rua/RUA_Disconnect.h:
A_SEQUENCE_OF(RUA_IE_t) list;
Doesn't seem to come from the asn1tostruct.py...
Thanks!!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi all,
I think we are close to the point of no return. All tickets and wikis have been imported. Please have a quick look if there is something obviously broken and if not I will proceed with post-processing and renaming tonight.
kind regards
holger
Hi,
When running lintian on openbsc, I get the following error:
E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl
E: osmocom-nitb: possible-gpl-code-linked-with-openssl
It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot
find any statement of OpenSSL exception for the AGPL. Debian policy requires
this.
Can you look into this? You can have a look at wget if you need an example.
Ruben
The openbsc branches to use for testing IuPS and IuCS have changed,
because Daniel and I have merged the branches.
They used to be daniel/gprs-iu (IIRC) and sysmocom/cscn.
Both are now merged as:
sysmocom/iu
Holger, this is relevant to our coverity configuration.
We are still using other branches that may or may not be merged to their
respective masters. I'd like to publicly record here why or why not we
should merge them now. Please add any reasons you know.
We're using master for Iu[h|CS|PS] in:
libasn1c: * master
libosmo-abis: * master
libosmocore: * master
openggsn: * master
osmo-python-tests: * master
osmo-iuh: * master
Reasons NOT to merge to master in:
openbsc: * sysmocom/iu
- hardcoded kc and sres for testing
- NITB and most probably osmo-bsc are not operational
- A-interface not implemented in CSCN
asn1c: * aper-prefix
- ?
libosmo-netif: * sysmocom/sctp
- ?
libosmo-sccp: * laforge/wip
- ?
Thanks for any additions...
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi,
First of all I would like to thank you guys for working on an awesome project
and contributing so much nice code!
I've been working on getting the Osmocom libraries into Debian. libosmocore has
been there for some time now, but I recently also got libosmo-sccp,
libosmo-abis, libosmo-netif, libsmpp34 (not directly osmocom) and openggsn in.
This means that all dependencies for building openbsc, osmo-bts and osmo-pcu
should be available in Debian. I would also like to thank you for keeping a
quite well-maintained debian directory in the tar-balls, even with good state
of SONAME-ing etc. I've used this as the starting point where possible, but
also modified them to meet "Debian standard".
It would be great if you could test the packages and also verify that the
copyright files contain all the copyright holders. Let me know on this list or
on private email if there is something missing or wrong.
Here are links to all copyright files:
https://tracker.debian.org/media/packages/libo/libosmo-abis/copyright-0.3.2…https://tracker.debian.org/media/packages/libo/libosmo-netif/copyright-0.0.…https://tracker.debian.org/media/packages/libo/libosmo-sccp/copyright-0.7.0…https://tracker.debian.org/media/packages/libo/libosmocore/copyright-0.9.0-4https://tracker.debian.org/media/packages/libs/libsmpp34/copyright-1.10-1https://tracker.debian.org/media/packages/o/openggsn/copyright-0.92-1
You will have to run Debian sid (unstable) to directly install the packages
using "apt install", but you could also download the .deb-files manually from:
https://packages.debian.org/unstable/[packagename] or for Ubuntu here:
https://launchpad.net/ubuntu/xenial/+source/[packagename]
I'm also aware of that the code is moving ahead rapidly and what is in Debian
unstable now may quickly get out-of-date. But I will try to keep them up-to-
date as much as possible, and also provide backport packages. Getting the
packages in the first time is usually much more cumbersome than keeping them
up-to-date.
For those interested in Ubuntu, the current versions will most likely get
into the next long-term support release (16.04), since its freeze date
for package imports from Debian is already Feb 18th. So let me know quickly
if there is something wrong so that I possibly may be able to fix it before the
freeze (when it's much more straight forward).
Cheers,
Keep up the good work.
Ruben
From: Max <msuraev(a)sysmocom.de>
Previously the presence of header and data blocks were communicated
in-band which decreases code readability and makes it unnecessary hard
to add support for new hardware.
Note: both OsmoBTS and OsmoPCU have to be modified to take advantage of
extended ph_data_param structure.
---
include/osmocom/gsm/l1sap.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h
index 9f3fe98..1af8ba8 100644
--- a/include/osmocom/gsm/l1sap.h
+++ b/include/osmocom/gsm/l1sap.h
@@ -25,6 +25,16 @@ enum osmo_mph_info_type {
PRIM_INFO_DEACT_CIPH, /*!< \brief Deactivation of ciphering */
};
+/*! \brief PH-DATA presence information */
+enum osmo_ph_pres_info_type {
+ PRES_INFO_INVALID = 0, /*!< \brief Data is invalid */
+ PRES_INFO_HEADER = 1, /*!< \brief Only header is present and valid */
+ PRES_INFO_FIRST = 3, /*!< \brief First half of data + header are valid (2nd half may be present but invalid) */
+ PRES_INFO_SECOND = 5, /*!< \brief Second half of data + header are valid (1st halfmay be present but invalid) */
+ PRES_INFO_BOTH = 7, /*!< \brief Both parts + header are present and valid */
+ PRES_INFO_UNKNOWN
+};
+
/*! \brief for PH-RANDOM_ACCESS.req */
struct ph_rach_req_param {
uint8_t ra; /*!< \brief Random Access */
@@ -48,6 +58,7 @@ struct ph_data_param {
uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */
uint32_t fn; /*!< \brief GSM Frame Number */
int8_t rssi; /*!< \brief RSSI of receivedindication */
+ enum osmo_ph_pres_info_type pdch_presence_info; /*!< \brief Info regarding presence/validity of header and data parts */
};
/*! \brief for TCH.{req,ind} | TCH-RTS.ind */
--
2.7.1
Hi list,
during testing of OsmoCSCN, I find that osmo-hnbgw connects to the CN
servers once, but when such a CN component restarts, no new connection is
established. Sequence:
- start hnbgw, which continuously tries to connect to CS and PS CN servers
every five seconds (osmo-cscn and dummy-cn in my case).
- start dummy-cn, hnbgw connects.
- start osmo-cscn, hnbgw connects.
- osmo-cscn segfaults ;)
- hnbgw logs the disconnect
- I restart osmo-cscn
- but hnbgw never attempts to reconnect to osmo-cscn.
- so I have to restart hnbgw, hnb-test and its VTY connection "all the
time", which is cumbersome.
I briefly tried to resolve the issue, but I'm losing patience. I tried to
enable the DLINP debug logging but found that hnbgw's VTY doesn't allow me
to manipulate logging levels, apparently.
Next I'd have liked to set the hnbgw_log_info to indicate
[DLINP] = { .loglevel = LOGL_DEBUG }
but DLINP is negative. Does this really have to be as fiendish?
I guess the INT2IDX() macro doesn't apply here, as it would cause index
overlaps with the other D* constants. It can be really hard to find my way
around the Osmo source code, with the little non-obvious things
accumulating...
I did find that much: the reconnect flag passed to
osmo_stream_cli_open2()
is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a
first connection is established. Now, if upon disconnect, something were
to set the state back to
cli->state = STREAM_CLI_STATE_CONNECTING
my guess is that the cli_timer_cb() would indeed attempt to reconnect as I
intend.
BTW, what does cli stand for? Not command-line interface, is it.
If I stayed onto this I'd probably solve the issue. My focus should be on
an IuCS Location Update though, so comments or help is appreciated :)
So long I'll carry on with the workaround, restarting hnbgw "all the time".
Thanks!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
I noticed that osmo-iuh/src/regen-common-includes.sh doesn't do anything
useful (anymore). Should it be redirected towards osmo-iuh/include or can
we drop it?
osmo-iuh/src/regen-common-includes.sh:
[[[
#!/bin/sh
#for f in `(cd ../asn1/hnbap/asn1c && ls --color=none -1 *.h)`; do echo "#include \"$f\""; done
for f in ranap/*.h; do echo "#include \"$f\""; done
]]]
Thanks
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
