Website nicht erreichbar - aber warum?

So, bin wieder daheim. Mal Butter bei die Fische:

Code: 
~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:21:85:3a:71:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever

Code: 
~ $ ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse 00:21:85:3a:71:16  
          inet Adresse:192.168.0.11  Bcast:192.168.0.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:9183 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:7958 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:6976439 (6.9 MB)  TX-Bytes:1765829 (1.7 MB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:703 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:703 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:67099 (67.0 KB)  TX-Bytes:67099 (67.0 KB)

Code: 
~ $ route -e
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
default         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     *               255.255.255.0   U         0 0          0 eth0

Code: 
cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

127.0.1.1 ???

Code: 
~ $ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	Hermes-MS-7360

#	 The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 ???

Mal abgeändert in 127.0.0.1. Name == Der Rechner selbst.

Aber: Hier auf's Forum sowie die sonst von mir besuchten Seiten (diverse Foren, eBay, amazon, etc.) gehen ja auch...
_____

Noch etwas: Die Änderungen, welche ich über die Netzwerkadmin GUI gemacht habe -> wurden nicht übernommen. Fail bei Linux Mint?

Grüße, Martin
 
Ähm, hat auch mal jemand an DualStack (Lite) gedacht? Bei Kabel-Anschlüssen sind die doch mit DS-Lite angebunden, also auch die WAN-IP des Modems/Routers ist eine private und wird beim Provider ins Internet maskiert.
Die Frage ist dann nur, warum für einen PC nochmal ein Zwischenweg genommen wird.
 
127.0.1.1 ist ebenfalls der lokale Rechner und es ist völlig normal, dass diese IP in der /etc/hosts auftaucht. Als ungewöhnlich sehe ich dessen Auftauchen aber in der resolv.conf an. Vermutlich wurde das durch den NetworkManager eingetragen, also muss man in dessen Konfiguration schauen (möglicherweise /etc/NetworkManager/*), was da nun genau als DNS benutzt wird.

MfG Dalai
 
Liberty Global. Du bist per Kabel-Modem und per DS-Lite verbunden. Das spinnt öfter mal rum bei UnityMedia und Co. Am Besten mal das Kabelmodem neu starten und/oder einen Werksreset machen, als ersten Ansatz.
 
Zuletzt bearbeitet:
Was ich dann nicht verstehe: Von der Windows-Kiste aus kein Problem, zeitgleich unter Linux explizit und reproduzierbar die eine Seite nicht erreichbar?

Grüße, Martin
 
Die 127.0.1.1 in der resolv.conf kommt vom dnsmasq der hier offenbar verwendet wird.
 
tomturbo schrieb:
Die 127.0.1.1 in der resolv.conf kommt vom dnsmasq der hier offenbar verwendet wird.
Zum Vergrößern anklicken....
Code: 
~ $ sudo apt-get remove dnsmasq
[sudo] password for amy: 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Package 'dnsmasq' is not installed, so not removed
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Grüße, Martin
 
Dann würde ich empfehlen mit netstat -tanp zu gucken wer auf dem 127.0.1.1 horcht um den "Übeltäter" ausfindig zu machen, der dns vorgibt zu tun.
Glasauge hab ich leider auch keins.
 
Ich hatte ja eigentlich auch ein route -C vorgeschlagen, theoretisch dürfte da nicht viel drinstehen (eher: garnix) aber wer weiß. route -C zeigt den routen cache.
 
Code: 
route -C 
Kernel-IP-Routencache
Ziel            Ziel            Genmask         Flags Metric Ref    Ben Iface
______

Ich habe gestern abend einen Raspberry Pi 2 frisch mit Ubuntu Mate aufgesetzt und ans Netzwerk angeschlossen. 9gag.com läd... Zwar langsam, aber die Seite kommt...

Ich gehe daher noch immer von einem Problem bei der Netzwerkkonfiguration der Linuxkiste aus. Nur wo genau das Problem liegt -> kein Plan.

Grüße, Martin
 
Und was sagt "netstat -tanp", wie tomturbo ? Lass dir doch nicht alles aus der Nase ziehen. ;)

Kannst das netstat -tanp auch auf "netstat -tanp | grep 127.0.1.1" erweitern, das zeigt dann nur die 127er Treffer. Wenn du nur "-tap" nimmst löst es das ganze auf, -tanp zeigt nur IP und Port.

*edit: Ok, hab grade mal etwas gegoogelt, bei vielen Debian basierenden (und damit auch Ubuntu usw) ist das wohl ein Workaround für die DNS Auflösung des localhosts und sollte nix mit dem Problem zu tun haben.

Bin mir grad nicht sicher, hast du schon mal von dem fraglichen System aus mit einer Live CD getestet?
 
Zuletzt bearbeitet:
Anfrage vom Pi 2 aus - der nun das gleiche Problem hat (siehe unten).

Code: 
sudo netstat -tanp
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      958/smbd        
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      626/systemd-resolve
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      721/dnsmasq     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      2072/cupsd      
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      958/smbd        
tcp        0      0 192.168.0.12:56894      198.47.127.11:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:60654      172.227.149.91:80       TIME_WAIT   -               
tcp        0      0 192.168.0.12:38629      62.67.193.23:80         VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:42098      199.38.164.156:80       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:44190      23.235.43.129:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:34940      8.30.11.13:80           VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:52810      2.17.214.8:80           VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:45869      173.194.112.90:80       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:44575      2.20.116.174:80         VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:37883      109.193.192.192:80      TIME_WAIT   -               
tcp        0      0 192.168.0.12:56893      198.47.127.11:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:56896      198.47.127.11:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:49197      85.13.128.193:443       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:53708      173.194.112.217:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:45868      173.194.112.90:80       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:37845      109.193.192.192:80      TIME_WAIT   -               
tcp        0      0 192.168.0.12:44450      185.29.133.33:80        TIME_WAIT   -               
tcp        1      0 192.168.0.12:50506      195.24.232.208:80       CLOSE_WAIT  4154/rhythmbox  
tcp        0      0 192.168.0.12:32845      188.40.60.146:443       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:35188      173.192.220.64:80       TIME_WAIT   -               
tcp        0      0 192.168.0.12:35187      173.192.220.64:80       TIME_WAIT   -               
tcp        0      0 192.168.0.12:40393      62.67.193.21:80         VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:39376      31.186.225.24:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:56172      104.74.86.35:80         VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:35186      173.192.220.64:80       TIME_WAIT   -               
tcp        0      0 192.168.0.12:49430      152.163.50.3:80         VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:60155      104.74.108.70:443       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:52496      173.194.112.252:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:56892      198.47.127.11:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:48680      148.251.247.207:443     VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:52773      2.17.214.8:80           VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:43066      173.194.116.122:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:56895      198.47.127.11:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:57492      104.74.108.185:80       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:40833      165.254.30.166:80       TIME_WAIT   -               
tcp        0      0 192.168.0.12:58821      54.192.45.226:80        VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:37888      109.193.192.192:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:52795      2.17.214.8:80           VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:37889      109.193.192.192:80      TIME_WAIT   -               
tcp        0      0 192.168.0.12:53707      173.194.112.217:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:54854      178.236.4.159:80        VERBUNDEN   1269/chromium-brows
tcp        1      0 192.168.0.12:42474      178.20.9.25:80          CLOSE_WAIT  1269/chromium-brows
tcp        1      0 192.168.0.12:35389      195.24.232.207:80       CLOSE_WAIT  4154/rhythmbox  
tcp        0      0 192.168.0.12:37856      109.193.192.192:80      VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:55651      74.201.214.143:80       VERBUNDEN   1269/chromium-brows
tcp        0      0 192.168.0.12:37902      109.193.192.192:80      VERBUNDEN   1269/chromium-brows
tcp6       0      0 :::139                  :::*                    LISTEN      958/smbd        
tcp6       0      0 :::5355                 :::*                    LISTEN      626/systemd-resolve
tcp6       0      0 ::1:631                 :::*                    LISTEN      2072/cupsd      
tcp6       0      0 :::445                  :::*                    LISTEN      958/smbd        
tcp6       0      0 :::6566                 :::*                    LISTEN      1/init          
tcp6       0      0 :::3689                 :::*                    LISTEN      4154/rhythmbox  
tcp6       0      0 2a02:8070:d287:4b:58282 2a00:1450:400a:806::443 VERBUNDEN   1269/chromium-brows
tcp6       0      0 2a02:8070:d287:4b:45653 2a00:1450:400a:805:::80 VERBUNDEN   1269/chromium-brows
tcp6       0      0 2a02:8070:d287:4b:45652 2a00:1450:400a:805:::80 VERBUNDEN   1269/chromium-brows
tcp6       0      0 2a02:8070:d287:4b:46266 2a00:1450:400a:806::443 VERBUNDEN   1269/chromium-brows
tcp6       0      0 2a02:8070:d287:4b:45654 2a00:1450:400a:805:::80 VERBUNDEN   1269/chromium-brows
tcp6       1      0 ::1:53453               ::1:631                 CLOSE_WAIT  579/cups-browsed
tcp6       0      0 2a02:8070:d287:4b:38590 2a00:1450:4001:805:::80 VERBUNDEN   1269/chromium-brows
tcp6       0      0 2a02:8070:d287:4b:40624 2a00:1450:4001:802:::80 VERBUNDEN   1269/chromium-brows
tcp6       1      0 ::1:53454               ::1:631                 CLOSE_WAIT  579/cups-browsed
tcp6       0      0 2a02:8070:d287:4b:33663 2a00:cd0:1005:2:80:8:80 VERBUNDEN   1269/chromium-brows

Code: 
sudo netstat -tanp | grep 127.0.1.1
[sudo] password for amy: 
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      721/dnsmasq

Riddler82 schrieb:
*edit: Ok, hab grade mal etwas gegoogelt, bei vielen Debian basierenden (und damit auch Ubuntu usw) ist das wohl ein Workaround für die DNS Auflösung des localhosts und sollte nix mit dem Problem zu tun haben.
Zum Vergrößern anklicken....
Ärgerlich bzw. ich komme mir gerade veralbert vor: Nach einem dist-upgrade habe ich beim Ubuntu Mate auf dem Pi 2 genau das gleiche Problem: 9gag.com läd nicht mehr. Zuvor - also vor dem Update - ging es.

Also wird wohl irgendwas vom Update die Anfrage zerhauen. Nur was?

Riddler82 schrieb:
Bin mir grad nicht sicher, hast du schon mal von dem fraglichen System aus mit einer Live CD getestet?
Zum Vergrößern anklicken....
Daran hatte ich noch nicht gedacht. Also die DVD von Mint 17.1 ins Laufwerk -> 9gag.com geht.

Aber: Am anderen Standort (Kabel Deutschland) klappt es mit Mint 17.2 und 9gag.com... Zusammenspiel UnityMedia/Kabel-BW und Debian bzw. Ubuntu/Mint als Ursache?

Grüße, Martin
 
Also doch dnsmasq ??
Trage entweder in der resolv.conf einen ordentlichen DNS resolver ein, bzw. in der interfaces Datei.
Oder deaktiviere, deinstalliere dnsmasq.
 
Auch auf der Kiste welche ich ursprünglich wegen dem Problem wie gewünscht »befragt« habe:

Code: 
~ $ sudo netstat -tanp | grep 127.0.1.1
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1938/dnsmasq
_____

Jedoch:

Code: 
~ $ sudo apt-get remove dnsmasq
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Package 'dnsmasq' is not installed, so not removed
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 6 nicht aktualisiert.

Code: 
~ $ sudo apt-get remove dnsmasq-base
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  cinnamon dnsmasq-base mint-meta-cinnamon network-manager
  network-manager-gnome
0 aktualisiert, 0 neu installiert, 5 zu entfernen und 6 nicht aktualisiert.
Nach dieser Operation werden 11,4 MB Plattenplatz freigegeben.

Cinnamon will ich ja nicht gerade auch mit runterwerfen...

Per Hand geändert:

Code: 
~ $ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 208.67.222.222 
nameserver 208.67.220.220

Keine Veränderung.
_____

Habe jetzt cd /etc/resolvconf/resolv.conf.d/head um die beiden Einträge von OpenDNS ergänzt und starte die Kiste neu.

Wo liegt der Eintrag mit der 127.0.1.1? Vor der Veränderung:

Code: 
/etc/resolvconf/resolv.conf.d $ ls -la
insgesamt 12
drwxr-xr-x 2 root root 4096 Nov 26  2014 .
drwxr-xr-x 5 root root 4096 Nov 26  2014 ..
-rw-r--r-- 1 root root    0 Dez 13  2012 base
-rw-r--r-- 1 root root  151 Dez 13  2012 head
lrwxrwxrwx 1 root root    8 Feb 12 10:08 tail -> original

Grüße, Martin

--- Update ---

Keine Veränderung. :(

Grüße, Martin
 
Zuletzt bearbeitet:
Also wenn ein dnsmasq läuft, dann muss das Ding auch von irgendeinem Paket mitgebracht worden sein. Nicht notwendigerweise heißt das Paket auch so. Rausbekommen, zu welchem Paket ein Binary gehört, geht z.B. mit
Code: 
dpkg -S <dateiname>
In deinem konkreten Fall könnte also ein
Code: 
dpkg -S dnsmasq
helfen.

MfG Dalai
 
Es muss ja nicht gleich dnsmasq deinstalliert werden.
Wenn solche bescheuerten Abhängigkeiten bestehen reicht es ja auch dnsmasq nicht zu starten, damit dieser keinen Unsinn machen kann.
Ebenso kannst Du mal die DNS Server von Opennic probieren. -> wiki.opennicproject.org
 
Ich war die letzte Woche komplett eingebunden und daher nicht mit »PC-Spielereien« belastbar. Heute wieder ein paar Tests -> Nun ist alles, was im LAN ist, nicht mehr erreichbar. Liegt aber wohl am DNS-Eintrag.

Code: 
$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 208.67.222.222 
nameserver 208.67.220.220
nameserver 127.0.1.1

Von einer Linux Mint 17.1 DVD gebootet lässt sich 9gag.com problemlos aufrufen. Beim Ubuntu-System auf meinem Raspberry Pi 2 ging es nach dem Update auch nicht mehr. Also scheint eine gemeinsame Komponente bei LAN-IPs herumzuzicken wenn ein externer DNS eingebunden wird?

Grüße, Martin
 
Sofern deine Rechner sich die Netzwerkkonfiguration via DHCP holen (also auch den DNS), stimmt wohl die Konfiguration deines Routers nicht. Normalerweise gibt es keinen Grund, warum jeder Rechner im LAN einen externen DNS befragen sollte - mal Ausnahmen/Sonderfälle außen vor gelassen. Stattdessen ist es sinnvoller, jeden PC den Router fragen zu lassen, und der befragt dann wiederum seinen DNS (einen externen), sofern er die Anfrage nicht selbst beantworten kann.

Die IPs, die du da hast, stammen von OpenDNS. Die sind bekannt dafür, irgendwelchen Murks mit DNS zu veranstalten, IIRC in ähnlicher Weise wie die Telekom mit ihrer "tollen" "Navigationshilfe", die auch nicht existierende Domains als existierend beantwortet. Ich verstehe echt nicht, warum OpenDNS immer wieder empfohlen wird. Verwende mal einen vernünftigen DNS-Server (z.B. einen vom CCC) und dann wird das sicher wieder funktionieren. Und wenn nicht, sollte man sich mal anschauen, welchen DNS der Router benutzt.

MfG Dalai
 
Beim Technicolor Modem/Router kann ich leider nicht wirklich viel einstellen. Vorgabe von KabelBW/Unitymedia eben. :(

Grüße, Martin
 
Dann wird normalerweise der DNS des Providers verwendet. Das erklärt allerdings nicht notwendigerweise, warum das Problem nicht an allen Rechnern des LAN auftritt. Möglicherweise hat das noch irgendetwas mit dem lokal installierten DNS-Server zu tun, welcher auch immer. Deine netstat-Ausgaben zeigen aber, dass da ein dnsmasq läuft. Nun musst du den nur noch lahmlegen oder deinstallieren (zu letzterem hab ich ja bereits etwas geschrieben, wie man mit dpkg das zuständige Paket findet).

MfG Dalai
 
Und, hast du mittlerweile mal einen Werksrestet der Technicolor-Büchse gemacht? Ich schreibe so etwas nicht ohne Grund. Das Ding ist praktisch Müll, und da verklemmt sich immer wieder mal was.
 
Ich war die letzte Woche wieder primär beim Arbeiten und hatte weder Lust (zu müde) noch Anlass (alles andere geht ja im Web) mich weiter mit dem Problem zu befassen.

Dalai schrieb:
Dann wird normalerweise der DNS des Providers verwendet. Das erklärt allerdings nicht notwendigerweise, warum das Problem nicht an allen Rechnern des LAN auftritt.
Zum Vergrößern anklicken....
Betrifft nur die auf den aktuellen Stand gebrachten Linuxkisten. Von einer älteren Linux Mint DVD gestartet (17.1) oder Windows 7/Vista aus -> kein Problem mit www.9gag.com.

Dalai schrieb:
Möglicherweise hat das noch irgendetwas mit dem lokal installierten DNS-Server zu tun, welcher auch immer. Deine netstat-Ausgaben zeigen aber, dass da ein dnsmasq läuft. Nun musst du den nur noch lahmlegen oder deinstallieren (zu letzterem hab ich ja bereits etwas geschrieben, wie man mit dpkg das zuständige Paket findet).
Zum Vergrößern anklicken....

Ich habe in /etc/NetworkManager/NetworkManager.conf den Eintrag dns=dnsmasq durch #dns=dnsmasq ersetzt.

sudo restart network-manager bzw. ohnehin in den letzten Tagen stattgefundene Neustarts -> keine Veränderung.

Damit es schön konfus bleibt: Nutze ich Linux Mint 17.2 in einem Haushalt mit Anschluss von Kabel BW -> www.9gag.com kann problemlos aufgerufen werden...
_____

BoMbY schrieb:
Und, hast du mittlerweile mal einen Werksrestet der Technicolor-Büchse gemacht? Ich schreibe so etwas nicht ohne Grund. Das Ding ist praktisch Müll, und da verklemmt sich immer wieder mal was.
Zum Vergrößern anklicken....
Werksreset: Nein. Da das Problem ausschließlich auf den Kisten mit Linux als OS existiert -> muss es wohl dort auch eine Lösung geben?
Inzwischen habe ich noch einen Linksys zwischen Rechner und Technicolor gepackt. Warum? Einfach um noch eine weitere Instanz als »Filter« zu nutzen. Keine Veränderung für 9gag.com.

Da es die einzige Seite ist, bei welcher ich das Problem bemerke und das zu verschmerzen ist -> ich gebe auf.

Auch das Nutzen von 8.8.8.8 und 8.8.4.4 als IP für den Nameserver (verteilt via Linksys und DHCP) -> keine Veränderung.

Grüße, Martin
 
Wenn du nicht sicherstellst, dass der dnsmasq nicht läuft, kann sich auch nichts ändern! Schau doch mal mit einem der vielen netstat-Varianten oder mit (dem einfach zu merkenden)
Code: 
sudo netstat -tulpen
ob noch ein dnsmasq aktiv ist. Wenn ja, dann musst du raussuchen, wie man den sauber beendet; unsauber geht ja in jedem Fall mit
Code: 
sudo killall dnsmasq

Mit einer Live-CD hast du das Problem nicht, weil dort sehr wahrscheinlich kein dnsmasq läuft.

MfG Dalai
 
Hätte ich noch dazu schreiben sollen: dnsmasq läuft nicht mehr (ps -e | grep dnsmasq).

Zur Sicherheit:

Code: 
sudo killall dnsmasq
dnsmasq: Kein Prozess gefunden

Grüße, Martin
 

Ähnliche Themen

T
[gelöst]ESXI hinter pfsense nicht erreichbar
Antworten
3
Aufrufe
2K
tommy1735
T
Diablo
Problem mit OpenWRT
Antworten
0
Aufrufe
2K
Diablo
Diablo
Azhrarn
ping von linux und win-client
Antworten
5
Aufrufe
592
PuckPoltergeist
PuckPoltergeist
A
Kein Ping ins lokale netz oder zum localhost (Mandrake 9.1)
Antworten
9
Aufrufe
1K
Arcanum
A
Zurück
Oben Unten