[GELÖST]Internet mit debian,google,yahoo ok - mit aol,brother u. anderen plötzlich nicht mehr!?

[debflash]

Hallo,
um mich an den künftigen Bullseye zu gewöhnen, habe ich ihn schon seit Monaten laufen, mit häufigen Updates. Mit dem Internet war es bisher in Ordnung, aber seit kurzem komme ich nicht mehr an alle Portale, nicht mit ping und schon gar nicht mit Firefox . Mit Ubuntu 18.04 oder Debian 10 - Multiboot auf derselben HD - ist alles in Ordnung mit allen Internetportalen.

* Beispiele für funktionierendes ping: debian.com, debian.org, google.com, yahoo.com

* Beispiele für "ping: connect: Network is unreachable": aol.com, brother.com, washingtonpost.com

So etwas ist mir seit ich Linux betreibe noch nie passiert, dass eine Distro plötzlich ein paar Portale sperrt, die den anderen Distros weiterhin frei zugänglich sind! Oder ist das nur ein vorübergehendes Problem, weil Bullseye gerade heftig überarbeitet wird?

Danke, debflash

[whisper]

Hand auf Herz.
Mit irgendwelche firewall Regeln rumgespielt?
Bin hier bei Bullseye gerade up2date es geht. brother (aws Cloud) und aol i.o.

[JTH]

So etwas ist mir seit ich Linux betreibe noch nie passiert, dass eine Distro plötzlich ein paar Portale sperrt, die den anderen Distros weiterhin frei zugänglich sind! Oder ist das nur ein vorübergehendes Problem, weil Bullseye gerade heftig überarbeitet wird?

Das ist eine sehr weit hergeholte Annahme, dass irgendetwas dort bewusst bestimmte Hostnamen sperrt.

* Beispiele für funktionierendes ping: debian.com, debian.org, google.com, yahoo.com

* Beispiele für "ping: connect: Network is unreachable": aol.com, brother.com, washingtonpost.com

Wenn ich die Namen bei mir mal anpinge, sehe ich:
Die ersteren, die bei dir funktionieren, werden alle zu einer IPv6-Adresse aufgelöst.
Die letzteren, die bei dir nicht funktionieren, werden zu einer IPv4-Adresse aufgelöst.

Du hast also vermutlich in deiner Bullseye-Installation (oder auch anderswo in deinem Netzwerk) die IPv4-Einstellungen kaputt gebastelt oder sogar etwas an der Namensauflösung.

[unitra]

Wie kommst Du auf diese Vermutung dass das an einer Distrubution liegt? Gibt es stichhaltige Beweise für diese Theorie? Ohne Beweise ist diese Annhahme falsch.

...
* Beispiele für funktionierendes ping: debian.com, debian.org, google.com, yahoo.com

* Beispiele für "ping: connect: Network is unreachable": aol.com, brother.com, washingtonpost.com

So etwas ist mir seit ich Linux betreibe noch nie passiert, dass eine Distro plötzlich ein paar Portale sperrt, die den anderen Distros weiterhin frei zugänglich sind! Oder ist das nur ein vorübergehendes Problem, weil Bullseye gerade heftig überarbeitet wird?

Danke, debflash

[debflash]

...Mit irgendwelche firewall Regeln rumgespielt?...

Nein, wie soll ich das gemacht haben? Ich wüsste nicht einmal, wo ich Firewallregeln finde und wie die zu bedienen sind. Ich habe nur ab und zu Updates gemacht. Gibt es denn keine Möglichkeit herauszufinden, wie ich das ändern kann?

[debflash]

Erstmal danke für's Ausprobieren!
...Du hast also vermutlich in deiner Bullseye-Installation (oder auch anderswo in deinem Netzwerk) die IPv4-Einstellungen kaputt gebastelt oder sogar etwas an der Namensauflösung.

Also das Netzwerk* kann es ja nicht sein, denn Ubuntu 18.04, Debian Buster Xfce, Linux Lite 5.2 und (ich geb's zu) Windows 10 auf meinem ein- und denselben Notebook machen keine Probleme. And den IPv4-Einstellungen gebastelt... wüsste nicht, was ich daran herumwerkeln kann.

* Mein Netzwerk: ein WLAN Router, drahtlose Verbindung zu/mit einem Brother MFC-J497DW und einm Notebook

[debflash]

@

Du hast mich auf einen Gedanken gebracht. Ich würde gerne zum Testen meine Network Connection ganz löschen und wieder neu einrichten. Wie kriege ich die denn komplett gelöscht, ausser "Disconnect"? Gibt es da noch irgendwelche Konfigurationsdateien in den Debian-"Innereien" zu entfernen?

Ich melde mich dann morgen. Kleine Jungs müssen jetzt ins Bett

[JTH]

Wie kriege ich die denn komplett gelöscht, ausser "Disconnect"? Gibt es da noch irgendwelche Konfigurationsdateien in den Debian-"Innereien" zu entfernen?

Ich bin da nicht auf dem Laufenden, was unter Xfce zur Netzwerkkonfiguration installiert wird (Willy?). Falls es der NetworkManager ist, kannst du Folgendes probieren:

Im Terminal:

Code: Alles auswählen

nmcli connection delete "Name der Verbindung"

oder daraus gestartet, grafisch:

Code: Alles auswählen

nm-connection-editor

In letzterem kann man dann konfigurierte Verbindungen auswählen und bearbeiten oder löschen.

[debflash]

Code: Alles auswählen

nmcli connection delete "Name der Verbindung"

Klappt, Verbindung gelöscht, wieder verbunden, dnach gleiches Problem. (Die Verbindung läßt sich auch über das nm-applet Menü löschen) Wie weiter unten erklärt, tritt das Problem nur mit Repeaterbetrieb auf.

Jetzt bin ich "brutal" rangegangen.: network-manager ge"purge"t, dann in

Code: Alles auswählen

/etc/NetworkManager/system-connections/

alle Verbindungen gelöscht, danach Neustart.

Anschließend network-manager und networkmanager-gnome wieder installiert (das war schon trickreich für mich so ganz ohne anfängliches Netz und ohne GUI). Nach Neustart war auch das nm-applet wieder im Panel, also Verbindungen neu aufgebaut, leider Problem NICHT gelöst!

Mein Notebook ist normalerweise per WLAN mit einen Repeater verbunden, der seinerseits über WLAN mit dem Router verbunden ist.
Ehe ich im folgenden den Stand der Dinge zusammenfasse: wieso haben dieses Problem nur die neuen Distros und nicht die alten mit ein- und derselben Hardware? Erklärung zu neu und alt und Zusammenfassung folgt hier:

* Distros ALT: Ubuntu 18.04, Debian Buster Xfce

* Distros NEU: Debian Bullseye/sid Lxde, Linux Lite 5.2 Xfce

* Getestete Netzportale (danke nochmal JTH für die Aufklärung):
ipv6: debian.com, google.com, yahoo.com
ipv4: aol.com, brother.com

> Alle Distros, ALT und NEU, verbinden über WLAN zum Router* mit allen Netzportalen (ipv4 und ipv6)

> Nur die ALTen Distros verbinden über WLAN zum Repeater** mit allen Netzportalen (ipv4 und ipv6)

> Die NEUen Distros verbinden über WLAN zum Repeater nur mit den ipv6-Netzportalen und NICHT mit ipv4

Frage: wie gehe ich jetzt bitte weiter vor? Denn auf die Siganlverstärkung durch den Repeater möchte ich bei den neuen Distros nicht verzichten.

Meine Hardware:

Notebook:
SAMSUNG ELECTRONICS CO., LTD. 300E5C-S04DE
RAM 4GB
Processor a 2,20 gigahertz Intel Core i3-2328M
64 kilobyte primary memory cache
256 kilobyte secondary memory cache
3072 kilobyte tertiary memory cache
64-bit ready
Multi-core (2 total)
Hyper-threaded (4 total)

Harddrive:
Model: ATA ST500LM012 HN-M5 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Router*:
Speedport Smart 3
WLAN-Standards IEEE 802.11 ac mit 2,4 GHz und 5 GHz gleichzeitig, abwärtskompatibel zu IEEE 802.11
b/g/n Antennen 4x4 u. 4x4 MIMO / MU MIMO

Repeater**:
TP-Link TL-WA850RE WLAN Repeater (300 Mbit/s, WLAN Verstärker, App Steuerung, Ethernet-Port, WPS, AP Modus, LED abschaltbar, kompatibel zu allen WLAN Geräten

[JTH]

Jetzt bin ich "brutal" rangegangen.: network-manager ge"purge"t

Das ist mehr die „Windows-Methode“ und ändert in den seltensten Fällen was. Wobei, ja, ein purge könnte schon was ändern, wenn man groß was in /etc/NetworkManager/NetworkManager.conf umgestellt hatte.

dann in

Code: Alles auswählen

/etc/NetworkManager/system-connections/

alle Verbindungen gelöscht, danach Neustart.

Das hätte durch die Neukonfiguration dann schon eher was erreichen können.

Mein Notebook ist normalerweise per WLAN mit einen Repeater verbunden, der seinerseits über WLAN mit dem Router verbunden ist.
Ehe ich im folgenden den Stand der Dinge zusammenfasse: wieso haben dieses Problem nur die neuen Distros und nicht die alten mit ein- und derselben Hardware?

Das gilts herauszufinden Bevor das ausgeschlossen ist, würd ich erstmal an ein ungewolltest/unbewusstes Konfigurationsproblem denken. Erst danach könnt man gucken, obs tatsächlich etwas mit der Hardware zu tun hat.

Wie ist denn dein Netzwerk konfiguriert? Statische IPs oder DHCP, andere relevante Besonderheiten?

> Alle Distros, ALT und NEU, verbinden über WLAN zum Router* mit allen Netzportalen (ipv4 und ipv6)

> Nur die ALTen Distros verbinden über WLAN zum Repeater** mit allen Netzportalen (ipv4 und ipv6)

> Die NEUen Distros verbinden über WLAN zum Repeater nur mit den ipv6-Netzportalen und NICHT mit ipv4

Das klingt doch schonmal interessant. Kannst du ausschließen, dass der Repeater irgendeinen Quatsch macht? Habe nicht allzuviel Erfahrung mit solchen Dingern. Wenn es, ohne das der Repeater involviert ist, funktioniert, ist der schonmal vorsichtig verdächtig.

Frage: wie gehe ich jetzt bitte weiter vor?

Ich würd mir wie gesagt erstmal die Konfiguration u.ä. anschauen. Was geben dir denn folgende Kommandos

Code: Alles auswählen

ip a
cat /etc/resolv.conf

auf dem neuen System aus, im funktionierenden und nicht funktionierenden Szenario.

[willy4711]

Die NEUen Distros verbinden über WLAN zum Repeater nur mit den ipv6-Netzportalen und NICHT mit ipv4

Trifft das auch zu, wenn du im Browser z.B. in die Adresszeile aol.com eingibst bzw. wenn du über Kabel gehst
Der Repeater hat ja auch eine Ethernet- Buchse?
Eventuell aufschlussreicher als ping:

Code: Alles auswählen

traceroute aol.com

Im Manual vom Speedport S. 244 steht:


In meinem Xfce-Bullseye hab ich nur den network-manager installiert, weil der network-manager-gnome
bei einer ummanaged Verbindung eh nichts anzeigt.
in der /etc/NetworkManager/NetworkManager.conf (hab am Hauptrechner kein WLAN)
steht nicht weiter als:

Code: Alles auswählen

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Vielleicht kann man noch irgend einen Haken in der Ausgabe von

Code: Alles auswählen

nmcli device show

Sehen ( ist aber wohl weitgehend identisch mit JTH's ip a)
Und die /etc/network/interfaces haben wir auch noch nicht gesehen:

Code: Alles auswählen

 cat /etc/network/interfaces

Aber so richtig hab ich mich darum noch nie gekümmert, da es funktioniert und ich da auch keine Klimmzüge mache

[debflash]

Mit connman klappt es über den Router

Danke erst mal für eure vielen Tipps
Ehe ich die im einzelnen ausprobiere, habe ich folgendes gemacht:

* connman installiert

* network-manager ge"purge"t

Nach Neustart mit connman zum Repeater über WLAN: alles ok, ip6- und und ip4-Portale

Ich mag ja network-manager lieber, aber ich bin jetzt noch mehr überzeugt, dass mein Problem mehr an Deb11, bzw. dessen network-manager, liegt als an meinem Repeater. Seid ihr anderer Meinung?

[debflash]

Nachdem ich jetzt auch festgestellt habe, dass ich meine Brother-Drucker-Warteschleifen in den NEUen Disros nicht so bequem umbenennen kann wie in den ALTEn, sondern nur mit "Trick 17", warte ich erst mal ab, bis Bullseye völlig vollständig ist. So lange nehme ich connman statt network-manager.

Aber vielen Dank nochmal für eure Beiträge

debflash

[willy4711]

Ich mag ja network-manager lieber, aber ich bin jetzt noch mehr überzeugt, dass mein Problem mehr an Deb11, bzw. dessen network-manager, liegt als an meinem Repeater. Seid ihr anderer Meinung?

Ich möchte mal behaupten: Es liegt an dem, der vor dem Rechner sitzt.

Da du uns alle Fragen nach den Einstellungen schuldig geblieben bist, und ich bisher noch nix gefunden habe, wo ähnliches beschrieben wird, ein anderer Netzwerk-Manager aber die Verbindung herstellt, wird wohl irgendetwas auf deinem Rechner
falsch konfiguriert gewesen sein.

Nachdem ich jetzt auch festgestellt habe, dass ich meine Brother-Drucker-Warteschleifen in den NEUen Disros nicht so bequem umbenennen kann wie in den ALTEn, sondern nur mit "Trick 17", warte ich erst mal ab, bis Bullseye völlig vollständig ist.

Ich weiß nicht, was du da treibst. Warum sollte man einen Warteschlange umbenennen ? Macht das nicht cups ?

warte ich erst mal ab, bis Bullseye völlig vollständig ist.

Ich denke mal, es ist fertig.
Auf jeden Fall glaube ich nicht , dass deine Probleme mit "fertig oder nicht fertig" zu tun haben.

[debflash]

...wird wohl irgendetwas auf deinem Rechner falsch konfiguriert gewesen sein.

Ich habe natürlich mit dem Live System auch getestet. Bullseye hatte ich nicht live, aber Linux Lite 5.2 Live USB, das ja dasselbe Problem hat. Auch die Liveversion konnte aol.com und brother.com nicht verbinden! Deshalb kann doch meine Rechnerkonfiguration nichts damit zu tun haben, oder?

[OrangeJuice]

Ich habe natürlich mit dem Live System auch getestet. Bullseye hatte ich nicht live, aber Linux Lite 5.2 Live USB, das ja dasselbe Problem hat. Auch die Liveversion konnte aol.com und brother.com nicht verbinden! Deshalb kann doch meine Rechnerkonfiguration nichts damit zu tun haben, oder?

Probleme mit DNS? Ich würde einfach mal mit metager.de nach den Seiten suchen und diese per Proxy "ANONYM ÖFFNEN" öffnen lassen. Manche Seiten konnte ich auch nicht erreichen, mit Proxy konnte ich sie dann dennoch aufrufen.

[willy4711]

Nun hab ich mal extra die DNS-Serve hin-und her gewechselt (Fritte)
Von Digitalcourage / Censurfridns Denmark (=mein Standard)
auf die Provider-DNS-Server und wieder zurück.

Ich schaffe es einfach nicht die angegebenen Adressen nicht zu erreichen

Mein Bullseye scheint irgendwie fertig (=debflash Klassifizierung )zu sein

[OrangeJuice]

Ich habe wahrscheinlich eine mögliche Lösung gefunden(mit Firefox 87). Es muss mit der Weiterleitung und dem NUR-HTTPS-Modus zu tun haben.

Einstellungen, in der Suche "HTTPS" eingeben und den Modus auf folgende Einstellung schalten "Nur-HTTPS-Modus nur in privaten Fenstern aktivieren" oder "Nur-HTTPS-Modus nicht aktivieren", danach klappt es.

Es finde eine Weiterleitung statt:

Code: Alles auswählen

brother.com --> https://global.brother/en/gateway?utm_source=brother.com...

@debflash
Welche Firefox Version verwendest du?

[debflash]

@debflash
Welche Firefox Version verwendest du?

78.8.0esr (64bit). Hängt denn die Funktionsweise von "ping" von der Firefoxversion ab?

[OrangeJuice]

Was genau dafür verantwortlich ist, weiß ich nicht. Vielleicht hat jemand anderes da eine bessere Idee.

Ich kann nur sagen, dass folgendes bei Firefox 87 doch klappt(Nur-HTTPS-Modus in allen Fenstern aktivieren).

In die Adresszeile "brother.com" geht nicht.
http://www.brother.com/ und https://www.brother.com/ geht hingegen und wird weitergeleitet.

Könnte vielleicht noch was mit der Amazon Cloud usw. zu tun haben(ping brother.com --> ...awsglobalaccelerator.com (13.248.151.157)) und (ping www.brother.com --> ...deploy.static.akamaitechnologies.com).

Es macht wohl einen Unterschied was du in den Browser und bei ping eingibst. Ich kann dir dabei aber nicht weiterhelfen, vielleicht weiß jemand anderes mehr.

[willy4711]

Also bei mir FF 88.0b2 (64-Bit) von Mozilla. Ist es so:
ich gebe in das Adressfeld z.B.

Code: Alles auswählen

brother.com

ein.
Dann kommt folgendes:


Bestätigen, und die Seite wird geladen.

Ich kann nur sagen, dass folgendes bei Firefox 87 doch klappt(Nur-HTTPS-Modus in allen Fenstern aktivieren).

Ist bei mir auch aktiviert.

Warum das Pingen dann nicht klappt (klappte) wird wohl nicht mehr zu ergründen sein.

[JTH]

Hängt denn die Funktionsweise von "ping" von der Firefoxversion ab?

Nein, die haben absolut rein gar nix miteinander zu tun.

[MSfree]

Nein, die haben absolut rein gar nix miteinander zu tun.

Die nutzen beide zumindest die selbe Methode zur Namensauflösung (DNS)
Aber, brother.com und www.brother.com sind zwei unterschiedliche Hosts und haben unterschiedliche IP-Adressen. Browser ergänzen gerne mal Kurzformen wie brother.com mit "www.", wenn unter brother.com keine Antwort kommt.

[JTH]

Die nutzen beide zumindest die selbe Methode zur Namensauflösung (DNS)

Das ist (abgesehen von DoH) natürlich richtig. Aber die Funktionalität von ping hat, siehe Zitat, nichts mit der Firefoxversion zu tun.

[debflash]

Interessante Diskussion
Ich möchte nur daran erinnern, dass ich mein weiter oben geschildertes Problem mit Debian 11 nur mit dem network-manager habe, nicht mit connman; und Debian 10 macht bei mir sowieso alles richtig mit dem network-manager und dem Repeater.