Cellular Network Infrastructure » Radio Access Network » OsmoTRX

this seems UHD related:

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

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.

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!

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.)

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?

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.