[AGW] [MME] Adding IP_ALLOCATION_RESPONSE to handle ip allocation process on SPGW… #5416
Conversation
ssanadhya
requested review from
ardzoht,
lionelgo,
pshelar and
ulaskozat
as code owners
Codecov Report
@@ Coverage Diff @@
## master #5416 +/- ##
=======================================
Coverage 63.58% 63.58%
=======================================
Files 301 301
Lines 20376 20376
=======================================
Hits 12957 12957
Misses 5514 5514
Partials 1905 1905 Continue to review full report at Codecov.
|
ardzoht
force-pushed
the
add_ip_allocation_rsp_itti_msg
branch
from
250ce2e
to
1398b43
Compare
|
MAGMA-OAI-TESTS |
| MobilityServiceClient::getInstance().AllocateIPv4AddressAsync( | ||
| subscriber_id, apn, | ||
| [=, &s5_response]( | ||
| const Status& status, AllocateIPAddressResponse ip_msg) { | ||
| [addr, subscriber_id, apn, pdn_type, context_teid, eps_bearer_id]( |
There was a problem hiding this comment.
We do not need to capture the addr from the caller scope here. It was originally used to capture the addr allocated by the RPC, but this will be taken care of through the ITTI message now.
| }); | ||
| return 0; | ||
| } | ||
|
|
||
| static itti_sgi_create_end_point_response_t handle_allocate_ipv4_address_status( | ||
| static int handle_allocate_ipv4_address_status( |
There was a problem hiding this comment.
Since caller is ignoring the return status, do you still need it?
| s_plus_p_gw_eps_bearer_context_information_t* bearer_ctxt_info_p = | ||
| sgw_cm_get_spgw_context(ip_allocation_rsp->context_teid); | ||
|
|
||
| if (bearer_ctxt_info_p) { |
There was a problem hiding this comment.
Add error or warning msg if context is not found
| if (ip_allocation_rsp->status == SGI_STATUS_ERROR_SYSTEM_FAILURE) { | ||
| /* | ||
| * This implies that UE session was not release properly. | ||
| * Release the IP address so that subsequent attempt is successfull | ||
| */ | ||
| // TODO - Release the GTP-tunnel corresponding to this IP address | ||
| char* apn = | ||
| (char*) bearer_ctxt_info_p->sgw_eps_bearer_context_information | ||
| .pdn_connection.apn_in_use; | ||
| release_ipv4_address(imsi, apn, &ip_allocation_rsp->paa.ipv4_address); | ||
| } |
There was a problem hiding this comment.
Any reason for not leaving this logic inside the function "handle_allocate_ipv4_address_status" to simplify this handler
… main thread Signed-off-by: Alex Rodriguez <ardzoht@gmail.com>
Signed-off-by: Alex Rodriguez <ardzoht@gmail.com>
ardzoht
force-pushed
the
add_ip_allocation_rsp_itti_msg
branch
from
1398b43
to
8544622
Compare
| MobilityServiceClient::getInstance().AllocateIPv4AddressAsync( | ||
| subscriber_id, apn, | ||
| [=, &s5_response]( | ||
| const Status& status, AllocateIPAddressResponse ip_msg) { | ||
| [subscriber_id, apn, pdn_type, context_teid, eps_bearer_id]( |
There was a problem hiding this comment.
is passing subscriber_id and apn that are pointers to the lambda function a safe call? Can what they are pointing to be deleted by the spgw thread?
There was a problem hiding this comment.
as discussed on the call, let's define std::string objects and pass those instead.
Signed-off-by: Alex Rodriguez <ardzoht@gmail.com>
ardzoht
force-pushed
the
add_ip_allocation_rsp_itti_msg
branch
from
bf4e293
to
aec144a
Compare
|
MAGMA-OAI-TESTS |
|
LGTM, but I cannot approve it as I created the PR on behalf of @ardzoht, waiting for approval from other code-owners. |
ulaskozat
added
the
apply-v1.4
…cess on SPGW… (#5416) * Adding IP_ALLOCATION_RESPONSE to handle ip allocation process on SPGW main thread Signed-off-by: Alex Rodriguez <ardzoht@gmail.com>
…cess on SPGW… (magma#5416) * Adding IP_ALLOCATION_RESPONSE to handle ip allocation process on SPGW main thread Signed-off-by: Alex Rodriguez <ardzoht@gmail.com>
… main thread
Signed-off-by: Alex Rodriguez ardzoht@gmail.com
Summary
Test Plan
Additional Information