W900V DECT deaktivieren

[florixyz]

EDIT:::::
Habs jetzt mit dem Skript von Spirou hinbekommen.
Man muss die rc.S noch etwas patchen (das habe ich vom jpascher skript übernommen)

fettgedrucktes muss eingefügt werden:
...
#! /bin/sh
isdn_params=""
isdn_params="${isdn_params} dect_hw=2"
if /usr/bin/checkempty /var/flash/dect_misc; then
isdn_params="${isdn_params} dect_on=1"
else
if /bin/testvalue /var/flash/dect_misc 1 0 0; then
isdn_params="${isdn_params} dect_on=0"
else
isdn_params="${isdn_params} dect_on=1"
fi
fi
modprobe isdn_fbox ${isdn_params}

---> das hier war der originalcode
#modprobe isdn_fbox dect_hw=2
sleep 2

Man kann dann wunderbar im WebIF Dect deaktivieren und aktivieren


--------------------------
Hallo,

hab mein Sp W900V mit sp-to-fritz.sh von Spirou in eine FritzBox verwandelt, jedoch lässt sich DECT nicht wirklich deaktivieren.
Ich hab die Version vom 27.12. vom Skript verwendet und die default Einstellungen in firmware.conf verwendet. parameter waren "-k -m 900".

Ich hab zwar im Menü den unterpunkt "DECT Mobilteile", und kann auch die Basis deaktivieren, jedoch auch wenn sie deaktiviert ist, kann sich das Mobilteil anmelden und zeigt eine Verbindung zur Basis an....... Nicht wirklich sinn der Sache, wenn man das Ding aus Energiespar/Strahlenreduktions-Gründen ausschalten möchte, weil man es nicht benötigt.

Hat jemand eine Idee wie es gehen könnte?

EDIT: Teilweise gelöst.... wenn ich den mod von jpascher verwende, und die rc.S modifiziere, so dass das isdn_fbox_fon4.ko modul mit den parametern "dect_hw=0 dect_on=0" geladen wird, dann scheint das dect teil tot zu sein. Das Telefon bekommt keine Verbindung zur Basis mehr (oder werden nach dem FW-Update die angemeldeten Tels gelöscht?? -> egal: selbst wenn ich 10 Sek. auf den Dect taster drücke und dann das tel. neu anmelden will findet es keine Station zum Anmelden )
Hmmmm... jetzt bekomme ich gar kein Dect Mobilteil mehr angemeldet..... auch nicht wenn ich wieder den default mit dect_hw=2 verwende usw.. werde es mal wieder mit der Spirou firmware probieren

EDIT2: Dect anmelden gehet wieder mit fritz firmware nach Spirou skript... aber nicht nach jpascher skript, egal wie oft ich neustarte und die option "dect basis deaktivieren" umstelle, keine der FWen kann sie wirklich an/aus schalten. Aus irgendeinem Grund wird jetzt in der jpascher version das isdn_fbox_... modul nicht mehr geladen und das usbahci modul auch nicht.... hab da aber wieder original skript ohne änderung benutzt. hatte nur vorher die spirou fw version drauf. sollte man alles auf werkseinstellungen setzen zwischen den fw wechseln?

 

[Jpascher]

Hatte nur vorher die spirou fw version drauf. sollte man alles auf werkseinstellungen setzen zwischen den fw wechseln?

ja unbedingt, ist ässerst empfindlich.

Der Fon Teriber ist extrem kritsch mit Voreinstellungen.

Mit meine Skript gibt es keine Probleme mit DECT ein/aus
Aber ein werksreset muss durchgeführt werden.
Und wenn das nicht reicht CLER_ENV ausführen dann klappes sicher.

http://www.ip-phone-forum.de/showpost.php?p=1001373&postcount=1

Ansonsten kann ich alles bestätigen was du schreibst, auch ich hatte festgestellt das Spirous Skrit nicht wirklich auf die Menüeinstellungen regieren kann.

Gibt da noch einige andere Sachen in Spirous Skript die noch nicht richtig funktioneiren können.
Getestet habe ich mit seinen Skript nicht aber ich sehe es an manchen fehlerhaften patches.
Bei Gelegenheit werde ich ihm perönlich daruf hinweisen aber auch mein Zeit ist begrenzt.

PS: Eigentlich bin ich verwundert, dass es berits mit dem Einfügen des obigen Teis reicht.

Änderungen werden immer erst nach reboot wirksam.

 

[Spirou]

Die Änderungen habe ich für das nächste Update vorgemerkt. Getestet hatte ich mit einem Sinus W500V, wo sich DECT ohne Probleme ein- und ausschalten liess (Reboot erfolgt automatisch).

@jpascher: Bitte nenn mir die von Dir gefundenen Fehler. Gerade wir zwei sollten uns doch ein wenig bei der Fehlersuche unter die Arme greifen. Ich denke eine pasuchale Aussage wie hier schreckt doch nur die Nutzer davon ab, das Skript zu benutzen. Was dann zu noch wenigeren Feedbacks und damit weniger Verbesserungen führt.

Ich muss hier auch nochmal betonen, dass ich selbst keinen W900V habe, an dem ich alle Änderungen testen kann. Ich übertrage hier im wesentlichen das, was ich bei meiner vorhandenen HW (Sinus W500V, Speedports W501/701V) bastele und was ich bei jpascher zu diesem Thema finde. Daher bin ich auch erstaunt, wenn es da zu größeren Diskrepanzen - nicht nur bei der Kosmetik - kommt. Allerdings gestehe ich auch, dass mit die Zeit fehlt, jedes Update auf Änderungen hin zu analysieren. Hier wünschte ich mir auch etwas mehr Übersicht, was an Funktionen/Anpassungen hinzu gekommen ist.

Grüsse

Spirou

 

[florixyz]

Um an dieser Stelle auch hier mal Feedback zu geben zu den Skripten bzgl. W900V:
Ich habe mal Spirous Dect einstellungen getestet, die sind ziemlich gut. Es werden die Mobilteile angezeigt, anmelden geht auch übers WebIF, abmelden auch. Das Interface macht auch optisch einen sehr Fritz!Box ähnliches Eindruck und die Netzwerkeinstellungen und SIP Einstellungen gehen auch. Mehr habe ich noch nicht getestet.
Die Jpascher Version hab ich noch nicht so intensiv getestet, aber mir persönlich hat das WebIF bei Spirou besser gefallen. Obwohl jpascher das von der 7170 verwendet ist doch das bei Spirou der original 7170 wesentlich ähnlicher. Abgesehen vom WebIF scheint aber bei jpascher mehr funktionalität bzgl. treiber, rc.S und zusätzlichen programme vorhanden zu sein.
Wäre wirklich schön wenn man beides vereinen könnte.

@jpascher: Ich meinte einfügen der Zeilen in die rc.S bevor das fw-image erstellt wird, dann nachdem die Dect einstellung geändert wurde einen Box reboot machen, damit die einstellung übernommen wird. so hats bei mir funktioniert.

 

[Jpascher]

Bitte nenn mir die von Dir gefundenen Fehler. Gerade wir zwei sollten uns doch ein wenig bei der Fehlersuche unter die Arme greifen.

Hier wünschte ich mir auch etwas mehr Übersicht, was an Funktionen/Anpassungen hinzu gekommen ist.


Ja kein Probelm, aber mir get es nicht viel anders als dir.
Wir beide sind Individualisten und nehmen uns wenig Zeit etwas zu diskutiern bevor wir Ändereungen angehen.
Gerade jetzt währe es aber villeicht doch so weit, dass wir das eine oder andere zuvor diskutieren.
Ich nehme mal an dass, wir an einen Punkt angelang sind wo es nicht um grundlegende Änderungen geht.

Ich würede vorschalgen du umreisst was du vorhast und ich Antworte mit meiner positiven Kritik.
Ich mocht noch mal betonen, dass ich keinerlei weitere Veränderungen vorhabe, da mometan mein Möglichkeiten sowiso erschöpft sind, und ich auch keine Lösung für die ausstehenden Probleme absehen kann.
Einzige Änderung an der ich arbeit ist die integration von Englishen Quellen, das erfordert. dass die Variable Language mit berücksichtigt wird.

Ich werde deine Version auch testen und Rückmeldungen machen vorausgesetzt ich finde genug Zeit dei wird nämlich immer knapper, ein Grund mehr warum ich alles abschließen möchte.

 

[Spirou]

@jpascher: Ich habe auch Deinen anderen Beitrag im Thread zum W701V gelesen. Du hast recht, dass wir mehr diskutieren sollten.

Ich sehe in Deiner Arbeit immer sehr interessante Ansätze zur Verbsserung der Funktionen der Box, während ich besonderen Wert auf eine sauber abgestimmte Oberfläche lege. Natürlich, nicht wegen des - sicherlich auch stattfindenden - sportlichen Wettbewerbs untereinander, sondern wegen der Möglichkeit noch mehr aus der originalen AVM GUI zu übernehmen, versuche ich Deine Arbeiten bei mir zu integrieren.

Du hast ja schon gelesen, dass ich aktuell dabei bin, das Skript auf die neueste GUI anzupassen und das Kernel-Update zum Standard zu erklären. Damit nähern sich unsere beiden Anätze wieder stärker an. Ich möchte AVM nur nicht zu weit vorgreifen und möglich wenig Flickwerk betrieben, da ich hoffe, dass auch für die anderen Modelle (7150, 7140) bald Updates erscheinen, die die neue GUI beinhalten und somit ein mühsames Portieren auf die Hardware der entsprechenden Speedport/Sinus-Modelle überflüssig machen. Damit wäre dann auch der DECT-Teil bald nativ von AVM.

Eine Integration von englischsprachigen Images hatte ich auch im Fokus und ich hoffe, dass das mit der nächsten Skriptversion bereits möglich ist.

Letzlich bleibt noch das Problem mit der Struktur und der Übersicht. Ich dneke, es ist natürlich, dass sich jeder in seiner Struktur am besten zurecht findet. Ich bin weniger ein Freund von stringent modularem Aufbau, ich halte mehr von Synergie und Übersicht - worüber sich natürlich streiten lässt, ob dies immer erkennbar ist. Ich versuche aber bei neuen Versionen dieses mehr und mehr durchzusetzen.

Mir hat im erwähnten Beitrag zum W701V auch gut gefallen, dass Du Deine Änderungen aufgelistet hast, da ich leider auch nicht immer die Zeit finde, jede neue Version sorgfältig zu analysieren.

Mein Ansatz ist meist der, dass ich ein Image mit Deinem Skript erstelle und dann per "diff" die Unterschiede zu einem mit meiner Version erstellten Image ermittle. Dann versuche ich, die Änderungen in meine Struktur zu integrieren.

Ich halte aktuell mehr davon, die produktpezifischen Informationen aus der Konfiguration (rc.conf, rc.init) zu lesen als aus dem Filesystem - lasse mich da aber gerne auf Diskussion ein, wo da aus Deiner Sicht die Vor- und Nachteile liegen.

Ich freue mich, auf die weitere, anregende Zusammenarbeit, wünsche mir aber bei positiver wie neagtiver Kritik etwas mehr konkrete Hinweise. Wenn Du in Deiner Arbeit Lösungen für Probleme findest, die auch mich betreffen könnten, wäre ich Dir ebenfalls für einen kurzen Hinweis dankbar. Da bist Du mir sicherlich in der Intensität und in der Hardwarenähe Deiner Arbeit weit voraus.

Das war jett viel und detailreich, aber ich denke, dass den ein oder anderen Nutzer unserer Skripte bestimmt interssiert, was uns an- und umtreibt. Die "fachlichen" Details, sollten wir dann in der Tat per PN austauschen.

Grüsse

Spirou

 

[Jpascher]

@Spirou
Ist doch schön, dass wir nicht alle gleich sind und etwas Konkurenz hat der Sache wie man sieht ja nicht geschadet.
Ich bin mir sehr wohl bewusst, dass du in vielerlei Hinsicht eine sehr guter Gegenpol zu mir bist!
Und wie wir alle wissen ist oft die Mitte oder der Kompromiss das beste.

Zur Sache: Ich halte es mit den diff's nicht so wie du, ich fertige praktisch nur diffs bei AVM firmwarversionen an und hab noch nie einen zum Skript angefertigt. Jedoch sehe ich mir ebenso dein Skrit an und habe auch bereis mache Zeile von dir Übernommen. abgesehn davon das ich ja auf deinen Skript von 9.4.2007 aufbaue, auch wenn jetzt vieles verändert wurde.

Ich habe bezüglich der Art und Weise wie und wann Variabeln aus der t-com oder der AVM firmware genommen werden auch noch nicht die optimale Lösung gefunden.
Mein Ansatz ist der, dass es auch in Zukunft mögicherweise sowohl Firmwarevarinten mit rc.init und ohne gebn könnte.
Da man aber nicht weis welche kombination auftritt ist es am sichersten in der erzeugten Version die rc.init nicht zu verwenden und alles bereits in die rc.conf zu schreiben. So halte ich es derzeit beim w900.
Das Probelm weche Variablen aus der T-com Firmware zu nehmen sind ist eignlich hinfällig da die Hardwre bereits bekannt ist und diese Variablem auch fix vorgegebn werden können.
(bin mir aber klar, dass ich dir ursprünglich aber das Gegnteil empfohlen habe )
Vorteil Das skript wird flexibler bezüglich der wahl der T-com firmware es kann auch ein falsches kernel.image sein solange die paar files die wir brauchen darin enthalten sind.

Warum Firmwareversion, Language und einige ander Variabem aus der Firmwar direkt nehmen?
Der Gurnd liegt darin, wenn wir es so machen wie AVM das in der rc.S auch macht erfinden wir das Rad nicht neu und wir sind wiederum auf der sichern Seite, da damit die Variabeln mit Sicherheit stimmen müssen.
Es gibt eine bestimte LINUX Rangordnug wie Variabeln im System zu tragen kommen, un so näher wir der entgültig verwendeten kommen, umso sicherer werden erzeugt Images auch bei leichen Änderungen in den Versionen, funktionieren.

Gruppen von verwendeten Variablen:
Hardwarebezogene (fix vorgeben stammen aber ürsprünglich aus dem T-com image)
Variablen die vom Benuzer angepasst werden (Beispiel: ANNEX, PRODUKTNAME, BOXNAME)
Ausnahme: kernel_args
Variablen die aus dem Image bezw. andern Files stammen (Produkt, Language, Version. Subversion, kernel_size ..)

Restliche Variablen die in der AVM rc.init bzw rc.conf auch oder nur vorkommen.

Eine Grund gäbne es die Harwarebezogenen Variabeln immer aus der t-com Firmware zu nehen:
Wenn das Skript so flexibel würde, dass auch zukünftige Hardware automatisch erkannt würde, aber das ist wohl Illusion. Asseredem weis man sowiso nicht welche Variablen dazukommen, logischerweise brint es nicht wirklch was.

PS: Sehe dir mal genau die Änderungen an die ich bezüglich install angebracht habe.
Die Änderungen wurden notwendig damit auch englisch sprachige Firmware via WebGUI geladen werden kann.
Weiters wird daduch atomatisch das flash (werksreset) glöscht wenn die firmware versionen zu weit auseinader liegen odern ein downgrad vorliegt.
Im Original ist ein downgrad nur im eine zweiten Anlauf möglich, macht aber nichts anders als die angepasste install jetzt automatisch macht.
Ausserdem habe ich die OEM und ANNEX Prüfungen ruasgenommen.
Und im Gegenzug ANNEX post_install reingenommen.
Momentan aber nur getestet aber nur mit W701.