Project

General

Profile

Actions

Bug #6424

open

TC_one_crcx_loopback_rtp_implicit consistently failing in master, but passes on latest

Added by laforge 30 days ago. Updated 28 days ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
03/26/2024
Due date:
% Done:

50%

Spec Reference:

Description

`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?

Actions #1

Updated by neels 29 days ago

I've been doing some MGW work, I'll try to bisect the cause.

Actions #2

Updated by neels 29 days ago

dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a is the first bad commit
commit dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a
Author: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Date:   Fri Dec 1 01:52:43 2023 +0100

check_rtp_origin: drop special case for legacy IuUP hack

We have proper IuUP support and everything about this legacy hack should
be purged.

The purpose of this function is to validate that RTP is coming from the
expected address and port. To allow that legacy IuUP hack, which is no
longer needed, we punched a hole into this validation, by adding this
special case for loopback mode (suddenly we don't care who or what sends
RTP and bounce it back to anyone). So let's get rid of this hole that
was only needed for very early 3G voice hacking.

Instead, we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b

Related: SYS#6657
Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40

src/libosmo-mgcp/mgcp_network.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
Actions #3

Updated by neels 29 days ago

  • Assignee changed from dexter to neels
Actions #4

Updated by neels 29 days ago

This test specifically tests whether osmo-mgw responds to an unknown remote address.

I think our agreement is that osmo-mgw must be told the remote RTP address and port to respond to.
This test sends a CRCX without a remote RTP address, and then runs some RTP.

osmo-mgw before the "bad" patch did respond to arbitrary peers when
  • in loopback mode,
  • and the remote address was not set yet

Why did it do that?
Because when I first hacked on 3G voice, I punched this very specific hole into osmo-mgw,
to accomodate a very questionable hack that happened to work for all the wrong reasons.

My conclusion here is that the test is wrong. When no remote address is set, osmo-mgw should not respond.
It's not a bug, it's a feature.
dexter pespin laforge do you agree with this conclusion, or is there something I'm missing? Thanks!

I would adjust the test to expect 0 packets. It would (accurately) fail on 'latest' then:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466

Actions #5

Updated by laforge 29 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

neels wrote in #note-4:
modate a very questionable hack that happened to work for all the wrong reasons.

My conclusion here is that the test is wrong. When no remote address is set, osmo-mgw should not respond.
It's not a bug, it's a feature.
do you agree with this conclusion, or is there something I'm missing? Thanks!

I agree based on your analysis.

I would adjust the test to expect 0 packets. It would (accurately) fail on 'latest' then:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466

makes sense.

Actions #6

Updated by pespin 29 days ago

Hi neels ,

I'd need to dig deeper into this, but it may be that still in 3G (without hacks) you need to "accept" the incoming packet (IuUP Init) so that the userplane is setup successfuly (IuuP Init ACK) before the HnodeB answers the RAB assignment and hence HNBGW sets the remote address on the MGW.

We could then discuss the details:
- Whether we really need "loopback" to work under that scenario (it's more like 3G specific forwarding of IuUP Init and answering/forwarding back IuUP Init ACK)
- Whether we really want to "accept" any packets or only IuUP INIT/INI-ACK (or whatever IuUP signalling).

Actions #7

Updated by neels 28 days ago

I'd need to dig deeper into this, but it may be that still in 3G (without hacks) you need to "accept" the incoming packet (IuUP Init) so that the userplane is setup successfuly (IuuP Init ACK) before the HnodeB answers the RAB assignment and hence HNBGW sets the remote address on the MGW.

I dimly remember us discussing this before and that I confirmed last time that
none of this hack is needed... I did all of my recent voice codecs testing
without this old loopback hack.

The loopback aspect originated from that early hack -- you'd never have
associated IuUP Initialization with loopback otherwise, because they should not
be and are semantically not related in any way at all.

One specific pointer is that the IuUP FSM doesn't hook in that RTP loopback
code path that was removed. I see in check_rtp_origin(), we do a specific iuup
check:

if (mgcp_conn_rtp_is_iuup(conn) && !conn->iuup.configured) {
/* Allow IuUP Initialization to get through even if we don't have a remote address set yet.
[...]

I think this was all discussed in dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a:
"we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b"

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)