Dvb-c repeater Alien Firmware findet kein wlan #15
Comments
|
Keine Ahnung, ich hab kein Gerät zum testen da. Der 1750 und dvbc sollten im Bereich Wlan soweit gleich sein: |
|
crash.log: AVM Log:
dmesg: |
|
crash.log: |
|
Betroffen sind 2,4GHz und 5GHz. Nachdem ich vorhin mit dem WLAN vom Repeater verbunden war funktioniert dies aktuell auch nicht mehr Zum Test nochmal schnell das 7.0.1 Image für den repeater selbst installiert, da funktioniert das wlan |
|
Die meshd-segfaults kann man vermutlich ignorieren, sowas hab ich auch auf anderen Geräten gesehen. Kann gut sein dass die "normal" sind und man die ohne Freetz nur nicht sehen kann
Ich versteh den Satz nicht. Also hat es kurz mal funktioniert? Und plötzlich nicht mehr? Vielleicht braucht man die Dateien athwlan.bin und utf.bin aus lib/firmware/AR9888/hw.2/ Zum testen: Den Patch unten anwenden (patch -p0 < alien.patch.txt), ins menuconfig + speichern und make Zum testen nach make ob es funktioniert hat: |
|
Was ganz anderes: Hast du mal ein Downgrade der Firmware gemacht, ohne die avm-Konfiguration zurückzusetzen? |
|
Beim downgrade gab es keine Probleme. Beim Upgrade gibt es die Probleme mit uns ohne reset. |
|
Patch eingespielt, leider findet der Repeater immer noch kein WLAN und sendet auch kein WLAN. Habe danach nochmal auf Werkseinstellungen zurückgesetzt. Auch dadurch leider keine Besserung |
|
Komisch an den Logs oben ist dass sie "DVBC_Repeater_CAL1_V" und "DVBC_Repeater_CAL2_V" enthalten. Wenn man ein Alien geflasht hat, sollte nichts mehr von DVBC zu finden sein, da die Firmware zu über 99% die 1750 Firmware ist. |
|
Die Logs waren immer mit der alien firmware erstellt |
|
Danke, das zähle ich aber auch zu remote und würde nicht helfen. |
|
Besorg von AVM mal den Sourcecode von
Meld dich wieder wenn es diese hier gibt: http:https://osp.avm.de/ Und häng ein Log vom "Step 3" von make an! |
|
Hey fda77. Der Sourcecode sind mittlerweile Online. Ich habe nochmal versucht ein aktuelles Image mit 7.12 (und der aktuellesten Laborversion) zu erstellen, beide haben das gleiche problem = kein Wlan. |
|
Hab schon gesehen dass es die Sourcen gibt. Die müssten dann noch eingebaut werden. |
|
Ich habe bisher immer selbst gebaut. Den Thread im DEB habe ich gelesen, weiß allerdings auch nicht was der User da meinte. Wenn du mir sagst wo ich ungefähr suchen kann werde ich mich am Freitag mal hinsetzen und die beiden Sourcecodes vergleichen. |
|
Alles :D
Also schonmal alle Glaskugeln bereitstellen... |
- fixes https://www.ip-phone-forum.de/threads/307287 - fixes #25 - refs #23 - refs #15
|
Bitte mal mit der aktuellsten Revision ausprobieren |
|
weiterhin bekomme ich folgenden fehler mit 7.12 bzw beta 7.19 images
Leider hatte ich am Wochenende nicht die Zeit mir die Kernel Sources anzusehen |
|
Schade die Änderung an Busybox nicht auch hier hilft |
|
Ich habe den kompletten Inhalt verglichen, das waren die einzigen Dateien die bei mir im diff unterschiedlich waren |
|
Ich meinte den Inhalt der Dateien, also WAS sich in diesen geändert hat :} |
|
Funktioniert leider weiterhin nicht. Mit beiden Versionen bekomme ich kein WLAN (Empfang und Senden) |
|
Aber DVB funktioniert, sowohl mit Alien als auch mit der normalen Firmware? Wegen #23 |
|
DVB-C habe ich nie genutzt. Habe ich hier auch nicht liegen, sonst hätte ich das kurz testen können. |
|
Die sind auch fast gleich, bis auf den hub mit den Tunern. Deshalb versteh ich auch nicht so ganz warum es mittlerweile diese Problem mit Wlan/DVB gibt. Ich hatte selbst mal einen 1750 und DVB, das war aber noch FritzOS 6.23/6.30. Auf beiden lief Wlan ohne Probleme |
|
Unterschiedliche Dateien der FOS 7.01 Sourcen 1750 > DVBC Dateien im Filesystem die "event" im Namen enthalten Diese könnte man zum Testen für das Alien aus der original Firmware mittels |
|
Hi @fda77, Many thx for the hint. I created the patch from above and try to build now only 1750E w/o alien. Could you please tell what is "RK"? BTW replacing the module dtsi in kernel in the original firmware image I should use fw* tools? Regards, |
|
Just unpack the REPLACE KERNEL, patch, (eg copy the 1 dts(i) over the other) and then compile, see make help. |
|
Ok, I did the following: After flashing WLAN doesn't work, factory reset didn't help either, got the log message "wlan-modul konnte nicht korrekt initialisiert werden. bitte fritz!repeater neu starten #102". Then I applied the alien patch (see attached). After flashing WLAN doesn't work, factory reset didn't help either, however I don't see messages like "wlan-modul konnte nicht korrekt initialisiert werden. bitte fritz!repeater neu starten #102". Anything I did wrong? |
|
Ich antworte übrigens meist in der Sprache in der gefragt wurde... |
|
Vielleicht reicht es auch aus die HWrev in der .kernelvariables im Hautpverzeichnis des Kernels zu ändern |
|
Unfortunately I can't communicate in German, even English is not my native language but at least I can communicate in English. I changed ADD_FILE_PID = Fritz_Box_HW205 inside the 1750E sources .kernelvariables. "make clean" and rebuilt the firmware - no luck still. ( Here https://www.ip-phone-forum.de/threads/freetz-f%C3%BCr-avm-dvb-c-repeater-verf%C3%BCgbar.307070/page-2 there was a proposal this issue is tied to avm_kernel_config which is used by 1750E and should be extracted from the DVB-C kernel due to avm_kernel_config is not part of sources provided by AVM. I am not that strong in building/extracting/packaging kernels etc. so understand all this is not so easy for me. Still trying to understand how to do it. Also I couldn't find original image and sources for 1750E 7.01 so far to try your another advice. ( |
|
Okay :) |
|
Could you please tell how to build 1750E 7.27 kernel using the extracted avm_kernel_config_area.S from the DVB-C? It looks like FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0=y for 1750E and the whole avm_kernel_config replacement part is skipped? Can I add it manually to ./source/kernel/ref-qca955x-1750_07.27/linux-4.4/arch/mips/kernel/? Will it be used during make kernel-precompiled phase? |
|
Length of 0 bytes is for "failure" of the config-area tool. Initial developer by PeterPawn, extended by er13 and now noone feels responsible to fix it for newer kernel... you have to do it yourself! See CHANGELOG, "Known problems" To only make changes on the kernel, do it in build/original/, this dir is just copied to modified |
Maybe this is true for the implementation by @er13 - but I've updated my project yesterday (PeterPawn/YourFritz@fbd0495) and as shown here, I was able to extract the EDIT: But beware of the fact, that the updated version will not work anymore with older kernels by AVM - there were changes in some C structures and I haven't implemented any checks, whether the newer or older structures are used by AVM's source files. |
|
To generate FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_* in config/.img/ * The change could be "since kernel version 4" - maybe the tool could be added a 2nd time... absent of FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_* = no config-area at all (=kernel v2?) |
|
Jetzt mache ich mal in Deutsch weiter, damit es nicht ermeut Verständnisprobleme beim Lesen gibt. Für das Extrahieren des Konfigurationsbereichs eines Kernels muß man dessen Größe gar nicht kennen ... hier reicht es tatsächlich, den größten bekannten Wert zu verwenden, denn beim Generieren der Assembler-Dateien werden ja ohnehin nur die vorhandenen Daten ausgegeben - was da noch an Müll dahinter kommt, interessiert gar nicht. Ein "quick hack", wie man die Größe dennoch aus dem (passenden) Loader-Skript für den Kernel ( Jedoch gibt es noch andere, markante Unterschiede zwischen den verschiedenen Versionen, die von AVM benutzt werden - und deren Behandlung regelt @er13 vermutlich anders (ich habe mir das seit der "Übernahme" nie wieder richtig angesehen), als ich das tat (und vermutlich auch anders, als ich es weiterhin tun würde). Mein Ziel war es nämlich, so weit wie möglich eine 1:1-Kopie des AVM-Bereichs zu erstellen ... das ist nun mal die Krux bei der ersten Implementierung, solange man noch nicht weiß, ob es überhaupt funktioniert. Da ist es nur natürlich, wenn man so dicht wie möglich an das Original will - nur so kann man bei einem Mißerfolg (einigermaßen) ausschließen, daß es an solchen Unterschieden gescheitert ist ... ansonsten müßte man das gesamte Prinzip beim Mißlingen in Frage stellen. Die Unterschiede bestehen bei AVM einerseits in den Werten für die Anzeige des letzten Eintrags in dem Array mit den Pointern auf die Strukturen - hier wird von AVM ein und die Anzahl der Einträge für diesen (und damit auch der Wert für den letzten) hängt von der möglichen Anzahl von Zum Beispiel die Notwendigkeit erneuter Änderungen, wenn AVM an diesen Strukturen weitere Änderungen vornimmt (daß das passiert, dazu komme ich gleich noch), auch wenn diese Änderungen ansonsten gar keine Auswirkungen auf die Verarbeitung durch das Programm hätten ... daß es Änderungen gibt, die auch bei Nutzung der Daten aus der Aber das Problem könnte man für die Tags wohl tatsächlich noch einigermaßen zuverlässig lösen, denn alle Einträge außer dem letzten (mit Tag Aber genau so eine Änderung, die Auswirkungen auf den bisher verwendeten Code hat, wurde durch AVM an einer weiteren Stelle vorgenommen ... so sah früher bei der 06.83 für die 7490 die o.a. Datenstruktur noch so aus: und befand sich in einer anderen Include-Datei. Das Problem mit dem richtigen Namen für das läßt sich nur noch mit bedingter Kompilierung (also Preprocessor-Anweisungen) einigermaßen sicher behandeln - solange man in einer Quelltext-Datei beide Fälle berücksichtigen will ... aber eben nicht mehr im erzeugten Programm. Die Strukturen, die bei der 06.83 für die 7490 verwendet wurden, sind natürlich auch heute noch z.B. bei der 7412 von Bedeutung ... denn deren letzte Version ist ja irgendetwas mit 06.8x. Man kann also auch nicht einfach auf die Unterstützung der alten Strukturen verzichten. Das alles macht es nun mal nicht leichter ... und von "mal eben schnell ändern" kann zumindest dann keine Rede sein, wenn man - wie es Freetz-NG ja wohl will - auch beide Varianten unterstützen wollte. Und dabei ist die Frage, ob man das auch als 64-Bit-Programm erstellen könnte, noch gar nicht angerissen ... das ist nämlich auch nicht sooo einfach, weil dann das "Hauptprogramm" selbst zwar mit 64-Bit-Datentypen arbeiten muß, aber die AVM-Include-Files immer noch auf eine 32-Bit-Architektur zielen und man daher sehr genau aufpassen muß, daß man keine Datentypen mit impliziter Größe (die sich dann zwischen 32- und 64-Bit-Architekturen unterscheidet) verwendet. Jedenfalls ist diese zweite Abhängigkeit von der FRITZ!OS-Version (basierend auf der anderen Struktur für die Modul-Tabelle) auch gleichzeitig der zweite Grund, warum das KEIN "host tool" ist und jeweils passend zum aktuell verwendeten Kernel erstellt werden sollte - erst recht nicht gehört es in irgendein vorbereitetes Download-File mit den ganzen anderen "host tools". Das ist jedenfalls meine feste Überzeugung ... und da man das Tool auch gar nicht benötigt, solange man kein "Replace kernel" machen kann (oder will), ist es auch vollkommen unnötig, das bei den Modellen, wo ein Kernel-Build ausgeführt wird, IMMER auch zu verwenden. Das wird - wie ich jetzt schon mehrfach festgehalten habe - erst beim Linken des eigenen Kernels überhaupt benötigt und es wäre nur folgerichtig, das deshalb auch erst an dieser Stelle zu machen. Da meine Implementierung auch genau darauf ausgerichtet ist und auch für die er13-Implementierung kein Grund besteht, das IMMER auszuführen, wäre der erste Schritt immer noch die Integration des Tools an der richtigen Stelle im Build und solange das nicht erfolgt ist, macht es für mich auch keinen Sinn, mir weitere Gedanken zu machen, wie ich meine Implementierung so an die unterschiedlichen Gegebenheiten bei AVM anpassen kann, daß man mit einem Quelltext alle Versionen bearbeiten kann. Das war ja auch mal mein ursprüngliches Ziel - nicht umsonst gibt es bei meiner Implementierung eine Funktion, die erst einmal versucht, die Reihenfolge bei der Speicherung (BE vs. LE) in den vorliegenden DATEN zu ermitteln (und damit auch erst zur Laufzeit), anstatt sich nur fix auf die Byte-Order des jeweiligen Modells zu stürzen. |
|
Auf deutsch ist auf jeden Fall einfacher! x64 Support brauche ich nicht unbedingt, ohne funktioniert es halt nicht auf zb aarch64: Es sieht so aus als ob es nur Kernel v4 betrifft: Die Liste ist übrigens nicht vollständig, zb 6660 hat 4.9 .175/.250/.199 aber FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0 ist in der 6660.in! Somit könnte man das ganze AKC für kernel 3 ignorieren und so lassen wie es ist - es funktioniert ja. Man muss nichts reparieren was nicht kaputt ist. Es gibt höchstens neue Fehler. Wie genau das mit den verschiedenen 7490 Versionen gelöst ist weiss ich nicht, ich sehe das als Blackbox an, solang herauskommt was ich erwarte ist es okay.
oder halt einen Alien der es erfordert, falls dieser ohne replace kernel funktionieren soll. Das ist aber nicht unbedingt nötig und man kann einfach automatisch RK auswählen
In Freetz gibt es die Symbole Ich hab übrigens kein AVM-Gerät mehr das mit Kernel v4 läuft und kann in dem Bereich nichts mehr testen. Die 7490 als ISDN Bridge hat noch v3 |
|
Vielleicht ist es ohnehin besser, auf "Replace kernel" zu verzichten - man weiß ja auch nie, was bei AVM in den Quellen noch alles fehlt. Außerdem ist das "Einarbeiten" der AVM-Quellen (gerade auch mit dem Freetz-Ansatz, das mit einer "Stammversion" und entsprechenden Patches für die Abweichungen bei anderen Modellen zu regeln) ja auch eine ziemliche Fleißarbeit und oft erst lange nach dem Release neuer Versionen machbar, wenn AVM die Quellen dann nachgereicht hat - da ist oft schon das nächste Release im Anflug. Es gibt nur sehr wenige Kernel-Options, die tatsächlich einen Rebuild erfordern (NFS wäre m.W. so eine, weil das an allen möglichen Stellen dann seine Hooks einbauen muß) und wenn man nur zusätzliche LKM braucht, muß man den Kernel ja noch lange nicht ersetzen. Die anderen Optionen bzw. Pakete, die einen tieferen Eingriff in den Kernel benötigen, funktionieren dann halt nicht für die neuen Modelle - der "Protest" wird sich in Grenzen halten. Entscheidender sind sicherlich andere Pakete, die auch mit dem originalen Kernel funktionieren ... ich bin nicht mal sicher, ob der neueste 7490-Kernel noch die Patches für die Traps bei Verwendung von TUN/TAP-Devices braucht (https://github.com/PeterPawn/YourFritz/tree/main/patch_kernel) und die GRX-Modelle brauchen den wohl schon länger nicht mehr - aber alles auch ohne jegliches "Wissen" meinerseits, da ich das nicht wirklich verfolge/teste und andere sicherlich auch nicht, solange das irgendwo "integriert" ist. Da es auch kein Problem ist, wenn das Zeug nichts zum Patchen findet, wird das vermutlich bis zum jüngsten Tag so implementiert bleiben. |
|
Die delta-Patches müssen nicht unbedingt sein, er13 wollte aber immer Platz auf den Mirrors und Bandbreite sparen. Anfang wurden sie von Freetz noch bei AVM direkt heruntergalden, die Pakete waren aber sehr gross und wenn Herr AVM nichts zu tun hat wurden auch schon immer zufällig Datein umbenannt, gelöscht oder unter gleichem Dateinamen ersetzt... das war nichts. |
|
@PeterPawn, eine Antwort auf #335 (comment) |
|
Laß uns (also "meinen Tester" und mich) mal erst (im IPPF) feststellen, ob das überhaupt (wie erwartet) funktioniert mit der 1750E-Firmware auf dem DVB-C-Repeater - und das dann auch mit vollem WLAN, worum es sich hier ja dreht. Wenn das klappen sollte (ich bin auch nicht 100% sicher, das derzeitige Problem mit der Initialisierung des LAN-Ports verstehe ich noch gar nicht), dann kann man hinterher noch einmal in Ruhe die notwendigen Änderungen ansehen ... und wenn sich dabei auch noch die RK-Option für andere, ähnliche Modelle (das mit dem Konfigurationsbereich zieht AVM bei allen Architekturen, egal ob ARM oder MIPS - bei den Pumas bin ich nicht sicher und müßte selbst erst nachsehen - konsequent durch) ergeben sollte, dann soll mir das auch recht sein. |
|
Ich denke die tk firmware könnte euch beim Testen helfen und mache Fehlerquelle ausschliessen, zb (ent)packen. Die Freetz-Sachen sind beim Starten des Kernels ja noch egal. |
|
Verstehe mich bitte nicht falsch ... aber ich wüßte gar nicht, was ich mit dem Skript anfangen soll und die Kommandos zum Entpacken und Packen, sowie zum Zerlegen eines Images, habe ich (meist) im Kopf bzw. verifiziere ich üblicherweise erst noch einmal (bei einem neuen Modell), indem ich sie Schritt für Schritt ausführe (wie so etwas aussieht, kannst Du Dir im parallelen IPPF-Thread ansehen - wobei dort natürlich nur die funktionierenden Kommandos und ihre Ergebnisse gezeigt werden und nicht die "Irrtümer", denen man zwischendrin zwangsläufig auch immer wieder unterliegt) und dabei jedes Zwischenergebnis noch einmal prüfe. Außerdem macht Freetz (und seine Forks) vieles aus meiner Sicht unnötig kompliziert ... ein Beispiel wäre hier die Suche nach der Stelle, wo man bei einem kombinierten Image ansetzen muß, um das in den Kernel und das Dateisystem (und ggf. auch in die NMI-Vector-Tabelle) zu zerlegen. Wenn ich mich nicht irre, verwendet Freetz an der Stelle immer noch das "Schweizer Taschenmesser" - was aber auch erst mal installiert (oder kompiliert) werden müßte. Das geht - zumindest in den Fällen, die ich benötige - aber mit "Standard-Tools" (u.U. sogar mit der Beschränkung auf solche, die zum POSIX-Standard gehören) mindestens genauso gut ... zumindest bin ich bisher noch auf keine unüberwindlichen Probleme gestoßen. Anderes wieder, wie das "Einbauen" eines NMI-Vectors wieder an der richtigen Stelle im Firmware-Image, wenn der bei der AVM-Firmware vorhanden war/ist, ist m.W. in Freetz (und Forks) gar nicht realisiert - "es geht ja auch ohne" ist die Begründung. Aber wie ich schon an anderer Stelle schrieb, mag es zwar beim Nachbauen von Lösungen denkbar sein, wenn man versucht, soviele "Sonderfälle" wie möglich unter ein gemeinsames Dach zu quetschen (z.B. beim Packen von Firmware-Images für die verschiedensten Modelle) oder sich auf ein "funktioniert doch" zurück zu ziehen, aber das ist etwas, was man bei "Erstbesteigungen" tunlichst vermeiden sollte - denn jede zusätzliche Abweichung (z.B. weil irgendein unerwarteter "Pfad" in so einem "Super-Skript" genommen wird) kann zu einem Mißerfolg führen und wenn man sich dann dieser Effekte nicht bewußt ist, marschiert man in die falsche Richtung weiter - will heißen: man zieht die falschen Schlußfolgerungen und muß schon sehr viel Glück haben, wenn man nicht noch viel mehr Zeit verschwendet hat, bevor man wieder ein paar Schritte zurück macht und dann im zweiten (oder dritten, etc.) Anlauf doch noch über die Stelle stolpert, wo es zuvor eben NICHT wie erwartet lief, ohne daß man es bemerkte. Es verbietet sich also bei solchen "Erkundungen im Neuland" von selbst, auf "Altbewährtes" zurückzugreifen, solange das nicht tatsächlich nur etwas "sehr Kleines" mit einer einzigen Aufgabe ist (wo dann auch nichts "unbemerkt" schief gehen kann) - womit wir wieder bei der Theorie "One tool for one job." wären ... auf diese These berufe ich mich ja nicht ohne Grund (und entsprechende Erfahrungen) immer wieder aufs Neue und dazu gehört auch das Bestreben, eine Aufgabe so weit es möglich ist, mit Standard-Tools zu lösen und auf die Verwendung von "Exoten" zu verzichten - auch wenn das nicht in jedem Fall funktionieren wird, manchmal auch nur aus Performance-Gründen - wie z.B. hier: https://github.com/PeterPawn/YourFritz/blob/main/scriptlib/functions/yf_base64.function, denn das dauert für größere Datenmengen mal so richtig. Um noch mal auf das Skript oben zurück zu kommen, wenn ich mir seinen Inhalt ansehe - das mag zwar alles irgendwann(!) mal "nett" sein als Änderung, aber ich sehe für nicht eine davon (bisher) eine Notwendigkeit, weil es - sofern tatsächlich der Kernel gepatcht werden muß - wohl nur dann Sinn macht (wenn überhaupt), das Image wieder "komplett" zusammen zu packen, wenn man das über Freetz installieren wollte. Irgendwelche "Cross-Updates" (wo von einer DVB-C-Version auf einen Alien (basierend auf der 1750E) gewechselt wird oder umgekehrt) werden ohnehin nicht funktionieren - nur in so einem Fall macht es aber überhaupt Sinn, sich mit Die automatische Suche nach anderen Dateien bei AVM (u.a. nach Online-Updates) macht auch fast keinen Sinn (sei es wg. notwendiger Änderungen am Kernel oder am Dateisystem) und wenn ich eine 1750E-Firmware als Alien auf einem DVB-C-Repeater betreibe, wird auch die Oberfläche weiterhin wie die eines 1750E aussehen ... denn die Dateien zur Unterstützung der anderen Features (von USB bis DVB-C) sind in der Alien-Firmware gar nicht vorhanden. Also entfällt auch Denn mit diesem Wert werden eben auch einige URLs gebildet und wenn die dann bei AVM auf eine Version zeigen, die es eigentlich gar nicht gibt, wird u.a. die Online-Hilfe (ohne jede Notwendigkeit) nicht funktionieren. Wenn da eine Firmware eines 1750E auf dem DVB-C-Repeater läuft, dann IST das auch eine 1750E-Firmware - egal, was auf dem Gerät selbst aufgedruckt ist. Irgendwelche Mimikry-Versuche sind da eher kontraproduktiv - zumindest in diesem Fall (und nach meiner Erfahrung auch in vielen anderen). Ohne eine Änderung an Das ist ein wenig so, als würde man in einer FRITZ!Box-Firmware als Alien für irgendein Speedport-Modell alles daran setzen, daß dieses Gerät sich auch weiterhin als "Speedport irgendwas" zu erkennen gibt - von solchen Bestrebungen wäre mir zumindest nichts bekannt und wenn es sie doch geben sollte, würde ich immer noch für jede einzelne Änderung nach dem Grund (der ja die Auswirkungen berücksichtigen sollte) fragen. Als Fazit würde ich also praktisch ALLE Änderungen aus dem oben verlinkten Skript für vollkommen unnötig (ja, ggf. sogar für kontraproduktiv) halten in diesem speziellen Kontext (1750E-Firmware als Alien auf einem DVB-C-Repeater) - und nur dafür ist das Skript ja offenbar gemacht. |
|
Ihr müsst es ja nicht benutzen wenn es dadurch nicht einfacher wird. Dateianhänge im IPPF sind übrigens problematisch da diese hinter einer Login-wall sind. Ich hatte selbst ca 2015 einen dvbc und 1750, und für mich sahen beide gleich aus, ausser dass der dvbc noch einen internen usb und daran einen em28174 dual-tuner hat. Das war da aber nicht im svn-Repo Mit neuerem Kernel v4 könnte sogar video4linux (oder wie das genau hiess) funktionieren. Eigentlich überrascht es mich dass Wlan beim Alien nicht mehr funktioniert. Bei Betrachtung von #15 (comment) könnte dies problematisch sein, der Rest sind wohl nur die Button+Led sfk ist übrigens Teil der Hosttools die man (solang man Spezialwissen vom Paketmanager hat) als "APTguru" auch vorcompiliert nutzen kann |
Es ist mir ja auch egal, was Freetz ((und Forks) da nutzt - ich wollte nur ein Beispiel bringen, daß nicht alles aus Freetz so ist, wie ich es (häufig) brauche (oder gebraucht habe). Ich weiß nicht, warum man hier überhaupt auf die Idee kam - und nicht nur hier, sondern auch im IPPF-Thread - ich bin ja dort eigentlich eingestiegen und das schon vor Monaten, als jemand durch Änderungen an der Hardware-Beschreibung sein Problem lösen wollte ... mit einem (noch deutchen) Kommentar, daß geänderte DTS-Files nichts helfen. Auch hier bin ich eher darauf angesprungen, wie man solche FDT-Änderungen erreichen kann - ohne zunächst noch einmal selbst zu hinterfragen, ob solche Änderungen überhaupt zielführend oder notwendig wären. Schaut man sich aber die FDT-Dateien in der 07.27 für den 1750E an, sind das für den DVB-C-Repeater und den 1750E andere Strukturen - das gesamte Und schaut man dann noch genauer in die Boot-Protokolle einer 07.27 auf dem DVB-C-Repeater, stellt sich heraus, daß es wohl gar nicht an der Hardware-Initialisierung scheitert (egal, welches fehlende PCI-Gerät da vermeintlich vermeldet wird), sondern irgendwann später. Und da wohl bei der Konfiguration der WLAN-Komponenten (durch Aber ich warte jetzt auf passende (und aktuelle) Protokolle für diese Konstellation - und (um ganz sicher zu gehen) das auch mit einer "selbst erstellten" Firmware, die wieder die NMI-Vector-Tabelle enthält. Das mag überflüssig sein - aber wie schon erwähnt: Bei solchen Unternehmungen tritt man mit der Maxime an, die Unterschiede so klein wie möglich zu halten und der Einbau der NMI-Vektor-Tabelle sind drei (oder vier, wenn man dessen Extraktion mitzählen wollte) zusätzliche Kommandos. So ganz weit im Hinterkopf habe ich auch noch die Idee als zusätzliche Fehlerquelle, daß irgendjemand zwar die neue Firmware als Alien über den Bootloader installiert hat, dabei aber total vergessen wurde, einfach mal das Gerät auch noch auf die Werkseinstellungen zu setzen, falls irgendein alter Inhalt in der Da m.W. bisher von systematischer(!) Suche nach dem Problem nichts zu sehen war, muß man wohl alles noch einmal von Beginn an überprüfen - ich ärgere mich schon genug über die verschwendete Zeit bei den (vermutlich unnötigen) Versuchen, die Hardware-Beschreibung irgendwie zu ändern. So weit, wie das alles schon funktioniert, kann es fast kein Layout-Problem mehr sein - dafür funktioniert viel zu viel mit der Alien-Firmware, wie ich jetzt erst gesehen habe. |
|
Werkseinstellungen sind ein gute Idee. Wobei ich eher nicht glaube dass es hilft. Am Alien funktioniert alles, bis auf Wlan (und DVB weil es das in der FW nicht gibt). Wenn ich mich richtig erinnere!! funktionierte Wlan bei älteren FOS noch als Alien. |
|
Ich habe einen DVB-C und 1750E Repeater da und die können beide zur Fehlersuche genutzt werden. Ich kann auch eine Serielle Konsole öffnen und die Ausgaben zur Verfügung stellen. Leider habe ich es auf Anhieb nicht hinbekommen etwas vollständig lesbares zu bekommen. Allerdings habe ich auch einen alten TTL Adapter, der nicht so richtig gut läuft und auf Notebook ist schon Windows 11. Aber vielleicht lag es ja auch nur an den COM Settings. Dazu wäre eine Anleitung super, um zu wissen das alles passt. Am besten mit dem dazu getesteten Terminal Tool. Putty und Tera Term waren nicht erfolgreich. Settings 115200-8-N-1 edit: mit GND + TX und RX war die Ausgabe OK. |
|
Mir fällt keine andere Erklärung mehr ein (immer unter der Annahme, daß die (WLAN-)Hardware 1:1 dieselbe ist beim 1750E und dem DVB-C-Repeater) als unterschiedliche Parameter für die WLAN-LKM beim Laden durch Wenn es da Unterschiede bei den Parametern für die LKM gibt, dann kann man erst mal von Hand versuchen, die LKM mit den passenden Parametern (und in der richtigen Reihenfolge, denn die ist (m.W.) bisher auch nur indirekt über ein paar Meldungen beim Laden bekannt - Ich würde die bisherigen Erkenntnisse jedenfalls so zusammenfassen, daß da vom Um da weiter "in das Da man das ganze Procedere von AVM auch "von Hand" anstoßen kann (ein Aufruf von Der Thread dazu im IPPF ist zum Erliegen gekommen, weil ich zwischendrin mal keine Zeit dafür hatte - obwohl ich dort (nachdem ich erst mal begriffen hatte, daß es gar keine Unterschiede im Hardware-Layout gibt, die einen Austausch der FDTs erfordern würden und das Augenmerk mehr in die Richtung ging, woran es am Ende tatsächlich scheitert, daß der Wenn es tatsächlich mit anderen Parametern für die LKM auch in der 07.27 funktionieren sollte, muß man vermutlich am Ende auch |
|
Vielleicht hat AVM eine Unterscheidung nach HWR nicht nur im dts/akc für die unterschiedlichen gpio-pins, sondern auch im Wlan-Kernelmodul oder der Binary. Und in neuerm FOS gibt es nur noch die HWR des 1750. Ich hab übrigens noch 6.2x/6.3x Supportdaten von beiden. Beim Dvbc sind zb diese Module zusätzlich geladen: Abgesehen von Bereich "calibration infos" des 1750 Beim Dvbc gleich bis auf Aus Bereich "wland": 1750 @PhoenixG36 Du kannst Textdateien/Bilder auf Github anhängen indem du sie mit der Maus in die Textbox ziehst |
|
Ein diff zwischen |
Ich habe gerade das alien Image für den dvb-c repeater erstellt und hochgeladen. Leider findet er jetzt aber kein anderes WLAN mehr. Weder im Monitor sieht er andere WLANs noch im Assistenten
The text was updated successfully, but these errors were encountered: