Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I5aad87b7d4c043f890f4ae2bc5d68cbad6d2c5c7
Assume that cat-testlogs.sh from osmo-ci is installed in $HOME/osmo-ci/scripts,
and call from jenkins.sh upon 'make check' failure.
Change-Id: I6ee37ae638aa0b95222e5c0ec78474fab1f8cfae
In the course of a rebase in libosmo-sccp, osmo_sua_link_get_user_priv() was
renamed to osmo_sccp_link_get_user_priv(). Apply this rename here to fix the
build.
Change-Id: I09603f5eb983f17c1e4a1232967fc43c7ceea12a
The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip',
'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so
it makes sense to do this now.
Change-Id: Ifda2653bf58044552a5f1477cd7008dec3fb9100
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
To prepare for an upcoming commit that accepts TMSI identification upon UE
Register Requests:
Add tmsi arg to ue_context_alloc().
Add ue_context_by_tmsi().
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected.
See the upcoming commit that enables accepting TMSI identities for further
detail.
Change-Id: I138458443319cc4cbea5ee7906cf5dd72d582130
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected.
Sending a proper registration reject speeds up the response seen on the UE and
avoids needless waiting.
See the upcoming commit that enables accepting TMSI identities for further
detail.
Change-Id: I03b69613e6ddd8a08d9358ffc2f74954c231fd2c
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
This is a known autoconf bug, it creates odd directories named literally
'$(top_srcdir)', potentially messing up dependency checking.
Change-Id: Ia47b038d4ca4f6c345711fb17d074f71c80e4453
Needed to fix these errors:
tar: osmo-iuh-UNKNOWN-dirty/include/osmocom/ranap/RANAP_SourceeNodeB-ToTargeteNodeB-TransparentContainer.h: file name is too long (max 99); not dumped
tar: osmo-iuh-UNKNOWN-dirty/include/osmocom/ranap/RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.h: file name is too long (max 99); not dumped
tar: osmo-iuh-UNKNOWN-dirty/include/osmocom/ranap/RANAP_TargeteNodeB-ToSourceeNodeB-TransparentContainer.h: file name is too long (max 99); not dumped
tar: osmo-iuh-UNKNOWN-dirty/include/osmocom/ranap/RANAP_Requested-RAB-Parameter-ExtendedGuaranteedBitrateList.h: file name is too long (max 99); not dumped
Change-Id: Id41bca92810a81ac50697c0230a6caef490b0ffd
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
Instead of building the same .c files twice, rather verify that the
'make regen' target produces identical .c files as are checked in.
Change-Id: I18e7677d8596f61b883e9db57b4bdd2a5c154ec3
When receiving a UE Register Request with TMSI and no IMSI, compose a
Register Reject with the same UE Identity and send.
The accepting function expects a ue_context argument and composes the
message from the IMSI found there. This new rejection message cannot rely
on a ue_context struct and hence uses the asn1 uE_Identity directly.
Change-Id: Ia47e398e50e316842cd260dc0d9a4e2d8a1c627c
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
Add config node hnbgw/iuh/bind, taking an IPv4 address.
Use this address to bind the Iuh server.
This is particularly useful for the ip.access nano3G, which is very sensitive
with SCTP addresses that don't respond to SCTP heartbeats. If the hnbgw listens
on 0.0.0.0, there will be SCTP heartbeats for all local interfaces on the
machine that the hnbgw runs on; the nano3G will interpret the "missing", or
rather, redundant heartbeat acks for the interfaces that aren't really related
to the Iuh server and assume a broken Iuh link, leading to an Iuh shutdown and
reconnection, looping every minute or so. By binding the hnbgw to only one
local interface, the SCTP addresses can be reduced and "missing" heartbeat acks
can be avoided.
Change-Id: Ie2749c152b878e17aa65dfb806826357d5c494f1
Add include/osmocom/iuh/ named after this project (osmo-iuh), and add vty.h to
define VTY node enum values. Also add (to) Makefile.am and configure.ac to
include in the build.
An upcoming commit will add the actual first config item to the hnbgw/iuh node.
Change-Id: I71545823d3bd81cb888c85df8e298a56c98bf131
Now that a config file gets parsed after the command line options, e.g. the
'logging timestamp 0' config item is stronger than a -T commandline option. So
rather store the cmdline options to take effect after config file parsing.
This adds a stupid 'log_disable_color = true' reverse boolean logic, which is
unavoidable if we want to use the same default cmdline options as osmo-nitb /
osmo-cscn.
Change-Id: I16ad55b173a443c36b71dc6b70f58695f6665312
Default options taken from osmo-nitb:
-h --help This text.
-d option --debug=DHNBAP:DSUA:DRUA:DRANAP:DMAIN Enable debugging.
-D --daemonize Fork the process into a background daemon.
-s --disable-color
-T --timestamp Prefix every log line with a timestamp.
-V --version Print the version of OsmoHNBGW.
-e --log-level number Set a global loglevel.
Change-Id: I931cee01c605c1b507c16041ada226cf963ea433
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
Have a bash function to build each dependency with the same commands. There is
a tradeoff: having each dependency build with the same function means you can't
easily tweak one of the dependencies. OTOH having a unified function means a)
more readable script, b) that we're sure not to forget some steps and c) no
need to do the same edit n times.
Set the PKG_CONFIG_PATH globally. Also a tradeoff: if a future addition
wouldn't need the same PKG_CONFIG_PATH, this would make things ugly. But that
is actually quite unlikely, and the readability improvement is substantial.
Use env variables to remember local paths. That means we always are sure to cd
to the same absolute base path, which a 'cd ..' can't guarantee; also, we avoid
possible typos for e.g. "$deps/install".
Build sysmocom/sctp branch of libosmo-netif, as needed for libosmo-sccp's
sysmocom/iu branch.
Build aper-prefix branch of asn1c, as needed by 'regen'.
'make regen' first, to generate the .c from asn1, needed by the build.
Change-Id: Ia7b4b9788b9c951f8be00cc5ae72a9c0a776fe64
On FreeBSD, we use gmake, so calling 'make -C ...' won't work here.
We need to invoke $(MAKE) so gmake is used again.
Change-Id: If8d09889db2c101eca66675fff8f820d6d1d7a65
The formerly existing make rule caused a race condition in parallel builds and
wrongly stated the .c files as targets, which caused make to execute the
rule twice (once for each target). This was actually only fallout of the
attempt to express the fact that those two files are generated by the rule.
The generated file ranap_ies_defs.h was moved by one make job, another
job then tried to access the file in the old location and failed.
parallel build verified with:
$ for i in $(seq 1 10)
do
echo "XXXX iteration $i"
git clean -xfd
autoreconf -i
./configure
make -j${i} || break
done
Coauthored by Andreas Rottmann <mail@rotty.xx.vu>
Change-Id: I439edcb4b7742de861c99ed401114f51061f8088
Reviewed-on: https://gerrit.osmocom.org/65
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
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.
Neels Hofmeyr
Neels Hofmeyr
Alexander Huemer
Daniel Willmann