Project

General

Profile

Bug #4469

osmo-trx-uhd is sending UDP packets to port 49600 at variousl addresses on startup

Added by laforge 12 days ago. Updated 9 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/22/2020
Due date:
% Done:

0%

Spec Reference:

Description

[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("127.255.255.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("192.168.103.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("10.8.0.2")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("176.16.222.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("176.16.46.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8

History

#1 Updated by laforge 12 days ago

  • Subject changed from osmo-trx is sending UDP packets to port 49600 at variousl addresses on startup to osmo-trx-uhd is sending UDP packets to port 49600 at variousl addresses on startup
  • Description updated (diff)

#2 Updated by laforge 12 days ago

this seems UHD related:

$ rgrep MPM-DISC
Binary file /usr/lib/x86_64-linux-gnu/libuhd.so.3.13.1 matches

#3 Updated by laforge 12 days ago

  • Assignee set to laforge

I couldn't immediately find any documentation on how to disable that. Who would want their UHD-using application to advertise its presence to every network segment your machine is attached to? That's a security/privacy concern, at the very least.

#4 Updated by funkylab 11 days ago

That's a security/privacy concern, at the very least.

Can't disagree there; the purpose of this is indeed automatic discovery (which kind of answers the "who would want that": the users of fancy embedded USRPs; or at least, that's the interpretation of customer intent. These guys rarely actually know what they want.).

This is UHD's new-ish remote device management protocol MPM, and I think it follows the scheme of "host broadcasts, devices reply" that old-school UHD's dudebro-protocol did. (So, I think you should've seen broadcast packets when instantiating any UHD device ever, as long as you don't fully specify the device address on construction.)

Since I'm oldschool, I'll have to check back on what MPM does internally. I'll be back!

#5 Updated by funkylab 11 days ago

Yes, as presumed, from UHD's uhd/host/lib/usrp/mpmd/mpmd_find.cpp: (code snippet from UHD 4.0.0.0 alpha0, but only whitespace changes to your 3.13.1.0, and better readable because of those):

/*! Find MPM devices based on a hint
 *
 * There are two scenarios:
 *
 * 1) an addr or mgmt_addr was defined
 *
 * In this case, we will go through all the addrs. If they point to a device,
 * we will then compare the other attributes (serial, etc.). If they match,
 * the device goes into a list.
 *
 * 2) No addrs were defined
 *
 * In this case, we do a broadcast ping to see if any devices respond. After
 * that, we do the same matching.
 *
 */
device_addrs_t mpmd_find(const device_addr_t& hint_)
{
#ifdef HAVE_DPDK
  []
#endif
    device_addrs_t hints = separate_device_addr(hint_);
    if (hint_.has_key("type")) {
        if (std::find(MPM_DEVICE_TYPES.cbegin(), MPM_DEVICE_TYPES.cend(), hint_["type"])
            == MPM_DEVICE_TYPES.cend()) {
            UHD_LOG_TRACE(
                "MPMD FIND", "Returning early, type does not match an MPM device.");
            return {};
        }
    }
    UHD_LOG_TRACE("MPMD FIND", "Finding with " << hints.size() << " different hint(s).");

    // Scenario 1): User gave us at least one address
    if (not hints.empty()
        and (hints[0].has_key(xport::FIRST_ADDR_KEY)
                or hints[0].has_key(MGMT_ADDR_KEY))) {
        // Note: We don't try and connect to the devices in this mode, because
        // we only get here if the user specified addresses, and we assume she
        // knows what she's doing.
        return mpmd_find_with_addrs(hints);
    }

    // Scenario 2): User gave us no address, and we need to broadcast
    if (hints.empty()) {
        hints.resize(1);
    }
    const auto bcast_mpm_devs = mpmd_find_with_bcast(hints[0]);
    UHD_LOG_TRACE(
        "MPMD FIND", "Found " << bcast_mpm_devs.size() << " device via broadcast.");
[]

So, Martin made sure the broadcasting only happens when there was no device hint (i.e. devicestring or argumentstring) containing a `FIRST_ADDR_KEY` (that's `"addr"`, btw), or `MGMT_ADDR_KEY` (`"mgmt_addr"`), and no `type=` that ruled out the MPM broadcasting.

If you supply either, pointing to an running USRP, or when you supply a `type` that says, nope, this is not an MPM device (at this point in time, that's only "n3xx" and "e3xx" or "mpm"), then you'd be fine.

So, a solution should be to specify the device address.

(I'll be looking into more generally sane methods, too, I'll drop you an email.)

#6 Updated by laforge 11 days ago

On Mon, Mar 23, 2020 at 11:16:22AM +0000, funkylab [REDMINE] wrote:

If you supply either, pointing to an running USRP, or when you supply a `type` that says, nope, this is not an MPM device (at this point in time, that's only "n3xx" and "e3xx" or "mpm"), then you'd be fine.

Is there something like catch-all types for "all USB devices" or "all non-networked devices"?

So, a solution should be to specify the device address.

I think a very common use case would be:
  • I know I only have a single device attached, so I don't want to specify the device
    name / serial number / specific model,
  • but I also know I don't have any networked/embedded devices and hence have no
    interest in broadcasting unsolicited messages to all network interfaces

#7 Updated by funkylab 10 days ago

Is there something like catch-all types for "all USB devices" or "all non-networked devices"?

no, sorry.

  • I know I only have a single device attached, so I don't want to specify the device
    name / serial number / specific model,
  • but I also know I don't have any networked/embedded devices and hence have no
    interest in broadcasting unsolicited messages to all network interfaces

I think for that kind of situation, `type=` would probably suffice, as my guess is you know whether it's a B2xx or a USRP1 or a B100, right?

#8 Updated by laforge 9 days ago

On Tue, Mar 24, 2020 at 03:30:23PM +0000, funkylab [REDMINE] wrote:

Is there something like catch-all types for "all USB devices" or "all non-networked devices"?

no, sorry.

what a pity.

  • I know I only have a single device attached, so I don't want to specify the device
    name / serial number / specific model,
  • but I also know I don't have any networked/embedded devices and hence have no
    interest in broadcasting unsolicited messages to all network interfaces

I think for that kind of situation, `type=` would probably suffice, as my guess is you know whether it's a B2xx or a USRP1 or a B100, right?

This means that we as an application (osmo-trx) would have to ship
model-specific config file samples if we don't want to have our users
broadcast unsolicited packets. That's rather suboptimal.

Sure, I can live with the current situation. We will probably put a big
fat warning in our user manual of osmo-trx describing what the UHD user
manual should do.

I just find such design decisions highly questionable. It's one thing
to make things easy to use - but making it hard to disable the feature
without loosing device auto-detection, is another thing.

I understand that you are just the messenger here. So please don't take
any of this directed to you.

If I was involved in the design, I would have considered any of those
options (possibly multiple):
  1. provide an API for applications so they can control enable/disable of this
  2. implement an environment variable, by which even unmodified legacy applications can be used with disabled network advertisement (e.g. from the startup script / systemd unit
  3. provide a special 'type=networked' or 'type=usb' or the like

What is the best forum to discuss such UHD topics?

Regards,
Harald

#9 Updated by funkylab 9 days ago

this means that we as an application (osmo-trx) would have to ship

model-specific config file samples

Yeah, I see how that's undesirable!

Describing what the UHD user manual should do.

:D If I don't get around to writing that PR for the manual to explicitly state that, first.

I just find such design decisions highly questionable. It's one thing

to make things easy to use - but making it hard to disable the feature
without loosing device auto-detection, is another thing.

Same here; but now we're getting into technical discussions: one of two sides, device or host, needs to broadcast, for any autodetection to work without resorting to some service that's at a fixed address.

I understand that you are just the messenger here. So please don't take

any of this directed to you.

Don't you worry :) Seriously! I like this discussion. And there's a feature I'll be writing tonight coming out of this, so that's a win-win, I'd guess.

provide an API for applications so they can control enable/disable of this
implement an environment variable, by which even unmodified legacy applications can be used with disabled network advertisement (e.g. from the startup script / systemd unit

That's pretty much what I plan to do, yes. API: have a nobroadcast UHD device address/param flag. There's UHD configuration files, which can permanently set such parameters, so you don't have to supply them when using UHD every time.

provide a special 'type=networked' or 'type=usb' or the like

Hm, that feels kind of orthogonal to both the different transports UHD supports and the device types. I'll think of something, for now, I think a simple local flag would be most useful, because type= already has a specific meaning, and it basically selects the drivers that should even try to detect a device (and that gets hairy – N310 can be both, host and USRP in the same box, or a network-attached device. I don't think a bunch of special-casings for in which mode such devices currently operates would make it through code review). Locality is what you're actually looking for – something that's most definitely attached to your machine, and only that, no matter whether it's USB, AHB, or some proprietary National Instruments measurement device bus.

However, that will require docs for future device driver developers to respect, and will take longer to agree on, and so I can't do it on my own. Now, as anywhere right now, things are a bit special at NI right now, so that's not something I'd be able to promise right now.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)