[Info] FRITZ!Box 7390 Labor-Firmware Version 6.10-28022 vom 21.05.2014

Mein Handy (Nexus 5) ist in meinem WLan angemeldet. Der Raspi hängt an einem Switch der wiederum direkt an meiner Fritz 7390 hängt. Sowohl Handy als auch Raspi sind im selben Netzwerk.
Vom Handy kann ich die FB-Gui problemlos aufrufen (ohne VPN Verbindung). Mein Handy hat die IP 192.168.99.30, der RasPi 192.168.99.4. Eine https Verbindung ist in dieser Konstellation weder zu .4 (RasPi) noch zu .2 (DiskStation) möglich.

Wenn ich eine VPN Verbindung (egal ob aus meinem lokalen WLan oder aus dem Mobilfunknetz aufbaue) erhält das Handy die IP 192.168.99.202. Damit kann ich https Verbindungen aufbauen. Als Ausgangs-IP erscheint auf der DiskStation dann auch die 192.168.202.

Das Handy habe ich schon mehrfach neu gestartet, alle Verbindungen gelöscht und neu eingerichtet und einen anderen Browser (Dolphin anstatt Chrome) versucht. Eine Verbindung über die entsprechenden FHEM und Synology Apps ist auch nur über VPN möglich.

Edit: Jetzt geht auch über VPN nichts mehr. Ich gebs auf und fange am WE mal von null an.
 
Zuletzt bearbeitet:
So, jetzt von mir auch ein komisches Verhalten!

Also die Box(en) laufen ohne erkennbare Mukken.
Aber beim durchstöbern der Systemmeldungen bin ich auf folgende Hinweise
gestossen.
SystemFritz7390.jpg

Die Meldung ist erst einmal Logisch, wenn man sieht was die Fritz da
protokolliert, das Umleiten der Ports von alt nach neu.
Komisch ist für mich nur, wann sie diese Meldung generiert?
Das OS habe ich am 21.5. aufgespielt und mich nicht darum gekümmert.
Heute um 8:03 den PC angeschmissen und um ca. 8:30 Uhr in die FB geschaut
und dabei diese Einträge, allerdings mit einem Zeitstempel von 8:03 Uhr.
Um diesen Effekt einzukreisen, FB "nur" neu Verbunden und beim Update
keine Einträge in System. Dann den PC neu gestartet und siehe da, die FB
generiert um 9:13 Uhr diese Portänderungen. Da die Angaben von 8:05 Uhr
aber auch noch da sind die große Frage, wo sind diese Einträge vom 21.5.
bzw. vom 22.05. als der PC jeweils gestartet wurde und definitiv eine andere IP
vorhanden war?
 
Supi, Danke für den Link, Smithy! Hat geklappt!

Wobei ich "nur" zwei Zertifikate mit OpenSSL bauen brauchte:

Code:
openssl genrsa -out /etc/ssl/fritzbox_private_key.pem 4096

und

Code:
openssl req -new -x509 -newkey rsa:2048 -days 3650 -key /etc/ssl/fritzbox_private_key.pem -out /etc/ssl/fritzbox_web_cert.pem

Die Inhalte der beiden dann per Texteditor in eine neue Textdatei kopiert, als .pem gespeichert und (in der Tat auch bei mir nur mit dem IE11 möglich) per GUI importiert.

Merci nochmal :cool:
 
Bei zwei Zertifikaten wirst Du dann aber vermutlich in die Browser das Root-CA manuell kopieren müssen (vertrauenswürdig), da es nicht von einer offiziellen Zertifizierungsstelle stammt ;)
 
Hallo,
Mal völlig OT:

Über welche Kosten spricht man bei einem solch Zertifikat eigentlich? Falls gratis, wo zu finden?
 
@Smithy: Korrekt - aber da ich das ja nur für mich privat nutze (und für ein "echtes" Cert keine Kohle ausgeben möchte ;) ), habe ich eben entschieden, dass ich meinen Self-Signed-Certs halt einfach mal vertraue :)
 
Hatte bei der 7490 geschrieben, dass es auch auch 12 Monats gratis Zertifikat gibt ;) Sache von ein paar Minuten. Wenn ich was Zeit finde mache Ich auch ein HowTo. Aber sicher nicht vor nächster Woche.

(StartSSL)
 
Da das Wochenende ansteht und vielleicht der ein oder andere sich mit SSL beschäftigen will, habe ich nun doch schon ein HowTo gemacht. Bitte seht mir nach wenn es noch nicht vollständig ist. Es ist ein Anfang :)

Zu finden hier.

Gruß
Smithy
 
Und hier das korrekte Changelog.
NEU - Benachrichtigung für neues FRITZ!OS per Push-Mail

Kann mir jemand sagen der die Beta installiert hat, was genau damit gemeint ist? Den Pushservice für "Neues FRITZ!OS" gab es doch schon seit Anfang an in Fritz!OS 6 oder verwechsle ich da was? In meinen Boxen mit **.06.03 ist das auf jeden Fall schon vorhanden :confused:
 
Ja, ich glaube auch das gibt es schon etwas länger. Allerdings bekam ich bisher eine solche Mail, wenn überhaupt, erst nach dem Update, niemals davor.
 
Habe gerade an den MTs Firmwareupdate auf die 3.26 bekommen.
 
Hut ab, gut gemacht.

Zu den HTTPS-Zugriffen von intern habe ich - nachdem ich bei heise.de auf Änderungen aufmerksam gemacht wurde - noch einige Sachen getestet.

Da ich hier noch nichts dazu gelesen habe, fasse ich es einmal zusammen:

1. (neu) Der ctlmgr wartet jetzt auch dann auf HTTPS-Verbindungen von innen (Standardport 443), wenn von außen kein Zugriff erlaubt ist ("Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" ist aus).

2. (bekannt) Hat man im GUI für den externen Zugriff den Port geändert, wird dieser auch nach innen benutzt.
(neu) Der Witz ist nur, diese Einstellung bleibt auch erhalten, wenn man den externen Zugriff deaktiviert.

3. (neu) Die Checkbox "Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" schaltet nunmehr nur noch die Weiterleitung von externen Anfragen auf dem gewählen HTTPS-Port an den ctlmgr ein oder aus.

4. Damit kann man jetzt auch von innen auf dem Standardport 443 HTTPS benutzen und trotzdem die Box von außen durch Wahl eines anderen Ports etwas aus der Schußlinie nehmen. Dazu einfach die Einstellungen zum externen HTTPS-Zugriff auf Port 443 zurückstellen ("Übernehmen" zwischendurch nicht vergessen) und anschließend den externen Zugriff deaktivieren (wieder "Übernehmen").

5. Nun nur noch in irgendeinem Skript das Forwarding manuell setzen. Die Abarbeitung der Skripte im /var/tmp/onlinechanged-Directory wurde meines Wissens noch nicht wegrationalisiert, diese Stelle bietet sich auch an, da man dann die externe Adresse einbeziehen kann. Allerdings sollte eine Regel "0.0.0.0:<externer_port> <interne_ip>:443" auch funktionieren.
Code:
test x"$1" == x"online" || exit
test "$(ctlmgr_ctl r connection0 pppoe:status/connect)" != "5" && exit
extaddr=$(ctlmgr_ctl r connection0 pppoe:status/ip)
locaddr=$(ctlmgr_ctl r interfaces settings/lan0/ipaddr)
extport=[I]externer_port[/I]
locport=443
rule="tcp $extaddr:$extport $locaddr:$locport"
oldrule=$(grep -i "^TCP .*:$extport $locaddr:$locport$" /proc/kdsld/dsliface/internet/ipmasq/forwards)
if [ ${#oldrule} -gt 0 ]; then
   msgsend dsld delfwrule $oldrule
   sleep 2
fi
msgsend dsld addfwrule $rule
Skripte in /var/tmp/onlinechanged müssen als reguläre Dateien vorliegen, Symlinks funktionieren nicht, da die "Enumeration" mit "find -type f" erfolgt.

Das Skript ist q&d, kein IPv6, kein Löschen beim "offline"-Gehen, usw.. Es soll nur eine Anregung sein, kein Rezept.

Die per msgsend eingerichteten Forwards tauchen in /proc/kdsld als "UPnP-Rules" auf, in der "Sicherheitsübersicht" werden sie aber als permanent geführt ... merkwürdig.

Es gab mal eine Zeit, da war der Aufruf der onlinechanged-Skripte nicht immer sichergestellt. Wenn das immer noch so sein sollte, muß man sich eben woanders dranhängen. Ganz paranoid wäre es z.B., zum Beginn jeder vollen Stunde den externen Port zu wechseln (natürlich vorhersagbar, analog zu OTPs). :)

Besser wäre es allerdings, wenn AVM auch den internen Port für HTTPS einstellbar macht und zwar unabhängig vom externen.
 
Zuletzt bearbeitet:
Bisherige Bugs:

Heute Abend war ein WLAN Ausfall. Durch Drücken des WLAN Tasters auf der Fritte konnte das WLAN wieder neu gestartet werden.

Das Sidebargadget zeigt nun nicht mehr den Down- und Upload vom Entertaintraffic an.
 
Hallo zusammen,

ich habe ein paar Punkte

zu "•Telefonie: Gesprächsqualität bei parallelem Datenverkehr im Heimnetz (WLAN<->LAN) verbessert":
Schön, dass jetzt Telefongespräche besser möglich sind, aber die WLAN-Performance leidet zu sehr.

Meine Performance von LAN --> WLAN ist eh nur 6 MB/s (DLAN-Strecke für den LAN-Pfad). Während eines Telefongesprächs sinkt Datenrate beim Filetransfer von LAN --> WLAN auf 2 MB/s. Das kann nicht so bleiben.


zu "•WLAN: MAC-Adressfilter verschoben nach WLAN/Sicherheit":
Viele bereits bekannte WLAN-Clients haben sich nicht mehr mit der 7390 verbunden. Ich musste nun den MAC-Filter ausschalten.


Des Weiteren geht bei mir der Online-Speicher auch nicht mehr:
"Verbindung zum Online-Speicher konnte nicht hergestellt werden. Fehler: /sbin/mount.davfs: SSL handshake failed: SSL error code -1/1/336130315."


Es gibt auch Positives:
Endlich kann man vernünftig makeln, Konferenzen einleiten etc. mit einem Siemens Gigaset.
Allerdings habe ich absolut kein Verständnis dafür, dass dies nun 4!!! Jahre dauern musste.


Ich bin jedenfalls zurück zur vorherigen Version, da in dieser zu viele Dinge nicht passen.
 
Zuletzt bearbeitet:
Bisher keine Probleme.
Nutze nur IPv4. IP-Telefonie mit mehreren Anbietern. Mehrere DECT-Telefone. PC über LAN. Ein Gerät über Power-LAN. Mehrere mobile Geräte per WLAN und Gast-WLAN. Eine DECT 200.
Alles läuft. DSL stabil.

Vermisse von den neuen Funktionen nur dem Temperatursensor der DECT 200 in der FRITZ Oberfläche zum temperaturabhängigen Schalten.

Anderes Problem:
Ich glaube mit Version 6.00 wurde "Wartemusik" eingeführt. Telefonie - Eigene Rufnummern - Anschlusseinstellungen - Wartemusik
Seit dem aber nicht wirklich brauchbar. Erstens begrenzt auf nur 8 Sekunden und zweitens in grottenschlechter Tonqualität.

Seit dem Labor geht da gar nix mehr. Nur bei "Ansage" kann der Wartende die bekannte (nervige) Standard-Ansage hören.
Bei "Musik" gibts nur noch Piep-Töne. Bei "Eigene" immer noch nur 8 Sekunden in schlechter Qualität, jetzt zusätzlich extremst verlangsamt abgespielt.
 
Ich könnte einen Besen fressen, mein traffic shaping Problem ist endlich behoben! :dance: Nicht so gut wie damals, aber zumindest funktioniert es überhaupt wieder. :)
Es lädt gerade jemand vom ftps und ich ziehe über http eine QSC Testdatei).
attachment.php


Vor langer Zeit, was ich selbst mit Recover nicht mehr hinbekommen habe, lief es allerdings mal wie folgt:
attachment.php


Vielleicht bekommt es AVM mit Feintuning wieder hin, zumindest habe ich nun Hoffnung.

Ohne ipv6 und WLAN rennt die Labor (bei mir) im Übrigen, neben den schon bekannten Fehlern, ohne Auffälligkeiten.

Mal eine Frage am Rande. Wenn man Rufnummern blockiert, kommt ja die Ansage, dass diese Rufnummer nicht vergeben sei. Entstehen dem Anrufer dabei eigentlich Kosten? :confused:
 
Mal eine Frage am Rande. Wenn man Rufnummern blockiert, kommt ja die Ansage, dass diese Rufnummer nicht vergeben sei. Entstehen dem Anrufer dabei eigentlich Kosten? :confused:

Der Anruf wird von der Box abgewiesen. Das Netz stellt den Anruf dann gar nicht bis zu dir durch. Oder anders ausgedrückt, der Anruf wird sozusagen zurückgewiesen ins Netz des Anrufers. Die Ansage die der Anrufer hört ist eine Netzansage des Anbieters des Anrufers und kann je nach Netz unterschiedlich sein. Also keine Kosten.
 
Zuletzt bearbeitet:
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.