Nun denn... es wird wohl noch ein langer dunkler Winterabend kommen...
:gruebel:
Hattest Du das Reset nicht in #30 schon gemacht ? Oder habe ich das mißverstanden ... Du hast nur getestet, ob es geht und dann die alten Einstellungen wiederhergestellt ?
Ich würde auch das Kind nicht mit dem Bade ausschütten ... einfach mal eine Sicherung machen, alle Vorkommen von 192.168 einer kritischen Plausibilitätsprüfung unterziehen (bei herbie_2005 dann die Freetz-Konfiguration nicht vergessen) und dann findet sich - notfalls im Quervergleich mit der gesicherten Konfiguration des zwischenzeitlichen Versuchs, ob das mit Werkseinstellungen alles klappt - garantiert auch der Übeltäter. Dauert eventuell auch so lange, dafür lernt man dabei ungemein interessante Sachen über die Einstellungen und wo da was gespeichert wird. Eine (permanente) Speicherung von Daten außerhalb der gesicherten Einstellungen (wie z.B. früher in der multid.leases) findet jedenfalls nicht mehr statt, damit sind auch alle DHCP-Vorgaben u.ä. jetzt in der ar7.cfg enthalten.
Ich könnte mir bei ganz alten Konfigurationen z.B. vorstellen, daß da alte Freigaben in den Einstellungen existieren, die an die IPv4-Adresse des Clients geknüpft sind, diese dann wiederum an die MAC-Adresse. Wenn jetzt aus irgendwelchen Gründen einer solchen MAC-Adresse (in Kombination mit den anderen neuen Einstellungen, wie unbekannte Clients zu behandeln sind) ein eingeschränktes Profil zugeordnet wird und die Plausibilitätsprüfung bei der Aktivierung der Weiterleitung sich dann daran stößt, daß dieser Client dem Profil nach eigentlich nur HTTP+Mail ausgehend verwenden darf, würde zwar die Fehlermeldung nicht ganz passen, aber die Erklärung wäre auch nicht vollkommen an den Haaren herbeigezogen.
Andere Möglichkeit: Selbst wenn jetzt bei herbie_2005 die .25 dem freizugebenden Gerät zugeordnet ist, kann ja immer noch eine alte Zuordnung der .25 in der landevices-Sektion existieren, die beim Iterieren vor der aktuellen erreicht wird.
Nur zwei theoretische Überlegungen ... aber anstelle des AVM-Supports würde sicherlich auch jeder von uns die simple Empfehlung "Machen Sie ein Werksreset." einer intensiveren Fehlersuche vorziehen; ist ja auch nicht ganz falsch, bürdet aber die Arbeit eben dem Kunden auf.
Wenn man das lieber vermeiden möchte, wäer die Sektion "landevices" da ein heißer Kandidat, dort hinein verirren sich auch schon mal solche Einträge:
Code:
} {
ip = 192.168.178.13;
name = "FR300E";
neighbour_name = "";
mac = A2:05:43:XX:XX:XX;
medium = medium_unknown;
auto_etherwake = no;
ifaceid = ::;
type = neightype_pc_linux;
staticlease = no;
} {
ip = 192.168.178.13;
name = "iPad";
neighbour_name = "iPad";
mac = C8:BC:C8:XX:XX:XX;
medium = medium_wlan;
auto_etherwake = no;
ifaceid = ::cabc:c8ff:feXX:XXXX;
type = neightype_pc_linux;
staticlease = no;
} {
Die doppelte IP-Adresse dürfte (der Theorie nach) nicht auftreten, aber der FR300E war inzwischen schon wesenlich länger als die Lease-Time nicht mehr zu sehen und dann wurde die Adresse eben irgendwann mal an das iPad vergeben, ohne dabei den FR300E aus der Liste zu löschen. Es kann genauso gut sein, daß der irgendwann mal mit importiert wurde.
In der "Liste der Netzwerkgeräte" im GUI taucht der FR300E jedenfalls gar nicht erst auf, wenn man aber manuell mit 'ctlmgr_ctl landevices settings/lanX' die Geräte durchgeht (wie das z.B. einige Lua-Skripte auch tun), kommt er
vor dem iPad und wenn man dann anhand seiner MAC-Adresse (A2:05:43:...) weiter sucht, kommt man auf das "gesperrt"-Profil. Wer also mit der IP-Adresse .13 seine Suche nach Netzwerkgeräten beginnt, landet bei einer Box mit dem o.a. Ausschnitt aus landevices am Ende beim "gesperrt"-Profil.
Blöderweise ließ sich bei meinem Test (7490 mit 06.20) dann doch eine Portweiterleitung auf die .13 einrichten ... allerdings wird die dann (eingerichtet über die Dropdown-Liste für 'iPad') glatt als "FR300E" angezeigt, obwohl das iPad im WLAN aktiv ist und die .13 in Wirklichkeit jetzt dort endet - das zeigt auch, daß man sich auf die Angaben in der Liste nur bedingt verlassen kann und die Anzeige "an Computer" da vielleicht doch zur Kontrolle noch die IP-Adresse zusätzlich enthalten sollte.
Eine HTTP-Portweiterleitung, die versehentlich auf dem falschen Gerät endet - sagen wir mal ein "blödes Webradio", dessen GUI so viele Lücken aufweist, daß es kein vernünftiger Mensch freiwillig freigeben würde, womöglich auch noch, weil ihm komplett die Authentifizierung fehlt und da jeder sich dran ausprobieren kann - ist nicht nur theoretisch eine Katastrophe.
Welche Angriffsmöglichkeiten selbst ein Tintenstrahldrucker als "Sprungbrett" ins LAN bieten kann, hatten wir doch erst vor kurzem, als jemand mal kurzerhand Doom auf dem TFT-Display eines solchen Druckers hat laufen lassen.
Und wer wirklich glaubt, alle seine Geräte auch nach innen ordentlich gesichert zu haben, ist entweder wie ich ein Paranoiker (ich weiß aber, daß ich nicht alles sichern
kann) oder irrt sich einfach nur gewaltig. Aus dem LAN (also mit einem Relay auf einem anderen Gerät) ist auch eine FRITZ!Box praktisch nackt. Und es gibt in einem modernen Haushalt genug Geräte, die potentiellen Angreifern ein lohnendes Ziel sein können ... selbst der DLNA-Server eines TV-Gerätes kann entsprechende Lücken haben.
Mal wieder OT, sorry, zurück zur Portweiterleitung an sich:
Man sieht jedenfalls schon an diversen Kleinigkeiten, daß da ein Konglomerat aus den verschiedensten Eingabedaten zusammengemischt und daraus zumindest die GUI-Anzeige gebaut wird (die ja durchaus bekanntermaßen ihre Inkonsistenzen aufweist, da gibt es genug Berichte zu).
Warum die Algorithmen bei der Plausibilitätsprüfung für Portfreigaben da grundsätzlich anders herangehen sollten, sehe ich nicht ... einige Sachen werden eben seit neuestem an die MAC-Adresse gebunden (die "verbesserte Kindersicherung" dürfte da eine Rolle spielen), während die Portweiterleitungen wohl immer noch von der IP-Adresse als "Schlüsselelement" ausgehen. Da kommt es dann leicht mal durcheinander ... s.o.
Fazit:
Was auch immer das sein mag, eines ist sicher: AVM hat zur 06.20 den Code zur Prüfung der Plausibilität einer Portfreigabe in dsld/ctlmgr (noch einmal) aufgenommen, die frühere Javascript-basierte Prüfung ist nicht mehr die einzige, die da ausgeführt wird. "Leichen" in der Netzwerkkonfiguration, die im GUI gar nicht sichtbar sind, könn(t)en auch diese Prüfung durcheinander bringen. Ein "Ausmisten" der landevices-Sektion der ar7.cfg (und die Kontrolle an anderen Stellen, z.B. bei statischen Routen) könnte auch schon helfen (anstelle einer kompletten Neukonfiguration), wenn man das Risiko der u.U. vergeblich investierten Zeit in Kauf nehmen kann und will.
