February 2022 - gerrit-log - lists.osmocom.org

Change in libosmocore[master]: gsm0808: Test if we properly decode a SRVCC cell identifier list

by laforge

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/27212 ) Change subject: gsm0808: Test if we properly decode a SRVCC cell identifier list ...................................................................... gsm0808: Test if we properly decode a SRVCC cell identifier list We don't handle this correctly, as we decided to overload the meaning of 0b1011 in a cell identifier list (defined by 3GPP as used in SRVCC) with something osmocom proprietary. Change-Id: I608220e8e5dd5a44f85c6bc5ea04622a2cad24ec --- M tests/gsm0808/gsm0808_test.c 1 file changed, 12 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/12/27212/1 diff --git a/tests/gsm0808/gsm0808_test.c b/tests/gsm0808/gsm0808_test.c index 3fff005..e0f8eb3 100644 --- a/tests/gsm0808/gsm0808_test.c +++ b/tests/gsm0808/gsm0808_test.c @@ -1072,6 +1072,17 @@ msgb_free(msg); } +static void test_gsm0808_dec_cell_id_list_srvcc() +{ + /* taken from a pcap file of a real-world 3rd party MSC (SYS#5838) */ + const uint8_t enc_cil[] = { 0x0b, 0x2, 0xf2, 0x10, 0x4e, 0x20, 0x15, 0xbe}; + struct gsm0808_cell_id_list2 dec_cil; + int rc; + + rc = gsm0808_dec_cell_id_list2(&dec_cil, enc_cil, sizeof(enc_cil)); + OSMO_ASSERT(rc == sizeof(dec_cil)); +} + static void test_gsm0808_enc_dec_cell_id_list_lac() { struct gsm0808_cell_id_list2 enc_cil; @@ -2490,6 +2501,7 @@ test_gsm0808_enc_dec_cell_id_list_multi_ci(); test_gsm0808_enc_dec_cell_id_list_multi_lac_and_ci(); test_gsm0808_enc_dec_cell_id_list_multi_global(); + test_gsm0808_dec_cell_id_list_srvcc(); test_cell_id_list_add(); -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/27212 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I608220e8e5dd5a44f85c6bc5ea04622a2cad24ec Gerrit-Change-Number: 27212 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

3 years, 4 months

1
0
0 0

Change in osmo-bsc[master]: stats: New stats for lchan life duration.

by neels

Attention is currently required from: iedemam. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/27081 ) Change subject: stats: New stats for lchan life duration. ...................................................................... Patch Set 8: (1 comment) Patchset: PS8: sorry for the weird formatting of my prev comment in gerrit, seems i can't edit the comment to fix it. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/27081 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347 Gerrit-Change-Number: 27081 Gerrit-PatchSet: 8 Gerrit-Owner: iedemam <michael(a)kapsulate.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: iedemam <michael(a)kapsulate.com> Gerrit-Comment-Date: Tue, 15 Feb 2022 18:48:18 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

Change in osmo-bsc[master]: stats: New stats for lchan life duration.

by neels

Attention is currently required from: iedemam. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/27081 ) Change subject: stats: New stats for lchan life duration. ...................................................................... Patch Set 8: (11 comments) Patchset: PS8: Hi Michael! Good to see a patch from outside of sysmocom. And what a patch it is. Reporting time durations in statistics is a head-spinning mathematically challenging topic. When reviewing the patch I went from "oh, that's simple" and "why didn't I think of this and went for all the effort with osmo_time_cc?" at first, all the way to "wait, no, how does this work again??" and to "oh that's why I wrote osmo_time_cc". This stuff can be really confusing. Let me try to break down what I figured out so far: This current patch has these flaws: - (there should be no averaging, see below, but) The N to average over should be the released-count, not the currently-active-count, because the millis value is added only later upon channel release. In stats, when we report the TCH_ACTIVE_MILLISECONDS_TOTAL and the BTS_CTR_CHAN_ACT_TCH, that gives an inaccurate metric, because N increments a long time before the millis increment. The metric takes a dip upon each channel activation, and un-dips on each channel release. If there were a metric counting releases, the value would be much more accurate, updated only when a channel releases with the correct duration value. - The value written on vty_out reflects an average over the process lifetime, not the current situation. A useful value would gradually "forget" the values of past time periods, literature seems to suggest averaging over an hour or 15 minutes. Instead osmocom offers rate_ctr. See below. - For the ACTIVE_MILLISECONDS_TOTAL, a rate_ctr would be better suited. A stat item is designed for current absolute values that can decrease, like how many lchans are currently active. A rate counter reports increments of a value over-time, like how many releases have occured over time (per second, per minute, etc); this over-time is very desirable. If we report the nr of channel releases as a rate counter as well as the sum of active milliseconds as a rate counter, a stats engine can form an accurate average over any time period it chooses. However, think that a phone call is taking 2 hours to complete, then the trivial implementation would report those 2 hours worth of milliseconds only when the call is hung up. Or extrapolated, if *all* channels are occupied with calls going on for 2 hours, your dashboard will only flag a high Erlang value two hours after your entire network has become congested. With osmo_time_cc, the milliseconds count would gradually increase as the call continues, even before it is hung up, and the metric would also stay accurate the entire time (no dips from chan act). No dips because no averaging: IIUC for an Erlang we would not actually average, but simply add up all lchans. We could put a separate osmo_time_cc for each lchan in place, and report the sum of those per BTS and chan type. Then if we get 10 minutes of increase within one minute, that's 10 Erlangs, or 10 TCH were active concurrently. I think this is what we should go for. From explaining this, I've actually come to appreciate the simple yet powerful nature of the Erlang unit, had not realized this before. In detail, I would: - add a new rate counter per BTS and per chan type; each gradually reports the seconds of activity per second, added up over all lchans of that type. E.g. BTS_ACTIVE_TIME_TCH, _SDCCH,... - we add one time_cc per lchan, and make all of them accumulate to the same BTS-wide rate counter (one per channel type). - in lchan_st_established_onenter() we set the time_cc = true, on established_onleave() to false. Nothing else is required. The patch might actually become simpler this way. (maybe there could also be separate rate counters for each TRX, and also globally over the entire BSC; a bit of implementation detail would be involved there, skipping that for now.) I would advise against using the current patch as-is. It would provide an improved value, but there would still be the flaws I pointed out, and eventually we'd probably need to fix those and have compat issues with existing setups. What do you think? Am I making sense? (I could also imagine taking over, but not sure how soon that would work out; would need to ask about our current priorities). I also wrote a bunch of code review on details of this patch. I'll keep some for sharing, in case you're interested in the style differences that come up. File include/osmocom/bsc/gsm_data.h: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/55df34cc_7eee50f1 PS8, Line 1130: unsigned long long gsm_lchan_active_duration_ms(const struct gsm_lchan *lchan); (idea: use uint64_t for a fixed size independent from arch. uint32_t spans 49 days of ms, uint64_t half a billion years) File src/osmo-bsc/bts.c: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/9e38af99_1efeb800 PS8, Line 1514: "Cummulative number of active milliseconds on TCH chans", ("Cumulative") doc reads a bit weird, as if the milliseconds are active, also leaves a lot of guessing about the nature of the metric. suggestion: "Average lchan activity duration per TCH lchan activation in milliseconds" File src/osmo-bsc/bts_trx_vty.c: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/d479f6ec_6c688a6f PS8, Line 574: uint duration_s = (gsm_lchan_active_duration_ms(lchan) + 500) / 1000; the +500 acts as a round(), yet the reported descriptions below suggest that floor() should be used instead. IOW please drop the 500. File src/osmo-bsc/bts_vty.c: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/d3a14304_f147c16c PS8, Line 3826: uint64_t activations_tch = rate_ctr_group_get_ctr(bts->bts_ctrs, BTS_CTR_CHAN_ACT_TCH)->current; osmocom style dictates that local variables are declared at the start of the function (or scope) File src/osmo-bsc/gsm_data.c: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/6b1bdb85_9746e7b5 PS8, Line 348: /* Get duration of active time for this lchan in milliseconds */ Rather: /* If the lchan is currently active, return the duration since activation in milliseconds. Otherwise return 0. */ https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/73cb38ff_8091843b PS8, Line 352: if (lchan->activate.concluded) { osmocom style asks for early-exit: struct timespec now; if (!lchan->activate.concluded) return 0; osmo_clock_gettime ... return elapsed.tv_sec * ... https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/cdcce2f6_c8642f83 PS8, Line 357: duration = elapsed.tv_sec * 1000LL + elapsed.tv_nsec / 1000000; the LL on the 1000 has no effect, the first operand defines the integer size for calculation. So you want one of these: (uint64_t)elapsed.tv_sec * 1000 + ... or 1000LL * elapsed.tv_sec + ... (i prefer the first) File src/osmo-bsc/lchan_fsm.c: https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/af32bb7e_b5fe7283 PS8, Line 1810: You should rather put this bit in a new lchan_st_established_onleave() function. This is the single place that is absolutely guaranteed to be called whenever the lchan leaves the active state. If you want to also count the time that the lchan release process takes (including any error timeouts that may be), then you'd instead put this in lchan_st_unused_onenter(). In lchan_fsm.c:1628, add a new onleave cb: [LCHAN_ST_ESTABLISHED] = { .onleave = lchan_st_established_onleave, https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/ad4f3c23_f4db6493 PS8, Line 1811: /* Add active milliseconds to cummulative counts per channel type */ /* Report how long this lchan was active, to add to the average activity duration metric. */ https://gerrit.osmocom.org/c/osmo-bsc/+/27081/comment/e0fc54f9_b83bf4f8 PS8, Line 1817: LOG_LCHAN(lchan, LOGL_INFO, "GSM_LCHAN_TCH was active for %llu milliseconds\n", duration_ms); i would rather just have a single LOG_LCHAN() that uses gsm_chan_t_name() above the switch, because then you don't need to duplicate which names we use for channel types in logging, and you can drop the weird 'default:' case. Also osmo_int_to_float_str() is nice. /* "TCH/H was active for 1.23 seconds" */ LOG_LCHAN("%s was active for %s seconds", gsm_chan_t_name(lchan), osmo_int_to_float_str_c(OTC_SELECT, millis, 3); switch(lchan->type) { osmo_stat_item_inc... break -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/27081 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347 Gerrit-Change-Number: 27081 Gerrit-PatchSet: 8 Gerrit-Owner: iedemam <michael(a)kapsulate.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: iedemam <michael(a)kapsulate.com> Gerrit-Comment-Date: Tue, 15 Feb 2022 18:42:19 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

Change in osmo-ttcn3-hacks[master]: ggsn: Rework tests validating wrong ipv6 saddr on IPv4v6 APNs

by pespin

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27189 ) Change subject: ggsn: Rework tests validating wrong ipv6 saddr on IPv4v6 APNs ...................................................................... ggsn: Rework tests validating wrong ipv6 saddr on IPv4v6 APNs The existing test TC_pdp46_act_deact_gtpu_access_wrong_global_saddr_ipv6 was wrong, because the global address was being finally encoded as a link local address by f_gen_icmpv6_router_solicitation(). Let's rewrite the test and add a new one for source link local addresses simlar to the ones used to test IPv6-only APNs. Change-Id: I3d0790104abea7acb4fa5e33109fe93cc51d94ea --- M ggsn_tests/GGSN_Tests.ttcn 1 file changed, 26 insertions(+), 4 deletions(-) Approvals: laforge: Looks good to me, but someone else must approve Vadim Yanitskiy: Looks good to me, approved Jenkins Builder: Verified diff --git a/ggsn_tests/GGSN_Tests.ttcn b/ggsn_tests/GGSN_Tests.ttcn index 4ea7cf4..8f4e709 100644 --- a/ggsn_tests/GGSN_Tests.ttcn +++ b/ggsn_tests/GGSN_Tests.ttcn @@ -1512,15 +1512,36 @@ f_pdp_ctx_del(ctx, '1'B); } - /* Assert that packets with wrong ipv6 global src addr are dropped by GGSN on APN IPv4v6 */ - testcase TC_pdp46_act_deact_gtpu_access_wrong_global_saddr_ipv6() runs on GT_CT { + /* Check that attempting RA with another ll src addr won't work, packet dropped: */ + testcase TC_pdp46_act_deact_gtpu_access_wrong_ll_saddr_ipv6() runs on GT_CT { f_init(); var PdpContext ctx := valueof(t_DefinePDP(f_rnd_imsi('26242'H), '1234'O, c_ApnInet46, valueof(t_EuaIPv4Dynv6Dyn))); ctx.pco_req := valueof(ts_PCO_IPv4_DNS_CONT); f_pdp_ctx_act(ctx); - var OCT16 saddr_v6 := f_inet6_addr("fde4:8dba:82e1:2000:1:2:3:4"); - f_send_gtpu(ctx, f_gen_icmpv6_router_solicitation(saddr_v6)); + var OCT16 saddr_ll := f_ipv6_link_local(ctx.eua.endUserAddress.endUserAddressIPv4andIPv6.ipv6_address); + var OCT16 saddr_ll_wrong := f_ipv6_mangle(saddr_ll, 8); + f_send_gtpu(ctx, f_gen_icmpv6_router_solicitation(saddr_ll_wrong)); + f_wait_gtpu_fail(ctx); + + f_pdp_ctx_del(ctx, '1'B); + } + + /* Assert that packets with wrong ipv6 global src addr are dropped by GGSN on APN IPv4v6 */ + testcase TC_pdp46_act_deact_gtpu_access_wrong_global_saddr_ipv6() runs on GT_CT { + f_init(); + var PdpContext ctx := valueof(t_DefinePDP(f_rnd_imsi('26242'H), '1234'O, c_ApnInet46, valueof(t_EuaIPv4Dynv6Dyn))); + ctx.pco_req := valueof(ts_PCO_IPv6_DNS); + f_pdp_ctx_act(ctx); + + f_send_gtpu(ctx, f_icmpv6_rs_for_pdp(ctx)); + f_wait_rtr_adv(ctx); + f_send_gtpu(ctx, f_gen_icmpv6_neigh_solicit_for_pdp(ctx)); + + var OCT16 dns1_addr := f_PCO_extract_proto(ctx.pco_neg, '0003'O); + var OCT16 saddr_glob := f_ipv6_global(ctx.eua.endUserAddress.endUserAddressIPv4andIPv6.ipv6_address); + var OCT16 saddr_wrong := f_ipv6_mangle(saddr_glob); + f_send_gtpu(ctx, f_gen_icmpv6_echo(saddr_wrong, dns1_addr)); f_wait_gtpu_fail(ctx); f_pdp_ctx_del(ctx, '1'B); @@ -1713,6 +1734,7 @@ execute(TC_pdp46_act_deact_pcodns6()); execute(TC_pdp46_act_deact_gtpu_access()); execute(TC_pdp46_act_deact_gtpu_access_wrong_saddr_ipv4()); + execute(TC_pdp46_act_deact_gtpu_access_wrong_ll_saddr_ipv6()); execute(TC_pdp46_act_deact_gtpu_access_wrong_global_saddr_ipv6()); execute(TC_pdp46_clients_interact()); execute(TC_pdp46_act_deact_apn4()); -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27189 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: I3d0790104abea7acb4fa5e33109fe93cc51d94ea Gerrit-Change-Number: 27189 Gerrit-PatchSet: 3 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 years, 4 months

1
0
0 0

Change in osmo-ttcn3-hacks[master]: ggsn: Support IPv4v6 PDP contexts in helper icmpv6 functions

by pespin

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27195 ) Change subject: ggsn: Support IPv4v6 PDP contexts in helper icmpv6 functions ...................................................................... ggsn: Support IPv4v6 PDP contexts in helper icmpv6 functions Change-Id: I564d51e02ea4b3cb5fedb79dfc1903c04619bd61 --- M ggsn_tests/GGSN_Tests.ttcn 1 file changed, 15 insertions(+), 2 deletions(-) Approvals: laforge: Looks good to me, approved Vadim Yanitskiy: Looks good to me, but someone else must approve Jenkins Builder: Verified diff --git a/ggsn_tests/GGSN_Tests.ttcn b/ggsn_tests/GGSN_Tests.ttcn index cebd6f2..4ea7cf4 100644 --- a/ggsn_tests/GGSN_Tests.ttcn +++ b/ggsn_tests/GGSN_Tests.ttcn @@ -750,9 +750,22 @@ return f_IPv6_enc(ip6); } + /* Get link-id from PDP Context EUA */ + function f_ctx_get_ipv6_interface_id(in PdpContext ctx) return OCT16 { + var OCT16 interface_id; + if (ischosen(ctx.eua.endUserAddress.endUserAddressIPv4andIPv6)) { + interface_id := ctx.eua.endUserAddress.endUserAddressIPv4andIPv6.ipv6_address; + } else if (ischosen(ctx.eua.endUserAddress.endUserAddressIPv6)) { + interface_id := ctx.eua.endUserAddress.endUserAddressIPv6.ipv6_address; + } else { + Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, "Unexpected request to submit icmpv6 rs in IPv4 PDP context"); + } + return interface_id; + } + /* create ICMPv6 router solicitation deriving link-id from PDP Context EUA */ function f_icmpv6_rs_for_pdp(in PdpContext ctx) return octetstring { - var OCT16 interface_id := ctx.eua.endUserAddress.endUserAddressIPv6.ipv6_address; + var OCT16 interface_id := f_ctx_get_ipv6_interface_id(ctx); return f_gen_icmpv6_router_solicitation(interface_id); } @@ -766,7 +779,7 @@ /* generate and encode ICMPv6 neighbor solicitation for PDP Context */ function f_gen_icmpv6_neigh_solicit_for_pdp(in PdpContext ctx) return octetstring { - var OCT16 interface_id := ctx.eua.endUserAddress.endUserAddressIPv6.ipv6_address; + var OCT16 interface_id := f_ctx_get_ipv6_interface_id(ctx); var OCT16 link_local := f_ipv6_link_local(interface_id); var OCT16 daddr := f_ipv6_sol_node_mcast(link_local); -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27195 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: I564d51e02ea4b3cb5fedb79dfc1903c04619bd61 Gerrit-Change-Number: 27195 Gerrit-PatchSet: 2 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 years, 4 months

1
0
0 0

Change in osmo-ttcn3-hacks[master]: ggsn: Rework tests validating wrong ipv6 saddr on IPv4v6 APNs

by Vadim Yanitskiy

Attention is currently required from: osmith, pespin. Vadim Yanitskiy has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27189 ) Change subject: ggsn: Rework tests validating wrong ipv6 saddr on IPv4v6 APNs ...................................................................... Patch Set 2: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27189 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: I3d0790104abea7acb4fa5e33109fe93cc51d94ea Gerrit-Change-Number: 27189 Gerrit-PatchSet: 2 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 15 Feb 2022 16:54:08 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

Change in libosmo-netif[master]: amr: cosmetic: fix grammer in comment

by dexter

dexter has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-netif/+/27210 ) Change subject: amr: cosmetic: fix grammer in comment ...................................................................... amr: cosmetic: fix grammer in comment Change-Id: I01ad26986d925acdcdb3760f89b8a85dccdc3d5b --- M src/amr.c 1 file changed, 2 insertions(+), 2 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, approved diff --git a/src/amr.c b/src/amr.c index 7bc24f5..add4285 100644 --- a/src/amr.c +++ b/src/amr.c @@ -103,8 +103,8 @@ * mode normally relys on out of band methods that explicitly select * one of the two modes. (See also RFC 3267, chapter 3.8). However the * A interface in GSM does not provide ways to communicate which mode - * is used exactly used. The following functions uses some heuristics - * to check if an AMR payload is octet aligned or not. */ + * is exactly used. The following functions uses some heuristics to + * check if an AMR payload is octet aligned or not. */ struct amr_hdr *oa_hdr = (struct amr_hdr *)payload; unsigned int frame_len; -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/27210 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: I01ad26986d925acdcdb3760f89b8a85dccdc3d5b Gerrit-Change-Number: 27210 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 years, 4 months

1
0
0 0

Change in libosmo-netif[master]: amr_test: increase test coverage for oe / bwe conversation

by pespin

Attention is currently required from: dexter. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-netif/+/27211 ) Change subject: amr_test: increase test coverage for oe / bwe conversation ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/27211 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: I53bd574e1ce7349419553e3957fff19e81567b93 Gerrit-Change-Number: 27211 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Tue, 15 Feb 2022 14:58:47 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

Change in libosmo-netif[master]: amr: cosmetic: fix grammer in comment

by pespin

Attention is currently required from: dexter. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-netif/+/27210 ) Change subject: amr: cosmetic: fix grammer in comment ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/27210 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: I01ad26986d925acdcdb3760f89b8a85dccdc3d5b Gerrit-Change-Number: 27210 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Tue, 15 Feb 2022 14:58:04 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

Change in osmo-ci[master]: ansible/ttcn3: don't install titan/libfftranscode

by pespin

Attention is currently required from: osmith. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ci/+/27206 ) Change subject: ansible/ttcn3: don't install titan/libfftranscode ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/27206 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ci Gerrit-Branch: master Gerrit-Change-Id: Ie46fe3dcb286a6258021fad9c35be10442544761 Gerrit-Change-Number: 27206 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Comment-Date: Tue, 15 Feb 2022 14:57:22 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 years, 4 months

1
0
0 0

2025

2024

2023

2022

gerrit-log February 2022