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', 60000))
data = s.recv(5000)
And here are the outputs of iptables, tcpdump, and ifconfig:
[r...@arcons controlScripts]# /sbin/iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
198K 78M RH-Firewall-1-INPUT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 87381 packets, 36M bytes)
pkts bytes target prot opt in out source
destination
Chain RH-Firewall-1-INPUT (2 references)
pkts bytes target prot opt in out source
destination
7973 1577K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
250 9904 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 255
0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0
2816 586K ACCEPT udp -- * * 0.0.0.0/0
224.0.0.251 udp dpt:5353
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:631
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:631
76657 64M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
7 384 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:22
110K 12M REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
[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-type EN10MB (Ethernet), capture size 96 bytes
14:51:17.089028 IP 10.0.0.30.60000 > 10.0.0.20.60000: UDP, length 4104
0x0000: ffff ffff ffff 0202 0a00 001e 0800 4500
0x0010: 1024 0000 4000 ff11 5797 0a00 001e 0a00
0x0020: 0014 ea60 ea60 1010 0000 0000 ffff 0000
0x0030: 0000 0000 ffff 0000 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000
1 packets captured
579 packets received by filter
520 packets dropped by kernel
[r...@arcons controlScripts]# /sbin/ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:07:43:06:DA:32
inet addr:10.0.0.30 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::207:43ff:fe06:da32/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:490204371 errors:10393 dropped:0 overruns:0 frame:10393
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2033128444178 (1.8 TiB) TX bytes:4575 (4.4 KiB)
Interrupt:98 Memory:fb8ff000-fb8fffff
Note, the design I'm running has the roach sending 4104 byte packets.
Thanks for the help.
Sean
> 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'? (You'll need to be root for the iptables
> command to work.)
>
> The first thing to check is that you programmed something vaguely
> intelligent into the MAC table. (Note: tgtap supposedly does this for
> you, but I wrote my stuff back when tgtap was somewhere between mostly
> and completely nonfunctional, at least when controlled via katcp.)
>
> --Andy
>
> On Thu, Oct 28, 2010 at 5:17 PM, <[email protected]> wrote:
>> 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
>> returned
>> to this problem recently, and managed to get data using a raw socket
>> with
>> the following Python code:
>>
>> from socket import *
>> s = socket(AF_PACKET, SOCK_RAW, htons(3))
>> s.setsockopt(SOL_SOCKET, SO_RCVBUF, 2**30)
>> s.bind(('eth1', 3)
>> # my packet is 4096 B
>> data = s.recv(4138)
>>
>> This gives you the data packet as well as the 42 byte packet header.
>>
>>
>> Sean
>>
>>
>>
>
>
