Bought a new router, TP-Link TL-WR841N. Since the day I plugged it in, my Fedora machine will no longer connect to internet. Windows machine didn't have a problem with new router. I have reset the router, re-booted the router, changed the NIC in the Fedora machine. Network manager says that it is connected but no web page will open. The light on the router is on but it isn't blinking. I have no idea what to do. I never expected a problem like this from a Linux OS. I also have a PC-BSD machine and it is connecting to internet with new router. Any ideas?

Fedora box has static IP of 192.168.1.3

It can ping the router and the other computer on the network

It can ping 74.125.227.105 (google) but it will not open in a browser. (Firefox)

resolv.conf returns:
#Generated by NetworkManager
nameserver 192.168.1.1
nameserver 207.69.188.186
nameserver 207.69.188.187

I can access the router's web configuration page. It shows that the Fedora box connected as 192.168.1.3

I set the dns server to 8.8.8.8 and this didn't change anything.
When I open the router page it shows the Fedora box connected.
Are TP-Link routers just Linux unfriendly? I am at wit's end here. Do I just need to buy another router? None of this makes any sense to me. Networking is the absolutely last thing I'd ever have imagined Linux to have a problem with.

As you can ping hosts on the Internet, the router must be working.

It really looks like your problem is related to name resolution and DNS. Which DNS server is the Windows box using? (ipconfig /all will tell you.)

Do any of these commands return the IP address of www.linuxquestions.org?

Windows box is using 8.8.8.8 and 8.8.4.4

Those commands returned:
connection timed out;no servers could be reached

Which means name resolution isn't working. What happens if you run the exact same commands on the Windows box? (nslookup works the same way on both platforms.)

you know if your using a cable company for your internet connection they use your UID mac address and associate it with your Password. If you used the old router to set up
the internet connection with the IP this would cause it. Usually you should set up the IP with your computer and clone your mac ID to the router.

And this also may be the cause this. Some routers have the option to clone your mac or you manually have to do it if you did set up your connection with your computer.
My old buffalo when set to auto dhcpd will automatically clone my mac for me.

I will be getting a lesson on att uverse this week I need to learn that system. But I have a feeling it will be very close to the same.

as for a DSL line it should be static or auto dhcpd.

Got this:

***Can't find server name for 192.168.1.1: Non-existent domain
Server UnKnown
Address: 192.168.1.1

Non-authoritative answer:
Name: www.linuxquestions.org
Address: 75.126.162.205

For nslookup on 8.8.4.4 I got:

Server: google-public-dns-b.google.com
Address: 8.8.4.4

Non-authoritative answer:
Name: www.linuxquestions.org
Address: 75.126.162.205

So the TP-Link router obviously has a working DNS proxy service. There's no reason why this service shouldn't also respond to requests from 192.168.1.3, so something must be blocking/filtering either the requests or the responses.

Could you post the output from iptables-save on the Fedora box?

Also, the output from arp -an on the Fedora box and arp -a on the Windows box immediately after ping 192.168.1.1 could be of interest, just to confirm that both boxes are reporting the same MAC address for 192.168.1.1.

2 members found this post helpful.

iptables-save returns:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3448:268173]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp-j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 631 -j ACCEPT
-A INPUT -d 224.0.0.251/32 -p udp -m state --state NEW -m udp --dport 5353 ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 631 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 631 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-probibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

arp -an on Fedora:
? (192.168.1.1) at 64:70:02:9e:49:d6 [ether] on p1p1

arp -a on Windows:
Interface: 25.160.72.19 --- 0x2
Internet Address Physical Address Type
25.0.0.1 7a-79-19-00-00-01 dynamic

Interface: 192.168.1.2 --- 0x3
Internet Address Physical Address Type
192.168.1.1 64-70-02-9e-49-d6 dynamic

From your resolv.conf output, you appear to be using Earthlink as your nameserver. Have you considered, e.g. OpenDNS? (You can specify the explicit namserver addresses in your connection profile(s).

For example, my version of the resolv.conf looks like this:where the 208.67... addresses are for OpenDNS, and the two non-routable addresses are for the two routers (one cable, one wireless) on my local network.

(And, in case you wondered, "bedroom" is this system's localhost name, not some weird porn site to be searched.)

This is proving to be quite an interesting problem. The layer 2 (Ethernet) and 3 (IP) connection seems to be working fine, as the MAC/IP mapping is correct, you can ping Internet hosts, and there are no blocking rules in the firewall. Yet layer 4 connections fail.

I guess it could be an MTU-related (hardware) issue. By default, the ping command sends a payload of only 64 bytes, and most sessions involving a transport protocol will have a payload significantly larger than that.

Try pinging the local router with increasingly larger packets:If this works (as it should on a functioning Ethernet network), try running nslookup in one terminal window while tcpdump is monitoring the interface in another window.

Terminal windows 1:Terminal window 2:Then post the output from the tcpdump session.

Slightly OT: The "search" parameter in resolv.conf is for specifying domain suffixes, not host names. Your entry will cause the resolver to append ".bedroom" to any queries that fail to resolve, and I'm pretty sure that's not what you want.

O.K. In my case, I don't have a local domain name, so I couldn't care less what the resolver does when if fails. (There's nothing to be done after failure.) But, yes, I misspoke: I should have said "local domain name."

But, please, let's not hijack this thread on illrevelancies.

From the OPer's comments, I had assumed that he was pinging using actual addresses, not DNS lookup results, and thought that another DNS provider might shed some light on the problem.

Pinging larger packets worked fine.
Results of tcpdump:

listening on p1p1, link-type EN10MB (Ethernet) capture size 65
535 bytes
16:23:51.455781 IP 192.168.1.3.47801 > 8.8.8.8.domain:19796+A? ping3.teamviewer.com.(38)
16:23:51:455899 IP 192.168.1.2.47801 > 8.8.8.8.domain:16176+ A AAA? ping3.teamviewer.com (38)

and similar lines until I stopped it with these results:
31 packets captured
31 packets received by filter
0 packets dropped by Kernel

Oh, and the nslookup returned it's usual since the beginning of this problem:
;;connection timed out;trying next origin
;;connection timed out;no servers could be reached