[Illuminatum]

Zeige bitte mal

lspci -nnk | grep "VGA\|'Kern'\|3D\|Display" -A2

lspci -nnk | grep "VGA\|'Kern'\|3D\|Display" -A2
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)
	DeviceName: VGA compatible controller
	Subsystem: Hewlett-Packard Company Core Processor Integrated Graphics Controller [103c:3674]
	Kernel driver in use: i915

und

dpkg -l | grep -i xserver

dpkg -l | grep -i xserver
ii  x11-xserver-utils                           7.7+7                                        amd64        X server utilities
ii  xserver-common                              2:1.18.4-0ubuntu0.7                          all          common files used by various X servers
ii  xserver-xorg-core-hwe-16.04                 2:1.19.5-0ubuntu2~16.04.1                    amd64        Xorg X server - core server
ii  xserver-xorg-hwe-16.04                      1:7.7+16ubuntu3~16.04.1                      amd64        X.Org X server
ii  xserver-xorg-input-all-hwe-16.04            1:7.7+16ubuntu3~16.04.1                      amd64        X.Org X server -- input driver metapackage
ii  xserver-xorg-input-evdev-hwe-16.04          1:2.10.5-1ubuntu1~16.04.1                    amd64        X.Org X server -- evdev input driver
ii  xserver-xorg-input-synaptics-hwe-16.04      1.9.0-1ubuntu1~16.04.1                       amd64        Synaptics TouchPad driver for X.Org server
ii  xserver-xorg-input-wacom-hwe-16.04          1:0.34.0-0ubuntu2~16.04.1                    amd64        X.Org X server -- Wacom input driver
ii  xserver-xorg-legacy-hwe-16.04               2:1.19.5-0ubuntu2~16.04.1                    amd64        setuid root Xorg server wrapper
ii  xserver-xorg-video-all-hwe-16.04            1:7.7+16ubuntu3~16.04.1                      amd64        X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu-hwe-16.04         1.3.0-0ubuntu1~16.04.1                       amd64        X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati-hwe-16.04            1:7.9.0-0ubuntu1~16.04.1                     amd64        X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev-hwe-16.04          1:0.4.4-1build6~16.04.1                      amd64        X.Org X server -- fbdev display driver
ii  xserver-xorg-video-intel-hwe-16.04          2:2.99.917+git20170309-0ubuntu1~16.04.1      amd64        X.Org X server -- Intel i8xx, i9xx display driver
ii  xserver-xorg-video-nouveau-hwe-16.04        1:1.0.14-0ubuntu1~16.04.1                    amd64        X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-qxl-hwe-16.04            0.1.5-2build1~16.04.1                        amd64        X.Org X server -- QXL display driver
ii  xserver-xorg-video-radeon-hwe-16.04         1:7.9.0-0ubuntu1~16.04.1                     amd64        X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa-hwe-16.04           1:2.3.4-1build3~16.04.1                      amd64        X.Org X server -- VESA display driver
ii  xserver-xorg-video-vmware-hwe-16.04         1:13.2.1-1build1~16.04.1                     amd64        X.Org X server -- VMware display driver

Ist auf einem Laptop installiert, ich weiß also nicht, warum da was von VMWare steht.

Danke!

MfG

[Dada]

Ist auf einem Laptop installiert, ich weiß also nicht, warum da was von VMWare steht.

Das beudeutet prinzipiell erstmal nur, dass der xServer mit der "Grafikkarte" von vmWare umgehen kann

[Taomon]

Erstmal hw-stack austauschen. Simulation

sudo apt --dry-run install --install-recommends xserver-xorg-core xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-video-intel xserver-xorg-video-qxl

Bei manchen Karten langt es den HW-Stack zu entfernen.

Gruß Taomon

[Penthesilea]

Der vollständigkeithalber will hier nur mal fix ein Link zum Arch Wiki unterbringen, in dem das Bootproblem bei einer UEFI Installtion in der VirtualBox beschrieben wird. Passend dazu gibts auch direkt Lösungsvorschläge

[Dada]

Hallöchen zusammen

Ich habe ein kleines Problemchen mit Zertifikaten unter Ubuntu (Genauer gesagt, unter IGEL OS 10, ist aber im Endeffekt ein Ubuntu 16.04).
Und zwar habe ich eine Website, die ein Clientzertifikat zur Authentifizierung anfordert. Normalerweise würde ich das im Firefox einfach über Einstellungen --> Zertifikate importieren. Für das Problem gehen wir einfach mal davon aus, dass ich nicht auf diese Einstellungen zugreifen kann.

In meiner Verzweiflung habe ich das Benutzerzertifikat schon an verschiedenste Stellen verschoben, jedoch bekomme ich egal wie einen SSL-Handshake-Fehler, folglich wird das Zertifikat nicht von Firefox abgerufen. Schaue ich mit certutil nach, finde ich das Zertifikat, allerdings als CA und nicht als User.

Kennt vielleicht jemand eine Möglichkeit, solche Nutzerzertifikate über die Konsole in Firefox einzubinden? Möglichst als PFX, damit wir die PKI nicht komplett umstellen müssen...

[Dada]

Okay, irgendwann findet man selbst die Lösung
Falls mal jemand in die Verlegenheit kommen sollte, Zertifikate über die CLI einbinden zu müssen:
Wichtig ist, dass im Verzeichnis eine cert8.db, bzw. eine cert9.db liegen. Dann seid ihr richtig

Älterer Firefox:

pk12util -d /verzeichnis/vom/firefox -i /pfad/zum/zertifikat.pfx

Neuerer Firefox:

pk12util -d sql:/verzeichnis/vom/firefox -i /pfad/zum/zertifikat.pfx

[Petrus]

Was gibt es eigentlich aktuell an Manjaro, dass es auf distrowatch selbst Mint in den letzten 6 Monaten mit großem Abstand hinter sich gelassen hat? Irgend etwas Sehenswertes? Oder sind die Zahlen vermurkst?

[foobar]

Was gibt es eigentlich aktuell an Manjaro, dass es auf distrowatch selbst Mint in den letzten 6 Monaten mit großem Abstand hinter sich gelassen hat? Irgend etwas Sehenswertes? Oder sind die Zahlen vermurkst?

Naja, hängt davon ab. Manjaro ist quasi ein benutzerfreundliches Arch. Wenn du also eine Rolling Release Distro willst, aber bist noch nicht so der Linux-Fuchs, dann ist Manjaro nicht die dümmste Wahl. Aus dem gleichen Grunde ist Mint ja bei den "herkömmlichen" Distro so beliebt. Es will alles ganz einfach machen.

Mehr ist mir jetzt nicht bekannt. Wenn das neuerdings mit Sexbots frei Haus geliefert werden sollte, hat mir mal wieder keiner Bescheid gesagt.

[Lookbehind]

Dazu sollte man noch erwähnen, dass Distrowatch sich nur an den Aufrufzahlen auf Distrowatch selbst orientiert, nicht daran wie oft die Distribution auch verwendet wird. Was auch schwer zu messen wäre.

Wie immer gilt: Traue keiner Statistik, die du nicht selbst gefälscht hast.

[Petrus]

Ich habe einen neuen Router angeschlossen (Connect Box/Unitymedia). Seitdem gibt es Packetloss beim ersten Hop (addr.arpa), was scheinbar ein rDNS Server ist, der Anfragen von IP zum Namen auflöst im Gegensatz zum normalen DNS server, der zu einer Domain die IP liefert. Muss heutzutage scheinbar so sein, gehört zur Infrastruktur.

Mein Lösungsversuch (Pingschwankungen wg. des Packetloss) wäre die named.conf Einträge und alles was damit zusammenhängt zu erneuern. Gibt es das irgendwie vollautomatisch, quasi ein

dhclient eth0

oder so? Ich hab mal in named.conf reingeblinzelt, aber da gibt es auch einige Bezüge zu anderen Dateien und Verweise. Also das korrekt manuell zu editieren traue ich mir eigentlich nicht zu. Hoffe, das ist auch nicht vorgesehen und es gibt eine elegantere Methode.

[Lookbehind]

Wird dein Netzwerk denn noch auf die klassische, manuelle Art verwaltet? Bei vielen Desktop-Linuxen kommt da inzwischen eher NetworkManager oder dergleichen zum Einsatz. Da gibts dann zwar oft die alten Config-Files noch, aber deren Inhalt wird automatisiert verwaltet. Wenn du da was änderst, is das nach dem nächsten Neustart wieder weg. Dann muss man gegebenenfalls woanders diese Dinge anpassen. Dafür müsste man aber wissen wer oder was deine Netzwerk-Configuration verwaltet.

[Petrus]

Solus:
NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; ven>
Drop-In: /usr/lib64/systemd/system/NetworkManager.service.d

Ubuntu wird auch sowas haben.
---
Da die Einträge nach dem Hardwaretausch nicht mehr stimmen (die interne IP und auch die rDNS Ip ist anders), muss es ja einen Weg um die automatische Verwaltungsschranke geben. Irgendwie.

[foobar]

Unitymedia

Mein Beileid. Ich hoffe, du kannst irgendwann auch nochmal ein vollwertiges Internet bei dir zuhause erhalten.

Seitdem gibt es Packetloss beim ersten Hop (addr.arpa), was scheinbar ein rDNS Server ist, der Anfragen von IP zum Namen auflöst im Gegensatz zum normalen DNS server, der zu einer Domain die IP liefert. Muss heutzutage scheinbar so sein, gehört zur Infrastruktur.

Wie genau äußert sich das? Kannst du mal ein Beispiel posten?

Einen "rDNS Server" in dem Sinne gibt es übrigens nicht. Die Rückwärtsauflösung von IPs zu Namen ist eine normale Funktion des herkömmlichen DNS, die es auch immer schon gegeben hat. Früher hatte man da IQUERYs, aber die konnten sich nicht wirklich durchsetzen, deshalb gibt's seit ca. 2002 halt den neuen Ansatz über PTR-Records in der dafür reservierten in-addr.arpa Domain.

Da wird dann die IP-Adresse - von rechts nach links geschrieben - in dieser Domain im DNS gesucht und das liefert den Namen als PTR-Record. Willst du also z.B. wissen, welchen Hostnamen der Server mit der IP w.x.y.z hat, dann fragst du das DNS nach z.y.x.w.in-addr.arpa (i.d.R. erledigt dein Client diese Umstellung) und kriegst deine Antwort.

Als Beispiel schauen wir mal, was Googles DNS über den Forenserver der WoP weiß:

Spoiler:(zum lesen bitte Text markieren)

$ dig @8.8.8.8 -x 46.4.29.208

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 -x 46.4.29.208
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;208.29.4.46.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
208.29.4.46.in-addr.arpa. 21599 IN      PTR     forum.worldofplayers.de.

;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 09 22:35:29 CEST 2018
;; MSG SIZE  rcvd: 90

Es ist also möglich, dass das kein "rDNS-Server" ist, sondern dass das Programm, welches du verwendest, einfach versucht, der IP-Adresse einen Hostnamen zuzuordnen. Falls das nicht klappt, bleibt es halt bei dem kryptischen Hostnamen aus der in-addr.arpa Domain.

Daher die Frage nach einem konkreten Beispiel. Was genau hast du gemacht?

[Petrus]

Mein Beileid. Ich hoffe, du kannst irgendwann auch nochmal ein vollwertiges Internet bei dir zuhause erhalten.

Wieso? Klär mich auf!

Wie genau äußert sich das? Kannst du mal ein Beispiel posten?

Alle ca. 20-30 Sekunden geht der Ping auf über 100ms hoch und hält sich danach wieder im Bereich von 20-30ms.

Spoiler:(zum lesen bitte Text markieren)

$ ping www.web.de
PING www.g-ha-web.de (82.165.229.138): 56 data bytes
64 bytes from 82.165.229.138: icmp_seq=0 ttl=247 time=21,718 ms
64 bytes from 82.165.229.138: icmp_seq=1 ttl=247 time=19,630 ms
64 bytes from 82.165.229.138: icmp_seq=2 ttl=247 time=21,828 ms
64 bytes from 82.165.229.138: icmp_seq=3 ttl=247 time=19,126 ms
64 bytes from 82.165.229.138: icmp_seq=4 ttl=247 time=24,364 ms
64 bytes from 82.165.229.138: icmp_seq=5 ttl=247 time=17,040 ms
64 bytes from 82.165.229.138: icmp_seq=6 ttl=247 time=28,888 ms
64 bytes from 82.165.229.138: icmp_seq=7 ttl=247 time=22,562 ms
64 bytes from 82.165.229.138: icmp_seq=8 ttl=247 time=30,680 ms
64 bytes from 82.165.229.138: icmp_seq=9 ttl=247 time=38,385 ms
64 bytes from 82.165.229.138: icmp_seq=10 ttl=247 time=25,605 ms
64 bytes from 82.165.229.138: icmp_seq=11 ttl=247 time=20,528 ms
64 bytes from 82.165.229.138: icmp_seq=12 ttl=247 time=142,681 ms
64 bytes from 82.165.229.138: icmp_seq=13 ttl=247 time=24,790 ms
64 bytes from 82.165.229.138: icmp_seq=14 ttl=247 time=70,241 ms
64 bytes from 82.165.229.138: icmp_seq=15 ttl=247 time=20,616 ms
64 bytes from 82.165.229.138: icmp_seq=16 ttl=247 time=52,371 ms
64 bytes from 82.165.229.138: icmp_seq=17 ttl=247 time=20,692 ms
64 bytes from 82.165.229.138: icmp_seq=18 ttl=247 time=19,985 ms
64 bytes from 82.165.229.138: icmp_seq=19 ttl=247 time=23,779 ms
64 bytes from 82.165.229.138: icmp_seq=20 ttl=247 time=36,379 ms
64 bytes from 82.165.229.138: icmp_seq=21 ttl=247 time=24,426 ms
64 bytes from 82.165.229.138: icmp_seq=22 ttl=247 time=20,894 ms

My traceroute [v0.91.1-4c982]
name (192.168.0.111) 2018-06-10T08:15:18+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. compalhub.home 0.0% 35 1.6 1.3 1.1 2.2 0.2
2. 84.116.198.90 28.6% 35 6237. 6393. 6124. 6623. 141.0
3. de-fra01b-rc1-ae28.fra.unity-med 0.0% 35 17.9 22.9 14.5 56.7 7.4
4. de-fra01b-ri2-ae29-0.aorta.net 0.0% 35 17.5 26.5 14.8 112.7 16.6
5. ae-8-0.bb-a.fra3.fra.de.oneandon 0.0% 35 21.8 22.8 14.0 49.5 7.3
6. ae-10-0.bb-a.bap.rhr.de.oneandon 0.0% 35 27.3 27.4 19.6 36.4 4.2
7. ae-0-0.gw-diste2-a.bap.rhr.de.on 0.0% 34 26.4 27.2 21.4 42.4 4.3
8. bap.web.de 0.0% 34 27.1 30.5 20.7 118.0 16.6

$ host 84.116.198.90
Host 90.198.116.84.in-addr.arpa. not found: 3(NXDOMAIN)

dig @8.8.8.8 -x 84.116.198.90
; <<>> DiG 9.11.3 <<>> @8.8.8.8 -x 84.116.198.90
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;90.198.116.84.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
198.116.84.in-addr.arpa. 1799 IN SOA ns1.upc.biz. hostmaster.chello.at. 2010121503 86400 7200 2592000 7200

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jun 10 08:24:39 CEST 2018
;; MSG SIZE rcvd: 122

Ist das mit Österreich normal? ^^
ns1.upc.biz. hostmaster.chello.at.

[foobar]

Wieso? Klär mich auf!

Unitymedia bietet meines Wissens nur DS-Lite-Anschlüsse an. Die sind nämlich (als ursprüngliche Fernsehkabelgesellschaft) erst zu einem Zeitpunkt in das Internetgeschäft eingestiegen, als öffentliche IPv4-Adressen bereits knapp - und damit teuer - zu werden begannen. Und da man natürlich nicht so viele einkaufen wollte, wie man eigentlich brauchte (das Geld lässt sich doch viel besser für die Bordellzulage des Vorstands verwenden), kam man auf die schlaue Idee, den Kunden einfach gar keine öffentliche IPv4-Adresse mehr zuzuweisen.

Statt dessen macht man CG-NAT (Carrier Grade Network Address Translation), quasi dasselbe NAT, das dein Router macht, um die vielen Geräte bei dir zuhause hinter eine öffentliche IP zu quetschen. Die Kabelprovider (wie Unitymedia) - und übrigens auch viele Mobilfunkanbieter - machen das halt für Kunden. Da werden hunderte oder tausende hinter einer einzigen öffentlichen IP zusammen gefasst. Eine etwas detailliertere Erklärung zur Funktionsweise gibt's hier.

Fairerweise muss man sagen, dass der normale Internet-DAU davon nicht allzu viel mitkriegt. Wenn du nur Facebook, YouTube, Twitter und BILD-Zeitung besuchst, dann funktioniert das i.d.R. problemlos. Blöd wird es für Leute, die etwas mehr mit ihrem Internetanschluss machen wollen. Insbesondere von außen zugreifen. Beispielsweise, um nicht auf Cloudanbieter angewiesen zu sein. Ich z.B. habe ein Android-Smartphone. Aus Gründen. Jetzt könnte ich die bequeme, vorinstallierte Google-Cloud benutzen, um meine Kontakte und Termine und Dateien zwischen meinem PC und meinem Handy synchron zu halten. Will ich als Aluhütchenträger aber nicht und wäre in meinem speziellen Falle als Selbständiger auch rechtlich nicht unproblematisch. Also habe ich meine eigene "Cloud". Auf meinem Server, hier bei mir im LAN. Da läuft ein Nextcloud, welches über einen DynDNS-Eintrag erreichbar ist. Und gegen den synchronisiert das Handy nun die Termine, Kontakte und Dateien. Niemand außer mir hat Zugriff auf die Daten und sie landen nicht bei Google oder sonstwo.

Auf ähnliche Weise könnte man z.B. Heimautomatisation machen, um kurz vor Feierabend auf der Arbeit schon mal zuhause die Heizung hochzudrehen. Bin selbst noch nicht so ganz von dem Konzept überzeugt, aber es scheint gegenwärtig der Renner zu sein. Und entweder läuft es über einen Clouddienst des Herstellers, dem man dann vertrauen muss. Oder man macht es selbst per Fernzugriff von außen (sofern das jeweilige System mitspielt, manche wollen natürlich nicht).

Das geht so alles mit Unitymedia nicht. Zumindest nicht via IPv4. Bei IPv6 gibt es genug Adressen, so dass man da auch tatsächlich eine öffentliche kriegt. DS-Lite steht ja für "Dual Stack Lite". Dual Stack heißt, es ist IPv4 und IPv6 gemeinsam aufgeschaltet und Lite heißt, der IPv4-Teil ist via CG-NAT kastriert. Aber IPv6 ist halt noch nicht überall verfügbar und macht gerne mal Probleme. Es führt wohl langfristig nichts daran vorbei, aber allzu viel halte ich von dem Protokoll nicht. Es wurde in den 90ern entwickelt und hauptsächlich auf die (ökonomischen) Anforderungen der Provider zugeschnitten. Userbedürfnisse wie bspw. Sicherheit oder auch nur, dass man sich so eine Adresse einfach mal merken kann, spielten offenbar keine Rolle. Dann schlummerte das Protokoll in den Schubladen vor sich hin, bis man sich wieder daran erinnerte, als die IPv4-Adressen knapp wurden und man dringend Ersatz brauchte. Egal, auf jeden Fall ist IPv6 in meinen Augen zumindest aktuell kein vollwertiger Ersatz für "richtiges" IPv4 (d.h. mit öffentlicher Adresse). Daher stufe ich Internet via TV-Kabel als "nicht vollwertiges Internet" ein.


Was du in dem Zusammenhang bei dir auch mal testen kannst: Wie sieht es auf IPv6 aus (der Befehl heißt dann "ping6")?

Ansonsten fällt mir jetzt im Moment nichts auf, was du bei dir falsch gemacht haben könntest, das dieses Verhalten erklärt. Es wäre denkbar, dass es sich einfach um eine providerseitige Überlastung handelt. Mir ist speziell Unitymedia in der letzten Zeit durch aggressive Werbung aufgefallen. Die stehen auf scheinbar jeder Messe und vor jedem Supermarkt und wollen mehr Kunden. Von entsprechenden Ausbaumaßnahmen der eigenen Infrastruktur, um mit der gestiegenen Last mithalten zu können, habe ich allerdings nichts mitgekriegt. Du kannst also auch mal schauen, ob das Verhalten über die Zeit konstant ist oder bevorzugt bspw. in den Abendstunden und am Wochenende auftritt.

Ist das mit Österreich normal? ^^

"Normal" nicht, aber es passt zu UnityMedia. Die gehören ja aktuell der niederländischen UPC, welche eine Tochter der Liberty Global ist (welcher wiederum diese IP-Adresse gehört). Dass der Server zufällig in Österreich steht, kann schon sein. Möglichst weit weg vom einzelnen Kunden, möglichst viele Kunden aus möglichst großem Einzugsgebiet zusammenfassen, dann ist es billig. Billig ist gut.

Angeblich soll UnityMedia demnächst an Vodafone verhökert werden, aber hoffentlich grätscht das Kartellamt da noch dazwischen. Denn da Vodafone sich bereits Kabeldeutschland einverleibt hat, hätten sie dann defacto ein Monopol im deutschen Kabelnetz. Aber der Verkauf liefert zumindest eine theoretische Erklärung für deren Verhalten in der letzten Zeit. Viele neue Kunden akquirieren, das steigert den Marktwert. Keinen Netzbau betreiben, das sind Kosten und senkt den Marktwert. Soll sich der neue Besitzer doch mit den überlasteten Netzen und verärgerten Kunden rumärgern, wir haben unseren Reibach schon gemacht.

[Petrus]

Sooo wunderbar, wie hast du nur von all diesen Dingen so einen guten Überblick und verstehst die Details noch dazu? Ich war mir dieser Hintergründe natürlich nicht bewusst, ist aber super interessant, soviel Erkenntnisgewinn hätte ich gerne bei vielen anderen Dingen die ich lese auch .

Was du in dem Zusammenhang bei dir auch mal testen kannst: Wie sieht es auf IPv6 aus (der Befehl heißt dann "ping6")?

Bei z.B. web.de funktioniert ping6 nicht (unknown host). Bei heise.de und wiki.archlinux.org schon und es gibt auch keine Pingspikes, allerdings zeigt MTR -6 nicht das komplette ipv6 Routing an (es fehlen alle Server außer dem Zielserver, wo pings und Varianzen normal dargestellt werden).

Ansonsten fällt mir jetzt im Moment nichts auf, was du bei dir falsch gemacht haben könntest, das dieses Verhalten erklärt. [...] Du kannst also auch mal schauen, ob das Verhalten über die Zeit konstant ist oder bevorzugt bspw. in den Abendstunden und am Wochenende auftritt.

Das ist konstant, egal ob nachts oder Samstag abends.

Ich dachte halt, dass die Einträge in named.conf nicht den aktuellen entsprechen, also z.B. die interne IP 192.168.0.weitereZahl und auch die so angelegte rDNS Datei namens rev.Zahl.0.168.192 und dass dieser Umstand zu der Verzögerung bei der Kommunikation mit dem DNS Server aus .at führt.

[foobar]

Sooo wunderbar, wie hast du nur von all diesen Dingen so einen guten Überblick und verstehst die Details noch dazu?

Ich bin halt genial.

*auf-die-fingernägel-hauch-und-am-hemd-abreib*

Und so bescheiden!

Ich dachte halt, dass die Einträge in named.conf nicht den aktuellen entsprechen, also z.B. die interne IP 192.168.0.weitereZahl und auch die so angelegte rDNS Datei namens rev.Zahl.0.168.192 und dass dieser Umstand zu der Verzögerung bei der Kommunikation mit dem DNS Server aus .at führt.

Die named.conf ist - überraschenderweise - die Konfigurationsdatei für den named. Ein anderer Name für BIND, also einen lokalen Nameserver. Ich bin mir nicht ganz sicher, wozu du denn benutzt. Normalerweise braucht man keinen eigenen Nameserver im LAN, der Router sollte bereits einen Resolver haben und das reicht dann für die meisten Anwendungen. Einen eigenen Nameserver brauchst du nur, wenn du spezielle Anforderungen hast. Und selbst da ist die Frage, ob es unbedingt BIND sein muss. Der kann zwar viel, ist aber auch komplex.

In jedem Fall halte ich es für eher unwahrscheinlich, dass der BIND mit dem Problem zu tun hat. Der löst einmal den Namen des Zielhosts zur IP-Adresse auf und hat dann mit eigentlichen Vorgang nichts mehr zu tun. Die ICMP-Echos und -Replies arbeiten bereits - und ausschließlich - mit der fertig aufgelösten IP-Adresse. Mit DNS-Namen können die nix anfangen.

Du könntest halt mal schauen, ob das Verhalten auch unter anderen Betriebssystemen und von anderen Endgeräten aus auftritt. Falls ja, kannst du ziemlich sicher sein, dass es nicht am lokalen Rechner bzw. dessen OS-Konfiguration liegt.

[Petrus]

Ok, ich hab noch Ubuntu, aber da hab ich auch genau diese Mini-Pingspikes. Könnte mir noch ein neues OS auf eine Partition packen zum Testen. 10GB reichen ja dicke, meistens. Vorschläge?
Dachte da an SELinux, nochmal Manjaro, Tiny Core, TrueOS (yay, BSD), ReactOS (für Warframe? ) oder tatsächlich mal Sabayon (uaah Gentoo).
Ich habe noch ein WindOS, aber ick fühl mir inzwischen unwohl da reinzubooten.

Bis dahin schau ich mal kurz mit Knoppix, ob es da auch hapert.

edit: nein, ich benutze kein BIND / lokalen nameserver, ich dachte die Konfiguration sei für addr.arpa dort abgelegt.

[foobar]

Wenn du ein Smartphone hast, das ist letztlich auch nur ein Computer (wird gerne vergessen). Bei Android kannst du z.B. mit Termux eine Linux-Shell mit den üblichen Tools bekommen.

[Petrus]

Es ist das gleiche mit Xubuntu und Knoppix: nur bei web.de (ipv4) kommen die Spikes durch den Packetloss vom addr.arpa Server in .at, bei heise.de (ipv6) gibt es keinen einzigen Ping über 50ms.
So wie du es oben beschrieben hast liegt es also sehr wahrscheinlich an dem CG-NAT.

Morgen früh kommt ein Lokal-Techniker, der für die Verkabelung des Hauses zuständig ist (bisher der einzige, der verstanden hat, wo das Problem liegen könnte), dessen Besuch natürlich obsolet ist, soviel war uns beiden schon vorher klar. Allerdings wird sein Bericht den 2nd-Level Support von Unitymedia aufwecken. Könnte Unitymedia da irgendwas ändern, also auf dieser Service-Ebene oder ist z.B. die Zuweisung zu einem Server in .de statt .at nichts, was der Support veranlassen könnte?

Smartphone, ne so'n Schweinkram hat man als Hütchenträger net.