Viele Seiten und Dienste nur via WLAN erreichbar

DHCPv4 arbeitet ja mit dem undirected Broadcast 255.255.255.255 und der wird niemals geroutet. Es muss sich um einen Ethernet-Link handeln, aber man kann auch 2 Ports eines Routers miteinander verbinden und hat genau das gleiche Ergebnis. Daher muss man den Störer jetzt finden. Das ist auch der Grund, warum in größeren Netzen Switche genutzt werden, die DHCPv4, DHCPv6 und die Router-Advertisements erkennen und blockieren können. Die Admins werden dann informiert, an welchem Port das war und man kann den Verursacher schneller finden.
 
Vielen Dank @Olstyle und @DJKuhpisse .
Plötzlich funktioniert die Verbindung via LAN wieder wie gewohnt - alle Seiten / Dienste laden ordnungsgemäß.

Unter Wireshark tauchen weiterhin beide IP's unter DHCP auf (Desktop PC nur via LAN verbunden). Trotzdem funktioniert es nun.

192.168.0.1 => ARRIS Group (Vodafone Router / richtiger Router)
192.168.1.1 => TP-LINK Tech.

Um auszuschließen, dass es sich bei dem 192.168.1.1 um meinen eigenen Repeater handelt, habe ich ARPING auf die IP laufen lassen und den Repeater währenddessen vom Strom genommen; ARPING lief weiter. Verstehe ich also richtig, dass es sich um den Repeater einer anderen Partei im Hause handeln muss und dieser möglicherweise falsch konfiguriert ist?
Und verstehe ich dich, @DJKuhpisse richtig, dass es nun zwar funktionieren kann, dieses Gerät jedoch dauerhaft bzw. immer wieder für Probleme sorgen kann / wird?
 
Es soll nur der DHCP des ARRIS-Routers Adressen rausgeben. Der andere MUSS abgestellt werden, der macht dir immer wieder Probleme, je nachdem wer zuerst antwortet. Ihr müsst im kompletten Haus schauen, welches TP-Link-Gerät das ist und dann abklären, warum das da ist und was es eigentlich tun soll.
 
Alles klar, ich werde mich umgehend mit meinem Vermieter diesbezüglich in Verbindung setzen und um seine Hilfe bei der Suche nach diesem Gerät bitten.

Riesigen Dank für die Hilfe! Alles andere als selbstverständlich, dass du / ihr so viel Zeit für einen n00b wie mich aufwendet.
Ich konnte hieraus einiges mitnehmen bzw. lernen.

Danke!
 
@bachenkieling: Es wäre dann noch sehr interessant zu wissen ob und wie du bzw. ihr den "Verursacher" finden konntet und um welches Gerät es sich dabei handelt.

Wäre nett wenn du das postest!
 
Wenn man keine Logs/spezielle Switche hat geht nur eins: Sukzessive rumgehen und alles abstecken, dann immer arping laufen lassen und schauen, wann das Gerät kommt. Dann an diesem Zweig weitersuchen. Bei WLAN halt mal das WLAN abstellen. So findet man raus, wie das Gerät angebunden ist und kann es finden und abstellen.
 
Ich werde den Vermieter bitten, mir physischen Zugang zum Router zu gewähren, um dann, wie @DJKuhpisse sagte, ein LAN-Kabel nach dem anderen zu ziehen, während arping auf das entsprechende Gerät läuft.
Anhand des Kabels sollte man dann feststellen können, zu welcher Wohnung das Gerät gehört und die dortige Partei darüber aufklären bzw. Hilfe bei der Rekonfiguration leisten.

Mich wundert, dass mein Hauptsystem jetzt normal funktioniert, meine VM jedoch weiterhin die gleichen Probleme hat, wobei sie doch über das selbe Kabel und den gleichen Netzwerkadapter läuft.
 
Mich wundert, dass mein Hauptsystem jetzt normal funktioniert, meine VM jedoch weiterhin die gleichen Probleme hat, wobei sie doch über das selbe Kabel und den gleichen Netzwerkadapter läuft.
Je nachdem welcher DHCP zuerst antwortet bekommst du halt ne passende IPv4 oder nicht. IPv6 ist davon unberührt und funktioniert, aber viele Server haben bisher kein IPv6 und bewegen sich noch in der Steinzeit.
 
Ich werde den Vermieter bitten, mir physischen Zugang zum Router zu gewähren, um dann, wie @DJKuhpisse sagte, ein LAN-Kabel nach dem anderen zu ziehen, während arping auf das entsprechende Gerät läuft.
Wäre es nicht sinnvoller, einen Aushang zu machen und zu fragen ob jemand einen TP-Link Router hat statt einfach mal allen ungefragt das Internet weg zu nehmen?

Derjenige macht das sicher nicht Absichtlich.

Aber einfach allen mal so, ohne Vorwarnung die Leitung zu kappen, ist nicht die feine Art :)
 
Wenn man sowas richtig professionell macht hat man daher auch Switche, die das erkennen und dann gleich die MAC und den Port speichern. So kann man schonmal prima eingrenzen.
 
Wäre es nicht sinnvoller, einen Aushang zu machen und zu fragen ob jemand einen TP-Link Router hat statt einfach mal allen ungefragt das Internet weg zu nehmen?

Derjenige macht das sicher nicht Absichtlich.

Aber einfach allen mal so, ohne Vorwarnung die Leitung zu kappen, ist nicht die feine Art :)
Du hast vollkommen Recht. Das wird in diesem Haus jedoch leider nicht funktionieren - die Leute hier sind nicht für Ihre Zuverlässigkeit bekannt und beachten Aushänge nicht. Und wie gesagt, das wird in Absprache mit dem Vermieter passieren. :)
 
Du hast vollkommen Recht. Das wird in diesem Haus jedoch leider nicht funktionieren - die Leute hier sind nicht für Ihre Zuverlässigkeit bekannt und beachten Aushänge nicht. Und wie gesagt, das wird in Absprache mit dem Vermieter passieren. :)
Da kann man aber wenigstens ankündigen, daß es aufgrund von Reparaturmaßnahmen Störungen im Internet geben kann von 13:00 bis 14:00 Uhr am Samstag in zwei Wochen.

Dann sollte das akzeptiert werden.
 
erledigt - ich war nur auf Seite1 :(
Das sieht so aus, als ob im Netz die IP Adresse des Gateways doppelt vergeben ist:
30:B4:9E - TP-Link
CC:2D:21 - Tenda Technology Co.,Ltd.Dongguan branch

arp -a zeigt Dir den Cache deines PC an.
Vergleiche den Eintrag von 192.168.1.1 mit der MAC Adresse des Routers.
 
Das kann nicht sein, denn es waren 2 unterschiedliche Adressen und ein DHCPv4 war aktiv, der nicht hätte sein sollen. Der muss abgestellt werden. Wenn eine IPv4 auf einem Link doppelt vergeben ist kommen auf die ARP-Anfrage 2 Antworten.
 
"Wenn eine IPv4 auf einem Link doppelt vergeben ist kommen auf die ARP-Anfrage 2 Antworten."

kamen auch - sieht man im arpping
Die erste Mac Adresse ist anders.

...
ubuntu@ubuntu:~/Desktop$ sudo arping 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.111 enp34s0
Unicast reply from 192.168.1.1 [30:B4:9E:F2:77:D2] 0.716ms
Unicast reply from 192.168.1.1 [CC:2D:21:87:91:48] 1.020ms
Unicast reply from 192.168.1.1 [CC:2D:21:87:91:48] 1.012ms
Unicast reply from 192.168.1.1 [CC:2D:21:87:91:48] 0.983ms
 
Zurück