lists.osmocom.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

gerrit-log

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
gerrit-log@lists.osmocom.org

January 2024

  • 1 participants
  • 1559 discussions
[S] Change in osmo-hnbgw[master]: pfcp: fix modification of wrong FAR ID
by neels 20 Jan '24

20 Jan '24
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/35641?usp=email ) Change subject: pfcp: fix modification of wrong FAR ID ...................................................................... pfcp: fix modification of wrong FAR ID Do not update the Core-facing Forwarding Action Rule with the Access side's remote TEID, update the Access-facing FAR as we should. This is a seemingly small but very grave bug in osmo-hnbgw's PFCP implementation, and proof that no-one anywhere has tested osmo-hnbgw's PFCP support properly yet. Related: SYS#5895 Change-Id: I596f1785d280d7e53e0cef649d6bb5df01ebf648 --- M src/osmo-hnbgw/ps_rab_fsm.c 1 file changed, 20 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/41/35641/1 diff --git a/src/osmo-hnbgw/ps_rab_fsm.c b/src/osmo-hnbgw/ps_rab_fsm.c index df98826..512c983 100644 --- a/src/osmo-hnbgw/ps_rab_fsm.c +++ b/src/osmo-hnbgw/ps_rab_fsm.c @@ -519,7 +519,8 @@ static void ps_rab_fsm_wait_pfcp_mod_resp_onenter(struct osmo_fsm_inst *fi, uint32_t prev_state) { /* We have been given the Access side's remote F-TEID, now in rab->access.remote, and we need to tell the UPF - * about it. */ + * about it. This affects the Core to Access direction: now we know where to forward payloads coming from Core. + */ struct ps_rab *rab = fi->priv; struct osmo_pfcp_msg *m; @@ -531,7 +532,7 @@ m = ps_rab_new_pfcp_msg_req(rab, OSMO_PFCP_MSGT_SESSION_MOD_REQ); - if (rab_to_pfcp_session_mod_req_upd_far(&m->ies.session_mod_req, ID_ACCESS_TO_CORE, &rab->access.remote)) { + if (rab_to_pfcp_session_mod_req_upd_far(&m->ies.session_mod_req, ID_CORE_TO_ACCESS, &rab->access.remote)) { LOG_PS_RAB(rab, LOGL_ERROR, "error composing Update FAR IE in PFCP msg\n"); ps_rab_failure(rab); return; -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/35641?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: I596f1785d280d7e53e0cef649d6bb5df01ebf648 Gerrit-Change-Number: 35641 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[S] Change in osmo-hnbgw[master]: pfcp: fix missing vty_write of pfcp local-port
by neels 20 Jan '24

20 Jan '24
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/35644?usp=email ) Change subject: pfcp: fix missing vty_write of pfcp local-port ...................................................................... pfcp: fix missing vty_write of pfcp local-port Change-Id: I180e67b8abdd3c0d91b30f1e7668b02f1a323809 --- M src/osmo-hnbgw/hnbgw_vty.c M tests/pfcp_cfg.vty.with_pfcp 2 files changed, 12 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/44/35644/1 diff --git a/src/osmo-hnbgw/hnbgw_vty.c b/src/osmo-hnbgw/hnbgw_vty.c index 674832b..d401279 100644 --- a/src/osmo-hnbgw/hnbgw_vty.c +++ b/src/osmo-hnbgw/hnbgw_vty.c @@ -945,6 +945,8 @@ vty_out(vty, " pfcp%s", VTY_NEWLINE); if (g_hnbgw->config.pfcp.local_addr) vty_out(vty, " local-addr %s%s", g_hnbgw->config.pfcp.local_addr, VTY_NEWLINE); + if (g_hnbgw->config.pfcp.local_port) + vty_out(vty, " local-port %u%s", g_hnbgw->config.pfcp.local_port, VTY_NEWLINE); if (g_hnbgw->config.pfcp.remote_addr) vty_out(vty, " remote-addr %s%s", g_hnbgw->config.pfcp.remote_addr, VTY_NEWLINE); diff --git a/tests/pfcp_cfg.vty.with_pfcp b/tests/pfcp_cfg.vty.with_pfcp index a093ffb..44b922c 100644 --- a/tests/pfcp_cfg.vty.with_pfcp +++ b/tests/pfcp_cfg.vty.with_pfcp @@ -50,6 +50,7 @@ ... pfcp local-addr 127.0.0.1 + local-port 8805 remote-addr 127.0.0.2 msc 0 ... -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/35644?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: I180e67b8abdd3c0d91b30f1e7668b02f1a323809 Gerrit-Change-Number: 35644 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[M] Change in osmo-hnbgw[master]: pfcp: implement sending Network Instance IEs
by neels 20 Jan '24

20 Jan '24
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/35645?usp=email ) Change subject: pfcp: implement sending Network Instance IEs ...................................................................... pfcp: implement sending Network Instance IEs Allow configuring specific Network Instance names for the Core and Access sides, to send to the UPF, to allow the UPF to pick the proper network interface to create GTP tunnels on. Add VTY cfg 'hnbgw' / 'pfcp' / 'netinst (access|core) NAME' to allow configuring Network Interface values to send in PFCP. These are "dotted" domain name strings, as in APN. Add these Network Interface names to the PFCP messages' detection as well as forwarding rules, each one indicating the side that it is detecting on or forwarding to. This helps lift osmo-hnbgw's PFCP support out of lab situations to a proper production scenario, where the core and access networks are in separate subnets, with osmo-hnbgw + UPF as the gateway. For example, in osmo-hnbgw, configure hnbgw pfcp netinst access my-ran netinst core my-core and in osmo-upf, configure netinst add my-ran 10.9.8.7 add my-core 1.2.3.4 In effect, all GTP tunnel endpoints towards the Access side will be bound on 10.9.8.7, and all GTP tunnel endpoints towards the Core side will be bound on 1.2.3.4. Related: SYS#5895 Change-Id: Ief53dbfacf1645c32a07847d590c4884d4c8ca56 --- M include/osmocom/hnbgw/hnbgw.h M src/osmo-hnbgw/hnbgw_vty.c M src/osmo-hnbgw/ps_rab_fsm.c M tests/pfcp_cfg.vty.with_pfcp 4 files changed, 103 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/45/35645/1 diff --git a/include/osmocom/hnbgw/hnbgw.h b/include/osmocom/hnbgw/hnbgw.h index e62fc71..f4f7dc1 100644 --- a/include/osmocom/hnbgw/hnbgw.h +++ b/include/osmocom/hnbgw/hnbgw.h @@ -265,6 +265,10 @@ uint16_t local_port; char *remote_addr; uint16_t remote_port; + struct { + char *access; + char *core; + } netinst; } pfcp; } config; /*! SCTP listen socket for incoming connections */ diff --git a/src/osmo-hnbgw/hnbgw_vty.c b/src/osmo-hnbgw/hnbgw_vty.c index d401279..c4c4217 100644 --- a/src/osmo-hnbgw/hnbgw_vty.c +++ b/src/osmo-hnbgw/hnbgw_vty.c @@ -842,6 +842,26 @@ return CMD_SUCCESS; } +DEFUN(cfg_pfcp_netinst, cfg_pfcp_netinst_cmd, + "netinst (access|core) NAME", + "Add a Network Instance IE to all outgoing PFCP rule sets," + " so that the UPF may choose the correct interface to open GTP tunnels on.\n" + "configure the Network Instance name sent in PFCP to create tunnels towards Access = the RNC = RAN\n" + "configure the Network Instance name sent in PFCP to create tunnels towards the core\n" + "The Network Instance as a dotted string. The string is transmitted in the length-byte-and-string" + " format common to APN and DNS, so this typically is a domain name. See 3GPP TS 29.244 8.2.4.\n") +{ + const char *access_or_core = argv[0]; + char **str; + if (!strcmp(access_or_core, "access")) + str = &g_hnbgw->config.pfcp.netinst.access; + else + str = &g_hnbgw->config.pfcp.netinst.core; + osmo_talloc_replace_string(g_hnbgw, str, argv[1]); + LOGP(DLPFCP, LOGL_NOTICE, "cfg: pfcp netinst %s %s\n", access_or_core, *str); + return CMD_SUCCESS; +} + #endif /* ENABLE_PFCP */ DEFUN_DEPRECATED(cfg_hnbgw_timer_ps, cfg_hnbgw_timer_ps_cmd, @@ -949,6 +969,12 @@ vty_out(vty, " local-port %u%s", g_hnbgw->config.pfcp.local_port, VTY_NEWLINE); if (g_hnbgw->config.pfcp.remote_addr) vty_out(vty, " remote-addr %s%s", g_hnbgw->config.pfcp.remote_addr, VTY_NEWLINE); + if (g_hnbgw->config.pfcp.netinst.access + && *g_hnbgw->config.pfcp.netinst.access) + vty_out(vty, " netinst access %s%s", g_hnbgw->config.pfcp.netinst.access, VTY_NEWLINE); + if (g_hnbgw->config.pfcp.netinst.core + && *g_hnbgw->config.pfcp.netinst.core) + vty_out(vty, " netinst core %s%s", g_hnbgw->config.pfcp.netinst.core, VTY_NEWLINE); return CMD_SUCCESS; } @@ -1019,6 +1045,7 @@ install_element(PFCP_NODE, &cfg_pfcp_local_addr_cmd); install_element(PFCP_NODE, &cfg_pfcp_local_port_cmd); install_element(PFCP_NODE, &cfg_pfcp_remote_addr_cmd); + install_element(PFCP_NODE, &cfg_pfcp_netinst_cmd); #endif osmo_tdef_vty_groups_init(HNBGW_NODE, hnbgw_tdef_group); diff --git a/src/osmo-hnbgw/ps_rab_fsm.c b/src/osmo-hnbgw/ps_rab_fsm.c index 512c983..82e4f30 100644 --- a/src/osmo-hnbgw/ps_rab_fsm.c +++ b/src/osmo-hnbgw/ps_rab_fsm.c @@ -199,6 +199,13 @@ return rab; } +#define set_netinst(NETINST_MEMBER, STRING) do { \ + if ((STRING) && *(STRING)) { \ + NETINST_MEMBER##_present = true; \ + OSMO_STRLCPY_ARRAY(NETINST_MEMBER.str, STRING); \ + } \ + } while (0) + /* Add two PDR and two FAR to the PFCP Session Establishment Request message, according to the information found in rab. */ static int rab_to_pfcp_session_est_req(struct osmo_pfcp_msg_session_est_req *ser, struct ps_rab *rab) @@ -234,6 +241,7 @@ .far_id_present = true, .far_id = ID_CORE_TO_ACCESS, }; + set_netinst(ser->create_pdr[ser->create_pdr_count].pdi.network_inst, g_hnbgw->config.pfcp.netinst.core); ser->create_pdr_count++; ser->create_far[ser->create_far_count] = (struct osmo_pfcp_ie_create_far){ @@ -268,6 +276,7 @@ .far_id_present = true, .far_id = ID_ACCESS_TO_CORE, }; + set_netinst(ser->create_pdr[ser->create_pdr_count].pdi.network_inst, g_hnbgw->config.pfcp.netinst.access); ser->create_pdr_count++; ser->create_far[ser->create_far_count] = (struct osmo_pfcp_ie_create_far){ @@ -288,6 +297,7 @@ OSMO_PFCP_OUTER_HEADER_CREATION_GTP_U_UDP_IPV4, true); osmo_pfcp_bits_set(ser->create_far[ser->create_far_count].apply_action.bits, OSMO_PFCP_APPLY_ACTION_FORW, true); + set_netinst(ser->create_far[ser->create_far_count].forw_params.network_inst, g_hnbgw->config.pfcp.netinst.core); ser->create_far_count++; return 0; @@ -484,7 +494,8 @@ /* Add an Update FAR to the PFCP Session Modification Request message, updating a remote F-TEID. */ static int rab_to_pfcp_session_mod_req_upd_far(struct osmo_pfcp_msg_session_mod_req *smr, - uint32_t far_id, const struct addr_teid *remote_f_teid) + uint32_t far_id, const struct addr_teid *remote_f_teid, + const char *far_netinst) { if (smr->upd_far_count + 1 > ARRAY_SIZE(smr->upd_far)) return -1; @@ -509,6 +520,7 @@ OSMO_PFCP_APPLY_ACTION_FORW, true); osmo_pfcp_bits_set(smr->upd_far[smr->upd_far_count].upd_forw_params.outer_header_creation.desc_bits, OSMO_PFCP_OUTER_HEADER_CREATION_GTP_U_UDP_IPV4, true); + set_netinst(smr->upd_far[smr->upd_far_count].upd_forw_params.network_inst, far_netinst); smr->upd_far_count++; return 0; @@ -532,7 +544,8 @@ m = ps_rab_new_pfcp_msg_req(rab, OSMO_PFCP_MSGT_SESSION_MOD_REQ); - if (rab_to_pfcp_session_mod_req_upd_far(&m->ies.session_mod_req, ID_CORE_TO_ACCESS, &rab->access.remote)) { + if (rab_to_pfcp_session_mod_req_upd_far(&m->ies.session_mod_req, ID_CORE_TO_ACCESS, &rab->access.remote, + g_hnbgw->config.pfcp.netinst.access)) { LOG_PS_RAB(rab, LOGL_ERROR, "error composing Update FAR IE in PFCP msg\n"); ps_rab_failure(rab); return; diff --git a/tests/pfcp_cfg.vty.with_pfcp b/tests/pfcp_cfg.vty.with_pfcp index 44b922c..68c8281 100644 --- a/tests/pfcp_cfg.vty.with_pfcp +++ b/tests/pfcp_cfg.vty.with_pfcp @@ -15,6 +15,7 @@ local-addr IP_ADDR local-port <1-65535> remote-addr IP_ADDR + netinst (access|core) NAME OsmoHNBGW(config-hnbgw-pfcp)# local-addr? local-addr Local address for PFCP @@ -31,6 +32,15 @@ OsmoHNBGW(config-hnbgw-pfcp)# remote-addr ? IP_ADDR IP address +OsmoHNBGW(config-hnbgw-pfcp)# netinst? + netinst Add a Network Instance IE to all outgoing PFCP rule sets, so that the UPF may choose the correct interface to open GTP tunnels on. +OsmoHNBGW(config-hnbgw-pfcp)# netinst ? + access configure the Network Instance name sent in PFCP to create tunnels towards Access = the RNC = RAN + core configure the Network Instance name sent in PFCP to create tunnels towards the core + +OsmoHNBGW(config-hnbgw-pfcp)# netinst access ? + NAME The Network Instance as a dotted string. The string is transmitted in the length-byte-and-string format common to APN and DNS, so this typically is a domain name. See 3GPP TS 29.244 8.2.4. + OsmoHNBGW(config-hnbgw-pfcp)# show running-config ... @@ -43,6 +53,8 @@ OsmoHNBGW(config-hnbgw-pfcp)# remote-addr 127.0.0.2 OsmoHNBGW(config-hnbgw-pfcp)# local-addr 127.0.0.1 OsmoHNBGW(config-hnbgw-pfcp)# local-port 8805 +OsmoHNBGW(config-hnbgw-pfcp)# netinst access ran.net +OsmoHNBGW(config-hnbgw-pfcp)# netinst core core.net OsmoHNBGW(config-hnbgw-pfcp)# show running-config ... @@ -52,5 +64,7 @@ local-addr 127.0.0.1 local-port 8805 remote-addr 127.0.0.2 + netinst access ran.net + netinst core core.net msc 0 ... -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/35645?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: Ief53dbfacf1645c32a07847d590c4884d4c8ca56 Gerrit-Change-Number: 35645 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[S] Change in osmocom-bb[master]: mobile: handle V.24 line status updates from V.110 TA
by fixeria 20 Jan '24

20 Jan '24
Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmocom-bb/+/35640?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder Change subject: mobile: handle V.24 line status updates from V.110 TA ...................................................................... mobile: handle V.24 line status updates from V.110 TA Change-Id: I05ba2e10fefe3cae687831b5ced971aa244ad336 Related: OS#4396 --- M src/host/layer23/src/mobile/tch_data.c 1 file changed, 36 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/40/35640/2 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35640?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I05ba2e10fefe3cae687831b5ced971aa244ad336 Gerrit-Change-Number: 35640 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-MessageType: newpatchset
1 0
0 0
[S] Change in osmocom-bb[master]: mobile: handle V.24 line status updates from V.110 TA
by fixeria 20 Jan '24

20 Jan '24
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmocom-bb/+/35640?usp=email ) Change subject: mobile: handle V.24 line status updates from V.110 TA ...................................................................... mobile: handle V.24 line status updates from V.110 TA Change-Id: I05ba2e10fefe3cae687831b5ced971aa244ad336 Related: OS#4396 --- M src/host/layer23/src/mobile/tch_data.c 1 file changed, 35 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/40/35640/1 diff --git a/src/host/layer23/src/mobile/tch_data.c b/src/host/layer23/src/mobile/tch_data.c index 6ee89dc..920fd38 100644 --- a/src/host/layer23/src/mobile/tch_data.c +++ b/src/host/layer23/src/mobile/tch_data.c @@ -187,11 +187,34 @@ osmo_soft_uart_tx_ubits(state->suart, buf, buf_size); } +static const struct tch_v110_circuit_map_item { + enum osmo_v110_ta_circuit c; + enum osmo_soft_uart_status s; +} tch_v110_circuit_map[] = { + { OSMO_V110_TA_C_106, OSMO_SUART_STATUS_F_CTS }, + { OSMO_V110_TA_C_107, OSMO_SUART_STATUS_F_DSR }, + { OSMO_V110_TA_C_109, OSMO_SUART_STATUS_F_DCD }, +}; + static void tch_v110_ta_status_update_cb(void *priv, unsigned int status) { - LOGP(DL1C, LOGL_DEBUG, "%s(): [status=0x%08x]\n", __func__, status); + const struct tch_data_state *state = (struct tch_data_state *)priv; - /* TODO: update status lines of the soft-UART (if state.suart != NULL) */ + LOGP(DL1C, LOGL_DEBUG, "V.110 TA status mask=0x%08x\n", status); + + for (unsigned int i = 0; i < ARRAY_SIZE(tch_v110_circuit_map); i++) { + const struct tch_v110_circuit_map_item *item = &tch_v110_circuit_map[i]; + bool is_on = (status & (1 << item->c)) != 0; + + LOGP(DL1C, LOGL_NOTICE, "V.110 TA circuit %s (%s) is %s\n", + osmo_v110_ta_circuit_name(item->c), + osmo_v110_ta_circuit_desc(item->c), + is_on ? "ON" : "OFF"); + + /* update status lines of the soft-UART */ + if (state->suart != NULL) + osmo_soft_uart_set_status_line(state->suart, item->s, is_on); + } } struct osmo_v110_ta *tch_v110_ta_alloc(struct osmocom_ms *ms, -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35640?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I05ba2e10fefe3cae687831b5ced971aa244ad336 Gerrit-Change-Number: 35640 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[M] Change in libosmocore[master]: isdn/v110_ta: avoid redundant .status_update_cb() calls
by fixeria 20 Jan '24

20 Jan '24
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/35639?usp=email ) Change subject: isdn/v110_ta: avoid redundant .status_update_cb() calls ...................................................................... isdn/v110_ta: avoid redundant .status_update_cb() calls Let's be smarter and call the status update callback iff the V.24 flagmask was actually changed. Change-Id: I9626d3e737d4e072fa163115c4cdf9ee6ee0968e Related: OS#4396 --- M src/isdn/v110_ta.c M tests/v110/ta_test.err 2 files changed, 44 insertions(+), 36 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/39/35639/1 diff --git a/src/isdn/v110_ta.c b/src/isdn/v110_ta.c index 7757dcc..6730b20 100644 --- a/src/isdn/v110_ta.c +++ b/src/isdn/v110_ta.c @@ -247,12 +247,15 @@ } } -static void v110_ta_flags_updated(const struct osmo_v110_ta *ta) +static void v110_ta_flags_update(struct osmo_v110_ta *ta, unsigned int v24_flags) { - const struct osmo_v110_ta_cfg *cfg = ta->cfg; + struct osmo_v110_ta_cfg *cfg = ta->cfg; + if (ta->state.v24_flags == v24_flags) + return; if (cfg->status_update_cb != NULL) - cfg->status_update_cb(cfg->priv, ta->state.v24_flags); + cfg->status_update_cb(cfg->priv, v24_flags); + ta->state.v24_flags = v24_flags; } static const struct osmo_tdef_state_timeout v110_ta_fsm_timeouts[32] = { @@ -272,6 +275,7 @@ { struct osmo_v110_ta *ta = (struct osmo_v110_ta *)fi->priv; struct v110_ta_state *ts = &ta->state; + unsigned int v24_flags = ta->state.v24_flags; /* 7.1.1.2 During the idle (or ready) state the TA will transmit continuous binary 1s into the B-channel */ ts->tx.d_bit_mode = V110_TA_DBIT_M_ALL_ONE; /* circuit 103: continuous binary '1' */ @@ -282,10 +286,10 @@ /* - circuit 104: continuous binary '1' */ ts->rx.d_bit_mode = V110_TA_DBIT_M_ALL_ONE; /* - circuits 107, 106, 109 = OFF */ - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_106); - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_107); - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_109); - v110_ta_flags_updated(ta); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_106); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_107); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_109); + v110_ta_flags_update(ta, v24_flags); } /* ITU-T V.110 Section 7.1.1 */ @@ -354,24 +358,25 @@ case V110_TA_EV_RX_FRAME_IND: { const struct osmo_v110_decoded_frame *df = data; + unsigned int v24_flags = ta->state.v24_flags; /* 7.1.2.4 When the receiver recognizes that the status of bits S and X are ON */ if (v110_df_s_bits_are(df, V110_SX_BIT_ON) && v110_df_x_bits_are(df, V110_SX_BIT_ON)) { /* ... it will perform the following functions: */ /* a) Turn ON circuit 107 toward the DTE and stop timer T1 */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_107); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_107); osmo_timer_del(&fi->timer); /* b) Then, circuit 103 may be connected to the data bits in the frame; however, the * DTE must maintain a binary 1 condition on circuit 103 until circuit 106 is turned * ON in the next portion of the sequence. */ /* c) Turn ON circuit 109 and connect the data bits to circuit 104. */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_109); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_109); ts->rx.d_bit_mode = V110_TA_DBIT_M_FORWARD; /* d) After an interval of N bits (see 6.3), it will turn ON circuit 106. */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_106); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_106); ts->tx.d_bit_mode = V110_TA_DBIT_M_FORWARD; - v110_ta_flags_updated(ta); + v110_ta_flags_update(ta, v24_flags); /* Circuit 106 transitioning from OFF to ON will cause the transmitted data to * transition from binary 1 to the data mode. */ v110_ta_fsm_state_chg(V110_TA_ST_DATA_TRANSFER); @@ -396,13 +401,14 @@ { struct osmo_v110_ta *ta = (struct osmo_v110_ta *)fi->priv; struct v110_ta_state *ts = &ta->state; + unsigned int v24_flags = ta->state.v24_flags; /* 7.1.3.1 While in the data transfer state, the following circuit conditions exist: * a): 105, 107, 108, and 109 are in the ON condition */ /* XXX: OSMO_ASSERT(V24_FLAGMASK_IS_ON(ts->v24_flags, OSMO_V110_TA_C_105)); */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_107); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_107); /* XXX: OSMO_ASSERT(V24_FLAGMASK_IS_ON(ts->v24_flags, OSMO_V110_TA_C_108)); */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_109); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_109); /* b) data is being transmitted on circuit 103 and received on circuit 104 */ ts->rx.d_bit_mode = V110_TA_DBIT_M_FORWARD; ts->tx.d_bit_mode = V110_TA_DBIT_M_FORWARD; @@ -410,9 +416,9 @@ * flow control is being used, either or both circuits may be in the ON or the OFF condition. */ if (!ta->cfg->flow_ctrl.end_to_end) { /* XXX: OSMO_ASSERT(V24_FLAGMASK_IS_ON(ts->v24_flags, OSMO_V110_TA_C_133)); */ - V24_FLAGMASK_SET_ON(ts->v24_flags, OSMO_V110_TA_C_106); + V24_FLAGMASK_SET_ON(v24_flags, OSMO_V110_TA_C_106); } - v110_ta_flags_updated(ta); + v110_ta_flags_update(ta, v24_flags); /* 7.1.3.2 While in the data transfer state, the following status bit conditions exist: */ /* a) status bits S in both directions are in the ON condition; */ @@ -453,14 +459,15 @@ case V110_TA_EV_RX_FRAME_IND: { const struct osmo_v110_decoded_frame *df = data; + unsigned int v24_flags = ta->state.v24_flags; /* 7.1.4.2 ... this TA will recognize the transition of the status bits S from * ON to OFF and the data bits from data to binary 0 as a disconnect request */ if (v110_df_s_bits_are(df, V110_SX_BIT_OFF) && v110_df_d_bits_are(df, 0)) { /* ... and it will turn OFF circuits 107 and 109. */ - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_107); - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_109); - v110_ta_flags_updated(ta); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_107); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_109); + v110_ta_flags_update(ta, v24_flags); /* DTE should respond by turning OFF circuit 108 */ break; /* XXX: shall we forward D-bits to DTE anyway? */ } @@ -478,14 +485,15 @@ { struct osmo_v110_ta *ta = (struct osmo_v110_ta *)fi->priv; struct v110_ta_state *ts = &ta->state; + unsigned int v24_flags = ta->state.v24_flags; /* 7.1.4.1 At the completion of the data transfer phase, the local DTE will indicate a * disconnect request by turning OFF circuit 108. This will cause the following to occur: */ /* a) the status bits S in the frame toward ISDN will turn OFF, status bits X are kept ON */ ts->tx.s_bits = V110_SX_BIT_OFF; /* b) circuit 106 will be turned OFF */ - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_106); - v110_ta_flags_updated(ta); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_106); + v110_ta_flags_update(ta, v24_flags); /* c) the data bits in the frame will be set to binary 0. */ ts->tx.d_bit_mode = V110_TA_DBIT_M_ALL_ZERO; @@ -554,6 +562,7 @@ { struct osmo_v110_ta *ta = (struct osmo_v110_ta *)fi->priv; struct v110_ta_state *ts = &ta->state; + unsigned int v24_flags = ta->state.v24_flags; switch (event) { case V110_TA_EV_V24_STATUS_CHG: @@ -575,8 +584,8 @@ ts->tx.x_bits = V110_SX_BIT_OFF; ts->tx.d_bit_mode = V110_TA_DBIT_M_ALL_ZERO; /* TODO: actually Tx those frames (delay state transition) */ - V24_FLAGMASK_SET_OFF(ts->v24_flags, OSMO_V110_TA_C_107); - v110_ta_flags_updated(ta); + V24_FLAGMASK_SET_OFF(v24_flags, OSMO_V110_TA_C_107); + v110_ta_flags_update(ta, v24_flags); v110_ta_fsm_state_chg(V110_TA_ST_DISCONNECTING); break; default: diff --git a/tests/v110/ta_test.err b/tests/v110/ta_test.err index 347f8f6..e8f80e6 100644 --- a/tests/v110/ta_test.err +++ b/tests/v110/ta_test.err @@ -2,7 +2,6 @@ ==== Running test_idle_ready() DLGLOBAL DEBUG V110-TA(test_idle_ready){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_idle_ready){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) Initial status: 0x00000000 circuit 106/CTS (Clear to Send) is OFF (expected to be OFF) circuit 107/DSR (Data Set Ready) is OFF (expected to be OFF) @@ -29,7 +28,6 @@ setting circuit 108/DTR (Data Terminal Ready) OFF DLGLOBAL DEBUG V110-TA(test_idle_ready){CONNECT_TA_TO_LINE}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_idle_ready){CONNECT_TA_TO_LINE}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) osmo_v110_ta_set_circuit() returns 0 setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_idle_ready){IDLE_READY}: Received Event V24_STATUS_CHG @@ -40,7 +38,6 @@ ==== Running test_conn_ta_line() DLGLOBAL DEBUG V110-TA(test_conn_ta_line){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_conn_ta_line){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_conn_ta_line){IDLE_READY}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_conn_ta_line){IDLE_READY}: State change to CONNECT_TA_TO_LINE (T1, 10s) @@ -79,7 +76,6 @@ DLGLOBAL DEBUG V110-TA(test_conn_ta_line){CONNECT_TA_TO_LINE}: Received Event RX_FRAME_IND v110_ta_test_status_update_cb(status=0x0000001e) DLGLOBAL DEBUG V110-TA(test_conn_ta_line){CONNECT_TA_TO_LINE}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) v110_ta_test_rx_cb(buf_size=48): 010101010101010101010101010101010101010101010101 osmo_v110_ta_frame_in() returns 0 DLGLOBAL DEBUG V110-TA(test_conn_ta_line){DATA_TRANSFER}: Deallocated @@ -87,7 +83,6 @@ ==== Running test_data_transfer() DLGLOBAL DEBUG V110-TA(test_data_transfer){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_data_transfer){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_data_transfer){IDLE_READY}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_data_transfer){IDLE_READY}: State change to CONNECT_TA_TO_LINE (T1, 10s) @@ -102,7 +97,6 @@ DLGLOBAL DEBUG V110-TA(test_data_transfer){CONNECT_TA_TO_LINE}: Received Event RX_FRAME_IND v110_ta_test_status_update_cb(status=0x0000001e) DLGLOBAL DEBUG V110-TA(test_data_transfer){CONNECT_TA_TO_LINE}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) v110_ta_test_rx_cb(buf_size=48): 010101010101010101010101010101010101010101010101 osmo_v110_ta_frame_in() returns 0 circuit 106/CTS (Clear to Send) is ON (expected to be ON) @@ -127,7 +121,6 @@ ==== Running test_data_transfer_disc_local() DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){IDLE_READY}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){IDLE_READY}: State change to CONNECT_TA_TO_LINE (T1, 10s) @@ -142,7 +135,6 @@ DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){CONNECT_TA_TO_LINE}: Received Event RX_FRAME_IND v110_ta_test_status_update_cb(status=0x0000001e) DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_local){CONNECT_TA_TO_LINE}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) v110_ta_test_rx_cb(buf_size=48): 010101010101010101010101010101010101010101010101 osmo_v110_ta_frame_in() returns 0 local TE initiates disconnection @@ -189,7 +181,6 @@ ==== Running test_data_transfer_disc_remote() DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){IDLE_READY}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){IDLE_READY}: State change to CONNECT_TA_TO_LINE (T1, 10s) @@ -204,7 +195,6 @@ DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){CONNECT_TA_TO_LINE}: Received Event RX_FRAME_IND v110_ta_test_status_update_cb(status=0x0000001e) DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){CONNECT_TA_TO_LINE}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) v110_ta_test_rx_cb(buf_size=48): 010101010101010101010101010101010101010101010101 osmo_v110_ta_frame_in() returns 0 remote TE initiates disconnection @@ -227,7 +217,6 @@ osmo_v110_ta_set_circuit() returns 0 DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){DISCONNECTING}: Received Event DESYNC_IND DLGLOBAL DEBUG V110-TA(test_data_transfer_disc_remote){DISCONNECTING}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) circuit 106/CTS (Clear to Send) is OFF (expected to be OFF) circuit 107/DSR (Data Set Ready) is OFF (expected to be OFF) circuit 109/DCD (Data Carrier Detect) is OFF (expected to be OFF) @@ -236,7 +225,6 @@ ==== Running test_syncing() DLGLOBAL DEBUG V110-TA(test_syncing){IDLE_READY}: Allocated DLGLOBAL DEBUG V110-TA(test_syncing){IDLE_READY}: State change to IDLE_READY (no timeout) -v110_ta_test_status_update_cb(status=0x00000000) setting circuit 108/DTR (Data Terminal Ready) ON DLGLOBAL DEBUG V110-TA(test_syncing){IDLE_READY}: Received Event V24_STATUS_CHG DLGLOBAL DEBUG V110-TA(test_syncing){IDLE_READY}: State change to CONNECT_TA_TO_LINE (T1, 10s) @@ -251,7 +239,6 @@ DLGLOBAL DEBUG V110-TA(test_syncing){CONNECT_TA_TO_LINE}: Received Event RX_FRAME_IND v110_ta_test_status_update_cb(status=0x0000001e) DLGLOBAL DEBUG V110-TA(test_syncing){CONNECT_TA_TO_LINE}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) v110_ta_test_rx_cb(buf_size=48): 010101010101010101010101010101010101010101010101 osmo_v110_ta_frame_in() returns 0 osmo_v110_ta_sync_ind(): the lower layer indicates out-of-sync event @@ -270,7 +257,6 @@ osmo_v110_ta_sync_ind(): the lower layer indicates sync event DLGLOBAL DEBUG V110-TA(test_syncing){RESYNCING}: Received Event SYNC_IND DLGLOBAL DEBUG V110-TA(test_syncing){RESYNCING}: State change to DATA_TRANSFER (no timeout) -v110_ta_test_status_update_cb(status=0x0000001e) osmo_v110_ta_frame_out(): S-bits are expected to be 0 (ON) osmo_v110_ta_frame_out(): X-bits are expected to be 0 (ON) osmo_v110_ta_frame_out(): D-bits are to be set by .tx_cb() -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35639?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: I9626d3e737d4e072fa163115c4cdf9ee6ee0968e Gerrit-Change-Number: 35639 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[L] Change in osmocom-bb[master]: mobile: implement sending CSD data over UNIX socket
by pespin 20 Jan '24

20 Jan '24
Attention is currently required from: fixeria, laforge, osmith. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/35583?usp=email ) Change subject: mobile: implement sending CSD data over UNIX socket ...................................................................... Patch Set 7: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35583?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: Id054af7b3d9d0a41715f7981deb420f6e09bf30c Gerrit-Change-Number: 35583 Gerrit-PatchSet: 7 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Sat, 20 Jan 2024 00:48:51 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment
1 0
0 0
[S] Change in osmocom-bb[master]: mobile: fix unsupported data rate (UR/IR) messages
by pespin 20 Jan '24

20 Jan '24
Attention is currently required from: fixeria. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/35638?usp=email ) Change subject: mobile: fix unsupported data rate (UR/IR) messages ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35638?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I4f68cc999cb7bf9c5a17c8650de0411248420c1e Gerrit-Change-Number: 35638 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Sat, 20 Jan 2024 00:47:11 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment
1 0
0 0
[L] Change in osmocom-bb[master]: mobile: implement sending CSD data over UNIX socket
by fixeria 20 Jan '24

20 Jan '24
Attention is currently required from: laforge, osmith. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/35583?usp=email ) Change subject: mobile: implement sending CSD data over UNIX socket ...................................................................... Set Ready For Review -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35583?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: Id054af7b3d9d0a41715f7981deb420f6e09bf30c Gerrit-Change-Number: 35583 Gerrit-PatchSet: 7 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Sat, 20 Jan 2024 00:37:12 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment
1 0
0 0
[S] Change in osmocom-bb[master]: mobile: fix unsupported data rate (UR/IR) messages
by fixeria 20 Jan '24

20 Jan '24
fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmocom-bb/+/35638?usp=email ) Change subject: mobile: fix unsupported data rate (UR/IR) messages ...................................................................... mobile: fix unsupported data rate (UR/IR) messages Change-Id: I4f68cc999cb7bf9c5a17c8650de0411248420c1e Related: OS#4396 --- M src/host/layer23/src/mobile/mnccms.c M src/host/layer23/src/mobile/tch_data.c 2 files changed, 14 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/38/35638/1 diff --git a/src/host/layer23/src/mobile/mnccms.c b/src/host/layer23/src/mobile/mnccms.c index 8427191..c03eed5 100644 --- a/src/host/layer23/src/mobile/mnccms.c +++ b/src/host/layer23/src/mobile/mnccms.c @@ -409,8 +409,8 @@ break; default: LOGP(DMNCC, LOGL_ERROR, - "%s(): User rate 0x%02x (octets 6a) is not supported (IR=0x%02x)\n", - __func__, bcap->data.user_rate, bcap->data.interm_rate); + "%s(): IR 0x%02x / UR 0x%02x combination is not supported\n", + __func__, bcap->data.interm_rate, bcap->data.user_rate); return -ENOTSUP; } diff --git a/src/host/layer23/src/mobile/tch_data.c b/src/host/layer23/src/mobile/tch_data.c index c58f485..6ee89dc 100644 --- a/src/host/layer23/src/mobile/tch_data.c +++ b/src/host/layer23/src/mobile/tch_data.c @@ -234,8 +234,8 @@ case BCAP_RATE(GSM48_BCAP_IR_8k, GSM48_BCAP_UR_300): default: LOGP(DCC, LOGL_ERROR, - "%s(): User rate 0x%02x (octets 6a) is not supported (IR=0x%02x)\n", - __func__, bcap->data.user_rate, bcap->data.interm_rate); + "%s(): IR 0x%02x / UR 0x%02x combination is not supported\n", + __func__, bcap->data.interm_rate, bcap->data.user_rate); return NULL; } -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/35638?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I4f68cc999cb7bf9c5a17c8650de0411248420c1e Gerrit-Change-Number: 35638 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • ...
  • 156
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.