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

[debflash]

Ich habe jetzt Debian Buster/sid komplett neu installiert, mit debian-testing-amd64-netinst.iso 202103150355 Desktop Xfce. Anschliessend NICHTS verändert. network-manager war danach schon fertig da. Tut mir leid, dass ich erst jetzt deine Fragen beantworten kann JTH, ich musste zwischendurch Home Office Arbeiten erledigen

Mein Notebook ist normalerweise per WLAN mit einen Repeater verbunden, der seinerseits über WLAN mit dem Router verbunden ist.

Und, wie gesagt, das Problem gibt es nur mit network-manager und Repeater, nicht mit connman.

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

DHCP, sonst nichts besonderes.

Kannst du ausschließen, dass der Repeater irgendeinen Quatsch macht?

Ja, mit connman klappt ja alles.

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.

***Ohne Repeater:

Code: Alles auswählen

~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 50:b7:c3:7f:73:40 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 20:16:d8:43:47:9a brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.100/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 1814337sec preferred_lft 1814337sec
    inet6 2003:d0:8f0d:7a0:244b:5b75:75c1:15e6/64 scope global dynamic noprefixroute 
       valid_lft 172761sec preferred_lft 86361sec
    inet6 fe80::18f6:ccdd:aa52:a08d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
~$ 

***Mit Repeater:

Code: Alles auswählen

~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 50:b7:c3:7f:73:40 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 20:16:d8:43:47:9a brd ff:ff:ff:ff:ff:ff
    inet6 2003:d0:8f0d:7a0:a80:3df1:d91b:4c6c/64 scope global temporary dynamic 
       valid_lft 172800sec preferred_lft 85804sec
    inet6 2003:d0:8f0d:7a0:2216:d8ff:fe43:479a/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 172800sec preferred_lft 86400sec
    inet6 fe80::2216:d8ff:fe43:479a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
~$

[MSfree]

Ich habe jetzt Debian Buster/sid komplett neu installiert, mit debian-testing-amd64-netinst.iso

Was soll das denn für ein Durcheinander sein.

Buster ist nicht SID sondern stable
SID ist nicht testing sondern Bookworm
testing ist Bullseye

[debflash]

...
Buster ist nicht SID sondern stable
SID ist nicht testing sondern Bookworm
testing ist Bullseye

Sorry, mein Schreibfehler. Also nochmal genau:
* Installiert habe ich mit der "Last modified" debian-testing-amd64-netinst.iso Version 2021-03-15 03:55
* Und in meinem Grub Menü heisst die Installation dann bullseye/sid
Alles klar?

EDIT: Download von https://cdimage.debian.org/cdimage/dail ... 64/iso-cd/. Inzwischen ist dort schon die heutige Version 2021-03-25 16:06

[debflash]

...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. ....

Ich hatte ja vorhin gesagt, dass ich zwischendurch arbeiten musste, aber jetzt eine "unberührte" Neuinstallation habe, sodass ich die Fragen von dir und JTH beantworten kann. Die von JTH habe ich 3 Posts weiter oben beantwortet. Jetzt zu dir:

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

Das hatte ich ja, wie gesagt, durch Live und auch Neuinstallation ausgeschlossen

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:..

Egal, ob ich pinge oder aol.com oder www.aol.com in die Adresszeile des Browsers gebe, es ändert nichts.

Wieso liege ich nach eurer Meinung falsch, wenn ich annehme, dass noch etwas mit network-manager in Bullseye nicht stimmt, wenn ich einen Repeater verwende, da doch der connman keine Probleme macht?

[JTH]

***Mit Repeater:

Code: Alles auswählen

~$ ip a
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 20:16:d8:43:47:9a brd ff:ff:ff:ff:ff:ff
    inet6 2003:d0:8f0d:7a0:a80:3df1:d91b:4c6c/64 scope global temporary dynamic 
       valid_lft 172800sec preferred_lft 85804sec
    inet6 2003:d0:8f0d:7a0:2216:d8ff:fe43:479a/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 172800sec preferred_lft 86400sec
    inet6 fe80::2216:d8ff:fe43:479a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Da sieht man, dass der Rechner, wenn der Repeater involviert ist, keine IPv4-Adresse bekommt (eine Zeile mit „inet“ am Anfang fehlt). Das ist die Ursache, die bei der Meldung

"ping: connect: Network is unreachable"

zu erwarten ist. Es ist kein IPv4-Netzwerk erreichbar. Das ganze ist also wohl kein Problem mit den Domainnamen – es fehlt einfach die Adresse.

Ist die Frage, warum das so ist und warum es mit conman dann funktioniert. Der anderen Ausgabe ohne den Repeater nach benutzt du dynamische Adressen mit DHCP. Evtl. macht der Repeater hier doch sein eigenes Ding oder ist falsch eingestellt? Die Hilfe hier würde dazu passen. Kenne mich mit WLAN-Repeatern wie gesagt nicht aus, weiß nicht, was die Hersteller da für Sachen treiben.

Ansonsten guck mal, ob der Network-Manager bei einer Verbindung mit dem Repeater etwas verrät, als root:

Code: Alles auswählen

journalctl -b -u NetworkManager.service | grep -i dhcp

[debflash]

...
Ansonsten guck mal, ob der Network-Manager bei einer Verbindung mit dem Repeater etwas verrät, als root:

Code: Alles auswählen

journalctl -b -u NetworkManager.service | grep -i dhcp

Hier ist der Output mit Repeater, verrät mir nichts, ich verstehe nur Bahnhof :

Code: Alles auswählen

# journalctl -b -u NetworkManager.service | grep -i dhcp
Mar 26 16:17:55 debi11 NetworkManager[502]: <info>  [1616771875.4830] dhcp-init: Using DHCP client 'internal'
Mar 26 16:22:47 debi11 NetworkManager[502]: <info>  [1616772167.8661] dhcp4 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 26 16:22:48 debi11 NetworkManager[502]: <info>  [1616772168.9226] dhcp4 (wlp2s0): state changed unknown -> bound, address=192.168.2.219
Mar 26 16:22:50 debi11 NetworkManager[502]: <info>  [1616772170.0771] dhcp6 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 26 16:22:50 debi11 NetworkManager[502]: <info>  [1616772170.4607] dhcp6 (wlp2s0): state changed unknown -> bound
Mar 26 17:06:55 debi11 NetworkManager[502]: <info>  [1616774815.5470] dhcp4 (wlp2s0): canceled DHCP transaction
Mar 26 17:06:55 debi11 NetworkManager[502]: <info>  [1616774815.5471] dhcp4 (wlp2s0): state changed bound -> done
Mar 26 17:06:55 debi11 NetworkManager[502]: <info>  [1616774815.5481] dhcp6 (wlp2s0): canceled DHCP transaction
Mar 26 17:06:55 debi11 NetworkManager[502]: <info>  [1616774815.5482] dhcp6 (wlp2s0): state changed bound -> done
Mar 26 17:06:56 debi11 NetworkManager[502]: <info>  [1616774816.7159] dhcp4 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 26 17:07:00 debi11 NetworkManager[502]: <info>  [1616774820.7904] dhcp4 (wlp2s0): state changed unknown -> bound, address=192.168.2.219
Mar 26 17:07:03 debi11 NetworkManager[502]: <info>  [1616774823.2711] dhcp4 (wlp2s0): canceled DHCP transaction
Mar 26 17:07:03 debi11 NetworkManager[502]: <info>  [1616774823.2712] dhcp4 (wlp2s0): state changed bound -> done
Mar 26 17:07:31 debi11 NetworkManager[502]: <info>  [1616774851.3174] dhcp4 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 26 17:07:35 debi11 NetworkManager[502]: <info>  [1616774855.5032] dhcp6 (wlp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 26 17:07:35 debi11 NetworkManager[502]: <info>  [1616774855.6106] dhcp6 (wlp2s0): state changed unknown -> bound
# 

[debflash]

Noch ein Beweis, wenigstens für mich, dass der NetworkManager in Debian 11 noch einen Fehler hat. Denn ganz ohne irgend einen Netzwerk Manager, weder network-manager noch connman, klappt es auch mit ipv4 Netzportalen:

*** 1 ***
NetworkManager gestoppt und Konfigurationsdateien umbenannt, auch /etc/xdg/autostart/nm-applet.desktop umbenannt.

*** 2 ***
Die "ip a" Geschichte

Code: Alles auswählen

# ip a
# ip link set wlp2s0 up

Danach in /etc/nerwork/interface ergänzt:

Code: Alles auswählen

# my wifi device
allow-hotplug wlp2s0
iface wlp2s0 inet dhcp
   wpa-ssid ESSID
   wpa.psk PASSWORD

Bei ESSID natürlich meine Repeateradresse eingetragen.

*** 3 ***
Nach Neustart und ifup und iw mit den nötigen Angaben, mit "ip a" das Internet gestartet, und, "lo and behold", brother.com und aol.com können nicht nur gepingt werden, sondern sind auch als www.aol.com oder www.brother.com in Firefox errreichbar

[OrangeJuice]

Könnte sein, dass es ein ZeroDay in dhcp ist, der noch offen ist, wer weiß... warum der(talosintelligence) seit 2020-08-18 nicht geschlossen wurde.

Code: Alles auswählen

alert udp any any -> any 68 (msg:"POLICY-OTHER TRUFFLEHUNTER TALOS-2020-1142 attack attempt"; sid:54831; gid:3; rev:1; classtype:policy-violation; reference:cve,2020-13529; reference:url,www.talosintelligence.com/reports/TALOS-2020-1142/; metadata: engine shared, soid 3|54831, service dhcp;)

Quelle

Talos Security Advisory for Systemd DHCP (TALOS-2020-1142/CVE-2020-13529) #16774

[debflash]

Danke nochmal für alle eure Antworten! Ich bin jetzt wieder bei connman, weil ein mir sehr lieber Mensch auch auf den Repeater angewiesen ist, und da möchte ich mit Softwarebasteln am Gerät nicht stören. Wenn mein Grub Menü irgendwann mal "bullseye" statt "bullseye/sid" anzeigt, teste ich vielleicht wieder den NetworkManager.
Gruss, debflash

[debflash]

Hallo,
eine für mich überraschende Lösung des Repeaterproblems durch Ausprobieren gefunden, u.z., mit network-manager und "...with a little help from my friends" nämlich connman. Unter Vorbehalt, ist jetzt zwar mit Linux Mint 20.1 Xfce (LL; habe im Moment Deb 11 nicht), aber /etc/debian_version von LL sagt "bullseye/sid" und LL hatte genau die gleichen Probleme mit dem Repeater wie Deb11.

*** 1 ***
network-manager und network-manager-gnome sind installiert.

*** 2 ***

Code: Alles auswählen

# apt install connman

Nur den, nicht das GUI und cmst installieren.

*** 3 ***
Vorsichtshalber

Code: Alles auswählen

# systemctl stop network-manager

Ich weiss nicht, ob dieser Schritt nötig ist. Dann auf jeden Fall in /etc/network/interfaces die letzten zwei Zeilen auskommentieren, sodass die Datei so aussieht:
/etc/network/interfaces:

Code: Alles auswählen

# The loopback network interface
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

# The loopback network interface
# auto lo
# iface lo inet loopback

(Diese letzten beiden Zeilen sind übrigens in Deb10 Xfce nicht auskommentiert, trotzdem funktioniert's dort, ohne connman).

*** 4 ***
Neustarten, mit dem nm-applet den Repeater anwählen, verbinden und ping und Firefox funktionieren jetzt auch mit ipv4 Portalen.

[debflash]

Finanzielle Lösung: Ich habe jetzt auch einen neueren TP-Link Repeater TL-WA850RE Version 7. Sieht identisch mit dem alten aus, arbeitet jedoch ohne Probleme mit neuen Debian/ubuntu-Versionen zusammen. Der alte ist Version 5 (eigenlich auch nicht so alt, kaufmäßig). TP-Link hat mir per e-Mail bestätigt, dass Version 5 ältere Hardware und überhaupt älteres Innenleben hat als Version 7 und nur WPA2.gegenüber Version 5 mit WPA3. Hätte ich das vor dem Kauf von Version 5 gewusst!