Allow logging the plane (Ctrl/User) and side (SGSN/GGSN) in functions that only
have a gtphub_bind* to work with, by adding a constant label to each bind.
Sponsored-by: On-Waves ehi
If a GGSN is already known from unmapping, don't invoke a host resolution.
In a live working environment, it wouldn't hurt, because the lookups would
mostly return from the cache. But in a testing environment without a name
server, it barfs on every packet.
Sponsored-by: On-Waves ehi
Initialize llist_heads to empty (2 were missing). Move those for struct gtphub
instances to gtphub_zero() (one moved, one added).
In from_[gs]gsns_read_cb(), use a return type that can actually reflect
negative return values.
resolved_addr.buf: no need to take the address of a byte array var
(cosmetic).
Pass the proper user data address to sgsn_ares_query(), not the address of
the pointer holding the user data address.
Initialize ggsn_lookup->expiry_entry (was missing). Publish the function for that
in gtphub.h so gtphub_ext.c can use it.
Sponsored-by: On-Waves ehi
Looking for a segfault, I added a lot of logging. This may be useful for
live testing ares, leaving it in there for now.
Note: I still want to clean up the logging concerning log levels etc. once
we're out of alpha.
Sponsored-by: On-Waves ehi
Allow a peer sending from an unknown port but a known address, and just
create the port (and unmap the seq nr back to this port later to return
the response to the sender).
Only an SGSN on the Ctrl plane is allowed to make the very first contact
from an unknown address.
Sponsored-by: On-Waves ehi
Split decoding return code GTP_RC_PDU in GTP_RC_PDU_C and GTP_RC_PDU_U.
Don't do IEs in GTP_RC_PDU_U.
Add a unit test for User plane data, expected to fail (nonstandard port case).
In gtphub_test.c, tweak logging so that it is easily visible which test
produced which output. Also add the global resolved_sgsn_addr and ggsn_sender,
symmetrically to resolved_ggsn_add and sgsn_sender.
Sponsored-by: On-Waves ehi
Generalize to make the PDP ctx message definitions and "sending" of messages
from SGSN->gtphub->GGSN and back reusable in future tests.
Publish gsn_addr_from_sockaddr() in gtphub.h for use in gtphub_test.c.
Use an osmo_sockaddr for resolved_ggsn_addr, because one is needed for
comparison in probably every future test.
Add LVL2_ASSERT() to print assertion message and return instead of abort,
so that functions can be called from several tests without losing the
info of which test caused it from which line.
Use globals for struct gtphub and time_t now, to reduce nr of args that need to
be passed around when writing tests. Add a default test setup function.
Sponsored-by: On-Waves ehi
Up to now I used the Echo as a test for sequence nr mappings. But Echos
should be handled differently: they are scoped on the link and an Echo
response should be sent right back to the requester.
Sponsored-by: On-Waves ehi
For the resolving function, change the function signature to return a
gtphub_peer_port. In consequence, publish two functions concerned with
gtphub_peer_port instances for use in test and gtphub_ext.c.
Add GGSN resolution queue, callback and cache. Simple implementation: if an
SGSN asks for a GGSN, it will first get no answer, and I hope it will ask again
once the GGSN is in the cache.
Within gtphub_ext.c, have a dummy sgsn struct, as the sgsn_ares code currently
depends on it (half the functions pass an sgsn instance pointer around, but the
other half use the global one).
In the unit tests, wrap away the ares initialization so that they can work
without a DNS server around. The netcat test breaks because of this, will
remove it.
Using sgsn_ares, implement the gtphub_resolve_ggsn_addr() function, I hope:
untested.
Minor cosmetics just to see if you're paying attention... ;)
Sponsored-by: On-Waves ehi
First steps towards a new GTP hub. The aim is to mux GTP connections, so that
multiple SGSN <--> GGSN links can pass through a single point. Background:
allow having more than one SGSN, possibly in various remote locations.
The recent addition of OAP to GSUP is related to the same background idea.
(This is a collapsed patch of various changes that do not make sense to review
in chronological order anymore, since a lot of it has thorougly transmorphed
after it was first committed.)
Sponsored-by: On-Waves ehf
Extend the ul/dl counting to count the usual messages on the
Gb interface. Add counters for the attach, routing area update,
pdp context activation and deactivation procedures. Update the
test result with the new counters.
RPM post-build-checks found some issue and marks these as error:
[ 38s] I: Program returns random data in a function
[ 38s] E: openbsc no-return-in-nonvoid-function meas_vis.c:118
Holger reports that the bitmap that accounts for available Osmux circuit
IDs is limited to 128, when the maximum number of circuit IDs are
determined by the uint8_t field in the header (ie. 256 circuits).
[hfreyther: Update the testcase now that we have more ids to allocate]
Trigger an OAP registration upon IPA connect. Feed incoming OAP messages to
oap_handle() and send replies returned by it.
Add oap_config to sgsn_config (todo: vty).
Sponsored-by: On-Waves ehf
[hfreyther: Fix coding style]
Add new kitchen sink openbsc/utils.h and libcommon/utils.c to make three so far
static functions public (so I can use them in the upcoming OAP code).
A place to put them could have been the gprs_utils.h, but all general functions
in there have a gprs_ prefix, and todo markings to move them away. All other
libcommon headers are too specific, so I opened up this kitchen sink header.
Replace the implementation of encode_big_endian() with a call to
osmo_store64be_ext(). See comments.
Apply the change in Makefiles and C files.
This change has some implications for the test case. It manipulated
bss_ptmsi_state and sgsn_tlli_state variables to make the output of
rand_r() and thus the TLLI/TMSI used predictable.
This possibility is gone when using RAND_bytes() so instead it is
overridden by a function that returns a deterministic sequence of values
(0x00dead00, 0x00dead01, ...). The test cases are adapted to expect
these values instead of the pseudo random values before.
The gbproxy_test stdout file changes as well, but only where the
TLLI/TMSI is displayed (in the hex dumps as well as the TLLI cache
entries). All other output is the same.
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This is needed by the next
commit to reset the RAND_bytes sequence.
Currently just the number of intercepted downlink messages is counted
and eventually checked. The contents of the messages is lost. The
PTMSI contained in ATTACH/RAU Accept messages is just 'guessed' by
resetting the random number generator after reference PTMSIs have
been generated. While this works with rand_r, RAND_bytes cannot be
forced to recreate a certain number sequence this way (unless the
backend is replaced).
This commit changes that behaviour so that the last received msgb is
kept and decoded. The PTMSI that has been assigned by the SGSN is
then taken in the affected test cases and used instead of a 'guessed'
one. This is similar to how a real MS would react to the Accept
message.
Sponsored-by: On-Waves ehf
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This will be needed by the
next commit that will store the last received msgb for later inspection.
Sponsored-by: On-Waves ehf
This API is a bit unfortunate as the caller will also
access the endpoint directly. E.g. like this:
output = bsc_mgcp_rewrite(...,
mgcp_net_src_addr(endp),
endp->net_end.local_port, -1,
In terms of "terminology" the "net" was meant to be bad
internet and the "bts" is the local and trusted network
segment. With this terminology the "bts" would be the
call-agent/MGW and "net" where the BSCs will send data
to but that is not the case and terminology actuallys
refers to:
* net: The addresses exposed to the entity that
made the MGCP call
* bts: The system where we get our data for the
local audio flow.
Fix the method but leave the API as it is. Use the net_end
in the net_src method and the bts_end in the bts_src method.
We put a signed integer into this string but did not account
for the newline and for the terminating NUL of the string. Add
the newline to the string and add one for NUL. Spotted while
accidently having a CID of 255.
There appears to be a leak of CIDs:
<000b> mgcp_osmux.c:544 All Osmux circuits are in use!
There are paths that a CID had been requested and never released
of the NAT. Remember the allocated CID inside the endpoint so it
can always be released. It is using a new variable as the behavior
for the NAT and MGCP MGW is different.
The allocated_cid must be signed so that we can assign outside
of the 0-255 range of it.
Fixes: OW#1493
Extend the osmux only setting from the MGCP MGW to the NAT. This
is applied when an endpoint is allocated and/or when the allocation
is confirmed by the remote system.
Not tested. The impact should only be when the new option is
being used.
Fixes: OW#1492
Some systems only want to use Osmux. In case only Osmux
should be used fail if it has not be offered/acked.
Client:
Verified On, Off and Only with X-Osmux: 3 and without this field.
<000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14
<000b> mgcp_protocol.c:884 Resource error on 0x14
NAT:
Not tested and implemented
Fixes: OW#1492
sizeof(uint8_t) == 1 and there is no need to create an array
with 16 bytes and then only use the first two of them. This
means the CID range is from 0 to 127 and we should be able
to extend this to 256 by changing the array size to 32. Update
the testcase now that we can have more than 16 calls with Osmux.
* Test that one can get an id
* That they are assigned predicatble right now
* That returning them will make the number of used ones go down
* That allocating more will fail
The log message does not help and says where the data is
being sent to. This is because we have both a RTP and RTCP
port. Remember if we failed with RTCP or RTP and improve
the log message.
I was searching a case where the port was bound to a local
address (e.g. 127.0.0.1) and tried to send the data to a
public one (e.g. 8.8.8.8).