[Info] FRITZ!Box 7390 Labor-Firmware Version 06.36-31922 vom 27.11.2015

[tuxedonet]

@PeterPawn: Danke! das LUA-Skripte ./dbtext.lua funktioniert Super!

LG tuxedonet

 

[rosi67]

@rosi67 Ja habe ich und auch kein Problem. Läuft alles Top

ja, ich habe nochmals das Update auf meine zwei FB 7390 aufgespielt, allerdings in anderer Reihenfolge (erst an FB Nr. 1 , IP Client Wlan und Dect Organisation), danach auf die FB 2 (Zugang zum Internet, Netzwerkverwaltung etc.).
Nun konnte ich auch die Dect Telefone verwenden. Hmm, Merkwürdig ??

 

[FrAnK_b]

hat jemand vo euch noch die letzte (Beta 06.36-31856)
mal per Mail für mich ?
[email protected]

Danke

 

[voipd]

Hat denn schon mal jemand das doppelte "hier" im Kopf der im Screenshot gezeigten Seite moniert?

Das ist mir gar nicht aufgefallen, ausserdem ist da noch ein Punkt zuviel: "... Netzwerkverbindungen und .Heimnetzes ..." oder ist das ein .hidden Heimnetzwerk?

Was macht eigentlich eine IP-Client-Box bei einem Klick auf dieses "hier"? Wenn ich das richtig verstehe, soll diese Übersicht ja nur die unmittelbar verbundenen Geräte zeigen (also alles, was mit der Box selbst Kontakt hat) ... die andere dürfte bzw. soll - wieder nur nach meinem Verständnis - aber bei einem IP-Client gar nicht mehr funktionieren (wenn das auf die berüchtigte "network.lua" hinauslaufen sollte mit diesem Link, wo der Menüpunkt ja absichtlich ausgeblendet wird bei einer Client-Box).

Der "hier" Link zeigt auf den Router, bzw. das Defaultgateway: "http://192.168.x.x/" - Mehr nicht.

Auch wenn nur die unmittelbar verbundenen Geraete angezeigt wuerden, waere das sehr hilfreich, da man dann wenigstens wuesste welche "IP" sich mit welcher Geschwindigkeit AM WLAN verbunden hat. Ausserdem wuerden Falschanmeldungen eher auffallen.

Also: Erwartungshaltung ist, dass die Box MAC, IP und Linkspeed im Client/AP-Modus anzeigt.


voipd.

 

[PeterPawn]

@voipd:
Bei einer getunnelten WLAN-Verbindung zu einer "Haupt-Box" kennt die Client-Box die IP-Adresse eines WLAN-Clients u.U. gar nicht selbst ... das läuft schließlich alles auf L2 ab und diese Adresse gibt es erst ab L3. Insofern ist diese Erwartungshaltung vielleicht nicht immer zu erfüllen - auch wenn (hier muß ich entweder vermutlich schreiben oder selbst recherchieren) die Verschlüsselung der WLAN-Verbindung zwischen der Client-Box als AP und dem WLAN-Client abläuft (alles andere wäre überraschend :gruebel: - vermutlich :mrgreen und damit theoretisch auch in so ein Paket hineingesehen werden könnte, wenn es nicht gleich vom l2tpv3d in den Tunnel gesteckt wird und tatsächlich in der Box landen sollte ... aber da bin ich im Moment nicht sattelfest in der Theorie und habe auch keinen Bock, deshalb jetzt zu suchen.

@tuxedonet:
Inzwischen habe ich auch das Mapping der "eventadd"-IDs auf die Zeichenketten wiedergefunden, das war die Datei /etc/default.$CONFIG_PRODUKT/$OEM/strings.tab, in der diese Zuordnungen zu finden sind. Damit hat man dann auch gleich eine Liste der möglichen Nummern, die bei der Verwendung mit "eventadd" einen Sinn ergeben.

 

[tuxedonet]

Also: Erwartungshaltung ist, dass die Box MAC, IP und Linkspeed im Client/AP-Modus anzeigt.

Hallo voipd,
evtl. hilft hier die Spaltenauswahl in Ansicht http://fritz.box/=?lp=netDev anzupassen
ich habe es bei FB7490-6.36-31909 ausgetestet und es geht:







LG tuxedonet

EDIT: Grafik ohne IP-Darstellung eingepflegt

 

[Micha0815]

Fatal das Tarif Fenster im UMTS-Betrieb

Gerade, da das Monatsende ansteht, fällt mir auf, dass die Option -Bei Erreichen des Kontingents I-Net-Verbindung Trennen- verschwunden ist. (Seit welcher Labor ggfs. weiss ich nicht?).

Hintergrund: Es gibt Mobilfunktarife, die nach einem verbrauchten "Traffic-Paket" nicht nur heruntertakten, sondern danach lustig jedes überschrittene MB weiter berechnen zu geschmeidigen Preisen.

Da nutzt es herzlich wenig, wenn eine LED anfängt zu Blinken/Leuchten, ohne die Verbindung zu trennen.

Gerade wenn eine FB entfernt steht/betrieben wird (z.B. via VPN-LAN-LAN-Verbindung) bringt ein Leuchten rein garnix.
Manche User stellen ihre FB wegen kritischem Mobilfunk-Empfang auch auf den Dachboden o.ä.

Besser ist es, dass die Verbindung nach Einstellung unterbrechbar ist, bis zum Beginn des nächsten, eingestellten Abrechnungszeitraums.

Als GSM-Gateway (mit voicefähigem Stick z.b. E3131) ist man weiterhin erreichbar bzw. kann weiterhin telefonieren.

Falls AVM-ler hier mitlesen ... Bitte wieder Einpflegen.

LG

 

[Tuffi]

Hallo Micha0815
Teil es AVM doch lieber direkt mit: http://avm.de/fritz-labor/labor-fuer-fritzbox-7390/ihr-feedback/

 

[Micha0815]

Werde ich tun Ich habe es leider erst in dieser Labor-FW entdeckt und wollte ggfs. Feedback anderer User hier abwarten, ob dies schon längers fehlt, bevor ich jetzt anfange backwards alle Labor-FW`s zu Flashen.

Ich mache gerade einen Langzeit-Stabilitäts-Test den ich dazu nicht unbedingt unterbrechen möchte.

LG

 

[Zorunel]

Hallo Zusammen,
ich lese hier immer fleißig mit wenn eine neue Laborversion kommt und bin mir diesmal unsicher als ich gelesen hab das es anscheinend Probleme beim DECT diesmal gibt?
Sind diese eher Ausnahme oder Regelfall? Ich habe nur noch DECT Telefone an meiner 7390 (mehrere M2 und ein C4) und würde lieber eine Version überspringen bevor ich auf einmal ohne Telefone dasitze ^^

 

[voipd]

@voipd:
Bei einer getunnelten WLAN-Verbindung zu einer "Haupt-Box" kennt die Client-Box die IP-Adresse eines WLAN-Clients u.U. gar nicht selbst ... das läuft schließlich alles auf L2 ab und diese Adresse gibt es erst ab L3. Insofern ist diese Erwartungshaltung vielleicht nicht immer zu erfüllen

Prima und das stimmt alles auch, aber es hat nichts damit zu tun, warum es nicht angezeigt werden kann.

Erstens zeigt die Box auch die MAC Adressen an die auf dem LAN aktiv sind. - Wozu, wenn es nur ein AP und passiver Switch ist?
Zweitens koennte man mit einem arp Befehl das herausfinden und dem User in der GUI anzeigen.

Richtig ist, dass es fuer einen nackten AP Betrieb nicht notwendig ist, aber wuenschenswert schon.

Mit dieser Argumentation koennte man die ganzen DSL (Hardware-)Anzeigen weglassen und bei Problemen mit dem Anschluss auf den Anbieter verweisen. ;-)

Von einer Fritzbox erwartet ich mehr und zumal es in den vorherigen Versionen bereits implementiert war. (Oder ist das auch ein "Sicherheitsaspekt" wie Telnet den man "weglassen" muss?)


voipd.

 

[Starlite]

Hallo Zusammen,
ich lese hier immer fleißig mit wenn eine neue Laborversion kommt und bin mir diesmal unsicher als ich gelesen hab das es anscheinend Probleme beim DECT diesmal gibt?
Sind diese eher Ausnahme oder Regelfall? Ich habe nur noch DECT Telefone an meiner 7390 (mehrere M2 und ein C4) und würde lieber eine Version überspringen bevor ich auf einmal ohne Telefone dasitze ^^

Hallo Zorunel, ich kann mich nur wiederholen, bei mir gibt es keine DECT Probleme und ich nutze MT-F, C4, Seimens Gigaset und weiteres DECT Zbh und alles wirklich ohne Probleme.

 

[PeterPawn]

Erstens zeigt die Box auch die MAC Adressen an die auf dem LAN aktiv sind. - Wozu, wenn es nur ein AP und passiver Switch ist?

Diese "wozu"-Frage ist ja mal ziemlich überflüssig ... wenn Du der Meinung bist, die sollte dann auch ausgelassen werden oder Du willst sie nicht sehen, schalte diese Anzeigespalte eben ab oder rufe die Seite gar nicht erst auf.

Ansonsten ist es eben so, daß die MAC-Adresse jedes direkt verbundenen Clients der Box auf L2 bekannt ist, ja - sogar bekannt sein muß, denn sonst könnte sie gar keine Daten gezielt mit ihm austauschen (Unicast) ... und dann wird sie halt angezeigt - über Sinn und Unsinn dieser Anzeige willst Du ja sicherlich nicht wirklich streiten wollen.

Zweitens koennte man mit einem arp Befehl das herausfinden und dem User in der GUI anzeigen.

Da bin ich mal gespannt, wie man mit einem arp-Befehl eine IP-Adresse zu einer MAC-Adresse ermittelt, wenn diese Zuordnung nicht bereits im ARP-Cache steht (wenn Du den Befehl meinst, der fragt ja nur diesen Cache ab).

Beim ARP-Protokoll hingegen lautet die Frage ja "Welche MAC-Adresse ist für die IP-Adresse a.b.c.d zuständig?" und nicht umgekehrt. Wenn die FRITZ!Box aufgrund anderer Kontakte (dann eben auf einer Ebene ab L3) diese IP-Adresse für eine MAC-Adresse tatsächlich kennen sollte (genauer müßte man ja von einer(!) IP-Adresse sprechen, denn da ist eine 1:n-Zuordung erlaubt), wird sie ja offenbar auch angezeigt (s. Beiträge von tuxedonet) und wenn sie sogar den Namen eines Clients kennen sollte, auch dieser anstelle von "PC-xx-xx..." - das war auch bisher schon so und ist m.W. so geblieben. Wenn die FRITZ!Box diese Angaben aber nicht kennt, gibt es (außer jemand anderen zu fragen) keine (sichere) Möglichkeit, sie aktiv zu ermitteln.

Von einer Fritzbox erwartet ich mehr und zumal es in den vorherigen Versionen bereits implementiert war.

Wenn das bereits implementiert war, könntest Du ja ruhig mal beschreiben, wie das dort funktioniert haben soll. Es gibt zwar auch ein (L3-)Protokoll für die Abfrage einer IP-Adresse für eine bekannte MAC-Adresse (RARP - RFC 903), das setzt aber einen entsprechenden Service im LAN voraus (einen RARP-Server). Der könnte auch tatsächlich auf einer Master-Box arbeiten (weil eben jedes Gerät bei einem Internet-Zugriff - oder bei DHCP im LAN - auch mit der Master-Box in Berührung kommt ... und hier sogar auf der richtigen OSI-Schicht für die begehrten Kenntnisse), aber mir wäre es tatsächlich neu, daß auf einer FRITZ!Box jemals ein rarp-Daemon zugange war - vielleicht war der aber tatsächlich im dsld oder multid irgendwo versteckt. Hast Du denn mal einen Netzwerkmitschnitt einer solchen RARP-Abfrage (und natürlich einer Antwort) zur Hand?

Willst Du meine Theorie überprüfen, bräuchte es nur einen Service auf so einer Slave-Box, den ein Client - mit vorher unbekannter und nicht angezeigter IP-Adresse - ansprechen kann ... kommt dabei ein Kontakt ab L3 zustande, sollte (notfalls nach einer kleinen Wartezeit und sicherlich auch nur für eine bestimmte Zeitspanne) auch die IP-Adresse des Clients auf der Slave-Box angezeigt werden können.

Ob - und wenn ja, wie lange - das neue FRITZ!OS solche Kenntnisse jetzt längerfristig bis dauerhaft speichert (was auch nicht ohne Probleme ist ... was macht so ein Slave denn, wenn sich die dynamische IP-Adresse eines solchen Clients dann mal ändert (er selbst bemerkt das bis zu einem erneuten Kontakt ab L3 gar nicht), zeigt er dann einfach weiter die alte (nunmehr falsche) Adresse an?), weiß ich auch nicht ... aus dem vorstehend genannten Grund hoffe ich mal, daß es zumindest keine persistente Speicherung dort (mehr?) gibt.

 

[_yg_]

habe etwas Probleme mit dem WLAN, 2 7390 eine davon als repeater. Verbindung steht bei 5GHz mit 250-300 MBit. Irgendwann (Zeiten zwischen ein paar Stunden und 2 Tagen) geht die Verbindung von 40 MHz auf 20 MHz und die Geschwindigkeit auf ~130MBit zurück. Nach reboot ist alles wieder OK...

 

[qwertz.asdfgh]

... ob dies schon längers fehlt,

Sieht so aus, bei mir fehlt es auch schon in der letzten Release 6.30:

 

[PeterPawn]

Ist zwar schwer zu testen (außer am letzten Tag des Abrechnungszeitraums) ... aber was passiert denn - mal abgesehen vom fehlenden Punkt im GUI, wenn man das "WarnOnly=yes" im "budget"-Abschnitt der ar7.cfg auf "no" setzt? Wird dann nicht immer noch getrennt bei Erreichen des Limits?

EDIT: Enabled=yes versteht sich sicherlich von selbst ...

 

[Micha0815]

Bingo

und Danke an qwertz.asdfgh für den Hinweis. Ich hatte bisher nur ältere FBs (7240,7340) dazu im Einsatz.

@Peter Pawn

Dein Hinweis als "Käpsele" war zielführend. Vielen Dank dafür. Ich habe den Abschnit mit einer .export von einer 7240 verglichen und in der ar7.cfg der 7390 angepasst.

budget {
                Enabled = yes;
                Period = 2;
                VolumeLow = 100000000;
                VolumeHigh = 0;
                ConnectionTime = 0;
                WarnOnly = no;

Und schon taucht in der GUI der Menue-Punkt wieder auf.


Weshalb AVM das mittlerweile standardmässig "versteckt"? Am Platz in der FW liegt es wohl nicht, wenn aus yes->no wird in einer Code-Zeile.

LG + TX

Nachtrag: Ich habe mal das Volumenkontingent auf 20 MB gesetzt und werde berichten, ob die Verbindung gekappt wird.

 

[PeterPawn]

@Micha0815:
Ne, der Platz ist wohl kaum der Grund ... die zusätzliche Abfrage

if (general.is_router()) then
local disconnect = box.query("connection0:settings/Budget/WarnOnly") ~= "1"
[COLOR="#FF0000"]if disconnect then
[/COLOR]box.out([[<p>]])
box.html([[{?141:485?}]])
box.out([[</p>]])
local labeltxt = [[{?141:703?}]]
if config.VOL_COUNTER then
labeltxt = [[{?141:77?}]]
end
box.out([[
<input type="checkbox" id="uiDisconnect" name="warn_only" checked>
<label for="uiDisconnect">
]])
box.html(labeltxt)
box.out([[</label>]])
end
[COLOR="#FF0000"]end[/COLOR]

nimmt Platz ein und spart keinen (außer in der generierten Seite).

Ich bin mir nicht mal 100%ig sicher, daß es tatsächlich Absicht ist, wenn die "disconnect"-Möglichkeit nicht mehr eingestellt werden kann, nachdem sie ausgeschaltet wurde - das könnte m.E. auch als Abfrage, ob das Budget an sich aktiviert ist (enabled), gedacht gewesen sein ... aber man weiß ja nie. Wer es bei sich ändern will, nimmt einfach die roten Zeilen raus aus der Datei "inetstat_budget.lua".

 

[andilao]

Es gibt Mobilfunktarife, die nach einem verbrauchten "Traffic-Paket" ... jedes überschrittene MB weiter berechnen zu geschmeidigen Preisen.

Das müssen aber Uralt-Tarife sein aus WAP-Zeiten. Selbst aktuelle Prepaid-Spar-Tarife mit einstellbaren Gesprächs- und SMS-Limits haben generell eine "echte" Datenflat, nur eben mit begrenztem Highspeed-Volumen.

Da der Einsatz einer älteren SIM mit vorprogrammiertem bill shock im Datentarif für die Box von vorneherein keinen rechten Sinn ergibt, ist das Verschwinden der Option Verständlich, wenn auch auch überflüssig. Es sein denn, AVM hat in der letzten Zeit zunehmend Unterstützung für Chaoten leisten müssen, die sich auf "Trennung der Internetverbindung ..." keinen Reim machen konnten und immer wieder mit "Box funktioniert nicht" anrufen mussten.

 

[Micha0815]

@andilao und falls der spanischen Sprache mächtig?
Ich muss dem Widersprechen. In z.B. aktuellen Masmovil.es -Tarifen kostet jedes zusätzliche MB über dem Freikontingent!



3,63Cent. Übersteigt das Volumen für die letzten 2 Tage des Monats/Abrechnungszeitraums (z.B. 1024MB =5€) um 100MB=3,63€ ... würde ich es lieber sehen, wenn die Verbindung 2 Tage ruht bzw. sich via FB selbst abschaltet!

Es gibt zudem imho etliche Prepaid-Mobilfunktarife, wo bei ausreichendem Guthaben, ein neues "Traffic-Paket" angebrochen wird kurz vor dem Stichtag und an selbigen verfällt und ein neues gebucht wird.

Ergosum aus meiner Sicht ein durchaus sinnvolles Feature. Da man dies aktiv ankreuzen muss, möchte ich dem Argument der "Chaoten" eher mit "Selbst Schuld" begegnen.

Danke @PeterPawn für #38 ... das ist mir eine Nummer zu hoch

Nur um einige Aspekte aus dem Thread/Post+drumherum zu erwähnen.

Da gerade auf dem "Lande" Magenta die Ambilvalenz (langsames DSL+LTE als Hybrid) forciert, könnte ich mir vorstellen, dass 1&1 (mit dem Vorteil zweier Mobilfunk-Vorleister) mal ein ähnliches Angebot auf den Markt bringt, statt des lästigen "Buschzuschlages".

Schenkt man dieser Befragung Glauben, gäbe es bei Vodafone als Vorleister von 1&1 doch reichlich brachliegende Kapazität?

Dass im Nachgang AVM, sofern 1&1 keine spezielle HW/FBs ordert, den Mobilfunkpart nicht gänzlich stiefmütterlich behandeln sollte, erscheint mir logisch.

Ebenso bedarf die Sofortstart-Option seitens 1&1 bis zum Schaltungstermin einer gewissen FW-Pflege für die Sticks.

Zudem gebe ich Dir Recht, dass das Gros der 1&1 Kunden eine FB mal mühsam einrichtet/einrichten lässt per Startcode und dann wergelt das Teil halt. NUR wird da mutmasslich nicht eine höherwertige FB7490 geordert sein/zum Einsatz kommen, und wenn ohne "Experten-Ansicht". Leute die sich eine "grössere" FB mit ISDN/S0 anschaffen, werden sicherlich den Focus auf Türsprechanlagen etc. im Focus haben oder DECT200/Heizungsventile etc.

OT: Imho überdauert ein Türsprechanlage z.B. Siedle locker 2-3 FB-Lebenszyklen? Dein Link zu professioneller HW hat mich preislich schon etwas Zusammenzucken lassen OT/OFF

LG Micha