Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: Ia633cae0a26f294e276b431a82256abb1b57ebba
Related: OS#5034
With new gcc 10.1.0, tests failed at runtime when built with ASAN
enabled, since some global variables where defined multiple times.
See OS#4556 for a sample Asan error.
Fixes: OS#4556
Change-Id: I12a667ea8a9f16404c13c9218b246d2e3acfe3e8
Caught by compiler:
test-ranap.c:54:30: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘RANAP_MaxBitrate_t’ {aka ‘long int’} [-Wformat=]
test-ranap.c:78:30: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘RANAP_CauseMisc_t’ {aka ‘long int’} [-Wformat=]
Change-Id: Icc4e81beaa35e13aea3adfed983016c78b730061
Catched by compiler:
hnb-test-ranap.c:76:44: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘RANAP_CN_DomainIndicator_t’ {aka ‘long int’} [-Wformat=]
Change-Id: Ie4cd6a36fd0e9a871a1815d600e8a321a3d2a208
Seveal of our RANAP messages were using criticality values at the
PDU level differing from what RANAP_PDU_Descriptions.asn states
for the respective procedures. Let's fix that.
This was discovered while working on the initial IuCS TTCN3 tests,
where the receive templates require the criticality to match.
Change-Id: I98eec0bdc0d0cb1b9284bd5d042b1f4403abef95
This ensures that the rpath of the generated binaries is set to use only
the just-compiled so-files and not any system-wide installed libraries
while avoiding the ugly shell script wrapper.
Change-Id: I92c7391631becc09d277981179c23f2e4dba3b54
Fix various mem leaks in the testing code.
Add test_common_cleanup() in test_common.c, to free talloc contexts; call in
test-{helpers,hnbap,ranap}.c. Upon talloc ctx cleanup, ensure that they are
actually empty, in order to catch newly introduced mem leaks.
If non-empty, print talloc context reports.
Change-Id: Ic66c005f2a264774e18bb54e58b87bef5944511c
This is actually default in all other osmocom projects, and it's a
big surprise that it hadn't been enabled for osmo-iuh. Now we finally
can see that there are e.g. unused static functions in the code.
Change-Id: I8d52b11e3f476ffd77f3ab185b679817cd3b2163
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I61b79f633d36814b53e40f1a92b5847c9ff4fde0
libosmo-sigtran now has a "proper" SCCP/M3UA stack, so we can make our hnb-gw
3GPP compliant by switching from the old SUA code to the new universal SCCP
user API with support for (currently) M3UA and SUA.
Main changes:
Use one cn_link to STP: We will connect to the core network using an (Osmo)STP
instance that routes to MSC and SGSN, so we want one SCCP link instead of two.
The only difference between IuCS and IuPS is a different remote osmo_sccp_addr.
This has various effects through the messaging code; the patch is a bit larger
than I would like, but it is hard to separate out truly independent smaller
changes.
CS or PS domain was previously flagged in the separate cn_link, as ctx pointer
for two separate sccp_sap_up()s. Now there's just one such ctx, so determine
is_ps from the RANAP Domain Indicator, or from the conn's hnbgw_context_map:
- Add is_ps to context_map_alloc_by_hnb().
- To find a matching context, the RUA ID alone is no longer sufficient, also
match is_ps (possible optimization todo: separate lists).
We would send separate CS or PS Reset messages based on the cn_link, instead
send both CS and PS Reset at the same time for the single cn_link. This could
be adjusted to detect presence of MSC or SGSN instead.
Pending: adjust the VTY config to reflect that there is only one remote
address. Place a TODO comment for that.
Smaller changes:
rua_to_scu(): populate called and calling addresses for N_CONNECT and
N_UNITDATA.
Remove DSUA.
Don't build dummy_cn, which is still implemented on SUA. Mark todo to maybe
re-include it based on M3UA later.
In hnbgw_cnlink, place sccp related items in a separate sub-struct.
Do not keep an llist of cn_links, just have the one. Remove iteration and list
management.
Change jenkins script to build libosmo-sccp master.
Patch-by: hwelte, nhofmeyr
Change-Id: I8ac15fa2fd25bedb26297177e416976a5389b573
The guaranteedBitrate lowers from 12200 to 6700, which is mimicking the values
found in a trace from a production 3G environment. So far we have no reason to
choose these values other than knowing that other operators seem to do this.
This came up while trying to fix voice RAB for the nano3G, but this patch had
no effect on that. Now that it's here, we might as well keep it.
Change-Id: Ia7eecca43d62a6a020466e9b8dc8b566ca988f9f
For IPv4 addresses, only 56bit of X.213 NSAP are used. The sysmocell5000
accepts such a field that is 56bits long, but the ip.access nano3G does not
(and crashes instead). Both work when zero-padded to 160bits size.
So far we used to send the IPv4 address as "raw" 32bits to the nano3G to avoid
the crash. With this zero padding we no longer need such a workaround and can
use identical config for both cells.
Change-Id: I070bbfe887ab93d08322df30571050a381d082d5
This is mimicking the IEs found in a trace from a production 3G environment. We
have no reason to add this other than knowing that other operators seem to do
this.
This came up while trying to fix voice RAB for the nano3G, but this patch had
no effect on that. Now that it's here, we might as well keep it.
Change-Id: I14c22b0befb308bac2eded662fe13a58c8478743
Properly initialize msgb talloc context in hnbgw and all tests, using the new
msgb_talloc_ctx_init().
test-ranap.c: since msgb talloc ctx is now in test_common_init(), remove msgb
talloc init here.
Change-Id: I807c799aff1239184728551ed77fdafa73bd683f
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: Icd9e670c1d30c156f7bd5d0d34892150aeba95e9
Remove an #if 0 to properly include the port information (verified to work).
Adjust test expectations.
Change-Id: I45fb134959dea9bcdfbfd9d8a061e67c3cc80fb7
This rule is bad because it re-invokes $(MAKE), but it seems to fix the
parallel build. It should probably be done differently.
Change-Id: I8107e08e4c211f20d671f520bf6bab9356f3c90e
This came up while fixing 'make distcheck'; this is certainly not the easiest
way but it makes sense to have the headers in include/, like we do in openbsc.
The easy alternative might be to add -I$(top_srcdir)/src to src/Makefile.am.
Remove -I$(top_srcdir)/src from src/tests/Makefile.am, no longer needed.
Change-Id: I5a82e029dcdc4df0a60a31271a4883393fe59234
fix extraneous rebuild for each make invocation: touch the ranap.stamp file in
src/ as the make target suggests.
fix for 'make distcheck': ranap gen: move generated sources to builddir, not
srcdir. Thus we also -I the builddir include to pick up those headers.
hnbap and rua have the same situation as ranap (they generate numerous files
from a single make rule). Use the same makefile semantics for those two
(commit for ranap gen omitted the same changes for hnbap and rua).
The generated headers are thus moved to include/osmocom/*/, so adjust #include
statements accordingly (*_common.h, *_ies_defs.h).
Also move hnbap_common.h to include/osmocom/hnbap and rua_common.h to
include/osmocom/rua, since the *_ies_defs.h want to include them; and since
*_ies_defs.h are now in include/osmocom/*, we want a '<foo>' include now.
Also adjust gitignore.
Change-Id: I32213666fcdfc144008fa7d46497c0938d093e86
In experr, we had line numbers in log output, which might change. Also, for
make distcheck, the path of the source file might have some '../../' added in
the log output (to indicate the src dir as seen from the build dir).
Fix both by dropping source file and line.
Also drop color while at it.
Change-Id: Ie76384c4176ce0a7d89d093f2efb848fe3f19400
Add use_x213_nsap arg to ranap_new_msg_rab_assign_voice() and
new_transp_info_rtp(). Pass this to new_transp_layer_addr() to compose 32bit
addresses when use_x213_nsap == false.
This is analogous to ranap_new_msg_rab_assign_data().
Particularly, the ip.access nano3G does not accept x213 NSAP 56bit addresses,
so we want to send 32bit addresses there.
Change-Id: I0c3c95d709c8a2b1c48d7a187faca34102226329
See libosmo-sccp.git 1a3875092f93df3c3054d26eac52bb0ea9bd09c3
Note: at time of commit, osmo-iuh still depends on the libosmo-sccp sysmocom/iu
branch to build.
The same rename has been committed to both sysmocom/iu and master on
libosmo-sccp. Above commit hash is on sysmocom/iu. The master commit is
03ad002c28073b347b92bcde16d5af80a06389e4.
Change-Id: Id9c0065d7398a6205ff24477d47c9663caac669c
The decoding target pointer has to be NULL so that a new structure is allocated
by aper_decode(). Fixes a probable segmentation fault upon decoding at
test-ranap.c:77 or free of unallocated memory in test-ranap.c:81.
After aper_decode(), we still need to free the decoded struct.
This was introduced in 14da5411a4
("test-ranap: Add test case about constrained integer range decode")
Note, in that commit there is another test failure in expout (a reversed byte
order) which is "secretly" fixed in bb289e3b81
("RAB parameters: add Extended Max Bitrate").
This commit fixes:
@@ -213,6 +212,7 @@
</RANAP_IE>
00 0a 00 11 00 00 01 00 29 40 0a 00 00 01 00 28 40 03 05 c2 d0
report
-talloc report on 'asn1_context' (total 0 bytes in 1 blocks)
+talloc report on 'asn1_context' (total 40 bytes in 2 blocks)
+ constr_CHOICE.c:927 contains 40 bytes in 1 blocks (ref 0) 0x187e690
talloc report on 'msgb' (total 1 bytes in 1 blocks)
exit
Adjust test expectation in test-ranap.c.
This IE is seen in a "real life" pcap of hNodeB operation. We did not need it
so far, but add it to test the ip.access nano3G.
Comment from the future: the ip.access nano3G rebooted upon RAB Assignment
Request, and after adding/tweaking some IEs it stopped rebooting. This is one
of the changes that fixed the reboot issue. The changes have been tested
incrementally until reboots vanished, but it's not clear/hasn't been tested
whether omitting this change alone will cause reboots to re-appear.
There was a bug in the asn1c/libffasn1c APER patch that caused
constrained integer ranges to be decoded incorrectly. Add a test
case for that to avoid people falling into that trap...