uhd_find_devices →
linux; GNU C++ version 4.4.1; Boost_103800;
UHD_0001.20101216232717.a78a72f
No UHD Devices Found
-
Used the latest UHD code by git pull
-
Used the latest firmware in
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
-
Prepared SD using
sudo ./u2_flash_tool --dev=/dev/sdc -t s/w usrp2_fw.bin
-w
sudo ./u2_flash_tool --dev=/dev/sdc -t fpga usrp2_fpga.bin
-w
-
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
10.13.0.0 0.0.0.0 255.255.0.0 U 0 0 0
eth1
0.0.0.0 10.13.0.1 0.0.0.0 UG 100 0 0
eth1
-
ping is working nice.
ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=32 time=3.31 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=32 time=0.073 ms
64 bytes from 192.168.10.2: icmp_seq=3 ttl=32 time=0.043 ms
64 bytes from 192.168.10.2: icmp_seq=4 ttl=32 time=0.063 ms
Any idea??
On 12/17/2010 06:00 PM, Josh B. wrote:
firewall perhaps? try this:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#debugging-networking-problems
I’ve found that on recent Fedoren, uhd_find_devices doesn’t work, but if
I explicitly:
uhd_usrp_probe --args “addr=192.168.10.2”
It works just fine.
I haven’t tracked down the exact firewall rules that cause this to
happen yet.
Josh: how does uhd_find_devices do its thing? Does it send out a UDP
broadcast, and if so, how does the USRP2 respond?
This will help me figure out what particular firewall rule is getting
in the way.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 12/17/2010 06:16 PM, Marcus D. Leech wrote:
Ok from the docs:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#debugging-networking-problems
Disable the firewall: If uhd_find_devices gives you nothing but
uhd_find_devices --args addr=192.168.10.2 yeilds a discovered device,
then your firewall may be blocking replies to UDP broadcast packets.
If you dont specify an address. UHD sends a broadcast on each interface.
From when I last tested, i think the usrp2 did indeed get the packet and
send the reply, which means that the firewall blocked the response. This
can also be confirmed with wireshark.
Disabling the firewall entirely seems to fix it. Thats using a
sledgehammer when you need a chisel. 
-josh
-A INPUT -m state --state NEW -m udp -p udp --sport 49152:49153
–dport 1024:65535 -j ACCEPT
You should just need 49152 to be open. The broadcasts only occur on the
control port.
Appears to allow uhd_find_devices to do its thing.
Glad to hear it!
Any protocol that does “discovery” using a UDP broadcast, followed by
a unicast reply will run into trouble with iptables, which is why
Basically the firewall lets devices talk back through port that
initiated the conversation. Because of this, UHD sends an data packet
into the USRP2 even for receive only applications. 
However, this simple firewall rule will not, in the case of a broadcast
open a reply hole for every device talking through that port.
I guess its just another one of those things you do to prepare a host
system for use. Just like setting up udev, or sysctl limits.
-josh
On 12/17/2010 09:56 PM, Josh B. wrote:
Disabling the firewall entirely seems to fix it. Thats using a
sledgehammer when you need a chisel.
-josh
The “most elegant” way to solve this is with a “conntrack” module for
the kernel, a la the conntrack
module for netbios-ns and snmp. But in lieu of that, the following
line in /etc/sysconfig/iptables
(on Fedoren):
-A INPUT -m state --state NEW -m udp -p udp --sport 49152:49153 --dport
1024:65535 -j ACCEPT
Appears to allow uhd_find_devices to do its thing.
Any protocol that does “discovery” using a UDP broadcast, followed by a
unicast reply will run
into trouble with iptables, which is why “conntrack” modules were
invented to handle
specific protocols that use a broadcast “discovery” phase. While there
appears to have been
discussion of a “generic” conntrack module to cover this case, it
doesn’t appear to have been
worked on.
The problem with the iptables config line above is that it doesn’t
quite provide the required security
semantic that would be provided by a conntrack module. But it will
suffice for now.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
HI!
I can’t find usrp2 with the command “uhd_find_devices --args
addr=192.168.10.2”
it got the rusrlut : no devices found
I visit the website
http://files.ettus.com/uhd_docs/manual/html/usrp2.html
and try the method ,but I still cannot find the usrp2!!
I CHANGED the ip address of the usrp2 before,but I FOGOT it now.
Do you know the reason?