Jim wrote: > On 10/02/2010 04:44 PM, Jim wrote: >> # ifconfig -a >> eth0 Link encap:Ethernet HWaddr 00:1D:72:A5:DD:B5 >> inet addr:69.243.171.15 Bcast:69.243.175.255 Mask:255.255.248.0 >> inet6 addr: fe80::21d:72ff:fea5:ddb5/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:509708 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:23265 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:59884381 (57.1 MiB) TX bytes:2849745 (2.7 MiB) >> Interrupt:28 Base address:0xc000 >> >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:16436 Metric:1 >> RX packets:153 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:153 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:9086 (8.8 KiB) TX bytes:9086 (8.8 KiB) >> >> # route -n >> Kernel IP routing table >> Destination Gateway Genmask Flags Metric Ref Use >> Iface >> 69.243.168.0 0.0.0.0 255.255.248.0 U 1 0 0 eth0 >> 0.0.0.0 69.243.168.1 0.0.0.0 UG 0 0 0 eth0 >> >> > # tcpdump -i eth0 -n -n > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 16:56:59.415664 ARP, Request who-has 69.243.175.114 tell 69.243.168.1, > length 46 > 16:56:59.586430 ARP, Request who-has 69.243.175.116 tell 69.243.168.1, > length 46 > 16:56:59.696286 ARP, Request who-has 71.25.90.146 tell 71.25.88.1, length 46 > 16:56:59.697488 ARP, Request who-has 98.228.201.211 tell 98.228.200.1, > length 46 [...] > 16:57:10.599762 ARP, Request who-has 68.57.226.27 tell 68.57.224.1, > length 46 > ^C > 172 packets captured > 172 packets received by filter > 0 packets dropped by kernel So, your routing appears to be good, but no sign of packets attempting a connection comes up in the dump. It could be you have a blocking firewall rule for outgoing packets. Is the iptables output you pasted in another mail coming from the server or client machine? We are checking the client's one. What we have understood until now is that the client is not producing packets to create a connection. We still do not know why. Let's go on playing around the tcpdump. - Does your (client) machine connect to the net? Does tcpdump see packets to port 80 when you browser the web? - Now, do you see packets when you try to ssh an IP which works when browsed via web? I mean, go to www.google.com, observe its IP address and then try to ssh to this address; google will refuse the connection, but we have to see that packets are exchanged on port 22. - In the same spirit, let's try to connect via http to your 70.236.39.98 server, by writing http://70.236.39.98/ in your browser. Your server will not respond, but packets must show up. My idea is to understand if the problem is in the IP or on the port. All tests are now on the client, because if there are no outgoing packets, messing with the server is useless. -- Roberto Ragusa mail at robertoragusa.it -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
