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.
The BSS-side of BSSGP requires quite a number of additional functions
for sending unidirectional messages that a SGSN never sends.
This is a first step into completing the BSSGP implementation and making
it ready to be used from osmo-bts and other BTS-side GPRS
implementations.
Note that this breaks the ABI and the low level API. But it shouldn't
break the high level API, nor the conv code definitions (because fields
default to 0, and for new fields '0' is the previous behavior)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Sylvain Munaut
Holger Hans Peter Freyther
Harald Welte
Alexander Huemer