Forum: GNU Radio non root access to usrp2 on Fedora 10

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2008-12-02 22:43
(Received via mailing list)
Hi all, I looked over the wiki and the mailing list but could not find
mention of how to access the usrp2 as a non-root user on Fedora 10.

As root, I get the following response from "find_usrps":

00:50:c2:85:30:68 hw_rev = 0x0300

but as a user, I get:

socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted
eth0: socket: No such file or directory
No USRP2 found.

I'm using svn checkout 10025.

Any suggestions?

thanks!

eric
unknown (Guest)
on 2008-12-03 19:14
(Received via mailing list)
Thank you very much for your response.  If I wanted to provide access
through suid, which file should be set suid?
Chris Albertson (Guest)
on 2008-12-03 19:53
(Received via mailing list)
>> For the foreseeable future, all USRP2 access must run as root.  You
>> could use suid (dangerous) or sudo (maybe a little less dangerous)
>> to allow non-root users to execute stuff as root, but it is always a
>> security risk to allow non-root users to execute
>> unstable/development code as root.  Another option might be to use
>> some sort of virtualization to give root access only on a virtual
>> machine and not the host OS; I believe that would work in vmware
>> with a bridged ethernet interface, but I'm not sure about other
>> virtualization tools.

I don't think the raw packets would be routeable on the virtual Ethernet

Logging in and running as root is actually more of a risk then is suid.

In both cases the SDR process runs as uid=0 but in the case of a root
login every process runs with uid=0.  Better to just set the one
trusted process as suid.

The best option would be to use UDP on the Ethernet connection then
the problem would just go away.  But then the problem of reduced
bandwidth and the larger code in the USRP.

A compromise I've seen is a "hack".  We call it "blindly blasted UDP".
 You write a special case network stack that only works on a point to
point Ethernet.  You don't even check for collisions at the Ethernet
level.
The UDP headers are fixed compile-time constants.  With this kind of
stack you get near wire speed bandwidth and very small code space,  So
much of a conventional stack is queueing and retry and error handling.
 This hack leaves all of that stuff out

This was used in a small AVR micro controller.  The application
sampled a sensor and then sent the value via UDP, one UDP packet per
sensor readout in a fast loop.

A device sending "blindly blast UDP" would take down a normal network.
 or a switch would disconnect it so it could only be used on a point
to point wired network.  But the advantage is that being UDP you don't
need special software on the computer to get the data.
--
=====
Chris Albertson
Redondo Beach, California
Gregory M. (Guest)
on 2008-12-03 23:02
(Received via mailing list)
On Tue, Dec 2, 2008 at 7:49 PM, Chris Albertson
<removed_email_address@domain.invalid> wrote:
[snip]
> A compromise I've seen is a "hack".  We call it "blindly blasted UDP".
>  You write a special case network stack that only works on a point to
> point Ethernet.  You don't even check for collisions at the Ethernet
> level.

Yes. You use a multicast destination MAC so you do not need to
participate in ARP.

Other than having to store a static packet header, you don't need to
do very much.

Maybe a little code to allow a root owned process to send the proper
destination address over the wire.
unknown (Guest)
on 2008-12-04 11:02
(Received via mailing list)
If I want to run the example program usrp2_fft.py, which routines
(python
and/or c++) need to be made suid?

thanks,
eric
unknown (Guest)
on 2008-12-04 11:58
(Received via mailing list)
Michael-

I found that setting usrp2_fft.py suid doesn't work:

[matlis@quadzilla z.research]$ ls -l /usr/local/bin/usrp2_fft.py
-rwsr-xr-x 1 root root 9915 2008-12-02 19:03 /usr/local/bin/usrp2_fft.py

This is the same permissions as ping, so I thought it would work:

[matlis@quadzilla ~]$ ls -l /bin/ping
-rwsr-xr-x 1 root root 41784 2008-09-26 02:02 /bin/ping

when I run usrp2_fft.py however, I get the following error:

[matlis@quadzilla ~]$ usrp2_fft.py
socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted
eth0: socket: No such file or directory
Traceback (most recent call last):
   File "/usr/local/bin/usrp2_fft.py", line 267, in <module>
     main ()
   File "/usr/local/bin/usrp2_fft.py", line 263, in main
     app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
36, in __init__
     wx.App.__init__ (self, redirect=False)
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7935, in __init__
     self._BootstrapApp()
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7509, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
39, in OnInit
     frame = stdframe (self.top_block_maker, self.title, self._nstatus)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
60, in __init__
     self.panel = stdpanel (self, self, top_block_maker)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
81, in __init__
     self.top_block = top_block_maker (frame, self, vbox, sys.argv)
   File "/usr/local/bin/usrp2_fft.py", line 68, in __init__
     self.u = usrp2.source_32fc(options.interface, options.mac_addr)
   File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py",
line
449, in source_32fc
     return _usrp2.source_32fc(*args)
RuntimeError: No USRPs found on interface eth0

so does this mean some other component must be made suid as well?

thanks,
eric
unknown (Guest)
on 2008-12-04 12:11
(Received via mailing list)
In terms of using sudo, there is some issue with the environment
variables
not being passed:

[matlis@quadzilla ~]$ sudo usrp2_fft.py
[sudo] password for matlis:
sudo: usrp2_fft.py: command not found

[matlis@quadzilla ~]$ sudo /usr/local/bin/usrp2_fft.py
execlp: couldn't exec usrp2_socket_opener: No such file or directory
eth0: socket: Bad file descriptor
Traceback (most recent call last):
   File "/usr/local/bin/usrp2_fft.py", line 267, in <module>
     main ()
   File "/usr/local/bin/usrp2_fft.py", line 263, in main
     app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
36, in __init__
     wx.App.__init__ (self, redirect=False)
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7935, in __init__
     self._BootstrapApp()
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7509, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
39, in OnInit
     frame = stdframe (self.top_block_maker, self.title, self._nstatus)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
60, in __init__
     self.panel = stdpanel (self, self, top_block_maker)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
81, in __init__
     self.top_block = top_block_maker (frame, self, vbox, sys.argv)
   File "/usr/local/bin/usrp2_fft.py", line 68, in __init__
     self.u = usrp2.source_32fc(options.interface, options.mac_addr)
   File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py",
line
449, in source_32fc
     return _usrp2.source_32fc(*args)
RuntimeError: No USRPs found on interface eth0
eth0: socket: Operation not permitted
Traceback (most recent call last):
   File "/usr/local/bin/usrp2_fft.py", line 267, in <module>
     main ()
   File "/usr/local/bin/usrp2_fft.py", line 263, in main
     app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
36, in __init__
     wx.App.__init__ (self, redirect=False)
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7935, in __init__
     self._BootstrapApp()
   File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line
7509, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
39, in OnInit
     frame = stdframe (self.top_block_maker, self.title, self._nstatus)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
60, in __init__
     self.panel = stdpanel (self, self, top_block_maker)
   File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line
81, in __init__
     self.top_block = top_block_maker (frame, self, vbox, sys.argv)
   File "/usr/local/bin/usrp2_fft.py", line 68, in __init__
     self.u = usrp2.source_32fc(options.interface, options.mac_addr)
   File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py",
line
449, in source_32fc
     return _usrp2.source_32fc(*args)
RuntimeError: No USRPs found on interface eth0


eric
unknown (Guest)
on 2008-12-04 12:13
(Received via mailing list)
Update-

making sudo chmod u+s /usr/local/bin/usrp2_socket_opener

allows usrp2_fft.py to work (also as suid) by a normal user.

thanks!

I would be interested in trying the sudo approach, but as I mentioned in
my previous post there are some issues perhaps with sudo not knowing
about
the path or other environment variables.

eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
121 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355
Matt E. (Guest)
on 2008-12-04 14:35
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> knowing about the path or other environment variables.
making usrp2_socket_opener suid root is the best way to set things up.
This allows us to use the least privileges possible on all other
programs, and usrp2_socket_opener is a nice short program that can
easily be audited.

Note that if you do a make install again it may overwrite your
usrp2_socket_opener, and then it won't have the permissions set
anymore.  You can get by this by putting the suid copy in your ~/bin
directory, which won't be overwritten every time.

Matt
This topic is locked and can not be replied to.