MR, Docker creates an abstraction over the physical machine, isolating the software inside from the rest of the machine.
What you are describing is the expected behavior of the default Docker network interface. When you run in --network=host mode, you are telling Docker to by-pass it’s networking layer and to share the host network as if you were a native application. This is the easiest way to get network applications working in Docker, but as you note, there are security issues. Further complicating things, if you are running on Windows or Mac, is that your Docker image actually runs in a lightweight Linux VM running on your computer, because of host operating system limitations. I have no experience with non-native (Linux) Docker, so just know that dealing with physical devices is a non-trivial configuration. Some things (like multicast) are darn near impossible using the Docker network. I don’t know how the UHD discovers the SDR. If you don’t run --network=host, you will to explicitly forward the port(s)/protocol(s) used by your radio to your Docker container. Note that TCP and UDP require separate forwarding rules as needed. Similarly, access to USB devices requires some careful configuration. Again, the host device must be exposed (typically through a volume mount) into the container for the container to see it. The link you shared shows how the USB device is exposed. Note also that the container requires escalated privilege (--privileged) for this to work. What you are observing is less a limitation of GRC and more the normal behavior of Docker. --- Jim Melton From: Discuss-gnuradio On Behalf Of M Esc Sent: Wednesday, October 19, 2022 06:51 To: discuss-gnuradio@gnu.org Subject: [EXTERNAL] GnuRadio within docker container access to ettus/n310 requires host mode network (similar cross post issued to uhd/usrp stack exchange) I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker image, where the image is also loaded up with the 4.10 UHD N310 libraries and osmocom libraries (and some Xterm stuff). I'm running the container of the image on an Ubuntu 20.0.4 host. I can connect my N310 (also running 4.10 UHD libs) to the host and ping the N310. I can fire up the docker image as a container and ping the N310 from within the container. When I run "uhd_find_devices" within the container, the command reports No UHD Devices found. When I run GNR companion within the container and set up a USRP/UHD as a sink with a simple sine wave source, and try to run the blocks, it will fail. However, if I run the container in the docker network=host mode, I can successfully run uhd_find_devices and see the N310's info and can successfully run the GNR companion with a simple USRP/UHD sink. I had a similar experience running a nooelec USB SDR and a pluto USB SDR on the same host, i.e. when attaching the USB radios and then running the container in network=host mode, I could run my GNR Companion blocks successfully, but only when in network=host mode. So it would *appear* that the network=host mode is required to successfully run GNR (either headless or with GNR companion) is required. I also set up and ran the sample non-GNR/headless container created by: https://hub.docker.com/r/openverso/ettus-uhd and found that I also had to add a network=host parameter to the commands listed on that page before I could successfully run a uhd_find_devices against my N310. I'd prefer not to use host network mode for a number of reasons, so wondered if anyone else has experienced this apparent limitation and/or how they solved it. By the way, our group considered trying to use a macvlan network rather than the host network mode, and that might help the N310 access problem, but we don't think that it will solve the same problem that we saw with the USB devices (nooelec/pluto). Bottom line question: has anyone else run into the limitation of running gnuradio source/sink to an external SDR from within a docker container and being forced to use network=host mode? Thanks MR CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You.
