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, <[email protected]> wrote: > 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 > Chain INPUT (policy ACCEPT) > target prot opt source destination > RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0 > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0 > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain RH-Firewall-1-INPUT (2 references) > target prot opt source destination > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255 > ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 > ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 > ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353 > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp > dpt:22 > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-host-prohibited > ACCEPT udp -- 0.0.0.0/0 10.0.0.30 state NEW udp > dpt:60000 > > > > [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 > 15:36:14.437538 IP 10.0.0.20.60000 > 10.0.0.30.60000: UDP, length 4104 > 0x0000: ffff ffff ffff 0202 0a00 0014 0800 4500 > 0x0010: 1024 0000 4000 ff11 5797 0a00 0014 0a00 > 0x0020: 001e ea60 ea60 1010 0000 0000 0000 0000 > 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0040: ffff 0000 ffff 0000 0000 0000 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 1 packets captured > 557 packets received by filter > 498 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:653515510 errors:10395 dropped:0 overruns:0 frame:10395 > TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2710843329882 (2.4 TiB) TX bytes:4575 (4.4 KiB) > Interrupt:98 Memory:fb8ff000-fb8fffff > > I'm using Scietific Linux (essentially RHEL 5). Thanks for the help. > > > Sean > > >> Hi, Sean, >> >> On Oct 28, 2010, at 3:05 PM, [email protected] wrote: >> >>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) >>> s.bind(('10.0.0.30', 60000)) >>> data = s.recv(5000) >>> >>> [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 >>> >>> [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 >>> >>> Note, the design I'm running has the roach sending 4104 byte packets. >> >> tcpdump shows data going from 10.0.0.30 to 10.0.0.20 (which I assume is >> the ROACH sending data to what it thinks is your server's IP address), yet >> ifconfig shows that your server's eth1 IP address is 10.0.0.30. Based on >> what tcpdump shows the ROACH to be doing, it seems that eth1 needs to have >> IP address 10.0.0.20. Likewise, I think the python code needs to bind to >> 10.0.0.20. I think this is why you get data using raw sockets (which >> ignores IP addressing), but not using UDP/IP (which heeds IP addressing). >> >> Hope this helps, >> Dave >> >> >> > > > >
