dirtyharry123
Freak
- Registriert
- 31. Juli 2012
- Beiträge
- 230
- Reaktionspunkte
- 129
- Punkte
- 103
AW: Howto: Matrix Cam Air
Ich lese hier schon seit längerer Zeit mit, leider besitze ich (noch) keine MCA, habe aber die Firmware mal unter die Lupe genommen.
gompf, audiofan und andere haben ja bereits einige wichtige Informationen zusammengetragen (Danke dafür).
@audiofan: du hattest ja bereits teilweise Erfolg mit einem gepatchten oscam, eventuell könntest du deine Patches hier veröffentlichen?
Zunächst einmal ist es relativ offensichtlich, dass die "offizielle" und die "inoffizielle" Firmware von den selben Autoren stammt.
In der mcam-binary der "inoffiziellen" firmware sind einige hardcoded Referenzen zu oscam und openxcas (genauer openxcas_msg) zu finden.
Auch die build-timestamps von den Firmwares unterscheiden sich teilweise nur um wenige Minuten.
Oscam wurde mit einer Toolchain kompiliert die das triplet arm-mca-linux verwendet.
Alle Funktionen des CAMs scheinen in der mcam-binary implementiert zu sein, die Funktionen Twitter, Gmail & Co greifen dabei auf eine externe API zu:
z.B:
für das Wetter
Dabei ist zu beachten, das auch Zugangsdaten an diesen Server gesendet werden, also Vorsicht!!!
Durch weitere Analyse der Domain stoßt man auf
Nun zu den bereits angesprochenen FIFOS (/tmp/mdbg, /tmp/mdesc, /tmp/mdvbi, /tmp/mflt):
/tmp/mdbg scheint das debug/log-interface des mcam prozesses zu sein, hier könnten einige hilfreiche Informationen enthalten sein.
(Möglicherweise muss das erst über einen Eintrag in der mca.ini aktiviert werden)
In der mcam-binary laufen hier mehrere Threads.
Leider konnte ich bis jetzt in keinem der Threads ein sleep oder ähnliches finden welcher wiederholt aufgerufen wird und die Probleme mit der V13 erklären könnte.
Eventuell wäre es jedoch hilfreich mal zu schauen, was das oscam.log auf der MCA sagt während es zu freezern kommt.
(Genauer, kommen die ECMS schon verzögert bei oscam an, oder liegt es eher an den CWs die zurück gehen).
Allerdings ist die mcam-binary an anderen Stellen voll mit sleeps von teilweise bis zu 20 Sekunden (was die langen bootzeiten sehr wahrscheinlich mit verursacht).
sm_task schreibt ECMS/EMMS nach /tmp/mdvbi (openxcas_msg)-format
cw_task ließt CWs von /tmp/mdesc
filter_task ließt filter (demux) von /tmp/mflt (Wichtig für Kanalwechsel etc)
die gesamte Kommunikation zwischen CAM und WIFI/Linux-Modul scheint über /proc/mio zu laufen, vielleicht kann man hier die mcam umgehen und direkt mit dem CAM kommunizieren?
Ich hoffe die Informationen helfen weiter.
P.S: Vielleicht hilft es ja auch mal die Entwickler anzuschreiben, ob sie nicht patches/sourcen veröffentlichen können (Das können die ja dann durchaus anonym machen)
schließlich würden die ja auch davon profitieren, wenn das Ding mal anständig läuft.
Ich lese hier schon seit längerer Zeit mit, leider besitze ich (noch) keine MCA, habe aber die Firmware mal unter die Lupe genommen.
gompf, audiofan und andere haben ja bereits einige wichtige Informationen zusammengetragen (Danke dafür).
@audiofan: du hattest ja bereits teilweise Erfolg mit einem gepatchten oscam, eventuell könntest du deine Patches hier veröffentlichen?
Zunächst einmal ist es relativ offensichtlich, dass die "offizielle" und die "inoffizielle" Firmware von den selben Autoren stammt.
In der mcam-binary der "inoffiziellen" firmware sind einige hardcoded Referenzen zu oscam und openxcas (genauer openxcas_msg) zu finden.
Auch die build-timestamps von den Firmwares unterscheiden sich teilweise nur um wenige Minuten.
Oscam wurde mit einer Toolchain kompiliert die das triplet arm-mca-linux verwendet.
Alle Funktionen des CAMs scheinen in der mcam-binary implementiert zu sein, die Funktionen Twitter, Gmail & Co greifen dabei auf eine externe API zu:
Sie müssen registriert sein, um Links zu sehen.
z.B:
Sie müssen registriert sein, um Links zu sehen.
für das Wetter
Dabei ist zu beachten, das auch Zugangsdaten an diesen Server gesendet werden, also Vorsicht!!!
Durch weitere Analyse der Domain stoßt man auf
Sie müssen registriert sein, um Links zu sehen.
(liegt auf dem selben Server).Nun zu den bereits angesprochenen FIFOS (/tmp/mdbg, /tmp/mdesc, /tmp/mdvbi, /tmp/mflt):
/tmp/mdbg scheint das debug/log-interface des mcam prozesses zu sein, hier könnten einige hilfreiche Informationen enthalten sein.
(Möglicherweise muss das erst über einen Eintrag in der mca.ini aktiviert werden)
In der mcam-binary laufen hier mehrere Threads.
Leider konnte ich bis jetzt in keinem der Threads ein sleep oder ähnliches finden welcher wiederholt aufgerufen wird und die Probleme mit der V13 erklären könnte.
Eventuell wäre es jedoch hilfreich mal zu schauen, was das oscam.log auf der MCA sagt während es zu freezern kommt.
(Genauer, kommen die ECMS schon verzögert bei oscam an, oder liegt es eher an den CWs die zurück gehen).
Allerdings ist die mcam-binary an anderen Stellen voll mit sleeps von teilweise bis zu 20 Sekunden (was die langen bootzeiten sehr wahrscheinlich mit verursacht).
sm_task schreibt ECMS/EMMS nach /tmp/mdvbi (openxcas_msg)-format
cw_task ließt CWs von /tmp/mdesc
filter_task ließt filter (demux) von /tmp/mflt (Wichtig für Kanalwechsel etc)
die gesamte Kommunikation zwischen CAM und WIFI/Linux-Modul scheint über /proc/mio zu laufen, vielleicht kann man hier die mcam umgehen und direkt mit dem CAM kommunizieren?
Ich hoffe die Informationen helfen weiter.
P.S: Vielleicht hilft es ja auch mal die Entwickler anzuschreiben, ob sie nicht patches/sourcen veröffentlichen können (Das können die ja dann durchaus anonym machen)
schließlich würden die ja auch davon profitieren, wenn das Ding mal anständig läuft.
Zuletzt bearbeitet:
