There is now a "libosmogsm.map" file containing an explicit list of
to-be-exported symbols. This should prevent us from leaking non-static
symbols into the global namespace.
A similar scheme should be adopted by all other osmocom libraries
In file included from telnet_interface.c:30:0:
osmocom/core/socket.h:25:4: warning: 'struct osmo_fd' declared inside parameter list [enabled by default]
telnet_interface.c: In function 'telnet_init_dynif':
telnet_interface.c:84:4: warning: passing argument 1 of 'osmo_sock_init_ofd' from incompatible pointer type [enabled by default]
osmocom/core/socket.h:24:5: note: expected 'struct osmo_fd *' but argument is of type 'struct osmo_fd *'
No idea where I copied the original from but here we use the
other notation. (matches wikipedia and sources)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
As requested by Mike Morrin <Mike.Morrin@ipaccess.com>, we introduce
GSMTAP sub-types for all the different GPRS and EGPRS coding schemes.
This is neccessary due to the fact that the RLC PDU doesn't contain any
explicit indication of the coding scheme used on the radio layer.
Rather than manually hard-coding numbers and using byte-arrays, we use
the msgb_*_{push,put}() function family of libosmocore/libosmogsm.
This is currently untested.
This tests verifies the content of the GSM 08.08 messages, it does
not verify the remaining headroom (which the SCCP/IPA code relies
on being plenty to prepend the header). More to come in the future.
gsm_data_shared.h includes e1_input.h of libosmo-abis, add the
LIBOSMOABIS_CFLAGS to Makefile.am, remove AM_LDFLAGS at the same
time as we only build .a archives.
This code should not play with the internals of the msgb like this,
this code got introduced in af48bed556 and is breaking the
osmo-bts usecase of forwarding an RSL message.
Add a test case that fails without the new code. I would prefer if
we could get rid of the manipulating the msgb like this, it is prone
to errors like this one.
DATA REQ with a msgb_l3len(msg) == 0 message does not make any
sense, log an error and return immediately before attempting to
send an empty I frame in lapd_send_i.
If a sequence error is received, the N(R) variable must still be used to
acknowledge previously transmitted frames.
If there are two subsequent sequence errors received, ignore it. (Ignore
every second subsequent error.) This happens if our reply with the REJ is
too slow, so the remote gets a T200 timeout and sends another frame with
a sequence error. Test showed that replying with two subsequent REJ
messages could the remote L2 process to abort. Replying too slow shouldn't
happen, but may happen over serial link between BB and LAPD.
Written-by: Andreas.Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This is testing the establishment of two ends (BTS, MS) one is in
the polling mode as used by osmo-bts. Transfer data between the two
ends. The sent data is not verified though. This should be followed
up soon.
Thsi tool usses libosmocore in order to generate 2G and 3G
authentication vectors from private key material, exactly like an AuC
would produce them in a real network.
Sylvain Munaut
Harald Welte
Holger Hans Peter Freyther