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 -----
  • November
  • 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

June 2023

  • 1 participants
  • 2480 discussions
[M] Change in osmo-bts[master]: ECU in UL path: move state alloc/free to l1sap
by falconia 27 Jun '23

27 Jun '23
falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/33470 ) Change subject: ECU in UL path: move state alloc/free to l1sap ...................................................................... ECU in UL path: move state alloc/free to l1sap In preparation for moving the now-optional application of ECU in UL path from osmo-bts-trx model-specific code to the common layer, move ECU state allocation and freeing from trx model to l1sap. Related: OS#6040 Change-Id: Ic98a2eb26b5a99bc4a89ad07ae87c9a86b921418 --- M src/common/l1sap.c M src/osmo-bts-trx/l1_if.c 2 files changed, 40 insertions(+), 20 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/70/33470/1 diff --git a/src/common/l1sap.c b/src/common/l1sap.c index 528a735..981d3bc 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -2208,6 +2208,13 @@ if (rc) return -RSL_ERR_EQUIPMENT_FAIL; + /* Is it TCH? If it is, attempt to allocate an Error Concealment Unit + * instance, if available, unless it is disabled by vty config. */ + if (lchan_is_tch(lchan) && trx->bts->use_ul_ecu) + lchan->ecu_state = osmo_ecu_init(trx, lchan2ecu_codec(lchan)); + else + lchan->ecu_state = NULL; + /* Init DTX DL FSM if necessary */ if (trx->bts->dtxd && lchan_is_tch(lchan)) { lchan->tch.dtx.dl_amr_fsm = osmo_fsm_inst_alloc(&dtx_dl_amr_fsm, @@ -2248,6 +2255,12 @@ lchan->tch.dtx.dl_amr_fsm = NULL; } + /* clear ECU state (if any) */ + if (lchan->ecu_state) { + osmo_ecu_destroy(lchan->ecu_state); + lchan->ecu_state = NULL; + } + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0); } @@ -2270,5 +2283,18 @@ LOGPLCHAN(lchan, DL1C, LOGL_INFO, "Modifying channel %s\n", rsl_chan_nr_str(chan_nr)); + /* Is it TCH? If it is and we are applying internal uplink ECUs, + * the new channel mode calls for a different ECU. Any changes + * in vty config (enabling or disabling this ECU application) + * will also take effect upon channel modification. */ + if (lchan_is_tch(lchan)) { + if (lchan->ecu_state) + osmo_ecu_destroy(lchan->ecu_state); + if (trx->bts->use_ul_ecu) + lchan->ecu_state = osmo_ecu_init(trx, lchan2ecu_codec(lchan)); + else + lchan->ecu_state = NULL; + } + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_MODIFY, 0); } diff --git a/src/osmo-bts-trx/l1_if.c b/src/osmo-bts-trx/l1_if.c index 69ee117..60f9232 100644 --- a/src/osmo-bts-trx/l1_if.c +++ b/src/osmo-bts-trx/l1_if.c @@ -439,14 +439,6 @@ break; } - /* Attempt to allocate an Error Concealment Unit - * instance, if available, unless it is disabled - * by the vty config. */ - if (trx->bts->use_ul_ecu) - lchan->ecu_state = osmo_ecu_init(trx, lchan2ecu_codec(lchan)); - else - lchan->ecu_state = NULL; - /* activate dedicated channel */ trx_sched_set_lchan(lchan, chan_nr, LID_DEDIC, true); /* activate associated channel */ @@ -475,13 +467,6 @@ mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_ACTIVATE, 0); break; case PRIM_INFO_MODIFY: - /* ECU for possibly new codec */ - if (lchan->ecu_state) - osmo_ecu_destroy(lchan->ecu_state); - if (trx->bts->use_ul_ecu) - lchan->ecu_state = osmo_ecu_init(trx, lchan2ecu_codec(lchan)); - else - lchan->ecu_state = NULL; /* change mode */ trx_sched_set_mode(lchan->ts, chan_nr, lchan->rsl_cmode, lchan->tch_mode, @@ -507,11 +492,6 @@ rc = -EPERM; break; } - /* clear ECU state (if any) */ - if (lchan->ecu_state) { - osmo_ecu_destroy(lchan->ecu_state); - lchan->ecu_state = NULL; - } /* deactivate associated channel */ bts_model_lchan_deactivate_sacch(lchan); if (!l1sap->u.info.u.act_req.sacch_only) { -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/33470 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Ic98a2eb26b5a99bc4a89ad07ae87c9a86b921418 Gerrit-Change-Number: 33470 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-MessageType: newchange
1 0
0 0
[M] Change in osmo-bts[master]: ECU in UL path: move it from trx model to l1sap
by falconia 27 Jun '23

27 Jun '23
falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/33471 ) Change subject: ECU in UL path: move it from trx model to l1sap ...................................................................... ECU in UL path: move it from trx model to l1sap With this change the application of ECU in the uplink path becomes consistent across all OsmoBTS models, enabled or disabled per vty config setting "rtp internal-uplink-ecu". An additional behavioral change from the previous trx-model-only implementation is that ECU insertion is now done after the link quality check in l1sap, thereby fixing the bug where this quality check would sometimes suppress ECU output and replace it with BFI markers in RTP. In the new implementation when the internal ECU is enabled and available for the selected codec (currently FRv1 only), the RTP output will gap (standard representation of BFI in RTP) only during DTXu pauses as indicated by a received SID frame (either valid or invalid), and the SID frame that triggers the switch from ECU mode into pause mode is reliably emitted in RTP. Related: OS#6040 Change-Id: Iac577975c9ab50cb8ebbc035c661c1880e7cecec --- M src/common/l1sap.c M src/osmo-bts-trx/sched_lchan_tchf.c M src/osmo-bts-trx/sched_lchan_tchh.c 3 files changed, 79 insertions(+), 69 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/71/33471/1 diff --git a/src/common/l1sap.c b/src/common/l1sap.c index 981d3bc..d116add 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -1813,6 +1813,52 @@ send_ul_rtp_packet(lchan, fn, msg->data, msg->len); } +/* A helper function for l1sap_tch_ind(): handling BFI + * + * Please note that we pass the msgb to this function, even though it is + * currently not used. This msgb passing is a provision for adding + * support for TRAU-UL-like RTP payload formats like TW-TS-001 that allow + * indicating BFI along with deemed-bad frame data bits, just like + * GSM 08.60 and 08.61 TRAU-UL frames. + */ +static void tch_ul_bfi_handler(struct gsm_lchan *lchan, uint32_t fn, + struct msgb *msg) +{ + struct gsm_time g_time; + uint8_t ecu_out[GSM_FR_BYTES]; + int rc; + + /* Are we applying an ECU to this uplink, and are we in a state + * (not DTX pause) where we emit ECU output? */ + if (lchan->ecu_state && !osmo_ecu_is_dtx_pause(lchan->ecu_state)) { + rc = osmo_ecu_frame_out(lchan->ecu_state, ecu_out); + /* did it actually give us some output? */ + if (rc > 0) { + /* yes, send it out in RTP */ + send_ul_rtp_packet(lchan, fn, ecu_out, rc); + return; + } + } + + /* Are we in rtp continuous-streaming special mode? If so, send out + * a BFI packet as zero-length RTP payload. */ + if (lchan->ts->trx->bts->rtp_nogaps_mode) { + send_ul_rtp_packet(lchan, fn, NULL, 0); + return; + } + + /* Most classic form of BFI handling: generate an intentional gap + * in the outgoing RTP stream. */ + gsm_fn2gsmtime(&g_time, fn); + LOGPLCGT(lchan, &g_time, DRTP, LOGL_DEBUG, + "Skipping RTP frame with lost payload\n"); + if (lchan->abis_ip.osmux.use) + lchan_osmux_skipped_frame(lchan, fn_ms_adj(fn, lchan)); + else if (lchan->abis_ip.rtp_socket) + osmo_rtp_skipped_frame(lchan->abis_ip.rtp_socket, fn_ms_adj(fn, lchan)); + lchan->rtp_tx_marker = true; +} + /* TCH received from bts model */ static int l1sap_tch_ind(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap, struct ph_tch_param *tch_ind) @@ -1851,6 +1897,9 @@ * available is expected as empty payload. We also check if quality is * good enough. */ if (msg->len && tch_ind->lqual_cb >= bts->min_qual_norm) { + /* feed the good frame to the ECU, if we are applying one */ + if (lchan->ecu_state) + osmo_ecu_frame_in(lchan->ecu_state, false, msg->data, msg->len); /* hand msg to RTP code for transmission */ if (bts->emit_hr_rfc5993 && lchan->type == GSM_LCHAN_TCH_H && lchan->tch_mode == GSM48_CMODE_SPEECH_V1) @@ -1865,19 +1914,7 @@ return 1; } } else { - /* Are we in rtp continuous-streaming special mode? If so, send - * out a BFI packet as zero-length RTP payload. */ - if (bts->rtp_nogaps_mode) { - send_ul_rtp_packet(lchan, fn, NULL, 0); - } else { - LOGPLCGT(lchan, &g_time, DRTP, LOGL_DEBUG, - "Skipping RTP frame with lost payload (chan_nr=0x%02x)\n", chan_nr); - if (lchan->abis_ip.osmux.use) - lchan_osmux_skipped_frame(lchan, fn_ms_adj(fn, lchan)); - else if (lchan->abis_ip.rtp_socket) - osmo_rtp_skipped_frame(lchan->abis_ip.rtp_socket, fn_ms_adj(fn, lchan)); - lchan->rtp_tx_marker = true; - } + tch_ul_bfi_handler(lchan, fn, msg); } lchan->tch.last_fn = fn; diff --git a/src/osmo-bts-trx/sched_lchan_tchf.c b/src/osmo-bts-trx/sched_lchan_tchf.c index 0b709bc..9acbf31 100644 --- a/src/osmo-bts-trx/sched_lchan_tchf.c +++ b/src/osmo-bts-trx/sched_lchan_tchf.c @@ -30,7 +30,6 @@ #include <osmocom/gsm/gsm0502.h> #include <osmocom/codec/codec.h> -#include <osmocom/codec/ecu.h> #include <osmocom/coding/gsm0503_coding.h> #include <osmocom/coding/gsm0503_amr_dtx.h> @@ -247,12 +246,9 @@ bfi_flag = true; } - if (rc != GSM_MACBLOCK_LEN && lchan->ecu_state) - osmo_ecu_frame_in(lchan->ecu_state, bfi_flag, tch_data, rc); - ber10k = compute_ber10k(n_bits_total, n_errors); if (bfi_flag) - goto bfi; + rc = 0; /* this is how we signal BFI to l1sap */ /* FACCH */ if (rc == GSM_MACBLOCK_LEN) { @@ -270,36 +266,13 @@ * the fake (BFI) TCH indication we set meas_avg.rssi to zero. * Doing so tells l1sap.c to ignore the measurement result. */ meas_avg.rssi = 0; - -bfi: - if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { - /* indicate bad frame */ - if (lchan->tch.dtx.ul_sid) { - /* DTXu: pause in progress. Push empty payload to upper layers */ - rc = 0; - goto compose_l1sap; - } - - /* If there is an ECU active on this channel, use its output */ - if (lchan->ecu_state) { - rc = osmo_ecu_frame_out(lchan->ecu_state, tch_data); - if (rc >= 0) /* Otherwise we send a BFI */ - goto compose_l1sap; - } - - /* In order to signal BFI in our UL RTP output, we need - * to push an empty payload to l1sap. The upper layer - * will choose the correct RTP representation of this - * BFI based on model-independent vty config. */ - rc = 0; - } + rc = 0; } if (rsl_cmode != RSL_CMOD_SPD_SPEECH) return 0; /* TCH or BFI */ -compose_l1sap: return _sched_compose_tch_ind(l1ts, fn_begin, bi->chan, tch_data, rc, meas_avg.toa256, ber10k, meas_avg.rssi, meas_avg.ci_cb, is_sub); diff --git a/src/osmo-bts-trx/sched_lchan_tchh.c b/src/osmo-bts-trx/sched_lchan_tchh.c index c91569f..8d1aab3 100644 --- a/src/osmo-bts-trx/sched_lchan_tchh.c +++ b/src/osmo-bts-trx/sched_lchan_tchh.c @@ -30,7 +30,6 @@ #include <osmocom/gsm/gsm0502.h> #include <osmocom/codec/codec.h> -#include <osmocom/codec/ecu.h> #include <osmocom/coding/gsm0503_coding.h> #include <osmocom/coding/gsm0503_amr_dtx.h> @@ -285,11 +284,8 @@ bfi_flag = true; } - if (rc != GSM_MACBLOCK_LEN && lchan->ecu_state) - osmo_ecu_frame_in(lchan->ecu_state, bfi_flag, tch_data, rc); - if (bfi_flag) - goto bfi; + rc = 0; /* this is how we signal BFI to l1sap */ /* FACCH */ if (rc == GSM_MACBLOCK_LEN) { @@ -307,33 +303,12 @@ bfi: /* A FACCH/H frame replaces two speech frames, so we need to send two BFIs. * One is sent here, another will be sent two bursts later (see above). */ - if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { - /* indicate bad frame */ - if (lchan->tch.dtx.ul_sid) { - /* DTXu: pause in progress. Push empty payload to upper layers */ - rc = 0; - goto compose_l1sap; - } - - /* If there is an ECU active on this channel, use its output */ - if (lchan->ecu_state) { - rc = osmo_ecu_frame_out(lchan->ecu_state, tch_data); - if (rc >= 0) /* Otherwise we send a BFI */ - goto compose_l1sap; - } - - /* In order to signal BFI in our UL RTP output, we need - * to push an empty payload to l1sap. The upper layer - * will choose the correct RTP representation of this - * BFI based on model-independent vty config. */ - rc = 0; - } + rc = 0; } if (rsl_cmode != RSL_CMOD_SPD_SPEECH) return 0; -compose_l1sap: /* TCH or BFI */ return _sched_compose_tch_ind(l1ts, fn_begin, bi->chan, tch_data, rc, meas_avg.toa256, ber10k, meas_avg.rssi, -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/33471 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Iac577975c9ab50cb8ebbc035c661c1880e7cecec Gerrit-Change-Number: 33471 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-MessageType: newchange
1 0
0 0
[S] Change in osmo-ttcn3-hacks[master]: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing
by arehbein 27 Jun '23

27 Jun '23
Attention is currently required from: fixeria. arehbein has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 ) Change subject: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing ...................................................................... Patch Set 2: (2 comments) File sgsn/SGSN_Tests.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465/comment/928b894e_406b… PS2, Line 1067: setverdict(pass) > There is already `setverdict(pass)` below, this one is redundant. yes I thought so too, but just wanted to make sure it doesn't fail because of that https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465/comment/b2e7fc91_33d8… PS2, Line 1078: vc_conn.done > have to say though... […] Alright my idea didn't fix anything it seems. I'm having a hard time debugging this, also because I can't find the log output coded in the `.ttcn3` file via `log()`. There seems to be all kinds of log data (e.g., output from the SGSN, packet dumps, logs in the folder `sgsn-tester` etc.) but I can't find a file with the log outputs coded in `SGSN_Tests.ttcn` (fairly certain I couldn't do so previously either - I think with another test) and I'm pretty certain the ttcn code has arrived at one of the log commands (since I don't have a debugger like gdb to wrap around the tester all I can do is try to guess until where the code is run...). I might try looking at the pcap again, but so far the output is fairly confusing for me since I don't know the procedure. Hmmm I just noticed the `log()` output is in the pcap through `GSMTAP libosmocore logging` (?) -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ibaf2134247153471bd45d7a7f91155294c6c6de5 Gerrit-Change-Number: 33465 Gerrit-PatchSet: 2 Gerrit-Owner: arehbein <arehbein(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 26 Jun 2023 22:33:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: arehbein <arehbein(a)sysmocom.de> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: comment
1 0
0 0
[S] Change in osmo-ttcn3-hacks[master]: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing
by arehbein 26 Jun '23

26 Jun '23
Attention is currently required from: fixeria. arehbein has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 ) Change subject: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing ...................................................................... Patch Set 2: (1 comment) File sgsn/SGSN_Tests.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465/comment/886a61ec_b2cd… PS2, Line 1078: vc_conn.done > Ah I think I know what's wrong. […] have to say though... if it is what I think, then I don't understand why the test gets a 'skipped' in Jenkins (because it's a failure and not the absence of a verdict) -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ibaf2134247153471bd45d7a7f91155294c6c6de5 Gerrit-Change-Number: 33465 Gerrit-PatchSet: 2 Gerrit-Owner: arehbein <arehbein(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 26 Jun 2023 20:45:52 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: arehbein <arehbein(a)sysmocom.de> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: comment
1 0
0 0
[S] Change in osmo-ttcn3-hacks[master]: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing
by arehbein 26 Jun '23

26 Jun '23
Attention is currently required from: fixeria. arehbein has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 ) Change subject: WIP: sgsn: Fix TC_attach_timeout_after_pdp_act failing ...................................................................... Patch Set 2: (1 comment) File sgsn/SGSN_Tests.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465/comment/7bcc77ec_90a0… PS2, Line 1078: vc_conn.done > AFAICS, osmo-sgsn is sending `GMM IDENTITY REQUEST: mi_type=IMEI`, but the testsuite does not respon […] Ah I think I know what's wrong. I'll try something as soon as I'm home -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33465 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ibaf2134247153471bd45d7a7f91155294c6c6de5 Gerrit-Change-Number: 33465 Gerrit-PatchSet: 2 Gerrit-Owner: arehbein <arehbein(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 26 Jun 2023 20:43:59 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: comment
1 0
0 0
[M] Change in osmo-ttcn3-hacks[master]: pcu: Wait for USF before start using UL TBF
by pespin 26 Jun '23

26 Jun '23
Attention is currently required from: osmith, fixeria. Hello osmith, Jenkins Builder, fixeria, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33466 to look at the new patch set (#2). Change subject: pcu: Wait for USF before start using UL TBF ...................................................................... pcu: Wait for USF before start using UL TBF Change-Id: Ibe8f8c24b239715c0a43d52e59475011e78cb4eb --- M pcu/GPRS_Components.ttcn M pcu/PCU_Tests.ttcn 2 files changed, 113 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/66/33466/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33466 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ibe8f8c24b239715c0a43d52e59475011e78cb4eb Gerrit-Change-Number: 33466 Gerrit-PatchSet: 2 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newpatchset
1 0
0 0
[S] Change in libosmo-pfcp[master]: Fix license information in dpkg + rpm packages: GPLv2+ and not AGPLv3+
by pespin 26 Jun '23

26 Jun '23
Attention is currently required from: laforge. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-pfcp/+/33469 ) Change subject: Fix license information in dpkg + rpm packages: GPLv2+ and not AGPLv3+ ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-pfcp/+/33469 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-pfcp Gerrit-Branch: master Gerrit-Change-Id: I94d0dda467b2c2b1c61ad1c6cb234cb66db46134 Gerrit-Change-Number: 33469 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Mon, 26 Jun 2023 17:05:42 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment
1 0
0 0
[S] Change in libosmo-pfcp[master]: Fix license information in dpkg + rpm packages: GPLv2+ and not AGPLv3+
by laforge 26 Jun '23

26 Jun '23
laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-pfcp/+/33469 ) Change subject: Fix license information in dpkg + rpm packages: GPLv2+ and not AGPLv3+ ...................................................................... Fix license information in dpkg + rpm packages: GPLv2+ and not AGPLv3+ These look like copy+paste issues. We don't generally do AGPL for library code; libraries are typically under GPLv2+ for maximum compatibility. Change-Id: I94d0dda467b2c2b1c61ad1c6cb234cb66db46134 --- M contrib/libosmo-pfcp.spec.in M debian/copyright 2 files changed, 23 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmo-pfcp refs/changes/69/33469/1 diff --git a/contrib/libosmo-pfcp.spec.in b/contrib/libosmo-pfcp.spec.in index 421a893..b936763 100644 --- a/contrib/libosmo-pfcp.spec.in +++ b/contrib/libosmo-pfcp.spec.in @@ -2,7 +2,7 @@ Version: @VERSION@ Release: 0 Summary: PFCP protocol encoding, decoding and endpoint implementation -License: AGPL-3.0-or-later AND GPL-2.0-or-later +License: GPL-2.0-or-later Group: Hardware/Mobile URL: https://osmocom.org/projects/libosmo-pfcp Source: %{name}-%{version}.tar.xz @@ -24,7 +24,7 @@ %package -n libosmo-gtlv1 Summary: Generic TLV and TLIV protocol support -License: GPL-2.0-or-later AND AGPL-3.0-or-later +License: GPL-2.0-or-later Group: System/Libraries %description -n libosmo-gtlv1 @@ -46,7 +46,7 @@ %package -n libosmo-pfcp0 Summary: PFCP protocol support -License: GPL-2.0-or-later AND AGPL-3.0-or-later +License: GPL-2.0-or-later Group: System/Libraries %description -n libosmo-pfcp0 diff --git a/debian/copyright b/debian/copyright index 90d27df..d41f22b 100644 --- a/debian/copyright +++ b/debian/copyright @@ -4,16 +4,16 @@ Files: * Copyright: 2022 sysmocom - s.f.m.c. GmbH <info(a)sysmocom.de> -License: AGPL-3.0+ +License: GPL-2.0+ This program is free software; you can redistribute it and/or modify - it under the terms of the GNU Affero General Public License as published by - the Free Software Foundation; either version 3 of the License, or + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or (at your option) any later version. - . + This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU Affero General Public License for more details. - . - You should have received a copy of the GNU Affero General Public License + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. -- To view, visit https://gerrit.osmocom.org/c/libosmo-pfcp/+/33469 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-pfcp Gerrit-Branch: master Gerrit-Change-Id: I94d0dda467b2c2b1c61ad1c6cb234cb66db46134 Gerrit-Change-Number: 33469 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange
1 0
0 0
[S] Change in osmo-mgw[master]: mgcp-client: Always mark client as UP if keepalive request-interval d...
by pespin 26 Jun '23

26 Jun '23
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-mgw/+/33467 ) Change subject: mgcp-client: Always mark client as UP if keepalive request-interval disabled ...................................................................... mgcp-client: Always mark client as UP if keepalive request-interval disabled In the previous logic, if "keepalive request-interval" was disabled (value 0, default), then if the client was configured to send a DLCX on startup it would end up in state UP or DOWN depending on whether the MGW answered to that request. As a result, an MGW that wouldn't answer would be left forever in DOWN state since it would have been selected no more and there would be a keepalive configured to re-mark it as UP. Change-Id: I290f7436f48418ee25179951359c76208796e279 --- M src/libosmo-mgcp-client/mgcp_client.c 1 file changed, 23 insertions(+), 6 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/67/33467/1 diff --git a/src/libosmo-mgcp-client/mgcp_client.c b/src/libosmo-mgcp-client/mgcp_client.c index 677a4f3..b0ccfe7 100644 --- a/src/libosmo-mgcp-client/mgcp_client.c +++ b/src/libosmo-mgcp-client/mgcp_client.c @@ -951,16 +951,16 @@ some_dlcx_sent = true; } - if (!some_dlcx_sent) { - if (mgcp->actual.keepalive.req_interval_sec > 0) { + if (mgcp->actual.keepalive.req_interval_sec > 0) { + if (!some_dlcx_sent) { /* Attempt an immediate probe to find out if link is UP or DOWN: */ osmo_timer_schedule(&mgcp->keepalive_tx_timer, 0, 0); - } else { - /* Assume link is UP by default, so that this MGW can be selected: */ - mgcp->conn_up = true; } + /* else: keepalive_tx_timer was already scheduled (if needed) down in the stack during Tx DLCX above */ + } else { + /* Assume link is UP by default, so that this MGW can be selected: */ + mgcp->conn_up = true; } - /* else: keepalive_tx_timer was already scheduled (if needed) down in the stack during Tx DLCX above */ if (mgcp->actual.keepalive.timeout_sec > 0) osmo_timer_schedule(&mgcp->keepalive_rx_timer, mgcp->actual.keepalive.timeout_sec, 0); -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/33467 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: I290f7436f48418ee25179951359c76208796e279 Gerrit-Change-Number: 33467 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
[S] Change in osmo-mgw[master]: mgcp-client: Mark client as UP when keepalive request-interval/timeou...
by pespin 26 Jun '23

26 Jun '23
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-mgw/+/33468 ) Change subject: mgcp-client: Mark client as UP when keepalive request-interval/timeout is disabled through VTY ...................................................................... mgcp-client: Mark client as UP when keepalive request-interval/timeout is disabled through VTY This way if keepalive becomes disabled for an MGW, it can be selected again (otherwise it would become non-selectable forever, and we already have a "blocked" config for that). Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30 --- M src/libosmo-mgcp-client/mgcp_client_vty.c 1 file changed, 29 insertions(+), 6 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/68/33468/1 diff --git a/src/libosmo-mgcp-client/mgcp_client_vty.c b/src/libosmo-mgcp-client/mgcp_client_vty.c index a164637..d57447c 100644 --- a/src/libosmo-mgcp-client/mgcp_client_vty.c +++ b/src/libosmo-mgcp-client/mgcp_client_vty.c @@ -323,10 +323,15 @@ /* If client already exists, apply the change immediately if possible: */ mgcp->actual.keepalive.req_interval_sec = atoi(argv[0]); if (mgcp->wq.bfd.fd != -1) { /* UDP MGCP socket connected */ - if (mgcp->actual.keepalive.req_interval_sec > 0) /* Re-schedule: */ + if (mgcp->actual.keepalive.req_interval_sec > 0) { + /* Re-schedule: */ osmo_timer_schedule(&mgcp->keepalive_tx_timer, mgcp->actual.keepalive.req_interval_sec, 0); - else if (osmo_timer_pending(&mgcp->keepalive_tx_timer)) - osmo_timer_del(&mgcp->keepalive_tx_timer); + } else { + if (osmo_timer_pending(&mgcp->keepalive_tx_timer)) + osmo_timer_del(&mgcp->keepalive_tx_timer); + /* Assume link is UP by default, so that this MGW can be selected: */ + mgcp->conn_up = true; + } } /* else: wait until connect() to do first scheduling */ return CMD_SUCCESS; @@ -371,10 +376,15 @@ /* If client already exists, apply the change immediately if possible: */ mgcp->actual.keepalive.timeout_sec = atoi(argv[0]); if (mgcp->wq.bfd.fd != -1) { /* UDP MGCP socket connected */ - if (mgcp->actual.keepalive.timeout_sec > 0) /* Re-schedule: */ + if (mgcp->actual.keepalive.timeout_sec > 0) { + /* Re-schedule: */ osmo_timer_schedule(&mgcp->keepalive_rx_timer, mgcp->actual.keepalive.timeout_sec, 0); - else if (osmo_timer_pending(&mgcp->keepalive_rx_timer)) - osmo_timer_del(&mgcp->keepalive_rx_timer); + } else { + if (osmo_timer_pending(&mgcp->keepalive_rx_timer)) + osmo_timer_del(&mgcp->keepalive_rx_timer); + /* Assume link is UP by default, so that this MGW can be selected: */ + mgcp->conn_up = true; + } } /* else: wait until connect() to do first scheduling */ return CMD_SUCCESS; -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/33468 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30 Gerrit-Change-Number: 33468 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • ...
  • 248
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.