[Problem] 7580: Falsche IP- Zuweisung trotz versch. MAC?!?

[M*I*B]

Update:
Nachricht von AVM nebst meiner Antwort...

Werter Herr ***,

das sind schlechte Nachrichten, zumal dieses Problem lt. der Userschaft aus dem "IP Phone Forum" schon seit etlichen OS- Versionen besteht...
Für "Tante Waltraud" und die üblichen Standardnutzer ist dieser Fehler sicherlich nicht relevant, aber für einen eher professionellen Einsatz quasi ein NoGo. Daher meine ich. das es gerade aus dieser Sicht für Ihr Unternehmen eine hohe Priorität haben sollte, solche Fehler zeitnah zu beseitigen... Aber diese Meinung vertreten tatsächlich nur die Nutzer, welche sich eher im professionellen Bereich bewegen; sicherlich nicht die Masse der Kunden, auf die es ankommt... oder?


Mit freundlichen Grüßen
Michael Buchholz


19. Dezember 2017 11:21, "AVM Support" <service bei avm punkt de> schrieb:


##- Bitte geben Sie Ihre Antwort über dieser Zeile ein. -##
AVM Support

Ihre Supportanfrage zu FRITZ!Box 7580 mit der Ticket-ID ***

*** *** (AVM Support)

19. Dez., 11:21 CET
Guten Tag Herr Michael Buchholz,

vielen Dank für Ihre Anfrage an den AVM Support.

Ich habe mich bei meinen Kollegen der Technologie einmal informiert
und leider können wir die korrekte Anzeige auf der Benutzeroberfläche bei mehr als einem Netzwerkadapter pro Gerät nicht zusichern.

Ich kann es gerne für zukünftige OS und als Verbesserungsvorschlag weiter reichen.

Freundliche Grüße aus Berlin
*** *** (AVM Support)

 

[koyaanisqatsi]

Was die Hostnamen betrifft: Ein System kann immer nur EINEN Hostnamen haben.

Ach, und warum befüllt mein AdAway die /system/etc/hosts mit unliebsamen DNS und lässt sie auf einen lokalen Webserver auflaufen ?

 

[M*I*B]

... was hat das denn bitte mit dem eigenen Hostnamen des Systems zu tun?!?

 

[koyaanisqatsi]

Aus Sicht des Systems ?
Mal zählen...
/ # wc -l /system/etc/hosts
58745 /system/etc/hosts
...ne Menge.

 

[HabNeFritzbox]

Du verwechselst wohl Hostname die das System via Multicast im Netzwerk streut, was auch der DNS anlernt, mit lokaler Hostauflösung.

So oder so, bringt es dem TE nicht weiter.

 

[koyaanisqatsi]

DNS wird überbewertet, deswegen nutzt das Fritz!Box Webinterface auch keine DNS Links in der Übersichtsseite/Heimnetzübersicht/Netzwerk.
...die traut sich selber nicht übern Weg.
...und die Verwirrung würde noch gesteigert werden , wenn eine DNS eine IPv6 zurückliefern würde.
Zum Glück tut das die Box nur im Ereignislog, wenn in einer Dual Stack Umgebung die "fritz.box", "myfritz.box" oder "fritz.nas" aufgerufen wird.

 

[HabNeFritzbox]

Die FB zeigt IPv6 IPs an in den Geräten wenn man diese bearbeitet, nicht nur beim einloggen im Log.

Ändert aber nichts am OT mittlerweile.

 

[PeterPawn]

Welchen professionellen(!) Sinn ergibt ein System, welches mit zwei NICs in demselben Segment unterwegs ist? Port-Trunking (bzw. "link aggregation") oder Failover ist ja eher unwahrscheinlich ... dafür fehlt dann wieder das (wirklich professionelle) Equipment in Form von Switches, die so etwas unterstützen. Das reklamiert eine FRITZ!Box ja nicht mal im Ansatz für sich, weder mit mehreren NICs noch mit einem einzelnen (VLAN).

Mir fehlt da etwas die Phantasie ... obwohl ich selbst genug "multi-homed systems" betreibe. Für "ein Adapter, mehrere Adressen" ist das mit den "use cases" kein Problem ... alles andere (bis hin zur Freigabe bestimmter Dienste nur unter einer definierten Adresse) würde ich eher anders lösen und wenn dieser weitere NIC irgendwie einer VM exklusiv zugewiesen wäre, würde er ja vom "bare metal server" eher nicht mehr benutzt.

Aber vielleicht wäre das ja auch nicht professionell genug, was ich da an Alternativen im Sinn hätte ... ich bin halt nur generell etwas skeptisch, wenn jemand eine Funktion benutzen will, die sich so nicht realisieren läßt - und dann ist das Ergebnis, daß das Gerät "nicht professionell genug" ist und nicht nur die Idee dahinter eher ungewöhnlich bis seltsam (kommt ja auch auf den eigenen Blickwinkel auf den "use case" an).

Wobei ... auch diesen Anspruch der "Professionalität" erhebt die FRITZ!Box ja eher nicht, schon die Positionierung im Geschäftskundenbereich (von AVM auch eher selten zu lesen - oder kennt irgendjemand AVM-Artikel, gerne auch aus der KB, die explizit auf gewerblichen Einsatz der Boxen zielen?) ist eher fragwürdig.

Die wenigsten werden wohl bestreiten, daß das FRITZ!OS mit seiner eher einfach gehaltenen Oberfläche (was die Anzahl der Optionen und ihre "Abhängigkeiten" über JS-Skripting angeht) sich weniger an professionelle Router-Admins richtet als vielmehr an jemanden, der von der Materie nur beschränkt Ahnung hat. Damit bietet das GUI eben nur die Optionen an, die wirklich einer Mehrzahl von Kunden etwas bringen ... jede weitere konfigurierbare Einstellung bringt zusätzliche Komplexität in die Oberfläche und erhöht die Chancen für Fehler - sowohl bei der Programmierung als auch bei der Benutzung.

Wenn einem dann die zusätzlichen Möglichkeiten (vom Shell-Zugang (den man sich ja problemlos einrichten kann, erst recht als Profi) bis zum Editieren der Export-Datei) nicht ausreichen für die Realisierung des eigenen Vorhabens, ist eine FRITZ!Box eben auch der falsche Router ... wer sie dann trotzdem für die Nutzung auserkoren hat, läßt mich irgendwie auch an seiner eigenen Professionalität zweifeln (zumindest bei dieser Entscheidung).

Das läßt für mich eben auch den Satz:

Daher meine ich. das es gerade aus dieser Sicht für Ihr Unternehmen eine hohe Priorität haben sollte, solche Fehler zeitnah zu beseitigen...

eher als Mißverständnis erscheinen ... dieser Fall des Einbindens eines Systems in ein Netzwerk mit zwei verschiedenen Adaptern innerhalb eines Netzwerk-Segments ist - in meinen Augen jedenfalls - extrem exotisch und die "Reaktion" des AVM-GUI betrachte ich selbst gar nicht als Fehler - jedenfalls nicht, solange die wirkliche Ursache nicht abgeklärt ist.

Zumal hier auch wieder eine extreme "Selektion" betrieben wird, wofür die FRITZ!Box nun wieder zuständig sein soll ... den DHCP-Server darf sie nicht geben, aber gleichzeitig soll sie eine "Übersicht" im Netzwerk anbieten bzw. diese Übersicht behalten und die richtigen Freigaben statisch einrichten.

Das ist wieder das alte Problem ... zwar hat AVM inzwischen beim IP-Client wohl diese Netzwerk-Übersicht eingeschläfert, weil die Kunden eben L2 und L3 nicht auseinanderhalten können (und müssen, sie sind ja keine Profis) und dann von einem IP-Client trotzdem hellseherische Fähigkeiten zum umliegenden Netzwerk erwarten.

Aber vielleicht muß man auch noch konsequenter vorgehen und gemeinsam mit dem DHCP-Server in der FRITZ!Box dann auch alle Versuche beerdigen, die Topologie des (Ethernet-)Netzwerks irgendwie zu erraten (WLAN ist da einfacher, zumindest beim "Meshen"), solange dafür keine wirklich tauglichen Informationen vorhanden sind (z.B. eben Switches, die LLDP beherrschen). Wobei AVM wohl genau in die entgegengesetzte Richtung marschiert oder die Behandlung von LLDP ist in den "deviceinfod" gewandert ... jedenfalls gibt es den früher mal vorhandenen "lltpd" auch schon seit einigen Versionen nicht mehr.

Jedenfalls würde ich dann unter "professionellen Aspekten" auch eher mit einer dynamischen Portweiterleitung mittels PCP arbeiten auf den betroffenen LAN-Clients (das richtet die dann ein, wenn der Service auch tatsächlich bereit ist) und nicht mit einer statischen Freigabe im Edge-Router - das "entschärft" dann auch die Folgen der "Verwirrung" der FRITZ!Box ob der verschiedenen IP-Adressen ein und desselben Hosts mit mehr als einem NIC, der auch noch (permanent) mit ihr verbunden ist. Wobei AVM tatsächlich Mist gebaut hätte, wenn eine einmal eingerichtete Freigabe für ein "landevice" (wo ja dann eine konkrete Adresse im "ipv4forwardrules"-Eintrag steht in der "ar7.cfg") einfach so auf eine andere Adresse gesetzt wird ... aber das ist normalerweise auch eher ein Fehler der (noch neuen) PCP-Implementierung und der versuchten Reaktion darauf, daß so ein Client schon mal seine Adresse ändern könnte (gerade bei DHCP-basierter IP-Adressvergabe).

Was läuft eigentlich auf diesem Server für ein System? Ist tatsächlich 100% sicher, daß dort das System bei einer ARP-Abfrage für "192.168.1.11" niemals von der MAC-Adresse antwortet (nicht mit "mit der MAC-Adresse" verwechseln), die auf "98" endet? Je nach System kann so ein "table lookup" ja auch unterschiedlich ablaufen und da hier wohl beide NIC ein solches Broadcast-Paket erhalten, könnte es auch gut sein, daß beide antworten ... selbst wenn der Adapter mit der IP-Adresse "192.168.1.10" mit der korrekten MAC-Adresse für den "99"-Adapter antwortet (und sich damit an die "Spielregeln" hält, wie es auch bei Proxy-ARP der Fall wäre), kommt diese Antwort aus Sicht der FRITZ!Box dann eben vom Host mit der "98"-MAC und damit sieht das ja auch so aus, als würde dieser Host für den anderen mit der "192.168.1.10" als ARP-Proxy arbeiten, was eine "relay"-Funktion nahelegt (was die Box dann als "angeschlossen über ..." interpretieren müßte).

Wenn das System des Servers es unterstützt, würde ich hier jedenfalls mal kontrollieren, wie die ARP-Antworten wirklich aussehen und - wenn meine Vermutung zutrifft - mittels "ebtables" (o.ä.) dafür sorgen, daß ARP-Antworten für die entsprechende IP-Adresse auch nur jeweils vom richtigen NIC gesendet werden und nicht "über Kreuz" oder gar zweimal (eine pro NIC).

 

[HabNeFritzbox]

Es gibt Switch unter 50€ die auch VLAN oder Portbündelung anbieten für link aggregation ect., dieses läuft auch trotz einer FB ohne Probleme.

Selbst mit Windows in einer VM auf dem NAS, kein Problem, jede VM bekommt von FB eigene IP und wird angezeigt als sei es eigene Gerät im Netzwerk. Jede VM streut aber auch eigenen Hostnamen und MAC, daher alles kein Problem.

Was 2 Netzwerkkarten im selben Segment sollen, weiß ich auch nicht. Ich habe meine am NAS gebündelt und nutze so 2Gbit Anbindung.

 

[Theo Tintensich]

Die neuen System generieren eine UUID für die Netzkonfiguration. So wird z.B. beim DHCP diese UUID für die Namensvergabe verwendet, nicht die MAC_Adresse, wenn das Gerät sich einmal am Netz gemeldet hat.
Auch bei der IP-Vergabe beim IPv6 durch DHCP6 oder Router-Advertisement.

Nur wenn explizit konfiguriert wird, dass sich das Geräte alle x Stunden/Tage einen neue IP geben soll, wird das nicht darüber geregelt.