Trennung zwischen Provider- und Handelsversion der 6490

[fesc]

[COLOR=#333333]Die Leute mit einer 06.50-Firmware und Telnet-Zugriff können ja mal nachsehen, was in der [/COLOR][COLOR=#333333][FONT=&quot]/etc/init.d/S10-checkvars[/FONT][/COLOR][COLOR=#333333] bei ihnen so steht. Bei den DSL-Modellen führte das (zumindest früher) nur zu einem nicht funktionierenden GUI (weil das richtige [/COLOR][COLOR=#333333][FONT=&quot]/usr/www[/FONT][/COLOR][COLOR=#333333]-Verzeichnis nicht verlinkt werden konnte), bei den DOCSIS-Modellen sollte das anders sein.[/COLOR]

Das steht in meinem image nur #!/bin/sh drin ...

 

[PeterPawn]

Hmm ... zwischenzeitlich stand mal in der S10-checkvars:

#! /bin/sh
## Skip Startup (on oem missmatch)
if ! [ -f /etc/default.${CONFIG_PRODUKT}/${OEM}/ar7.cfg ] ; then
echo "FATAL: ++++++++++++++++++++++++++++++++++++++++++++"
echo "FATAL: ++++++++++++++++++++++++++++++++++++++++++++"
echo "FATAL: OEM '${OEM}' not supported - set 'skip init'"
echo "FATAL: ++++++++++++++++++++++++++++++++++++++++++++"
echo "FATAL: ++++++++++++++++++++++++++++++++++++++++++++"
touch /var/skip_init
fi

Wo mag das jetzt abgeblieben sein? In der Kombination mit dem an anderer Stelle gezeigten Aufbau der /etc/init.d/rc.S wurde damit bei "oem mismatch" jede weitere Abarbeitung von Init-Skripten unterbunden durch die Existenz der /var/skip_init.

 

[noob_noob]

War unpräzise formuliert: ich meine natürlich "6490 als TV-Empfänger und via LAN1 am Internet" nutzen.

funktioniert. allerdings ist inet über lan1 ne doofe option. dann spielt das ding router. http://www.ip-phone-forum.de/showthread.php?t=287567 mal lesen. damit ist ruhe, das ding läuft als ata im lan

 

[wusel-09]

Die Bewertung "Bug" ist sicherlich eine Frage des eigenen Standpunktes.

Nunja. Wenn die Provider-6360 stirbt und jener Dir stattdessen eine 6490 hinstellt, dann ist das Drop-in-Replacement schnell ein Drop-out-Replacement, wenn auf der .254 z. B. ein Router (Standardvorgehen in Firmennetzen: Router auf .1 oder .254) oder ein sonstiges Gateway liegt. So geschehen bei UM Business, und daß die 6490 auch noch Link-Loss zum Switch erzeugt (den sich die 6360 sparte), ist das Sahnehäubchen.

Insofern: ja, die Nutzung der »$broadcast_IP - 1« ist ein Bug, kein Feature. Das Verhalten ist nicht konfigurierbar, es wird dem Nutzer nicht kommuniziert, es ist nicht überwacht (ARP before use). Sicher, es gibt tonnenweise Negativbeispiele, wo nicht einmal ein Netz jenseits 192.168.0.0/16 konfiguriert werden kann. Dennoch ist dieses IP-Hijacking ein neuer Tiefpunkt bei AVM

 

[robert_s]

Dennoch ist dieses IP-Hijacking ein neuer Tiefpunkt bei AVM

Das ist m.W. keine Erfindung von AVM, sondern vom Intel, denn andere Puma6-Produkte habe/hatten die .254 wohl auch. Mit der AVM-Firmware 6.8x ist das aber verschwunden. Insofern wären Vorwürfe an Intel und die KNB, welche die aktuelle Firmware nicht ausliefern, IMHO eher angebracht. AVM kann da noch am wenigsten dafür.

 

[PantaRhei]

Das ist m.W. keine Erfindung von AVM, sondern vom Intel, denn andere Puma6-Produkte habe/hatten die .254 wohl auch. Mit der AVM-Firmware 6.8x ist das aber verschwunden.

@robert_s
Könntest Du Bitte erklären, was an FW 6.8x "bzgl. a.b.c.254 IP-Vergabe" anders ist;

 

[robert_s]

Ab AVM-Firmware 6.8x wird der ARM-Core nicht mehr exponiert, sodass der ATOM-Core die eingestellte LAN-Adresse verwenden kann und ein "Hijacking" der .254 nicht mehr erforderlich ist.

 

[PantaRhei]

@robert_s Danke!

 

[PeterPawn]

Insofern: ja, die Nutzung der »$broadcast_IP - 1« ist ein Bug, kein Feature.

Die Meinungen dürfen da trotzdem geteilt sein ... als "Bug" wird ja gemeinhin etwas angesehen, was nicht wie vorgesehen funktioniert (und das muß sich nicht immer mit "wie erwartet" decken).

Diese Verwendung der letzten Adresse im konfigurierten Netzwerk-Segment ist sehr offenkundig Absicht (man kann es bei der alten Firmware durch die Verwendung verschiedener Netzwerk-Masken jederzeit selbst testen), so daß von einem unabsichtlichen Fehler sicherlich nicht die Rede sein kann.

Insofern kann man das vielleicht einen Verstoß gegen die "guten Sitten" im Netzwerkbereich nennen oder irgendetwas in dieser Richtung ... aber ein Fehler (bei der Umsetzung) ist es zunächst mal nicht, denn es funktioniert ja und das auch noch so, wie (vermutlich) vorgesehen.

Was man AVM allerdings zum "Vorwurf" machen kann, ist die falsche Dokumentation dieses Umstands im Handbuch der 6490 ... dort standen in der alten Version tatsächlich noch die Adressen .1 und .255 als einzige "reservierte" Adressen im Segment auf den Seiten 126 und 127 - aber das war vermutlich auch nur aus anderen Handbüchern abgeschrieben (es ist auch nicht das erste Mal, daß solche Stellen aufgefallen sind, auch bei der Anzahl von Tunern in der 6490, 6590 und dem DVB-C-Repeater gab es derartige Fundstellen) und wurde von niemandem mit dem notwendigen Know-How hinterher mal Korrektur gelesen.

Wie das bei anderen Herstellern aussehen mag, kann ich nicht einschätzen ... ich kenne kein anderes Puma6-Gerät, welches den eRouter auch noch auf dem ARM-Core betreibt (bzw. inzwischen ja "betrieben hat").

Wobei die meisten FRITZ!Box-Besitzer wohl ohnehin eher selten in ein solches Handbuch blicken und damit die Dokumentation dieser Besonderheit vermutlich ohnehin untergegangen wäre ... auch die Tatsache, daß das komplette Netz 192.168.180.0/24 nach dem Willen von AVM als "reserviert" anzusehen ist (es gibt auch immer zwei Routing-Table-Einträge für 192.168.180.1 und 192.168.180.2, die direkt auf "dev dsl" verweisen), dürfte den meisten FRITZ!Box-Besitzern unbekannt sein.

 

[wusel-09]

Das ist m.W. keine Erfindung von AVM, sondern vom Intel, […] Mit der AVM-Firmware 6.8x ist das aber verschwunden. Insofern wären Vorwürfe an Intel und die KNB, welche die aktuelle Firmware nicht ausliefern, IMHO eher angebracht. AVM kann da noch am wenigsten dafür.

Freies Land, freie Meinungen Da "AVM" und nicht "Intel" auf den Boxen steht, da AVM das Problem offensichtlich lösen konnte und da AVM und nicht Intel die Oberfläche von Fritz!OS verantwortet – in der *nirgendwo* auch nur ein Hinweis auf einen Adressenkonflikt, der ja durchaus ganz ohne Raketenwissenschaft erkennbar ist, angezeigt wird –, sehe ich den Inverkehrbringer der Hardware-Software-Kombination "Fritz!Box 6490" als Verantwortlichen.
Der lokale KNB ist natürlich mit Schuld, denn auf dieses Detail wurde beim Austausch der 6390 durch eine 6490 nicht hingewiesen, die Anschaffung neuer Switche wäre durch 6.63 unnötig gewesen und der komplette Netzumbau durch 6.8x (meine Spiel-6490 antwortet jedenfalls unter 6.85 tatsächlich nicht mehr auf .254). Da jener Business-Support aber die Packetloss-Störung um 18:00 minutengenau zum Hotlineende um 20:00 mit einer SMS "Schon mal Werkseinstellungen probiert?" beantwortete, erwarte ich da kein Entgegenkommen, und Abstimmen mit den Füßen ist dank lokaler Kabelmonopole nun einmal schwierig.

als "Bug" wird ja gemeinhin etwas angesehen, was nicht wie vorgesehen funktioniert (und das muß sich nicht immer mit "wie erwartet" decken).

Daß die 6490 als Drop-In-Replacement einer 6390 weitere Adressen im LAN eigenmächtig, stillschweigend und ungeprüft annektiert, ist aus Sicht des Netzverwalters definitiv ein nicht vorgesehenes Verhalten. Die .254 war halt schon vergeben, Fritz!OS hätte dies erkennen können und müssen und durfte die IP keinesfalls nutzen.

Insofern kann man das vielleicht einen Verstoß gegen die "guten Sitten" im Netzwerkbereich nennen oder irgendetwas in dieser Richtung ... aber ein Fehler (bei der Umsetzung) ist es zunächst mal nicht, denn es funktioniert ja und das auch noch so, wie (vermutlich) vorgesehen.

Wenn »denn es funktioniert ja«, daß zwei Geräte in einem Netz sich eine IPv4-Adresse problemlos teilen können, stimmen würde, wäre es mir ja egal. Aber wenn fritz.nas und der lokale SIP-Server sich die .254 »teilen«, geht das im LAN mit ca. 50% Packetloss je Ziel einher. Im LAN ist wahrscheinlich der SIP-Server schneller beim Beantworten der ARP-Pakete, in der 6490 evtl. eher der NAS-Server ...

auch die Tatsache, daß das komplette Netz 192.168.180.0/24 nach dem Willen von AVM als "reserviert" anzusehen ist (es gibt auch immer zwei Routing-Table-Einträge für 192.168.180.1 und 192.168.180.2, die direkt auf "dev dsl" verweisen), dürfte den meisten FRITZ!Box-Besitzern unbekannt sein.

Das habe ich in meiner Netzplanung drin (genauer: 192.168.178.0/23, 192.168.180.0/23 sind freizulassen, ebenso 192.168.0.0/22 (Defaultnetze von TP-Link, Speedport, Sonstigen)). Aber willkürliches Belegen der $broadcast - 1 ist (war) eben eine 6490-Spezialität und ist ein Novum. Solange die Fritz!Box nicht auch der Defaultrouter im LAN ist, ist die »Reservierung« von 192.168.179.0/24 und 192.168.180.0/24 eine Marginalie. Im zugewiesenen LAN hingegen IPs hijacken, dies hat direkte, nicht umgehbare Auswirkungen; einstweilige Erschießung der Verantworlichen ist hier das mildeste probate Mittel.

wenn man Gastnetz einschaltet wird auch ein fester IP-Bereich in verwendet

… der als nicht änderbar (192.178.179.0/24) klar ausgewiesen wird, wenn man diess Feature nutzen will: "Der Adressbereich wird von der FRITZ!Box festgelegt und ist nicht veränderbar". Die .254 taucht sichtbar AFAIK *einzig* in Heimnetz -> Heimnetzübersicht -> Netzwerkverbindungen auf. Es wird AFAICS *nirgends* in der gesamten UI auf die scheiß-egal-ist-jetzt-meine-Nutzung der ".254" (eigentlich ja $broadcast - 1) auch nur hingewiesen. Auf Adresskonflikte schon gleich gar nicht.

Aber mit »Trennung zwischen Provider- und Handelsversion der 6490« hat das alles nichts tun tun; bis 6.8x ist die 6490 eher ein net.terrorist denn ein guter net.citizen, egal aus welcher Quelle.