Maybe somebody with more experience will chime in here ... (Consider that an invitation
)
But my take is that you are getting to the Internet fine with UDP packets. Specifically a) you have no problem with DNS resolution (it translates
yahoo.com into
206.190.60.37 w/o problems) and b) The UDP packets used by
traceroute seems to go out fine. (I thought it should be ICMP packets coming back, but that, I presume, is my ignorance, not an issue with your system.) For the record, I just did a
tracepath (similar to
traceroute) to yahoo.com, and, like you, I ceased getting responses at some point once I was within the yahoo.com domain. So I don't see that you have an problem there.
So the question is, what is happening to the TCP packets. You've actually introduced me to the the
-s option for
netstat (thanks!), but my understanding of the output is that your computer sent a
reset packet on every TCP connection attempt. So the question is why.
First, lets makes sure this isn't a firewall issue. You seem to be behind some sort of router or NAT device (192.168.1.1), so there shouldn't be much risk in turning off your firewall (on the Fedora 9 system -- if you have one) for a brief test. (Sorry. While I imagine there is a way to do that in a GUI, I am not sure what it is. But you should be able to easily find out.) If that doesn't fix the problem and if you know how, check what the settings are on whatever 192.168.1.1 is and make sure it isn't blocking. (
Never mind -- see my last sentence in this post. And if you need to post back for more help, let us know what that device is.) If this doesn't solve things,
as root give the following command and then use your browser to try to go to some website.
Code:
tcpdump -nni eth0 -c 10
This will show the first 10 packets sent/received through eth0. (I am assuming you don't have extraneous traffic that we need to filter out.) Below is the result I got when I went to
www.linuxtoday.com. I've highlited the "3 packet handshake" which gets TCP connections started; after that is the exchange of actual data. (The fourth packet is just a repeat of the third with the "PUSH" flag set. My system was getting impatient for a reply.) The first two packets (prior to the handshake) is the DNS request to find the IP address of
www.linuxtoday.com. And I've obfuscated some IP addresses with the letter "x." The "not tcp port 22" in the command was to filter out local SSH traffic.
Code:
root@box:~# tcpdump -nni eth0 -c 10 not tcp port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:16:43.106892 IP 192.168.xx.xx.32920 > xx.xx.xx.xx.53: 16088+ A? www.linuxtoday.com. (36)
01:16:43.290246 IP xx.xx.xx.xx.53 > 192.168.xx.xx.32920: 16088 1/0/0 A 63.236.73.20 (52)
01:16:43.290331 IP 192.168.xx.xx.56602 > 63.236.73.20.80: S 3585483026:3585483026(0) win 5840 <mss 1460,sackOK,timestamp 1874882 0,nop,wscale 2>
01:16:43.470286 IP 63.236.73.20.80 > 192.168.xx.xx.56602: S 3462935632:3462935632(0) ack 3585483027 win 5792 <mss 1460,sackOK,timestamp 684055805 1874882,nop,wscale 7>
01:16:43.470306 IP 192.168.xx.xx.56602 > 63.236.73.20.80: . ack 1 win 1460 <nop,nop,timestamp 1874927 684055805>
01:16:43.470366 IP 192.168.xx.xx.56602 > 63.236.73.20.80: P 1:278(277) ack 1 win 1460 <nop,nop,timestamp 1874927 684055805>
01:16:43.710277 IP 63.236.73.20.80 > 192.168.xx.xx.56602: . ack 278 win 54 <nop,nop,timestamp 684055830 1874927>
01:16:44.400541 IP 63.236.73.20.80 > 192.168.xx.xx.56602: . 1:1449(1448) ack 278 win 54 <nop,nop,timestamp 684055880 1874927>
01:16:44.400566 IP 192.168.xx.xx.56602 > 63.236.73.20.80: . ack 1449 win 2184 <nop,nop,timestamp 1875160 684055880>
01:16:44.549119 IP 63.236.73.20.80 > 192.168.xx.xx.56602: . 1449:2897(1448) ack 278 win 54 <nop,nop,timestamp 684055880 1874927>
10 packets captured
21 packets received by filter
0 packets dropped by kernel
Hmmm. Upon reviewing my post, I don't see how 192.168.1.1 could be causing your Fedora 9 host to send reset packets. But it still
might be useful for us to know what it is.
