Hi all,
This a follow-up to an old thread, in case anyone runs into a similar
problem.
I can see the data coming in from the roach via the 10gbe using Tcpdump
and Wireshark with the correct IP address and port, but I never was able
to get data using this Python socket. Still puzzled. However, I
I think that the ROACH design team does fairly sophisticated thermal
analysis using a model of enclosure, PCB and cooling fans. Is this
analysis available yet for ROACH 2 and where might I find some data?
Is it possible extrapolate from the models (or perhaps rerun the
models) to predict h
I never had any problem reading the data with UDP sockets. Can you
post some code that doesn't work, the output of 'ip addr' (you're on
Linux, right?), Wireshark output (a .pcap file, perhaps) containing a
couple packets (not tons -- one or two will suffice), and the output
of 'iptables -L -n -v'?
Sure. I posted the code earlier and the consensus was that it ought to
work. Instead, it simply hangs on the recv line. Here it is again:
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('10.0.0.30', 6))
data = s.recv(5000)
And here are the outputs of iptables, tcpdump, and ifc
I've seen this occur when the port is not opened in the firewall.
-Terry
On Oct 28, 2010, at 3:05 PM, mch...@physics.ucsb.edu wrote:
> Sure. I posted the code earlier and the consensus was that it ought to
> work. Instead, it simply hangs on the recv line. Here it is again:
>
> s = socket.so
Hi, Sean,
On Oct 28, 2010, at 3:05 PM, mch...@physics.ucsb.edu wrote:
> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> s.bind(('10.0.0.30', 6))
> data = s.recv(5000)
>
> [r...@arcons controlScripts]# /usr/sbin/tcpdump -xx -i eth1 -c 1
> tcpdump: verbose output suppressed, use -v or -
Hi Dave,
Good eye. Sorry, I corrected that recent blunder, but I still have the
same problem. I also added the port to the firewall, as Terry suggested
(though I'm not sure I did that correctly). No luck yet, the Python udp
socket still fails.
[r...@arcons sysconfig]# /sbin/iptables -L -n
Chai
Could it be a route problem since it works when you bind to the
interface but not to the IP? What does your routing table show?
On Thu, Oct 28, 2010 at 3:47 PM, wrote:
> Hi Dave,
>
> Good eye. Sorry, I corrected that recent blunder, but I still have the
> same problem. I also added the port to
Rule order matters with iptables. Move the "state NEW udp dpt:6"
rule to above the "reject-with icmp-host-prohibited" rule.
Billy
mch...@physics.ucsb.edu wrote:
> Hi Dave,
>
> Good eye. Sorry, I corrected that recent blunder, but I still have the
> same problem. I also added the port to t
> Rule order matters with iptables. Move the "state NEW udp dpt:6"
> rule to above the "reject-with icmp-host-prohibited" rule.
That worked! Thanks a lot, gents.
Sean
Glad you got it going, Sean! Here's one more tidbit for you...
On Oct 28, 2010, at 3:47 PM, mch...@physics.ucsb.edu wrote:
> [r...@arcons controlScripts]# /usr/sbin/tcpdump -xx -i eth1 -c 1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-ty
If you're using the Python wrapper, you can check the status of the ARP table
and core config easily with a little debug function that prints this info to
the screen. A correctly-configured 10GbE core should look something like this
(where I'm using IP addresses around 10.0.0.128):
In [1]: impo
12 matches
Mail list logo
