[PROBLEM] ARP overwritten: ALICE routet fremde private IPs über WAN

der_Gersthofer

Admin-Team
Mitglied seit
17 Apr 2004
Beiträge
3,585
Punkte für Reaktionen
0
Punkte
36
Es gibt ein weiteres folgendes, unregelmäßig aber kontinuierlich auftretende Problem:

Netzwerkaufbau:

Sphairon Turbolink IAD -> Intertex IX67 (192.168.0.1) -> Toshiba Laptop (192.168.0.31; per DHCP zugewiesen)

Im Protokoll des Routers IX67 finden sich immer wieder Meldungen "ARP info overwritten", danach ist keine Internetverbindung vorhanden und es hilft nur ein Neustart des Sphairon und des IX67.

Mehrere Netzwerkgeräte (MAC-Adressen) melden also die gleiche IP-Adresse, demnach also mehrere Geräte die gleiche IP haben, was natürlich nicht sein kann/darf. Die MAC-Adressen beginnend mit 00:04:0e gehören dem Pool von AVM an - jedoch befindet sich kein AVM-Gerät im lokalen Netzwerk (nur die obigen drei Geräte).

Woran kann dies liegen? Was kann man machen?

Code:
0d 00:00:07   tMicroCron   debug   DNS query (A) for 'de.pool.ntp.org' resulted in 81.169.178.103
0d 00:00:07   tMicroCron   debug   DNS query (A) for 'de.pool.ntp.org' resulted in 81.210.250.100
JUL 02 20:40:01   tMicroCron   info   SNTP: Uptime 0d 00:00:07 = Real Time JUL 02 20:40:01
JUL 02 20:40:01   tMicroCron   debug   de.pool.ntp.org Time=1183401601, Uptime=7
JUL 02 20:40:01   tMicroCron   debug   IX_Real_Time_offs=1183401594, IX_Time_Adjust=7200
JUL 02 20:40:03   tMicroCron   debug   Promote. Permission check: disabled
JUL 02 20:45:36   tCfg   info   NET config started
JUL 02 20:45:36   tCfg   info   Default gateway, 192.168.178.1, initialized.
JUL 02 20:45:36   tCfg   info   NET config finished
JUL 02 20:45:36   tCfg   info   SEC config started
JUL 02 20:45:36   tCfg   info   SEC config finished
JUL 02 20:45:36   tCfg   info   Configured proxy; 0 mappings
JUL 02 20:45:36   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:7e:xx:xx
JUL 02 20:45:36   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:45:36   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:76:xx:xx
JUL 02 20:45:36   tInit   info   et2: New DHCP lease, IP address: 192.168.178.27
JUL 02 20:45:37   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:45:38   tMicroCron   debug   DynDnsTask: tic
JUL 02 20:45:38   tMicroCron   debug   DynDnsUpdate: start
JUL 02 20:45:41   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:af:xx:xx
JUL 02 20:45:42   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:46:04   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:af:xx:xx
JUL 02 20:46:04   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:46:22   tInit   info   et1(mac0): Link down.
JUL 02 20:46:23   tMicroCron   debug   DynDnsTask: tic
JUL 02 20:49:48   tMicroCron   debug   EmailNotificationTask(): tick
JUL 02 20:49:48   tMicroCron   debug   IX_display_email: 0
JUL 02 20:49:48   tMicroCron   debug   DynDnsTask: tic
JUL 02 20:51:39   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:af:xx:xx
JUL 02 20:51:39   tNetTask   debug   arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:53:50   tInit   info   et1(mac0): Link up.
JUL 02 20:53:53   tMicroCron   debug   DynDnsTask: tic
JUL 02 20:54:27   *** System memory: 3523048 bytes allocated, 4811788 bytes free ***
JUL 02 20:54:27   *** Rel: "release-4.03-final" (Apr 12 2007) ***
JUL 02 20:54:27   *** Uptime: 0d 00:14:33 ***

Also vier unterschiedliche AVM MAC Adressen:

JUL 02 20:45:36 tNetTask debug arp info overwritten for c0a8b2xx by 00:04:0e:7e:xx:xx
JUL 02 20:45:36 tNetTask debug arp info overwritten for c0a8b2xx by 00:04:0e:bc:xx:xx
JUL 02 20:45:36 tNetTask debug arp info overwritten for c0a8b2xx by 00:04:0e:76:xx:xx
[...]
JUL 02 20:45:41 tNetTask debug arp info overwritten for c0a8b2xx by 00:04:0e:af:xx:xx

Es ist aber gar kein einziges Gerät von AVM hier im Netzwerk vorhanden.


Intertex schrieb schon

You have multiple units (MAC 00:04:0e:7e:xx:xx and 00:04:0e:bc:xx:xx) having the same IP address (c0a8b2xx = 192.168.178.x).

The MACs 00:04:0e belong to AVM GmbH

When the second unit answers to ARP IX67 detects that another unit already is listed in the ARP table with that IP address. Then the old entry is replaced with the new one, and the log message is added.

You are not allowed to have multiple units with the same IP address on an IP network.
 
Was kann man machen?

Dem Internet Provider solange in den Allerwertesten treten, bis er das Problem löst. Aus Deinem eigenen Netzwerk dürfte das Problem mit 99,9% Sicherheit nicht stammen. Es sieht danach aus, als ob im WAN auch private IP Adressen geroutet werden, was eigentlich auf keinen Fall passieren darf.

Du könntest als Sofortmaßnahme mal versuchen, den IP Bereich Deines eigenen Netzwerkes zu ändern. Also z.B. 192.168.144.x zu verwenden anstatt 192.168.178.x
 
Danke, werde ich machen.

Die IP 192.168.178.1 habe ich nicht vergeben (das Netzwerk - IX67, Laptop - ist im Bereich 192.168.0.x angelegt). Und auf den Turbolink komme ich mangels Passwort nicht drauf.

Nachdem das 4 unterschiedliche MAC Adressen sind, die allesamt zu AVM-Geräten gehören, scheinen sich da vier mir unbekannte Geräte mit dem Netzwerk verbinden zu wollen, die der Turbolink alle durchlässt....

Alice, finde ich spitze!
 
Du hast anscheinend Dein Internet über einen Switch mit dem LAN verbunden.
Dafür nimmt man einen Router.

siehe OSI-Modell

Das Sicherheitsproblem hat der Anwender wenn er vergisst zu routen oder beim routen Pakete aus privaten Adressbereichen oder loopback in sein LAN lässt. Bei Internet über Kabel ist das nicht so gut gefiltert wie bei Telekom-DSL.
 
Wie oben geschrieben: Netzwerkaufbau:

Sphairon Turbolink IAD -> Intertex IX67 -> Toshiba Laptop


Da ist kein Switch. Der Intertex IX67 ist ein reiner Router (ohne integriertem Modem).
Und das Sphairon wurde von Alice genau so geliefert (ist vorkonfiguriert und passwortgeschützt). Der Intertex IX67 Router ist am LAN 1 des Sphairon angeschlossen...

Das ist auch kein Kabelinternet, sondern HanseNet (Alice) DSL
 
Thomas007 schrieb:
Du hast anscheinend Dein Internet über einen Switch mit dem LAN verbunden.

so ein Quark... :rolleyes:

Dafür nimmt man einen Router.

Gut daß uns das endlich mal jemand sagt :rolleyes:

Das Sicherheitsproblem hat der Anwender

Ein Sicherheitsproblem ist das nicht direkt, nachdem ja nun geklärt ist, daß die 192.168.178 nicht im LAN definiert ist. Und schon gar nicht ein Sicherheitsproblem beim Anwender. Das ist vielmehr eine unsaubere Netzwerkkonfiguration auf der WAN-Seite, die sich im vorliegenden Fall bis zum WAN Port des IX67 erstreckt und vom Anwender überhaupt nicht beeinflußt werden kann. Und darum kann sich einzig und alleine der DSL Provider kümmern. Wobei hier scheinbar mehrere Provider versagt haben. Denn der Internetprovider, über den die AVM Geräte überhaupt ins Internet kommen, dürfte die privaten IPs erst gar nicht ins Internet routen, andererseits dürfte auch Alice diese Pakete nicht weiterrouten. Aber vielleicht sind ja die Fritzboxen auch über Alice DSL angebunden :mrgreen:
 
Intertex schrieb mir aufgrund weiterer Protokolle jetzt noch:

One thing I see in your firewall log is repetitive ARP sweeps coming in to your WAN port from 192.168.1.1 (MAC address 00:01:e3 is registered as Siemens). There comes 253 ARP packets, requesting host 192.168.1.2 to
192.168.1.254 to answer. My guess is either your ISP or (more likely) some of your hacker-wannabe neighbours is scanning the subnet for other clients. As your WAN IP address is not on the 192.168.1.x subnet I suspect more your neighbour's equipment than your ISP's.

Anyway, the ARP sweep is not the cause of your problem, just an indication something is fishy on your WAN connection. My guess is your "arp info overwritten" ARP packets also come from your WAN connection.

You could contact your ISP and show them your firewall logs and ask where all those ARP sweeps come from.

Was komisch ist: mal 192.168.178.x, mal 192.168.1.x Beides ist von mir nicht vergeben (wobei der Sphairon möglicherweise die 192.168.1.1 hat). Es ist aber auch kein Siemens-Gerät im Netzwerk vorhanden. Das Sphairon hängt direkt an der Telefonbuchse.
WLAN am IX67 ist deaktiviert, von da kann also nichts kommen.
 
der_Gersthofer schrieb:
Was komisch ist: mal 192.168.178.x, mal 192.168.1.x Beides ist von mir nicht vergeben.

Das ist nicht wirklich komisch. Wenn Alice wirklich fälschlicherweise private IPs routet, dann können bei Dir beliebige private IPs aufschlagen. Also alles im Bereich 192.168.yyy.zzz oder auch mal 172.xxx.yyy.zzz

Von einem bösartigen Hack-Angriff würde ich übrigens gar nicht mal ausgehen. Ich denke, die Besitzer der Fritzboxen wissen gar nicht, daß ihre lokale IP im Internet rumschwirrt. Wenn jemand wirklich hacken wollte, würde er das sicher intelligenter machen ;)

Hast Du denn schon Kontakt zu Alice aufgenommen? Mich würde mal deren Antwort viel mehr interessieren als die Antworten von Intertex.
 
betateilchen schrieb:
Aber vielleicht sind ja die Fritzboxen auch über Alice DSL angebunden :mrgreen:
Ich schätze mal genau dieses, da haben manche wohl das Sphairon mittels diverser im Internet herumvagabundierender Anleitungen gegen eine FBF "ersetzt"...

Wenn das die Ursache ist, sollte ALICE diesen Nutzern den entstandenen/entstehenden Schaden mal in Rechnung stellen (ist schließlich ein Verstoß gegen die AGB dieser Nutzer). Hier kann der DSL Anschluss nämlich nicht mehr vernünftig genutzt werden.


Ja, ich habe ALICE schon geschrieben - aber erst vor ca. 20 Minuten.

Es wird immer besser (von Alice natürlich noch keine Antwort)

Well, its quite a mess.

Apparently there is an 192.168.178.1 on the WAN you are connected to that acts as a DHCP server (see the 11th packet on the first page of your fwlog.asp.pdf).

At the bottom of the second page your IX67 sends out a DHCP request, and its a mess - several DHCP servers answer.

At the bottom of page 44 your IX67 sends out a new DHCP request (as your old dhcp lease has expired). Now it gets an answer from 192.168.178.1 and apparently uses that DHCP server. It gets the IP address 192.168.178.29 from that DHCP server, and is told to use 192.168.168.1 as DNS server too.

From that point on its getting even stranger. Each time your IX67 wants to resolve an address it tries to use 192.168.178.1 as DNS server as it was told so by the DHCP server. But 192.168.178.1 answers different MAC addresses for each request. You never get any DNS answer from it either.
Thus no surfing.

There are so many strange things in your log one could write a book about it. The main questions are:
* Who is 192.168.178.1? According to its 00:04:0e MAC it is an AVM machine.
* Who is 192.168.1.1? According to its 00:01:e3 MAC it is a Siemens machine. It is sending out ARP scans over the 192.168.1.0 subnet.

I believe it is your Sphairon router that is the cause of some of your problems. Perhaps it has two different built-in DHCP servers?! But that would be so strange its unheard of. Rather I think you get DHCP answers from your Sphairon - and from some other DHCP server on your Internet connection too.

Have you connected any PC-s or any other units to your Sphairon? PC-s can act as DHCP servers sometimes.

Anyway, the strange packets are coming from your WAN connection. Thus you should check your Sphairon and WAN connection, and contact your ISP. If you find someone with technical knowledge at their support you should send him the firewall log and point to the bottom of pages 2 and 44 - he should get the picture from there.

Es ist weder ein AVM Gerät noch ein SIEMENS Gerät (wie die MAC-Adresse des Sphairons beginnt (ob sich hinter der Siemens MAC also das Sphairon verbirgt) kann ich jetzt gerade nicht nachsehen) im Netzwerk eingebunden. Und so geht das jetzt schon seit einigen Wochen (Aufschaltung war der 01.06.).
 

Anhänge

  • fwlog.asp.pdf
    1.9 MB · Aufrufe: 15
  • syslog.asp.pdf
    155.1 KB · Aufrufe: 5
betateilchen schrieb:
Das ist nicht wirklich komisch. Wenn Alice wirklich fälschlicherweise private IPs routet, dann können bei Dir beliebige private IPs aufschlagen. Also alles im Bereich 192.168.yyy.zzz oder auch mal 172.xxx.yyy.zzz

Hast Du das Problem doch noch erkannt, besser spät als nie.

Das ist aber nicht wirklich schlimm, da man solche Pakete beim routen filtert.
Sicherheitsproblem beim Anwender (siehe oben)
Da WAN und LAN auch an zwei unterschiedlichen Schnitstellen hängen (sollen) ist das auch problemlos möglich.


Scheint so als würde jemand privates einen DHCP Server im Alice Netz betreiben. Das ist natürlich ein echtes Sicherheitsproblem.

Schau halt ob Du Deinen DHCP-Client konfigurieren kannst. Man muss nicht alles nehmen was der Server schickt.
 
Wenn Du schon zitierst, dann tu das bitte so, daß es nicht dermaßen sinnentstellend endet, wie Du es im vorliegenden Fall getan hast.

Meine Aussage "Das ist nicht wirklich komisch" bezog sich definitiv auf das im Thread zuvor getroffene "Was komisch ist: [...]" und hatte überhaupt nichst lustiges an sich. Aber das hast Du wohlwissend einfach "übersehen".


Scheint so als würde jemand privates einen DHCP Server im Alice Netz betreiben. Das ist natürlich ein echtes Sicherheitsproblem.

Das hat Intertex auch schon festgestellt, deshalb steht das ja auch schon eine ganze Weile hier im Thread. Und auf diese Tatsache der Existenz privater IP Adressen im Alice Netzwerk bezog sich auch meine allererste Antwort, daß man da nur dem Provider auf die Füße treten kann, um das Problem zu antworten.

Also was willst Du uns eigentlich mit Deinem Beitrag sagen :noidea:
 
betateilchen schrieb:
Wenn Du schon zitierst, dann tu das bitte so, daß es nicht dermaßen sinnentstellend endet, wie Du es im vorliegenden Fall getan hast.

Nö, lies halt richtig. Das filtern von privaten IPs kann und sollte der Anwender machen. Das hast Du bestritten.

Und im Alice Netz scheint es sogar notwendig zu sein den DHCP Client besonders sorgfältig zu konfigurieren.
Das man sich so einfach einen gefakten DNS-Server zuweisen lässt ist ein Sicherheitsproblem wie man sieht.

Man kann natürlich auch dem Provider vertrauen und das Beste hoffen.
 
Thomas007 schrieb:
Nö, lies halt richtig. Das filtern von privaten IPs kann und sollte der Anwender machen. Das hast Du bestritten.

:crazy:

Keine Ahnung, wo ich das bestritten haben soll. Davon abgesehen werden mindestens 99% aller Anwender gar nicht die Möglichkeiten haben, eine solche Filterung mit der ihnen vom Provider zur Verfügung gestellten Internet-Verbindungs-Hardware durchführen zu können.

Und das Sphairon wurde von Alice genau so geliefert (ist vorkonfiguriert und passwortgeschützt).

Zwischen dem Sphairon und dem Intertex Router ist nix mehr, wo man irgendwas konfigurieren könnte - wer den Thread und die Problembeschreibung aufmerksam gelesen hat, dem wird das aufgefallen sein. Der Anwender hat also gar keine andere Möglichkeit, als dem "Provider zu vertrauen". Das heißt doch, eine Möglichkeit gibt es noch: Einen Provider zu wählen, der vertrauenswürdiger ist und solch einen Mist in seinem Netzwerk erst gar nicht zuläßt.

Geiz ist eben doch ungeil.
 
betateilchen schrieb:
Zwischen dem Sphairon und dem Intertex Router

Wie Du richtig geschrieben hast "Router".
Der sollte auch paketfiltern und der DHCP-Client auf dem Router sollte für dieses nicht vertrauenswürdige Netzwerk "sicherer" konfiguriert werden.

betateilchen schrieb:
ist nix mehr, wo man irgendwas konfigurieren könnte

Ein Router und ein DHCP-Client sind da. Ob man da wie Du meinst nichts derartiges einstellen kann ich nicht bestätigen.
 
@Thomas007

Ich kann deine Posts nicht verstehen. Zuerst schreibst du was von Switch, dann von Kabelinternet, dann, das das ein Anwenderproblem sein sollte?!

Also: Das ist der Anschluss meiner Freundin. Die hätte, wie die meisten Kunden, wohl kaum das technische Wissen, einen Client zu konfigurieren. Die schließen den Router (Intertex IX67) am "Modem" (Sphairon) an und tragen im Router (IX67) die PPPoE Zugangsdaten ein. Den Rest (DNS-Server-IP, WAN-IP etc.) muss der Server des Providers liefern.
Und dann wird der Laptop (IP: 192.168.0.31, per DHCP vom Router bezogen) eben am Router (IP: 192.168.0.1) angeschlossen.


Hier ist zwischen Sphairon (nochmal: auf den habe ich keinen Zugriff, da von Alice passwortgeschützt! Zudem gibt es kein Webinterface, da dieses, wie ich anderweitig gelesen habe, mit der letzten automatisch (remote) durchgeführten Firmwareaktualisierung entfernt wurde) und angeschlossenem Router nichts. Im Router (IX67) sind die PPPoE Zugangsdaten hinterlegt.

Woher soll der Router wissen, dass die 192.168.178.1 nicht aus meinem Netzwerk kommt (sondern eine fremde, eigentlich externe IP, die er wegfiltern muss)? Das dürfte er nur dann wegfiltern wenn er wüsste, dass das nichts mit meinem Netzwerk zu tun hat. Kann er aber nicht wissen, denn es könnte ja tatsächlich ein Gerät in meinem Netzwerk sein, das als DHCP Server fungiert und die IP 192.168.178.1 hat und IPs aus dem Adressbereich 192.168.178.x verteilt...

Thomas007 schrieb:
Und im Alice Netz scheint es sogar notwendig zu sein den DHCP Client besonders sorgfältig zu konfigurieren.
Das man sich so einfach einen gefakten DNS-Server zuweisen lässt ist ein Sicherheitsproblem wie man sieht.

Man kann natürlich auch dem Provider vertrauen und das Beste hoffen.

Was soll ich also deiner Meinung nach am Router wie konfigurieren? Manuell eine DNS Server-IP vorgeben?

Das würde trotzdem nichts daran ändern, dass der Router als Gateway-IP teilweise diese 192.168.178.1 (irgendeines AVM-Endgeräts) mitgeteilt bekäme und auch nichts daran, dass nach dem derzeitigen Stand bei Alice ein Sicherheitsproblem besteht.


PS: Die Jungs von Intertex haben wirklich Ahnung. Wenn die sagen, dass das ein Problem des Providers ist, dann kann man mit 99,999%iger Sicherheit davon ausgehen, dass es ein Providerproblem ist. Die Supportmitarbeiter sind nämlich dort keine Telefondamen/-herren, sondern Techniker. Und hier stammt die Aussage vom (m.W.) Chef der Entwicklungsabteilung.


PPS: Antwort von Alice

Liebe Alice Kundin, lieber Alice Kunde!

Ihre E-Mail haben wir erhalten.

Aufgrund der großen Nachfrage zu unseren aktuellen Produkten und Optionen verzögert sich die Bearbeitung Ihrer Anfrage ein wenig. Wir werden uns jedoch innerhalb der nächsten 7 Tage mit Ihnen in Verbindung setzen. Bis dahin bitten wir Sie um etwas Geduld.

Da dies eine automatisch erstellte Eingangsbestätigung zu Ihrer E-Mail-Anfrage ist, bitten wir Sie, über die Funktion "Antworten" keine E-Mails an uns zu senden.

Mit freundlichen Grüßen

Ihre Alice Kundenbetreuung
 
Thomas007 schrieb:
Ein Router und ein DHCP-Client sind da. Ob man da wie Du meinst nichts derartiges einstellen kann ich nicht bestätigen.

Das ist der Unterschied zwischen Deinen und meinen Antworten - ich kenne den IX67 weil ich den eine Zeitlang selbst im Einsatz hatte und deshalb weiß ich auch ziemlich genau, wovon ich rede, wenn ich sage, daß das hier beschriebene Problem nur vom Provider gelöst werden kann. Ich meine das nicht nur.
 
Möglichkeiten z.B.
Dein LAN hängt an eth0 Subnet A, wenn jetzt an WAN eth1 ein Paket ebenfalls aus Subnet A ankommt dann ist was kaputt.
Man kann auf die IP des DHCP-Server filtern.
Man kann einzelne Einträge des DHCP-Servers überschreiben.

Ob das für Dich mit Deiner Hard- und Software praktikabel ist habe ich nicht behauptet.

In jedem Fall passt Deine Konfiguration nicht zu dem Netzwerk an dem Du angeschlossen bist.

Dein Internet geht schließlich nicht und es ist gibt ein Sicherheitsproblem.

Ob die Ursache nun temporärer Fehler oder "es ist eben so" bei Alice ist weiß ich nicht.
 
Hallo,

Thomas007 schrieb:
Das finde ich auch lustig. ;) Im OSI Modell steht also, dass man für den Internetzugang einen Router benötigt.
Bitte zitiere mal die Stelle. Die ist mir bislang nicht aufgefallen.

Verzeiht, wenn ich mich einmische, fühle ich mich doch fast ein wenig "mitschuldig", da ich schon ein paar mal die Konstellation "Fritz hinter IAD" eingerichtet habe.

Die Logs lassen eigentlich keinen anderen Schluss zu als den, den auch betateilchen schon geäußert hat: Alice routet private IPs. :shock:

Das finde ich offen gestanden einigermaßen verwunderlich, grenzt es meines Erachtens doch an einen Anfängerfehler.

Auch gegen die Analysen von Intertex ist nichts zu sagen, soweit man das mit den vorliegenden Informationen beurteilen kann.

Die Frage, die ich mir aber momentan noch stelle: Wie kommen Pakete aus dem LAN eines Routers ins WAN bei Alice? Ich hab schon Fritzboxen mit "Internet über LAN" eingerichtet (sowohl über PPPOE als auch über IP) und auch schon Paketmitschnitte auf DSL Ebene in solchen Szenarien durchgeführt: Pakete aus dem LAN wie z.B. DHCP OFFERS hab ich da nie gesehen.

Auch wundern mich die ARP Requests der Siemens Geräte. Das sind doch sogar Broadcasts an die MAC FF:FF:FF:FF:FF:FF, oder? Das macht die Sache noch mysteriöser.
Es wird eine ARP-Anforderung (ARP Request-Broadcast) mit der IP-Adresse des gesuchten Computers gesendet. Bei Broadcasts ist das Erzeugen eines Ethernetframes kein Problem, da als MAC-Zieladresse die Broadcast-Adresse ff-ff-ff-ff-ff-ff verwendet wird.
Quelle: http://de.wikipedia.org/wiki/Address_Resolution_Protocol
(Diese ARP Sweeps kenne ich übrigens von meinem alten Siemens SE 505, der machte das auch, aber nur im LAN).

Wie also kommen die Pakete ins WAN? Vielleicht, weil einer WAN und LAN seines Routers auf den gleichen Switch legt (vielleicht sogar den im IAD)? Merkwürdig zwar, aber denkbar.
Aber das erklärt es eigentlich auch nicht: Der "Anfang" der Internetverbindung ist ja nicht am Modem, sondern das PPPOE Interface, auf dem die WAN IP liegt, und liegt damit quasi "im Router". Also doch eine fehlerhafte Implementierung in Siemens oder AVM Geräten? Vielleicht ausgelöst durch Modifikationen?

Wie man es auch dreht und wendet: Alice routet definitiv fehlerhaft. Außerdem bin ich mir sicher, dass der_Gersthofer selbst gar nichts gegen dieses Problem tun kann.
Dennoch frage ich mich (eher aus Neugier), wie überhaupt Pakete aus dem LAN ins WAN kommen.

Viele Grüße

Frank
 
Zuletzt bearbeitet:
Das verstehe ich alles auch nicht. Vor allem wundert mich auch, warum das nicht schon mehr Leute genauer untersucht haben. Vielleicht liegen die zahlreichen Probleme die immer wieder berichtet werden, genau an diesem Phänomen. Denn dass dies so nur bei meiner Freundin auftaucht, kann ich mir kaum vorstellen.


Im Router (IX67) kann ich nicht viel einstellen diesbezüglich. Ich kann fixe DNS Server Adressen setzen und auch eine fixe IP Gateway Adresse (ich habe die bezogenen Adressen einfach mal "fixiert" noch beover diese mit 192.168.178.1 ersetzt werden und die ARP overwritten messages im Log auftauchen), aber das scheint auch keine Verbesserung gebracht zu haben. Zudem ist dann beim nächsten Neustart wegen der sich geändert habenden Gateway IP dann natürlich die vormals fixierte falsch und es kommt dann gar keine Internetverbindung zu Stande.

Internet geht übrigens sowieso nur dann, wenn ich den IX67 zuerst einschalte, 1-2 Minuten warte und dann erst das Sphairon ans Stromnetz anschließe. Mache ich das gleichzeitig, dann kommen von Anfang an ARP overwritten messages.

Aber auch wenn Einschaltreihenfolge 1) IX67 2) Sphairon tauchen die ARP overwritten Nachrichten manchmal schon direkt beim Start auf, manchmal nach einigen Minuten, manchmal auch erst nach noch längerer Zeit (hängt wahrscheinlich vom DHCP lease ab). Ein Muster konnte ich nicht erkennen.
 
Hallo,

da kommt mir aber doch plötzlich die Frage: Warum sucht der IX67 überhaupt nach einem DHCP Server auf dem WAN Interface und wertet dessen Informationen aus?
der_Gersthofer schrieb:
Code:
JUL 02 20:45:36   tCfg   info   Default gateway, 192.168.178.1, initialized.
Das sieht so aus, wie ein DHCP Lease einer Fritzbox.

Alice macht doch PPPOE, und da wird meines Wissens die IP Aushandlung über LCP gemacht, genau wie bei PPP. Ist der IX67 nicht als PPPOE Client mit den Alice Zugangsdaten konfiguriert? Warum lauert da ein DHCP Client Daemon?

Viele Grüße

Frank
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.