| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This is needed for the ip.access nano3G femto cell.
|
|
There are different Iu dialects in terms of encoding the
transport layer address inside RAB Assignment req + resp.
Let's be liberal in what we accept, and simply use the length
as an indicator of the format. Wireshark uses similar heuristics.
|
|
When the RNC confirms the RAB Assignment, it can each time indicate a
new TEID for the GTP-U endpoint on the RNC side. We need to update our
information about the PDP context and include that in the UPDATE PDP
CONTEXT that we're sending towards the GGSN. This is similar to
updating the RNC-side IP address of the GTP endpoint.
|
|
When receiving an RAB-Assignment response from the RNC,
we should use the RAB ID (=NSAPI) to resolve the PDP context.
We cannot use the TEID, as the TEID chosen by the RNC for this RAB has
no relationship to the TEID we were using for the RAB-Assignment
request. TEIDs are local to each of the peer, like UDP port numbers.
|
|
As Dieter has pointed out, the RANAP spec requires the RAB ID to be
equal to the NSAPI of the PDP context for which it is established.
|
|
Add use_x213_nsap parameter to iu_rab_act_ps(), pass the new parameter
from two callers as 1 such that there is no functional change.
|
|
|
|
|
|
|
|
sgsn_libgtp.c: missing include, for asn1str_to_u32()
iu_cs.c: missing include, for subscr_name()
osmo_bsc_vty.c: int/pointer conversions
(note: this was discussed on the list to be solved by passing a pointer
instead. Until then...)
iudummy.c: opaque struct declarations
|
|
|
|
The new iu event callback will now be called for RAB assignment response, IU
release and security mode complete
|
|
|
|
|
|
In the IU case the RNC and ggsn communicate directly on the user plane.
Since the IP address of the RNC is not known in our case (it sits behind
the hnbgw) we need to update the PDP context with the new IP address
after receiving the RAB assignment response (which includes the IP
address).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Let's explicitly mark those sgsn_mm_ctx members that apply for Gb mode
and (upcoming) Iu mode, respectively.
|
|
We don't care how many bytes the length has but the
destination we want to copy to.
Fixes: CID#1296813
|
|
We have verified/selected the APN. Either based on the subscriber
data, a global APN match. But at least this SGSN has looked at
what the MS has asked for and then selected a matching GGSN.
|
|
Bits 3 to 8 are spare bits and should be set to 1 in etsi
specifications. Do that.
|
|
Clear LAC/RAC with pre-defined value in the RAI.
3GPP 29.060 v7.17.0 section 7.3.1 page 23:
"The SGSN may include the Routeing Area Identity (RAI) of the
SGSN where the MS is registered. The MCC and MNC components shall
be populated with the MCC and MNC, respectively, of the SGSN
where the MS is registered. The LAC and RAC components shall be
populated by the SGSN with the value of 'FFFE' and 'FF',
respectively.”
|
|
Most SGSNs pass the IMEI(SV). We currently only enquire about
the IMEI and then pad the 'SV' with 1111b (thanks to the encoding
routine). Sadly it insists on always writing the length which
means we have to memmove the data around by a single octet.
Manually verified using the pcu-emu and looking at the trace
using wireshark.
|
|
Give the GGSN another opportunity to determine which tarif
to apply for the SGSN/subscriber. This code assumes tha the
RAN is a GERAN system but the assumption has been made in
other places as well.
|
|
For PDP context creation we always want to include the RAI
for the current mmctx. This might help commercial GGSNs to
determine which charging to apply.
|
|
This is consuming the new signals and allows to install several
different CDR/observing/event/audit modules in the future. For
getting the bytes in/out the code would have had to undo what the
rate counter is doing and at the same time adding a "total" to
the ratecounter didn't look like a good idea, the same went for
making it a plain counter.
Begin writing the values one by one and open/closing a new FILE
for every log messages. This is not efficient but easily deals
with external truncation/rotation of the file (no fstat for and
checking the links and size). As usual we will wait and see if
this is an issue.
Add some new members to our PDP context structure to see what it
is about.
|
|
|
|
If QoS is only three bytes it does not include the allocation/
retention policy. Otherwise it does. Copy it depending on that.
We should have a macro for the clamping to reduce code duplication.
The insanity does come from the MAP data and this seems to be
the easiest in terms of complexity. It is an array of bytes that
is transported from MAPProxy to the SGSN and then simply forwarded.
The case of more than three bytes is neither unit nor manually
tested so far.
|
|
sgsn_create_pdp_ctx should use the subscribed QoS. When selecting
the PDP context we inject the QoS to be used into the TLV structure
and use it during the request. Assume a "qos-Subscribed" structure
only with three bytes and prepend the Allocation/Retention policy
to the request.
|
|
The MSISDN should be present for "security" reasons in the first
activation of a PDP context. Take the encoded MSISDN, store it for
future use and then put it into the PDP activation request.
The MM Context contains a field for a decoded MSISDN already. As
we need to forward the data to the GGSN I want to avoid having to
store TON and NPI in another place. Simply store the data in the
encoded form.
|
|
Assume we are always a GERAN network right now.
|
|
Currently the PDP contexts are hard freed (via sgsn_pdp_ctx_free)
at some places in gprs_gmm.c on the reception of a Detach Req and on
re-use of an IMSI that is already associated with an MM context. This
can lead to segfaults when there is a pending request or a data
indication at libgtp.
This patch add a new function sgsn_pdp_ctx_terminate that de-associates
the PTP context from the MM context, deactivates SNDCP, sets pdp->mm
to NULL and then calls sgsn_delete_pdp_ctx. sgsn_libgtp is updated to
check for pdp->mm being non-NULL before dereferencing it. The
sgsn_pdp_ctx_terminate function will be called for each PDP context of
an MM context before this context is going to be deleted via
sgsn_mm_ctx_free. To ensure, that the ctx->llme (which is accessed
during the deactivation of SNDCP) remains valid, the call to
gprs_llgmm_assign is moved after the call to sgsn_mm_ctx_free. The
handling of re-used IMSIs is changed to mimic the processing of a
Detach Req.
Addresses:
<0002> gprs_gmm.c:654 MM(/f6b31ab0) Deleting old MM Context for same
IMSI p_tmsi_old=0xc6f19134
<000f> gprs_sgsn.c:259 PDP freeing PDP context that still has a
libgtp handle attached to it, this shouldn't happen!
[...]
SEGFAULT
Ticket: OW#1311
Sponsored-by: On-Waves ehf
|
|
Many log levels were DEBUG without any good reason. Also where possible
the details of the MM or PDP context are now logged with LOGMM/PDPCTXP.
|
|
CC sgsn_libgtp.o
sgsn_libgtp.c: In function ‘create_pdp_conf’:
sgsn_libgtp.c:262:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
^
sgsn_libgtp.c: In function ‘cb_data_ind’:
sgsn_libgtp.c:432:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
|
|
In case of a failure this method didn't set the pctx->lib back to
NULL. In case of a timeout the callback will be made with pdp=NULL
and this would lead to leaking the PDP context. Check for the case
of having a pctx->lib != pdp and free it.
This resolves:
<000f> gprs_sgsn.c:259 freeing PDP context that still has a libgtp handle attached to it, this shouldn't happen!
|
|
The code was written like checking the return value of the
osmo_fd_register but the rc variable was not assigned for the
subsequent calls.
Fixes: Coverity CID 1040741
|
|
A crash was obsserved in cb_data_ind() when mm is dereferenced.
This patch adds some safeguards that try to prevent the library handle
back-pointer to the pdp_ctx to be NULL, and print a stack backtrace in
case we are free() ing the sgsn-side pdp_ctx while there's still a
library handle attached.
|
|
We change the minority of functions employing the gprs_bssgp_ prefix to
match with the majority without gprs_ in front.
|
|
This also removes the dependency to osmo_sock() inside libcommon and
replaces it with osmo_sock_* from libosmocore
|
|
found by Smatch
|
|
Summary of changes:
s/struct bsc_fd/struct osmo_fd/g
s/bsc_register_fd/osmo_fd_register/g
s/bsc_unregister_fd/osmo_fd_unregister/g
s/bsc_select_main/osmo_select_main/g
|
|
Summary of changes:
s/struct timer_list/struct osmo_timer_list/g
s/bsc_add_timer/osmo_timer_add/g
s/bsc_schedule_timer/osmo_timer_schedule/g
s/bsc_del_timer/osmo_timer_del/g
s/bsc_timer_pending/osmo_timer_pending/g
s/bsc_nearest_timer/osmo_timers_nearest/g
s/bsc_prepare_timers/osmo_timers_prepare/g
s/bsc_update_timers/osmo_timers_update/g
s/bsc_timer_check/osmo_timers_check/g
|
|
These are not needed any more. We used them for u_int
types but we now use uint which comes from stdint.h
|
|
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
|
|
The reason for this is quite simple: We want to make sure anyone
running a customized version of OpenBSC to operate a network will
have to release all custom modifiations to the source code.
|
