November 2023 - gerrit-log - lists.osmocom.org

[S] Change in libosmocore[master]: sim/class_tables: Prevent out-of-bounds access
by laforge 28 Nov '23

28 Nov '23

laforge has submitted this change. ( https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email ) Change subject: sim/class_tables: Prevent out-of-bounds access ...................................................................... sim/class_tables: Prevent out-of-bounds access The INS tables always must be declared with 256 elements, even if they only use some of them. We never know which random INS code might be used to index them. This was not discovered until now as the only known user of those tables is always using the SIM/UICC/USIM table and not the plain ISO7816 table. Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 --- M src/sim/class_tables.c 1 file changed, 18 insertions(+), 1 deletion(-) Approvals: laforge: Looks good to me, approved; Verified diff --git a/src/sim/class_tables.c b/src/sim/class_tables.c index 724c077..6d05ede 100644 --- a/src/sim/class_tables.c +++ b/src/sim/class_tables.c @@ -19,7 +19,7 @@ #include <osmocom/core/utils.h> #include <osmocom/sim/class_tables.h> -static const uint8_t iso7816_ins_tbl[] = { +static const uint8_t iso7816_ins_tbl[256] = { [0xB0] = 2, /* READ BIN */ [0xD0] = 3, /* WRITE BIN */ [0xD6] = 3, /* UPDATE BIN */ -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 Gerrit-Change-Number: 35155 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-MessageType: merged

1 0

[S] Change in libosmocore[master]: sim/class_tables: Prevent out-of-bounds access
by laforge 28 Nov '23

28 Nov '23

laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email ) Change subject: sim/class_tables: Prevent out-of-bounds access ...................................................................... Patch Set 2: Verified+1 Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 Gerrit-Change-Number: 35155 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Tue, 28 Nov 2023 21:22:25 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[S] Change in libosmocore[master]: libosmosim: Support Microsoft smart card discovery process
by laforge 28 Nov '23

28 Nov '23

Attention is currently required from: Hoernchen, dexter. Hello Hoernchen, Jenkins Builder, dexter, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email to look at the new patch set (#3). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder Change subject: libosmosim: Support Microsoft smart card discovery process ...................................................................... libosmosim: Support Microsoft smart card discovery process Our class/instruction tables (used mainly by simtrace cardem host software) only contain support for those instructions permitted in the related card specification. Microsoft blindly tries CLA=0xCA with INS=0x00 which is not somethin that the GSM SIM, ETSI UICC or 3GPP USIM specs specify, and which hence results in log output like this: DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6a88) DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 ca 7f 68 00 DLGLOBAL ERROR Unknown APDU case 0 DLGLOBAL FATAL Failed to recognize APDU, terminating Let's adjust to microsoft and *always* support their instructions no matter which osim_cla_ins_card_profile was used. Special thanks to Eric Wild for pointing me to this unexpected behaviour of PC/SC on modern Windows. Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Related: SYS#6617 --- M src/sim/class_tables.c 1 file changed, 47 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/54/35154/3 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Gerrit-Change-Number: 35154 Gerrit-PatchSet: 3 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 0

[S] Change in libosmocore[master]: libosmosim: Support Microsoft smart card discovery process
by laforge 28 Nov '23

28 Nov '23

Attention is currently required from: Hoernchen, dexter. Hello Hoernchen, dexter, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email to look at the new patch set (#2). Change subject: libosmosim: Support Microsoft smart card discovery process ...................................................................... libosmosim: Support Microsoft smart card discovery process Our class/instruction tables (used mainly by simtrace cardem host software) only contain support for those instructions permitted in the related card specification. Microsoft blindly tries CLA=0xCA with INS=0x00 which is not somethin that the GSM SIM, ETSI UICC or 3GPP USIM specs specify, and which hence results in log output like this: DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6a88) DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 ca 7f 68 00 DLGLOBAL ERROR Unknown APDU case 0 DLGLOBAL FATAL Failed to recognize APDU, terminating Let's adjust to microsoft and *always* support their instructions no matter which osim_cla_ins_card_profile was used. Special thanks to Eric Wild for pointing me to this unexpected behaviour of PC/SC on modern Windows. Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Related: SYS#6617 --- M src/sim/class_tables.c 1 file changed, 45 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/54/35154/2 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Gerrit-Change-Number: 35154 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de> Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-CC: Jenkins Builder Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 0

[S] Change in libosmocore[master]: sim/class_tables: Prevent out-of-bounds access
by laforge 28 Nov '23

28 Nov '23

laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email ) Change subject: sim/class_tables: Prevent out-of-bounds access ...................................................................... Patch Set 1: Code-Review+2 (1 comment) Patchset: PS1: so trivial, doesn't need review. -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 Gerrit-Change-Number: 35155 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: Jenkins Builder Gerrit-Comment-Date: Tue, 28 Nov 2023 21:03:08 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[S] Change in libosmocore[master]: sim/class_tables: Prevent out-of-bounds access
by laforge 28 Nov '23

28 Nov '23

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email ) Change subject: sim/class_tables: Prevent out-of-bounds access ...................................................................... sim/class_tables: Prevent out-of-bounds access The INS tables always must be declared with 256 elements, even if they only use some of them. We never know which random INS code might be used to index them. This was not discovered until now as the only known user of those tables is always using the SIM/UICC/USIM table and not the plain ISO7816 table. Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 --- M src/sim/class_tables.c 1 file changed, 18 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/55/35155/1 diff --git a/src/sim/class_tables.c b/src/sim/class_tables.c index 7c11f3b..4e0bb60 100644 --- a/src/sim/class_tables.c +++ b/src/sim/class_tables.c @@ -19,7 +19,7 @@ #include <osmocom/core/utils.h> #include <osmocom/sim/class_tables.h> -static const uint8_t iso7816_ins_tbl[] = { +static const uint8_t iso7816_ins_tbl[256] = { [0xB0] = 2, /* READ BIN */ [0xD0] = 3, /* WRITE BIN */ [0xD6] = 3, /* UPDATE BIN */ -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35155?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6739f469f6e84eed9aab403cc481ebff86df0181 Gerrit-Change-Number: 35155 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

1 0

[S] Change in libosmocore[master]: libosmsim: Support Microsoft smart card discovery process
by laforge 28 Nov '23

28 Nov '23

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email ) Change subject: libosmsim: Support Microsoft smart card discovery process ...................................................................... libosmsim: Support Microsoft smart card discovery process Our class/instruction tables (used mainly by simtrace cardem host software) only contain support for those instructions permitted in the related card specification. Microsoft blindly tries CLA=0xCA with INS=0x00 which is not somethin that the GSM SIM, ETSI UICC or 3GPP USIM specs specify, and which hence results in log output like this: DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6a88) DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 ca 7f 68 00 DLGLOBAL ERROR Unknown APDU case 0 DLGLOBAL FATAL Failed to recognize APDU, terminating Let's adjust to microsoft and *always* support their instructions no matter which osim_cla_ins_card_profile was used. Special thanks to Eric Wild for pointing me to this unexpected behaviour of PC/SC on modern Windows. Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Related: SYS#6617 --- M src/sim/class_tables.c 1 file changed, 45 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/54/35154/1 diff --git a/src/sim/class_tables.c b/src/sim/class_tables.c index 724c077..7c11f3b 100644 --- a/src/sim/class_tables.c +++ b/src/sim/class_tables.c @@ -350,6 +350,13 @@ [0x88] = 4, /* AUTHENTICATE */ }; +/* https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/discov… */ +static const uint8_t microsoft_discovery_ins_tbl[256] = { + [0xA4] = 4, /* SELECT FILE */ + [0xCA] = 2, /* GET DATA */ + [0xC0] = 2, /* GET RESPONSE */ +}; + int osim_determine_apdu_case(const struct osim_cla_ins_card_profile *prof, const uint8_t *hdr) { @@ -374,5 +381,14 @@ return rc; } } + /* special handling for Microsoft who insists to use INS=0xCA in CLA=0x00 which is not + * really part of GSM SIM, ETSI UICC or 3GPP USIM specifications, but only ISO7816. Rather than adding + * it to each and every card profile, let's add the instructions listed at + * https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/discov… explicitly + * here. They will only be used in case no more specific match was found in the actual profile above. */ + rc = microsoft_discovery_ins_tbl[ins]; + if (rc) + return rc; + return 0; } -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35154?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I424964c0afab643e6a5d7824d91c2c86b0d3f25b Gerrit-Change-Number: 35154 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

1 0

[M] Change in osmo-hnbgw[master]: mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side
by pespin 28 Nov '23

28 Nov '23

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/35153?usp=email ) Change subject: mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side ...................................................................... mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side In general, the HNBs end up binding its IuUP/RTP streams to the same IP address used for Iuh signalling. When receiving a RAB-Ass-Req from CN, osmo-hnbgw creates an endpoint in its co-located MGW and creates 2 MGCP conns on it, one facing the RAN side and one facing the CN side. At that point, the remote CN IuUP IP address is known (was include din the received RAB-Ass-Req), but the RAN one is not yet known. Hence, the CRCX on the RAN-side conn contained no remote IP address, which means MGW has to blindly guess a good local IP address if "ip probing" is enabled. As a result, when RAB-Ass-Resp comes back from the hNodeB containing the allocated remote IuUP IP address and MGW is updated through MGCP MDCX, it may happen that MGW rebinds to a better fitting local IP address and returns it in MDCX. This has several downfalls: 1- We don't yet support updating the hNodeB about the changed IP address (see mgw_fsm_mdcx_hnb). For that, we'd need to send a RAB-Modify-Req+Resp. 2- Even if we supported it, in the general case we'd be delaying call establishment because an extra roundtrip is needed to update RAB-Modify-Req+Resp. In general, the HNBs end up binding its IuUP/RTP streams to the same IP address used for the Iuh signalling. Hence, use this assumption to announce the Iuh IP address as a remote IuUP IP address when transmitting the MGCP CRCX at the RAN-side conn to the MGW. This way the MGW can potentially select a proper local IuUP IP address from the start, so no RAB-Modify-Req is required later on. The logic to transmit RAB-Modify-Req is left unimplemented in this commit and is left as a later improvement. Related: SYS#6657 Change-Id: I87c514204603e0f15a55da9b619c7ce1e14f042e T# Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe --- M src/osmo-hnbgw/mgw_fsm.c 1 file changed, 63 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/53/35153/1 diff --git a/src/osmo-hnbgw/mgw_fsm.c b/src/osmo-hnbgw/mgw_fsm.c index 7b4c811..5251374 100644 --- a/src/osmo-hnbgw/mgw_fsm.c +++ b/src/osmo-hnbgw/mgw_fsm.c @@ -26,6 +26,8 @@ #include <osmocom/core/logging.h> #include <osmocom/core/sockaddr_str.h> +#include <osmocom/netif/stream.h> + #include <osmocom/ranap/ranap_common.h> #include <osmocom/ranap/ranap_common_cn.h> #include <osmocom/ranap/ranap_common_ran.h> @@ -132,6 +134,7 @@ { struct mgw_fsm_priv *mgw_fsm_priv = fi->priv; struct hnbgw_context_map *map = mgw_fsm_priv->map; + struct hnb_context *hnb_ctx = map->hnb_ctx; struct osmo_sockaddr addr; struct osmo_sockaddr_str addr_str; RANAP_RAB_AssignmentRequestIEs_t *ies; @@ -168,6 +171,21 @@ mgw_info.codecs[0] = CODEC_IUFP; mgw_info.codecs_len = 1; + /* The HNB IuUP IP address & port is not yet known here (Rx RAB-Ass-Req Tx CRCX (RAN) time): + * Assume and announce "remote IuUP IP address" == "remote Iuh signalling IP address" to the MGW + * here, so that it can most probably select a proper IuUP local IP address to be used from the + * start. In the event we receive a "remote IuUP IP address" != "remote Iuh signalling IP address" + * later on during RAB-Ass-Resp, we'll update IP addr at the MGW through MDCX and if MGW decides + * to use another IuUP local IP address as a result, it will be updated at the HNB through + * RAB-Modify-Req. */ + if (hnb_ctx && hnb_ctx->conn && + (rc = osmo_stream_srv_get_fd(hnb_ctx->conn)) >= 0) { + if (osmo_sock_get_remote_ip(rc, mgw_info.addr, sizeof(mgw_info.addr)) < 0) + LOGPFSML(fi, LOGL_ERROR, "Invalid Iuh IP Address\n"); + } + LOGPFSML(fi, LOGL_ERROR, "PESPIN: mgw_info.addr=%s\n", mgw_info.addr); + //mgw_info.port = 80; + mgw_fsm_priv->mgcpc = mgcp_client_pool_get(g_hnbgw->mgw_pool); if (!mgw_fsm_priv->mgcpc) { LOGPFSML(fi, LOGL_ERROR, @@ -322,8 +340,7 @@ * normally. This is a situation we cannot recover from. */ LOGPFSML(fi, LOGL_ERROR, "Failed to extract RTP IP-address and Port from RAB-AssignmentResponse\n"); osmo_fsm_inst_state_chg(fi, MGW_ST_FAILURE, 0, 0); - return; - } + return; } rc = osmo_sockaddr_str_from_sockaddr(&addr_str, &addr.u.sas); if (rc < 0) { -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/35153?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe Gerrit-Change-Number: 35153 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange

1 0

[M] Change in osmo-mgw[master]: mgcp-cli: Transmit remote IP addr in CRCX if known and port=0
by pespin 28 Nov '23

28 Nov '23

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-mgw/+/35152?usp=email ) Change subject: mgcp-cli: Transmit remote IP addr in CRCX if known and port=0 ...................................................................... mgcp-cli: Transmit remote IP addr in CRCX if known and port=0 A client may know the IP address during CRCX but not yet the port, or it may simply want to hint an initial IP address so that the MGW can better guess when allocating a local IP address. Related: SYS#6657 Change-Id: I30165dbac5e484011d0acf46af36f105954a501d --- M src/libosmo-mgcp-client/mgcp_client.c M src/libosmo-mgcp-client/mgcp_client_fsm.c 2 files changed, 58 insertions(+), 31 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/52/35152/1 diff --git a/src/libosmo-mgcp-client/mgcp_client.c b/src/libosmo-mgcp-client/mgcp_client.c index b5897a6..103f17f 100644 --- a/src/libosmo-mgcp-client/mgcp_client.c +++ b/src/libosmo-mgcp-client/mgcp_client.c @@ -1302,9 +1302,6 @@ local_ip_family = osmo_ip_str_type(local_ip); if (local_ip_family == AF_UNSPEC) return -EINVAL; - audio_ip_family = osmo_ip_str_type(mgcp_msg->audio_ip); - if (audio_ip_family == AF_UNSPEC) - return -EINVAL; /* Add owner/creator (SDP) */ MSGB_PRINTF_OR_RET("o=- %x 23 IN IP%c %s\r\n", mgcp_msg->call_id, @@ -1314,33 +1311,41 @@ /* Add session name (none) */ MSGB_PRINTF_OR_RET("s=-\r\n"); - /* Add RTP address and port */ - if (mgcp_msg->audio_port == 0) { - LOGPMGW(mgcp, LOGL_ERROR, - "Invalid port number, can not generate MGCP message\n"); - msgb_free(msg); - return -EINVAL; + /* Add RTP address */ + if (mgcp_msg->presence & MGCP_MSG_PRESENCE_AUDIO_IP) { + audio_ip_family = osmo_ip_str_type(mgcp_msg->audio_ip); + if (audio_ip_family == AF_UNSPEC) + return -EINVAL; + if (strlen(mgcp_msg->audio_ip) <= 0) { + LOGPMGW(mgcp, LOGL_ERROR, + "Empty ip address, can not generate MGCP message\n"); + msgb_free(msg); + return -EINVAL; + } + MSGB_PRINTF_OR_RET("c=IN IP%c %s\r\n", + audio_ip_family == AF_INET6 ? '6' : '4', + mgcp_msg->audio_ip); } - if (strlen(mgcp_msg->audio_ip) <= 0) { - LOGPMGW(mgcp, LOGL_ERROR, - "Empty ip address, can not generate MGCP message\n"); - msgb_free(msg); - return -EINVAL; - } - MSGB_PRINTF_OR_RET("c=IN IP%c %s\r\n", - audio_ip_family == AF_INET6 ? '6' : '4', - mgcp_msg->audio_ip); /* Add time description, active time (SDP) */ MSGB_PRINTF_OR_RET("t=0 0\r\n"); - MSGB_PRINTF_OR_RET("m=audio %u RTP/AVP", mgcp_msg->audio_port); - for (i = 0; i < mgcp_msg->codecs_len; i++) { - pt = map_codec_to_pt(mgcp_msg->ptmap, mgcp_msg->ptmap_len, mgcp_msg->codecs[i]); - MSGB_PRINTF_OR_RET(" %u", pt); + /* Add RTP address port and codecs */ + if (mgcp_msg->presence & MGCP_MSG_PRESENCE_AUDIO_PORT) { + if (mgcp_msg->audio_port == 0) { + LOGPMGW(mgcp, LOGL_ERROR, + "Invalid port number, can not generate MGCP message\n"); + msgb_free(msg); + return -EINVAL; + } + MSGB_PRINTF_OR_RET("m=audio %u RTP/AVP", mgcp_msg->audio_port); + for (i = 0; i < mgcp_msg->codecs_len; i++) { + pt = map_codec_to_pt(mgcp_msg->ptmap, mgcp_msg->ptmap_len, mgcp_msg->codecs[i]); + MSGB_PRINTF_OR_RET(" %u", pt); + } + MSGB_PRINTF_OR_RET("\r\n"); } - MSGB_PRINTF_OR_RET("\r\n"); /* Add optional codec parameters (fmtp) */ if (mgcp_msg->param_present) { @@ -1470,10 +1475,10 @@ MSGB_PRINTF_OR_RET("I: %s\r\n", mgcp_msg->conn_id); } - /* Using SDP makes sense when a valid IP/Port combination is specified, + /* Using SDP makes sense when a valid IP or Port is specified, * if we do not know this information yet, we fall back to LCO */ if (mgcp_msg->presence & MGCP_MSG_PRESENCE_AUDIO_IP - && mgcp_msg->presence & MGCP_MSG_PRESENCE_AUDIO_PORT) + || mgcp_msg->presence & MGCP_MSG_PRESENCE_AUDIO_PORT) use_sdp = true; /* Add local connection options (LCO) */ diff --git a/src/libosmo-mgcp-client/mgcp_client_fsm.c b/src/libosmo-mgcp-client/mgcp_client_fsm.c index 660f0ad..73479f1 100644 --- a/src/libosmo-mgcp-client/mgcp_client_fsm.c +++ b/src/libosmo-mgcp-client/mgcp_client_fsm.c @@ -136,10 +136,19 @@ static void add_audio(struct mgcp_msg *mgcp_msg, struct mgcp_conn_peer *info) { - mgcp_msg->presence |= MGCP_MSG_PRESENCE_AUDIO_IP | MGCP_MSG_PRESENCE_AUDIO_PORT; - mgcp_msg->audio_ip = info->addr; - mgcp_msg->audio_port = info->port; - mgcp_msg->conn_mode = MGCP_CONN_RECV_SEND; + bool ip_is_set = info->addr[0] != '\0' && + strncmp(info->addr, "::", sizeof(info->addr)) != 0 && + strncmp(info->addr, "0.0.0.0", sizeof(info->addr)) != 0; + if (ip_is_set) { + mgcp_msg->presence |= MGCP_MSG_PRESENCE_AUDIO_IP; + mgcp_msg->audio_ip = info->addr; + } + if (info->port) { + mgcp_msg->presence |= MGCP_MSG_PRESENCE_AUDIO_PORT; + mgcp_msg->audio_port = info->port; + } + if (ip_is_set && info->port) + mgcp_msg->conn_mode = MGCP_CONN_RECV_SEND; } static void set_conn_mode(struct mgcp_msg *mgcp_msg, struct mgcp_conn_peer *peer) @@ -221,8 +230,7 @@ mgcp_ctx->conn_peer_local.endpoint); make_crcx_msg(&mgcp_msg, &mgcp_ctx->conn_peer_local); - if (mgcp_ctx->conn_peer_local.port) - add_audio(&mgcp_msg, &mgcp_ctx->conn_peer_local); + add_audio(&mgcp_msg, &mgcp_ctx->conn_peer_local); set_conn_mode(&mgcp_msg, &mgcp_ctx->conn_peer_local); msg = mgcp_msg_gen(mgcp_ctx->mgcp, &mgcp_msg); -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/35152?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: I30165dbac5e484011d0acf46af36f105954a501d Gerrit-Change-Number: 35152 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange

1 0

[S] Change in libosmocore[master]: gsup: add message type for osmo-epdg CEAI interface
by lynxis lazus 28 Nov '23

28 Nov '23

lynxis lazus has submitted this change. ( https://gerrit.osmocom.org/c/libosmocore/+/32033?usp=email ) Change subject: gsup: add message type for osmo-epdg CEAI interface ...................................................................... gsup: add message type for osmo-epdg CEAI interface The CEIA interface is an interface between osmo-epdg and strongswan. It is used by the osmo-epdg to synchronize state. Related: OS#6091 Change-Id: I6f7c20340c99f94b1326a8a7dc99c86cf6a0dbc3 --- M include/osmocom/gsm/gsup.h M src/gsm/gsup.c 2 files changed, 24 insertions(+), 0 deletions(-) Approvals: laforge: Looks good to me, but someone else must approve daniel: Looks good to me, approved Jenkins Builder: Verified diff --git a/include/osmocom/gsm/gsup.h b/include/osmocom/gsm/gsup.h index 56d7a30..6e7fcf0 100644 --- a/include/osmocom/gsm/gsup.h +++ b/include/osmocom/gsm/gsup.h @@ -198,6 +198,10 @@ OSMO_GSUP_MSGT_E_ABORT = 0b01001011, OSMO_GSUP_MSGT_ROUTING_ERROR = 0b01001110, + + OSMO_GSUP_MSGT_EPDG_TUNNEL_REQUEST = 0b01010000, + OSMO_GSUP_MSGT_EPDG_TUNNEL_ERROR = 0b01010001, + OSMO_GSUP_MSGT_EPDG_TUNNEL_RESULT = 0b01010010, }; #define OSMO_GSUP_MSGT_E_ROUTING_ERROR OSMO_GSUP_MSGT_ROUTING_ERROR @@ -281,6 +285,7 @@ OSMO_GSUP_MESSAGE_CLASS_SMS = 2, OSMO_GSUP_MESSAGE_CLASS_USSD = 3, OSMO_GSUP_MESSAGE_CLASS_INTER_MSC = 4, + OSMO_GSUP_MESSAGE_CLASS_IPSEC_EPDG = 5, /* Keep this as last entry with a value of max(enum osmo_gsup_message_class) + 1. * This value shall serve as the size for an array to aid de-muxing all known GSUP classes. */ OSMO_GSUP_MESSAGE_CLASS_ARRAYSIZE diff --git a/src/gsm/gsup.c b/src/gsm/gsup.c index ef33ed0..4e09ac8 100644 --- a/src/gsm/gsup.c +++ b/src/gsm/gsup.c @@ -103,6 +103,10 @@ OSMO_VALUE_STRING(OSMO_GSUP_MSGT_ROUTING_ERROR), + OSMO_VALUE_STRING(OSMO_GSUP_MSGT_EPDG_TUNNEL_REQUEST), + OSMO_VALUE_STRING(OSMO_GSUP_MSGT_EPDG_TUNNEL_RESULT), + OSMO_VALUE_STRING(OSMO_GSUP_MSGT_EPDG_TUNNEL_ERROR), + { 0, NULL } }; @@ -911,6 +915,7 @@ { OSMO_GSUP_MESSAGE_CLASS_SMS, "SMS" }, { OSMO_GSUP_MESSAGE_CLASS_USSD, "USSD" }, { OSMO_GSUP_MESSAGE_CLASS_INTER_MSC, "Inter-MSC" }, + { OSMO_GSUP_MESSAGE_CLASS_IPSEC_EPDG, "IPsec-ePDG" }, {} }; -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/32033?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6f7c20340c99f94b1326a8a7dc99c86cf6a0dbc3 Gerrit-Change-Number: 32033 Gerrit-PatchSet: 3 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: lynxis lazus <lynxis(a)fe80.eu> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

1 0