https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-03-22T11:02:04ZOpen Source Mobile CommunicationsOsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178332020-03-22T11:02:04Zlaforge
<ul><li><strong>Subject</strong> changed from <i>osmo-trx is sending UDP packets to port 49600 at variousl addresses on startup</i> to <i>osmo-trx-uhd is sending UDP packets to port 49600 at variousl addresses on startup</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17833/diff?detail_id=29591">diff</a>)</li></ul> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178342020-03-22T11:03:48Zlaforge
<ul></ul><p>this seems UHD related:<br /><pre>
$ rgrep MPM-DISC
Binary file /usr/lib/x86_64-linux-gnu/libuhd.so.3.13.1 matches
</pre></p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178352020-03-22T11:12:09Zlaforge
<ul><li><strong>Assignee</strong> set to <i>laforge</i></li></ul><p>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.</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178512020-03-23T10:27:16Zfunkylab
<ul></ul><blockquote>
<p>That's a security/privacy concern, at the very least.</p>
</blockquote>
<p>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.).</p>
<p>This is UHD's new-ish remote device management protocol <a href="https://files.ettus.com/manual/page_mpm.html" class="external">MPM</a>, 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.)</p>
<p>Since I'm oldschool, I'll have to check back on what MPM does internally. I'll be back!</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178522020-03-23T11:16:22Zfunkylab
<ul></ul><p>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):</p>
<pre><code class="cpp syntaxhl"><span class="cm">/*! 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.
*
*/</span>
<span class="n">device_addrs_t</span> <span class="nf">mpmd_find</span><span class="p">(</span><span class="k">const</span> <span class="n">device_addr_t</span><span class="o">&</span> <span class="n">hint_</span><span class="p">)</span>
<span class="p">{</span>
<span class="cp">#ifdef HAVE_DPDK
</span> <span class="p">[</span><span class="err">…</span><span class="p">]</span>
<span class="cp">#endif
</span> <span class="n">device_addrs_t</span> <span class="n">hints</span> <span class="o">=</span> <span class="n">separate_device_addr</span><span class="p">(</span><span class="n">hint_</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">hint_</span><span class="p">.</span><span class="n">has_key</span><span class="p">(</span><span class="s">"type"</span><span class="p">))</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="n">find</span><span class="p">(</span><span class="n">MPM_DEVICE_TYPES</span><span class="p">.</span><span class="n">cbegin</span><span class="p">(),</span> <span class="n">MPM_DEVICE_TYPES</span><span class="p">.</span><span class="n">cend</span><span class="p">(),</span> <span class="n">hint_</span><span class="p">[</span><span class="s">"type"</span><span class="p">])</span>
<span class="o">==</span> <span class="n">MPM_DEVICE_TYPES</span><span class="p">.</span><span class="n">cend</span><span class="p">())</span> <span class="p">{</span>
<span class="n">UHD_LOG_TRACE</span><span class="p">(</span>
<span class="s">"MPMD FIND"</span><span class="p">,</span> <span class="s">"Returning early, type does not match an MPM device."</span><span class="p">);</span>
<span class="k">return</span> <span class="p">{};</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="n">UHD_LOG_TRACE</span><span class="p">(</span><span class="s">"MPMD FIND"</span><span class="p">,</span> <span class="s">"Finding with "</span> <span class="o"><<</span> <span class="n">hints</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o"><<</span> <span class="s">" different hint(s)."</span><span class="p">);</span>
<span class="c1">// Scenario 1): User gave us at least one address</span>
<span class="k">if</span> <span class="p">(</span><span class="n">not</span> <span class="n">hints</span><span class="p">.</span><span class="n">empty</span><span class="p">()</span>
<span class="n">and</span> <span class="p">(</span><span class="n">hints</span><span class="p">[</span><span class="mi">0</span><span class="p">].</span><span class="n">has_key</span><span class="p">(</span><span class="n">xport</span><span class="o">::</span><span class="n">FIRST_ADDR_KEY</span><span class="p">)</span>
<span class="n">or</span> <span class="n">hints</span><span class="p">[</span><span class="mi">0</span><span class="p">].</span><span class="n">has_key</span><span class="p">(</span><span class="n">MGMT_ADDR_KEY</span><span class="p">)))</span> <span class="p">{</span>
<span class="c1">// Note: We don't try and connect to the devices in this mode, because</span>
<span class="c1">// we only get here if the user specified addresses, and we assume she</span>
<span class="c1">// knows what she's doing.</span>
<span class="k">return</span> <span class="n">mpmd_find_with_addrs</span><span class="p">(</span><span class="n">hints</span><span class="p">);</span>
<span class="p">}</span>
<span class="c1">// Scenario 2): User gave us no address, and we need to broadcast</span>
<span class="k">if</span> <span class="p">(</span><span class="n">hints</span><span class="p">.</span><span class="n">empty</span><span class="p">())</span> <span class="p">{</span>
<span class="n">hints</span><span class="p">.</span><span class="n">resize</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
<span class="p">}</span>
<span class="k">const</span> <span class="k">auto</span> <span class="n">bcast_mpm_devs</span> <span class="o">=</span> <span class="n">mpmd_find_with_bcast</span><span class="p">(</span><span class="n">hints</span><span class="p">[</span><span class="mi">0</span><span class="p">]);</span>
<span class="n">UHD_LOG_TRACE</span><span class="p">(</span>
<span class="s">"MPMD FIND"</span><span class="p">,</span> <span class="s">"Found "</span> <span class="o"><<</span> <span class="n">bcast_mpm_devs</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o"><<</span> <span class="s">" device via broadcast."</span><span class="p">);</span>
<span class="p">[</span><span class="err">…</span><span class="p">]</span>
</code></pre>
<p>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.</p>
<p>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.</p>
<p>So, a solution should be to specify the device address.</p>
<p>(I'll be looking into more generally sane methods, too, I'll drop you an email.)</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178552020-03-23T16:20:21Zlaforge
<ul></ul><p>On Mon, Mar 23, 2020 at 11:16:22AM +0000, funkylab [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Is there something like catch-all types for "all USB devices" or "all non-networked devices"?</p>
<blockquote>
<p>So, a solution should be to specify the device address.</p>
</blockquote>
I think a very common use case would be:
<ul>
<li>I know I only have a single device attached, so I don't want to specify the device<br />name / serial number / specific model,</li>
<li>but I also know I don't have any networked/embedded devices and hence have no<br />interest in broadcasting unsolicited messages to all network interfaces</li>
</ul> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178602020-03-24T15:30:23Zfunkylab
<ul></ul><blockquote>
<p>Is there something like catch-all types for "all USB devices" or "all non-networked devices"?</p>
</blockquote>
<p>no, sorry.</p>
<blockquote>
<ul>
<li>I know I only have a single device attached, so I don't want to specify the device<br />name / serial number / specific model,</li>
<li>but I also know I don't have any networked/embedded devices and hence have no<br />interest in broadcasting unsolicited messages to all network interfaces</li>
</ul>
</blockquote>
<p>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?</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178632020-03-25T07:50:17Zlaforge
<ul></ul><p>On Tue, Mar 24, 2020 at 03:30:23PM +0000, funkylab [REDMINE] wrote:</p>
<blockquote><blockquote>
<p>Is there something like catch-all types for "all USB devices" or "all non-networked devices"?</p>
</blockquote>
<p>no, sorry.</p>
</blockquote>
<p>what a pity.</p>
<blockquote><blockquote>
<ul>
<li>I know I only have a single device attached, so I don't want to specify the device<br />name / serial number / specific model,</li>
<li>but I also know I don't have any networked/embedded devices and hence have no<br />interest in broadcasting unsolicited messages to all network interfaces</li>
</ul>
</blockquote>
<p>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?</p>
</blockquote>
<p>This means that we as an application (osmo-trx) would have to ship<br />model-specific config file samples if we don't want to have our users<br />broadcast unsolicited packets. That's rather suboptimal.</p>
<p>Sure, I can live with the current situation. We will probably put a big<br />fat warning in our user manual of osmo-trx describing what the UHD user<br />manual should do.</p>
<p>I just find such design decisions highly questionable. It's one thing<br />to make things easy to use - but making it hard to disable the feature<br />without loosing device auto-detection, is another thing.</p>
<p>I understand that you are just the messenger here. So please don't take<br />any of this directed to you.</p>
If I was involved in the design, I would have considered any of those<br />options (possibly multiple):
<ol>
<li>provide an API for applications so they can control enable/disable of this</li>
<li>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</li>
<li>provide a special 'type=networked' or 'type=usb' or the like</li>
</ol>
<p>What is the best forum to discuss such UHD topics?</p>
<p>Regards,<br /> Harald</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=178642020-03-25T12:21:33Zfunkylab
<ul></ul><blockquote>
<p>this means that we as an application (osmo-trx) would have to ship</p>
</blockquote>
<p>model-specific config file samples</p>
<p>Yeah, I see how that's undesirable!</p>
<blockquote>
<p>Describing what the UHD user manual should do.</p>
</blockquote>
<p>:D If I don't get around to writing that PR for the manual to explicitly state that, first.</p>
<blockquote>
<p>I just find such design decisions highly questionable. It's one thing</p>
</blockquote>
<p>to make things easy to use - but making it hard to disable the feature<br />without loosing device auto-detection, is another thing.</p>
<p>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.</p>
<blockquote>
<p>I understand that you are just the messenger here. So please don't take</p>
</blockquote>
<p>any of this directed to you.</p>
<p>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.</p>
<blockquote>
<p>provide an API for applications so they can control enable/disable of this<br />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</p>
</blockquote>
<p>That's pretty much what I plan to do, yes. API: have a <code>nobroadcast</code> 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.</p>
<blockquote>
<p>provide a special 'type=networked' or 'type=usb' or the like</p>
</blockquote>
<p>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 <code>local</code> flag would be most useful, because <code>type=</code> 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.</p>
<p>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.</p> OsmoTRX - Bug #4469: osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startuphttps://osmocom.org/issues/4469?journal_id=187062020-06-13T18:07:12Zlaforge
<ul><li><strong>Subject</strong> changed from <i>osmo-trx-uhd is sending UDP packets to port 49600 at variousl addresses on startup</i> to <i>osmo-trx-uhd is sending UDP packets to port 49600 at various addresses on startup</i></li></ul>