[SOLVED] Internet connection gone since bought new router
FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
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.
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.
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.)
Got this:
***Can't find server name for 192.168.1.1: Non-existent domain
Server UnKnown
Address: 192.168.1.1
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.)
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.
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.
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:
Code:
$ cat /etc/resolv.conf
# Generated by NetworkManager
search bedroom
nameserver 208.67.220.220
nameserver 208.67.222.222
nameserver 192.198.1.1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 10.0.0.1
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.
(And, in case you wondered, "bedroom" is this system's localhost name, not some weird porn site to be searched.)
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.
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.
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:
Code:
tcpdump -i <interface_name> -n udp port 53
Terminal window 2:
Code:
nslookup -q=a www.linuxquestions.org 192.168.1.1
Then post the output from the tcpdump session.
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.