| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently incoming BSSGP STATUS messages are just logged and no other
action is taken. This makes it impossible for higher layers to react
to failures which are indicated by corresponding STATUS messages
unless a timeout is triggered as a result of that failure later on.
This commit adds a bssgp_rx_status() function and calls it on
incoming STATUS messages. That function logs a message, increments the
new BSSGP_CTR_STATUS counter if the bctx context exists and invokes
an NM_STATUS status indication. The latter will allow the application
to handle failures immediately. Since all STATUS messages should be
handled, the function is already called in bssgp_rcvmsg and the
message is no longer handled in (and will not reach) bssgp_rx_sign
and bssgp_rx_ptp.
Ticket: OW#1414
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently each incoming PtP BSSGP STATUS message is handled as 'not
yet implemented' and a BSSGP STATUS message (cause
BSSGP_CAUSE_PROTO_ERR_UNSPEC) is sent back to the peer. This will
cause endless messages loops if both peers use this BSSGP stack
implementation. This does not apply to signalling messages.
This commit changes the implementation of bssgp_rx_ptp() to just do
logging in this case.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when using 'logging print extended-timestamp 1', the
subsecond part (milliseconds) of the printed timestamp is always 0.
This makes it difficult to correlate log entries with PCAP file
entries if there are many of them per second.
This patch changes _output in logging.c to use gettimeofday() instead
of time() when extended timestamps are enabled and replaces the '000'
by the milliseconds computed from tv_usec.
Sponsored-by: On-Waves ehf
|
|
|
|
|
| |
This got introduced in 2d6ad13d8daf860595e6d4025861e122ce574871
and I thought that our vty tests would have caught such mistakes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
dpkg-shlibdeps: warning: symbol vector_free used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vector_set used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vector_set_index used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol tall_vty_vec_ctx used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol ipa_msg_recv_buffered used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cmd_free_strvec used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vector_lookup used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vector_lookup_ensure used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cmd_make_strvec used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vector_init used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The big LIBOSMOCORE_CFLAGS and LIBOSMOCORE_LIBS macros are not
defined when building linosmocore. Use the .la files directly
Fixes:
dpkg-shlibdeps: warning: symbol osmo_hexdump used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol gsm48_parse_ra used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol _talloc_zero used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol _talloc_memdup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol talloc_strndup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol msgb_length used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol msgb_alloc used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol msgb_free used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol talloc_strdup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol talloc_free used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These patches enhance the Supplementary Service (SS) processing from
only being able to handle USSD to other SS, specifically activation,
deactivation and interrogation of those SS. Registration is not yet
implemented.
include/osmocom/gsm/protocol/gsm_09_02.h has been added with needed
values for SS.
Modified by Harald Welte to keep the old ussd-only functiosn for API/ABI
stability.
|
| |
|
|
|
|
| |
Those hex strings can then be copy+pasted into the OSmoNITB VTY
|
|
|
|
|
|
|
|
|
|
| |
We tried to fix it but it isn't that easy. The original fix was
cd6ed82d1ff48f47ad9e33e6322df62896a76ed5 but we had to revert it
as "everything" is present/used in existing config files.
If we ever change the ABI we can make everything be something
that is > 0. For now use a wording that makes it obvious that
people should not use "everything".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the ipa_send function returns -1 in one execution branch
to indicate an error and -EIO in another. This is not consistent and
can lead to a misinterpretation of the error code, since -1 is -EPERM
and in general, EPERM is not returned by write(2).
This patch changes the return code to -errno instead of -1 for the
case that write(2) fails for same reason. So -rc is always a sensible
error value if there is a failure.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
| |
First we check if a color is defined and then we call it again
and use the result. Avoid the second call and use the result of
the previous call.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to see from which category/subsystem a certain log message
is coming from and use a different timestamp format as well. Add
two new bitfields. This doesn't change the size of the structure
and on 32bit we still have 27bits left.
The extended timestamp will take preference over the current and
default timestamp format.
Fixes: SYS#602
|
|
|
|
|
| |
We want to use libosmocore/libosmovty in the GGSN sourcecode
and reserve a global region here.
|
|
|
|
|
|
|
|
|
| |
For the BSC/NITB application we see that people modify the band
without modifying the ARFCN. This creates an unbootable config.
Using the new hook the BSC/NITB can check if the config is
consistent and prevent the config file being written.
Related: SYS#739
|
|
|
|
|
|
| |
this fixes some compilation issues with libosmocore under NuttX,
particularly as some #defines are missing or some header files are
slightly different.
|
| |
|
|
|
|
| |
.. Nuttx doesn't know u_long
|
|
|
|
| |
... u_char not being defined on Nuttx.
|
|
|
|
| |
Not all systems have strings.h
|
|
|
|
| |
This is needed on Nuttx.
|
|
|
|
|
|
|
|
|
|
| |
Currently this command segfaults (at least when ASAN is enabled),
because when getting the NSEI the index to argv is wrong and out of
bounds.
This patch fixes the offset.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
| |
PCSC_ERROR() macro is already performing error checking.
Found by coverity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pkg-config file already points into the PCSC directory. This
is needed for FreeBSD where /usr/local/include is not in the
default compiler search path.
On Debian
$ pkg-config --cflags libpcsclite
-pthread -I/usr/include/PCSC
On FreeBSD
$ pkg-config --cflags libpcsclite
-I/usr/local/include/PCSC -D_THREAD_SAFE -pthread
|
|
|
|
|
| |
according to Holger, using AGPLv3+ at the time was a mistake and the
license should always have indicated GPLv2+.
|
|
|
|
| |
... which it should have been all along.
|
|
|
|
|
|
| |
libosmocore.{so,a} should always have been GPLv2+. However, when
migrating some code from OpenBSC or OsmocomBB, we sometimes introduced
it with a wrong license header.
|
|
|
|
|
|
|
|
|
|
|
| |
The copyright holders Harald Welte, Holger Freyther, Andreas Eversberg
and sysmocom - s.f.m.c. GmbH (represented by Holger and Harald) agree
that the license of libosmogb should be GPLv2+ and not AGPLv3+.
The reason the source files stated AGPLv3+ is due to the history, as
they were moved from OpenBSC to libosmocore at the time we needed to use
them from osmo-pcu. It was an oversight back then to not re-license
them accordingly.
|
|
|
|
|
| |
before we only did it partially, and by exporting data from sim,
rather than the new osim_int_cprof_add_{gsm,telecom}() functions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
affected files: sim.h, sim/core.c
affected funtions/strucutres: osim_new_apdumsg, osim_apdu_case,osim_apdu_cmd_hdr, osim_msgb_cb
|
|
|
|
|
|
|
|
|
| |
APDU_CASE_2 becomes APDU_CASE_2S
APDU_CASE_2_EXT becmoes APDU_CASE_2E
APDU_CASE_3 becomes APDU_CASE_3S
APDU_CASE_3_EXT becmoes APDU_CASE_3E
APDU_CASE_4 becomes APDU_CASE_4S
APDU_CASE_4_EXT becmoes APDU_CASE_4E
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently sending SUSPEND/RESUME messages to this function (like it
is done in the osmo-sgsn) results in STATUS messages complaining
about an unknown BVCI. The reason is, that these messages rely on a
TLLI/RAI pair to identify the context and do not contain an explicit
BVCI.
This patch modifies bssgp_rcvmsg() to only complain about and unknown
BVCI if one is given but a matching context is not found (except for
RESET messages). The ctx argument is removed from the functions
handling SUSPEND and RESUME since it will always be NULL then.
Sponsored-by: On-Waves ehf
|
|
|
|
| |
Signed-off-by: Max <max.suraev@fairwaves.co>
|