otrdecoder für NSLU2 debian (little endian)

[foobar2sup]

Hallo zusammen,

das Thema wurde schon mal diskutiert - leider aber ohne Lösung geschlossen.

Der Dekoder für Linux ARM funktioniert zwar auf der unslung-Plattform leider auch nicht auf der inzwischen sehr beliebten debian Plattform (wegen der anderen Endianess Einstellung).
Es wäre eine tolle Sache, wenn Ihr den Dekoder auch einmal für NSLU2 debian anbieten könntet.
QEMU oder andere Emulatoren gibt es dort leider nicht. :(

Danke und viele Grüße.,
M.

[Fenriswolf]

evtl. wäre das hier was für dich: http://otrforum.com/showthread.php?t=42169&highlight=NSLU2

oder ist das nicht die Variante, die du suchst? weil ich hab von Linux null plan ;)

[opty]

Hallo alle,

das thema hatten wir (leider) schon oft hier. Ich hab das Anliegen auch schon ein paar mal vorgetragen. passiert is aber nix. Sehr, sehr schade

grüsse,
opty

[foobar2sup]

Ja, bitte!

[worfroz]

Der Übersichtlichkeit wegen habe ich die Beiträge von soj und foobar2sup in den von soj verlinkten Thread verschoben und diesen wieder geöffnet.

[opty]

Hi,

Oh cool. Das Thema mal wieder. Da bin ich ja mal gespannt ob diesmal was passiert.

grüsse,
opty

[soj]

Hallo opty,

Ich hoffe auch.

Gruß SOJ :)

[sizilium]

Damit dieses Thema nicht einschläft wollte ich folgendes loswerden:

Liebes OTR Team, bitte stellt auch einen Dekoder für die ARM Architektur mit little-endian zur Verfügung!

Dies sollte doch in einer ruhigen Stunde erledigt sein ...

Ich spende auch gern mal was ;)

[worfroz]

Auf Wunsch von sizilium wieder geöffnet und seinen Beitrag hierher verschoben.

[sizilium]

Also:
Hab jetzt mit einem Verantwortlichen Kontakt gehabt und der meinte das es aus Zeitgründen frühestens April geht.

Abgelehnt wurde der Vorschlag jedenfalls nicht.

[sizilium]

Der OTR Decoder wurde ja bereits für den ARM Prozessor kompiliert, nur eben nicht im little endian Format. Muss man da nicht einfach nur eine kleine Compiler Einstellung setzen? Vermutlich eine Sache von Minuten ...

Die Idee mit Java finde ich gut. Dann wäre es leichter den Decoder zu portieren.

[Artemis1121]

Muss man da nicht einfach nur eine kleine Compiler Einstellung setzen?

hab zwar keine erfahrung damit, aber ein wenig googlen lieferte folgendes:

http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/ARM-Options.html#ARM-Options
3.17.2 GCC ARM Options
-mlittle-endian
Generate code for a processor running in little-endian mode. This is the default for all standard configurations.
-mbig-endian
Generate code for a processor running in big-endian mode; the default is to compile code for a little-endian processor.

[SGE]

Man braucht auch noch eine passende Build-Toolchain zum crosscompilen, mit dem einen gcc-Schalter ist das nicht getan. Die dazugehörigen Instrumente muß man sich auch erst selbst bauen.

Details Of Cross-Compiling

A cross-compile toolchain exists of a set of tools: a compiler, linker, assembler, debugger and a C library. A cross-compile toolchain runs on your host system and creates native binaries for your target system. A cross-compile toolchain is basically created in six steps:
Get and prepare the Kernel and C library headers of your target system
Compile the binutils package for your target
Compile a static C compiler for your target
Compile and install a C library for your target
Compile and install a full C/C++ compiler
Compile and install the GNU debugger
http://www.freewrt.org/docs/1.0/handbook/html-single/handbook.html#SECTION00350000000000000000

[soj]

Mein Intresse an so einem Decoder liegt immer noch vor.

@sizilium:
Java läuft nicht auf der NSLU2

Gruß SOJ :)

[SGE]

make: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped
und die Datei läuft auch auf meinem NAS.
Sollte also so funktionieren.

Funktionieren tut das sicher auch mit dem Decoder, da bin ich mir sicher.
Was halt fehlt ist jemand der die Quellen und die Lust dazu hat.
Letzteres wäre hier ja bei vielen vorhanden....;)

[Artemis1121]

april.. hmm...
wollen wir ihm alle in 56 Minuten eine pm schreiben?

SCNR

[Hal1983]

april.. hmm...
wollen wir ihm alle in 56 Minuten eine pm schreiben?

SCNR

Sehr gute Idee...allerdings hat er LEIDER das Empfangen von PMs deaktiviert.

[Artemis1121]

nslu2: XScale IXP420 133-266mhz, 32mb ram, 8mb flash, meistens Debian
das teil ist leistungsmäßig am limit.. verbraucht dafür kaum strom!

[sledge77]

Hallo

schon etwas neues?

Würde mich freuen wenn der Decoder für Debian little endian kommen würde.

Sledge77

[Hal1983]

Afaik sollte der Decoder irgendwann ab April umgesetzt werden.
Da cyberwolf das wohl in seiner freien Freizeit macht, will man ja auch niemanden drängen. Grad wo so schönes Wetter ist ;)

[sledge77]

Hast recht. Drängeln muss nicht sein. Würd mich aber trotzdem freuen wenn es in naher zukunft noch was wird.

Sledge77

[SGE]

Afaik sollte der Decoder irgendwann ab April umgesetzt werden.
Da cyberwolf das wohl in seiner freien Freizeit macht, will man ja auch niemanden drängen. Grad wo so schönes Wetter ist ;)

Der erste Wunsch nach einem solchen Decoder datiert übrigens vom 31.8.07, nur mal so nebenbei zum Thema Geduld...

[sledge77]

Kommt da noch was?
Wäre schon schön.

[Hal1983]

ich bump das mal...ist ja schon Mai ;)

[worfroz]

Auf Wunsch von Hal1983 wieder geöffnet.

[Hal1983]

Auf Wunsch von Hal1983 wieder geöffnet.

Vielen Dank.

@cyberwolf:
Wie schauts denn nu aus mit einem crosscompile?

[worfroz]

Auf Wunsch von MueMa wieder geöffnet.

[MueMa]

Hallo? Keiner da? Kein Admin der Stellung zur Lage der Entwicklung machen kann? Kein User der seine Meinung dazu äußert?

@Admin
da es ja nicht nur NSLU2 geht, könnte man den Beitrag in 'otrdecoder für weitere Linux-Systeme' umbenennen?

[KojiKui]

Würde schon meine Meinung äußern, nur was bringt es.

Möchte gerne so einen Dekober haben. Wo ich helfen kann werde ich gerne helfen, z.B. Testen o.ä. aber mehr kann man als armer User ja leider nicht tun :-)

[Hal1983]

Naja ich glaube alle die Intresse an einem ARM Decoder haben, haben sich schon geäußert. Und der Wunsch nach einem solchen Decoder besteht ja auch nicht erst seit gestern ;)

[PeppeLePew]

.. besteht noch eine Chance in absehbarer Zeit eine Version des DECODERS u.a. für den DLINK DNS-323 zu bekommen. => Linux 2.6.12.6 armv5tejl

Liebes OTR Team,

könnt Ihr bitte auch einen Dekoder für die ARM Architektur mit little-endian zur Verfügung stellen?


Vielen Dank!

[Klaus1978]

Habe sheevaplug... feine sache wäre das schon... rtorrent fertig... automatisch decoder... usw...

aber solange die admins sich taub und blind stellen wird da nischt passieren...

[sizilium]

Liebes OTR Team,

könnt Ihr bitte auch einen Dekoder für die ARM Architektur mit little-endian zur Verfügung stellen? Nun ist schon einige Zeit vergangen und das Interesse scheint da zu sein.

Ich wäre wie gesagt auch bereit eine Kleinigkeit zu spenden.

Vielen Dank!

[Artemis1121]

ich will auch einfach nur noch mal Bedarf signalisieren.
mein sheevaplug lechzt nach aufgaben!

[Klaus1978]

ich will auch einfach nur noch mal Bedarf signalisieren.
mein sheevaplug lechzt nach aufgaben!

meine Rede Arte ;)

[oberling]

So ... nun bin auch ich in die missliche Lage gekommen, einen dekoder für mein sheevaplug zu suchen ...
dementsprechend auch meine interessensbekundungen hier!

[Fischstäbchen]

meine Rede Arte ;)

ich reih mich dann mal in euren club ein ;)

[MueMa]

da ich gerade verzweifelt versuche den otrdecoder mit qemu auf meiner Diskstation zum Laufen zu bekommen ist mit ein Gedanke gekommen. Bin aber technisch und vor allem mit Linux nicht so versiert, dass ich nicht weiß ob es Blödsinn ist oder nicht.

Wenn ich file otrdecoder eingebe bekomme ich

otrdecoder: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.3, stripped

Bei anderen Befehlen/Programmen steht da mal z.B. python. Wäre es nicht möglich den otrdecoder in python zu schreiben? Dann müsste er doch auf jedem Rechner laufen auf dem python ist unabhängig vom Prozessor (i386, ARM etc)

[Murphy43]

Schreib bitte eine Mail an webmaster [at] onlinetvrecorder.com

[SGE]

Schreib bitte eine Mail an webmaster [at] onlinetvrecorder.com

Und wieso kann nicht einfach cyberwolf, der diesen Thread kennt und in dem er letztes Jahr noch einen Decoder für April angekündigt hat, hier mal was dazu sagen?

[Murphy43]

Und wieso kann nicht einfach cyberwolf, der diesen Thread kennt und in dem er letztes Jahr noch einen Decoder für April angekündigt hat, hier mal was dazu sagen?

Das mußt Du cyberwolf fragen. Ich weiß das nicht. ;)

[Artemis1121]

hab gerade die mail abgeschickt. ich hoffe mal das das hier dann klappt :)

[Klaus1978]

vielleicht kommt ja jetzt mal der stein ins rollen...

obwohl ich das noch bezweifel... der beitrag wird regelmäßig durch neue post´s auf die erste seite gerückt... den kennen doch mitlerweile alle... und nur weil wir ne mail schicken soll sich jetzt was ändern?

trotzdem gespannt ;-)

Greez Klaus

[cyberwolf]

.. besteht noch eine Chance in absehbarer Zeit eine Version des DECODERS u.a. für den DLINK DNS-323 zu bekommen. => Linux 2.6.12.6 armv5tejl

Liebes OTR Team,

könnt Ihr bitte auch einen Dekoder für die ARM Architektur mit little-endian zur Verfügung stellen?


Vielen Dank!

Leider habe ich derzeit genügend andere Baustellen zu bewältigen. Der Dekoder steht auf meiner ToDo Liste. Aber halt leider nicht oben. Außerdem gibts bald die Möglichkeit auch direkt AVIs herunterzuladen.

[Klaus1978]

War es das jetzt schon wieder?

Ich schließe mich Artes meinung an... da für mich keine avi´s in betracht kommen, werde ich mit meinem dsl lite weiterhin torrent nehmen müssen...

Daher brauchen wir den Decoder wirklich! Zumindest würde es den Ablauf sehr erleichtern.

Daher würden wir uns bestimmt sehr freuen und auch unseren dank zeigen wenn der stein mal in´s rollen kommen würde!

Greez Klaus

[aba13385]

Falscher Thread. Her geh's ausschließlich um ARM. Ich nehme an, es wurde der MorphOS Decoder verwendet.
Apropos: Im Übrigen ist das wohl ein Witz: Für MorphOS gibt's einen eigenen Decoder, nicht aber für ARM-LE. Die Zahl der Anwender dürfte wohl um Zehnerpotenz höher sein. Lasst mich raten: Einer der Admins hat einen Pegasus :)

[Artemis1121]

schaut mal bitte hier rein und stimmt mit ab :)
http://otrforum.com/showthread.php?t=58174

[Artemis1121]

der zuständige admin hat eine umfrage gestartet! :):):)
http://otrforum.com/showthread.php?t=56706

[Klaus1978]

Und seit dem ist hier leider nichts mehr passiert... :-(

[cyberwolf]

Und seit dem ist hier leider nichts mehr passiert... :-(

Ja, hat mir denn schon einer eine Anleitung für einen Crosscompiler für armv5 little endian geschickt? Ich hab zumindest noch nichts erhalten. Und wie gesagt, hab ich noch anderes zu tun. Wenn mir einer diese Sucharbeit abnimmt kann es durchaus wesentlich schneller gehen;-).

[Artemis1121]

Ja, hat mir denn schon einer eine Anleitung für einen Crosscompiler für armv5 little endian geschickt? Ich hab zumindest noch nichts erhalten. Und wie gesagt, hab ich noch anderes zu tun. Wenn mir einer diese Sucharbeit abnimmt kann es durchaus wesentlich schneller gehen;-).

ich habe mich gerade nur mal schnell eingelesen, da ich zur zeit unterwegs bin und so nicht auf meinem richtigen system testen kann. habe auch noch nicht mit mingw gearbeitet, also bitte korrigiert mich falls ich schwachsinn schreibe.

wenn ich das richtig sehe compiliert man ja unter mingw ganz normal mit dem gcc. und wenn ich da richtig lese gibts da einfache den parameter

-mlittle-endian
Generate code for a processor running in little-endian mode. This is the default for all standard configurations.
-mbig-endian
Generate code for a processor running in big-endian mode; the default is to compile code for a little-endian processor.


falls ich da viel zu einfach denke, könntest du noch ein wenig was über die build umgebung und die voraussetzungen schreiben? dann würde ich versuchen das demnächst bei mir mal nachzuvollziehen.

[spamkiller]

Was hat die sheevaplug eigentlich für einen Prozessor drin?

EDIT:
war auf der falschen maschine....
CS407:
Processor : ARM926EJ-S rev 1 (v5l)

Sheevaplug:
Processor : Feroceon 88FR131 rev 1 (v5l)

[Artemis1121]

das hier spuckt mein sheevaplug aus:

plug:~# cat /proc/cpuinfo
Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1192.75
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Marvell SheevaPlug Reference Board
Revision : 0000
Serial : 0000000000000000

plug:~# cat /proc/version
Linux version 2.6.32-trunk-kirkwood (Debian 2.6.32-5) (ben@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 Mon Jan 11 10:57:12 UTC 2010

[SGE]

Artemis, nimm mal das angehängte HelloWorld, das ist diesmal statisch gebaut.
Das andere hatte aber z.B. bei spamkiller auf der Cube funktioniert.

[spamkiller]

@SGE: wie baut man eigentlich statisch? Ist das ein einfacher Kommandozeilenparameter oder ist das komplizierter? Ich frage, weil meine Fedora Installation bereits eine fertige ARM Toolchain mitbringt (s.o.). Dann könnte ich mir die Emulation sparen.

[Artemis1121]

tja.. dann warten wir mal auf nen mod..

bin gerade seit fast 3 stunden dran crosstool-ng zu bauen..
also einen arm-little-endian crosscompiler auf nem arm-little-endian system.. aber das teil hat zumindest nen gutes menu zum auswählen der zielplattform!

[spamkiller]

Wozu benötigst du denn dann noch einen crosscompiler? Du kannst dann doch ganz normal nativ auf deinem arm-Little-endian System kompilieren. Oder verstehe ich das was falsch?

[Artemis1121]

um herauszufinden wie crosstool-ng funktioniert und um dem admin danach dann ne anleitung schreiben zu können..

wie gesagt (http://otrforum.com/showpost.php?p=289759&postcount=75),ein nativ kompiliertes HelloWorld hab ich schon hochgeladen (http://www.artemis1121.de/tmpdownloads/HelloWorldTest)

[SGE]

@SGE: wie baut man eigentlich statisch? Ist das ein einfacher Kommandozeilenparameter oder ist das komplizierter? Ich frage, weil meine Fedora Installation bereits eine fertige ARM Toolchain mitbringt (s.o.). Dann könnte ich mir die Emulation sparen.

man gcc: Linker Options; -static

Allerdings weiß ich auch nicht was dir deine Fedora-Toolchain nützt, der einzige der eine braucht ist cyberwolf, den der ist der einzige mit dem relevanten Sourcecode....;


um herauszufinden wie crosstool-ng funktioniert und um dem admin danach dann ne anleitung schreiben zu können..

War meine Beschreibung nicht einfach genug? Eine Chain hab ich auch schon damit gebaut und hochgeladen

Hier ist das statische HW:
http://ultrashare.de/f/1124/HelloWorld_static.zip.html

[Artemis1121]

War meine Beschreibung nicht einfach genug? Eine Chain hab ich auch schon damit gebaut und hochgeladen

achso, dachte du hättest crosstool genommen.. ich teste gerademal crosstool-ng, oder ist das das gleiche? sah nach dem nachfolger aus.

so weit bin ich aktuell:

menuconfig:

plug:~/crosstool/crosstool-ng-1.6.0# ct-ng menuconfig

crosstool-NG v1.6.0 Configuration - .config
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqq
lqqqqqqqqqqqqqqqqqqqqqqqqqqqq Target options qqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Arrow keys navigate the menu. <Enter> selects submenus --->. x
x Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, x
x <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> x
x for Search. Legend: built-in [ ] excluded <M> module < > x
x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqk x
x x *** General target options *** x x
x x Target Architecture (arm) ---> x x
x x Default instruction set mode (arm) ---> x x
x x (*) Use EABI x x
x x (*) Use the MMU (NEW) x x
x x Endianness: (Little endian) ---> x x
x x Bitness: (32-bit) ---> x x
x x *** Target optimisations *** x x
x x () Architecture level (NEW) x x
x x () Emit assembly for CPU (NEW) x x
x mqqqqv(+)qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqj x
tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqu
x <Select> < Exit > < Help > x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqj



und jetzt das bauen des crosscompilers

plug:~/crosstool/crosstool-ng-1.6.0# ct-ng build
[INFO ] Performing some trivial sanity checks
[INFO ] Build started 20100217.140108
[INFO ] Building environment variables
[WARN ] You did not specify the build system. That's OK, I can guess...
[INFO ] ================================================== ===============
[INFO ] Retrieving needed toolchain components' tarballs
[INFO ] Retrieving needed toolchain components' tarballs: done in 130.62s (at 02:16)
[INFO ] ================================================== ===============
[INFO ] Extracting and patching toolchain components
[INFO ] Extracting and patching toolchain components: done in 2577.84s (at 45:14)
[INFO ] ================================================== ===============
[INFO ] Installing GMP
[INFO ] Installing GMP: done in 972.77s (at 61:27)
[INFO ] ================================================== ===============
[INFO ] Installing MPFR
[68:31] / ^Z
[1]+ Stopped ct-ng build
plug:~/crosstool/crosstool-ng-1.6.0# fg
ct-ng build
[INFO ] Installing MPFR: done in 5471.95s (at 152:39)
[INFO ] ================================================== ===============
[INFO ] Installing PPL
[186:57] |



---




Hier ist das statische HW:
http://ultrashare.de/f/1124/HelloWorld_static.zip.html


plug:~/armlittleendiantest# ./HelloWorld_static
Hello, world!

funktioniert!




-------------




damit ist ja jetzt crosstool-ng überflüssig.. ich breche das kompilieren dann mal ab!

[monarc99]

Allerdings weiß ich auch nicht was dir deine Fedora-Toolchain nützt, der einzige der eine braucht ist cyberwolf, den der ist der einzige mit dem relevanten Sourcecode....;

Nun, nicht ganz ... der Decoder braucht auf alle Fälle die ffmpeg Libs und da ist der Code verfügbar. cyberwolf meinte ja, dass die am meisten Ärger machen.

[SGE]

achso, dachte du hättest crosstool genommen.. ich teste gerademal crosstool-ng, oder ist das das gleiche? sah nach dem nachfolger aus.

Jaja, ich sollte mal genauer lesen, das ng hatte ich übersehen.:cool:
ng steht für Next Generation, das ist schon die Weiterentwicklung, die hatte ich auch schon auf dem Schirm, aber wollte erstmal die alte probieren.


damit ist ja jetzt crosstool-ng überflüssig.. ich breche das kompilieren dann mal ab!

Weiß nicht ob das schon der Durchbruch auf dem Weg zum Decoder ist, ein HelloWorld ist dioch schon etwas einfacher strukturiert.;)
Ich würd die an deiner Stelle schon noch durchcompilieren lassen (dauert ewig, nicht wahr?)

[SGE]

Nun, nicht ganz ... der Decoder braucht auf alle Fälle die ffmpeg Libs und da ist der Code verfügbar. cyberwolf meinte ja, dass die am meisten Ärger machen.

Da ist die Frage was man auf einer NAS will:
diesen dochnichtsoEasy-Decoder mit schwurbeligen Schnitttechniken, oder einen einfachen kleinen Consolen-Decoder, der keine ffmpeg-libs braucht?
Mir würde letzteres völlig reichen, automatisiert nachts mal eine sheevaplug schneiden lassen und am nächsten Tag schauen was da so lustiges oder weniger lustiges bei rausgekommen ist stell ich mir sehr unbefriediegend vor.

[monarc99]

Da ist die Frage was man auf einer NAS will:
diesen dochnichtsoEasy-Decoder mit schwurbeligen Schnitttechniken, oder einen einfachen kleinen Consolen-Decoder, der keine ffmpeg-libs braucht?

Da musst du ihn fragen, was er von den ffmpeg libs braucht. Da sind ja nicht nur Encoder und Decoder drin ;)

[SGE]

Da musst du ihn fragen, was er von den ffmpeg libs braucht. Da sind ja nicht nur Encoder und Decoder drin ;)

Die sind rein für das schneiden da drin, da brauch ich ihn nicht fragen.
Mein Linux-Decoder braucht keine und ist auch nicht gegen die gebaut.
Und der hat auch die letzten Tage mit allen Filmen wunderbar funktioniert. Nicht wie bei anderen.;)

[cyberwolf]

Da musst du ihn fragen, was er von den ffmpeg libs braucht. Da sind ja nicht nur Encoder und Decoder drin ;)

Die configure Parameter für FFmpeg sind in jedem Dekoderpaket enthalten;-).

[spamkiller]

Mir würde schon eine einfacher Konsolendecoder (ohne die easy Features) reichen. Den einfach mit einem gepushten OTRkey füttern und gut ist.

Wenn der Source nicht public ist, dann würde mir schon eine lib reichen, die ich in eigene Programme einbinden könnte...

[Artemis1121]

cyberwolf, hast du zeit gefunden dir das mal anzuschauen? gibts noch irgendwelche probleme die zu lösen wären?

[Artemis1121]

enschuldigung das ich das jetzt so sagen muss, aber:

ES IST ZUM KOTZEN!

da es ja nicht möglich ist auf dem sheevaplug nativ zu dekodieren, muss jetzt alles übers netzwerk laufen.. ich dekodiere seit 16 stunden 400gb also mit einer durchschnittlichen rate von 7,11mb/s.. lesen und schreiben kann ich aber mit 30mb/s(getestet mit h2testw, und auch coldcut bekommt das hin)!

was treibt der dekoder da?
ich hatte vor jahren mal ein ähnliches problem mit projektX, lange getestet und am quellcode rumgebastelt. das problem ist, das direktes lesen zwar lokal schnell geht, aber übers netzwerk riesige probleme bereitet(was die geschwindigkeit angeht). der fix der am ende auch ins programm einfloss) bestand darin einfach einen BufferedInputStream zwischenzuhängen.

wäre es denn nicht vielleicht möglich einfach nur nen kleinen readbuffer(1-4mb reichen da schon) in den aktuellen schweren dekoder(nicht dem easy) einzubauen?
cyberwolf, das wäre klasse!


ps: ich schreibe das hier, da es ja auch um den sheevaplug geht, da cyberwolf hier (hoffentlich) mitliest und da man cyberwolf keine direkte nachricht zukommen lassen kann.

pps: und jetzt darf ich die 3 dateien suchen die aufgrund der statusverlängerungen nicht dekodiert wurden.. :(

[spamkiller]

@cyberwolf: Lass doch mal hören, wie der Stand der Dinge ist. Hier warten alle ungeduldig darauf, dir zu helfen.

Vielleicht könntest du dich auch einmal zu dem Vorschlag mit der Library äussern. Irgendetwas, was die Geheimnisse der Dekodierung verbirgt und doch anderen Entwicklern die Möglichkeit gibt, eigene Programme zu schreiben.

[spamkiller]

Java wäre noch eine Möglichkeit, um plattformübergreifend zu kompilieren. Ich habe hier (CS407) als Compiler jikes und als VM jamvm laufen.

Ich kann mir nicht vorstellen, dass die zu schützenden Programmteile, die sich mit der Dekodierung beschäftigen (also Schlüssel, Authentication, usw.), so umfangreich sind, dass sie nur mit großem Aufwand zu portieren wären.

Es geht ja nur um die reine Dekodierung. Ein Aufruf mit OTRKey InputStream, OutputStream für die dekodierten Daten auch noch mitgeben, fertig. Das ganze drumherum mit Batch Modus, OTRKey nach Dekodierung löschen, usw.... geschenkt.

[cyberwolf]

So das warten hat ein Ende:-P. Ich hab jetzt mal gerade die ARM Version kompiliert, ohne die ganzen Easydecoderfunktionen. Also so wie der alte Dekoder.
Ihr findet den Dekoder hier: http://www.onlinetvrecorder.com/downloads/otrdecoder-bin-arm-unknown-linux-gnu-0.4.1148.tar.bz2

[Artemis1121]

ich google gleich erst noch mal und ergänze dann, aber erst schon mal schnelles feedback:


plug:~/otrdecoder-bin-arm-unknown-linux-gnu-0.4.1148# ldd otrdecoder
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.1.2' not found (required by ./otrdecoder)
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./otrdecoder)
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./otrdecoder)
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.1.3' not found (required by ./otrdecoder)
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.1' not found (required by ./otrdecoder)
./otrdecoder: /lib/libc.so.6: version `GLIBC_2.0' not found (required by ./otrdecoder)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40009000)
libm.so.6 => /lib/libm.so.6 (0x400e9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40191000)
libc.so.6 => /lib/libc.so.6 (0x401a5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.3 (0x2a000000)



plug:~/otrdecoder-bin-arm-unknown-linux-gnu-0.4.1148# strings /lib/libc.so.6 | grep GLIBC
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_PRIVATE
GNU C Library (Debian EGLIBC 2.10.2-6) stable release version 2.10.2, by Roland McGrath et al.


plug:~/otrdecoder-bin-arm-unknown-linux-gnu-0.4.1148# /lib/libc.so.6
GNU C Library (Debian EGLIBC 2.10.2-6) stable release version 2.10.2, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux >>2.6.30-2-iop32x<< system on 2010-02-07.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

[spamkiller]

Aaaahhh :-) endlich :-)

auf meiner CS407 einfach nur den decoder ohneParameter aufgerufen ergibt:

./otrdecoder: /lib/libgcc_s.so.1: version `GCC_4.0.0' not found (required by ./otrdecoder)

[Artemis1121]

wenn ich das alles richtig verstanden habe, ist das für eine ältere glibc version gebaut. man kann dies setzen mit

export LD_ASSUME_KERNEL=2.X.X

funktioniert aber leider nicht. für welchen kernel und glibc version wurde denn compiled?

[spamkiller]

kann man den decoder evtl. statisch bauen? Oder löst das dieses Problem nicht?

[cyberwolf]

Ich habe den Crosscompiler von SGE verwendet. Gab es da keine andere Lösung als statisch bauen?

[spamkiller]

Was ist denn schlecht an der statischen Lösung?

[Artemis1121]

nachteile der statischen lösung:
höherer speicherplatzverbrauch auf der festplatte, da alle libs die der decoder benötigt mitgeliefert werden müssen(stecken im binary mit drin).
höherer speicherplatzverbrauch im ram, da jedes programm seine eigene lib laden muß, bei x instanzen wird auch die lib x mal statt nur 1 mal geladen.
fehlerbehebungen in den libs erfordern ein update des programms. dynamisch gelinkte programme profitieren direkt vom update der lib.

---

cyberwolf, für welchen kernel, welche libc version wurde denn gebaut?

hat sich erledigt. hab gerade in die demo-arm.sh geschaut:
eval `cat arm.dat gcc-4.1.0-glibc-2.3.2-tls.dat` sh all.sh --notest

export LD_ASSUME_KERNEL=2.3.2
bringt leider nix.

[cyberwolf]

Also hier mal die statische Version:
http://www.onlinetvrecorder.com/downloads/otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148.tar.bz2

[spamkiller]

cube-1> ./otrdecoder
Illegal instruction (core dumped)

[Artemis1121]

plug:~/otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148# ./otrdecoder
Decoder for otrkey files.
Usage: ./otrdecoder [global options] [-i FILE|URL [input options]] ...

global options:
-h prints this screen
-v prints version
-e EMAIL use EMAIL to fetch the key directly from otr
-p PASSWORD use PASSWORD to fetch the key directly from otr
-b BUFFERSIZE use BUFFERSIZE*blocksize as size for the IO buffer.
0 disables IO buffering. (default: 1024)
-o DIRECTORY use DIRECTORY as default output directory (default: .)
-q don't verify input file before processing.
If this is turned off, it is possible to decode partially
downloaded otrkeys in the new format
-f force overwriting of output file
-U enable user interaction

input options:
-i FILE use FILE as input file
-o DIRECTORY use DIRECTORY as output directory (default: .)

:)




plug:/media/maindata/torrent/finished# ~/otrdecoder-bin-arm-unknown-linux-gnu-st
atic-0.4.1148/otrdecoder -e blub@blubdi.blub -p blubbeldiblub -i The_Big_Bang_Theory__The_Excelsior_Acquisition_10. 03.01_21-31_uswcbs_29_TVOON_DE.mpg.HQ.avi.otrkey

Could not verify login: Error: Could not connect to server to verify account data.
Verifying input ...
Successfully verified input.
Check authorization ...
Authorized.
Decoding ...
Successfully decoded.
Verifying output ...
Successfully verified output.

http://diefreien.bds-clan.de/images/smiles/wav.gif

---

ps: ich teste gerade crosstool-ng, hatte damals wegen platzmangels das kompilieren abbrechen müssen. wird warhscheinlich dann morgen früh fertig sein. mal schaun ob damit dann dynamisches linken möglich ist. falls ja, schreib ich nen kleines howto(ergibt sich aber fast alles von selbst!)

[cyberwolf]

@cyberwolf: Falls ja, welches Target wurde da gewählt?


Als Parameter für den g++ werden die folgenden für das static binary verwendet:

-g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -static
für das shared binary:

-g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -Wl,-rpath,$ORIGIN
und für die .o Dateien:

-DHAVE_CONFIG_H -DLOCALEDIR="/usr/local/share/locale" -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -c

[Klaus1978]

Wollte mich auch nochmal zu Wort melden...

Dickes LOB und DANKE an Cyberwolf der es jetzt durchzieht... ;-)

Mein Dank ist dir gewiss... Spende an OTR wird kommen sobald das ding läuft!

[Artemis1121]

@klaus: die static version funktioniert bereits auf dem sheevaplug! :)


compiliert hab ich den crosscompiler, nur bin ich jetzt irgendwie zu dumm den aufzurufen. kann mir jemand den befehl nennen oder nen howto verlinken? danke!

[Klaus1978]

super geht ;-)

PS: Wo kann man denn jetzt Spenden... finde das nicht mehr

[SGE]

@klaus: die static version funktioniert bereits auf dem sheevaplug! :)


compiliert hab ich den crosscompiler, nur bin ich jetzt irgendwie zu dumm den aufzurufen. kann mir jemand den befehl nennen oder nen howto verlinken? danke!

Die relevanten Binarys findest du hier:

ls -F $DEIN_PFAD_ZU/crosstool/gcc-4.1.0-glibc-2.3.2/arm-unknown-linux-gnu/bin


-rwxr-xr-x 1 1872563 9. Feb 07:14 arm-unknown-linux-gnu-addr2line*
-rwxr-xr-x 2 1845367 9. Feb 07:13 arm-unknown-linux-gnu-ar*
-rwxr-xr-x 2 2804440 9. Feb 07:14 arm-unknown-linux-gnu-as*
-rwxr-xr-x 2 310077 9. Feb 09:18 arm-unknown-linux-gnu-c++*
-rwxr-xr-x 1 1836852 9. Feb 07:14 arm-unknown-linux-gnu-c++filt*
-rwxr-xr-x 1 309410 9. Feb 09:18 arm-unknown-linux-gnu-cpp*
-rwxr-xr-x 2 310077 9. Feb 09:18 arm-unknown-linux-gnu-g++*
-rwxr-xr-x 2 308483 9. Feb 09:18 arm-unknown-linux-gnu-gcc*
-rwxr-xr-x 2 308483 9. Feb 09:18 arm-unknown-linux-gnu-gcc-4.1.0*
-rwxr-xr-x 1 16412 9. Feb 09:18 arm-unknown-linux-gnu-gccbug*
-rwxr-xr-x 1 74593 9. Feb 09:18 arm-unknown-linux-gnu-gcov*
-rwxr-xr-x 1 2177193 9. Feb 07:14 arm-unknown-linux-gnu-gprof*
-rwxr-xr-x 2 2667972 9. Feb 07:14 arm-unknown-linux-gnu-ld*
-rwxr-xr-x 2 1906948 9. Feb 07:14 arm-unknown-linux-gnu-nm*
-rwxr-xr-x 1 2385646 9. Feb 07:13 arm-unknown-linux-gnu-objcopy*
-rwxr-xr-x 2 2536234 9. Feb 07:13 arm-unknown-linux-gnu-objdump*
-rwxr-xr-x 2 1845366 9. Feb 07:13 arm-unknown-linux-gnu-ranlib*
-rwxr-xr-x 1 440417 9. Feb 07:14 arm-unknown-linux-gnu-readelf*
-rwxr-xr-x 1 1750115 9. Feb 07:13 arm-unknown-linux-gnu-size*
-rwxr-xr-x 1 1731986 9. Feb 07:13 arm-unknown-linux-gnu-strings*
-rwxr-xr-x 2 2385677 9. Feb 07:14 arm-unknown-linux-gnu-strip*

[KojiKui]

Ist auf jeden Fall sehr schade das es auf der Cubestation noch nicht läuft. Hier bei mir geht es auch nicht :-(

[Artemis1121]

float f = 1.234;
f *= 2.345;
f += 3.456;
f /= 4.567;

mit ein wenig pech fasst der gcc das zusammen zu:

float f = 1.39035034;

[cyberwolf]

mit ein wenig pech fasst der gcc das zusammen zu:

float f = 1.39035034;

Okay, dann halt ein bisschen anders;-).
Mit einem
#include <cmath> und dann
float f=sin(1.2345);

[spamkiller]

Der build brach wieder ab:

[INFO ] Installing native gdb
[INFO ] ================================================== ===============
[INFO ] Installing ncurses library
[INFO ] ================================================== ===============
[INFO ] Installing native ncurses tic
[EXTRA] Configuring ncurses tic
[EXTRA] Building ncurses tic
[ERROR] make[1]: *** [tic] Error 1
[ERROR] Build failed in step 'Installing native ncurses tic'
[ERROR] called in step 'Installing ncurses library'
[ERROR] called in step 'Installing native gdb'
[ERROR] Error happened in '/opt/crosstool/lib/ct-ng-1.6.0/scripts/functions' in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR] called from '/opt/crosstool/lib/ct-ng-1.6.0/scripts/build/debug/300-gdb.sh' at line # 180 in function 'do_debug_gdb_build'
[ERROR] called from '/opt/crosstool/lib/ct-ng-1.6.0/scripts/build/debug.sh' at line # 35 in function 'do_debug'
[ERROR] called from '/opt/crosstool/lib/ct-ng-1.6.0/scripts/crosstool-NG.sh' at line # 562 in function 'main'
[ERROR] Look at '/root/x-tools/arm-unknown-linux-gnueabi/build.log' for more info on this error.
[ERROR] (elapsed: 235:23.45)
[235:25] / make: *** [build] Error 2

Im log file steht:

[ALL ] i686-build_redhat-linux-gnu-gcc ../objects/tic.o ../objects/dump_entry.o -I../progs -I/opt/devel/arm-unknown-linux-gnueabi/t
argets/src/ncurses-5.7/progs -DHAVE_CONFIG_H -I/opt/devel/arm-unknown-linux-gnueabi/targets/src/ncurses-5.7/progs/../include -I. -I../includ
e -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -O2 --param max-inline-insns-single=1200 -static -L../lib -lncurses -L../lib -lncurses -dy
namic -ldl -o tic
[ALL ] /usr/bin/ld: cannot find -ldl
[ALL ] collect2: ld returned 1 exit status
[ERROR] make[1]: *** [tic] Error 1

Keine Ahnung warum ld einen Fehler meldet, jedenfalls weiss ich da nicht mehr weiter. :(

Vielleicht hat jemand anders mehr Erfolg, eine softfloat toolchain zu bauen.

[Artemis1121]

weil ich faul bin ^^
auf dem sheevaplug hab ich alles zum compilieren installiert und das teil läuft auch rund um die uhr..
auf meinem normalen rechner müßte ich erst mal alles zum compilieren zusammenbasteln.

und ich baue ja nicht direkt für den sheevaplug sondern:

M[EXTRA] Dumping internal crosstool-NG configuration
M[EXTRA] Building a toolchain for:
M[EXTRA] build = arm-linux-gnueabi
M[EXTRA] host = arm-linux-gnueabi
M[EXTRA] target = arm-unknown-linux-gnueabi
M[EXTRA] Dumping internal crosstool-NG configuration: done in 0.35s (at 00:06)
das zielsystem ist zudem softfloat und wenn alles geht wissen wir auch ob das dynamische linken geht :]

[spamkiller]

Ich habe den gdb jetzt auch noch rausgenommen. Jetzt habe ich eine toolchain arm-unknown-linux-gnueabi (softfloat). Wie teste ich denn nun das ganze? Ich sehe vor lauter Verzeichnissen und Dateien nichts mehr...

[spamkiller]

Der Link liefert einen 404

[spamkiller]

Irgendwelche Vorschläge, was ich mit den vielen Ordnern und Dateien anstellen soll, die ct-ng erstellt hat?

drwxr-xr-x 11 root root 4096 2010-03-07 16:46 build-binutils
drwxr-xr-x 5 root root 4096 2010-03-07 18:46 build-binutils-for-target
drwxr-xr-x 10 root root 4096 2010-03-07 18:03 build-cc
drwxr-xr-x 10 root root 4096 2010-03-07 17:08 build-cc-core-shared
drwxr-xr-x 9 root root 4096 2010-03-07 16:53 build-cc-core-static
drwxr-xr-x 2 root root 4096 2010-03-07 18:52 build-dmalloc
drwxr-xr-x 19 1000 1000 4096 2010-03-07 18:52 build-duma
drwxr-xr-x 15 root root 4096 2010-03-07 16:33 build-gmp
drwxr-xr-x 15 root root 4096 2010-03-07 18:39 build-gmp-target
drwxr-xr-x 4 root root 4096 2010-03-07 16:09 build-kernel-headers
drwxr-xr-x 57 root root 4096 2010-03-07 17:54 build-libc
drwxr-xr-x 6 root root 4096 2010-03-07 16:57 build-libc-headers
drwxr-xr-x 5 root root 4096 2010-03-07 17:00 build-libc-startfiles
drwxr-xr-x 4 root root 4096 2010-03-07 18:50 build-libelf
drwxr-sr-x 6 1000 1000 4096 2010-03-07 18:53 build-ltrace
drwxr-xr-x 5 root root 4096 2010-03-07 16:39 build-mpfr
drwxr-xr-x 5 root root 12288 2010-03-07 18:43 build-mpfr-target
drwxr-xr-x 2 root root 4096 2010-03-07 18:50 build-sstrip
drwxr-xr-x 3 root root 4096 2010-03-07 18:54 build-strace
drwxr-xr-x 2 root root 4096 2010-03-07 16:07 configs
drwxr-xr-x 9 root root 4096 2010-03-07 17:10 gcc-core-shared
drwxr-xr-x 9 root root 4096 2010-03-07 23:08 gcc-core-static

Über all die Ordner sind binaries verteilt. Muss ich jetzt den Pfad anpassen und jedes bin und lib Verzeichnis da aufnehmen? Oder wie geht es jetzt weiter...:confused:

Ich habe schon in den gcc-static Ordner gewechselt:

lrwxrwxrwx 1 root root 72 2010-03-07 16:47 arm-unknown-linux-gnueabi-ar -> /root/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ar
lrwxrwxrwx 1 root root 72 2010-03-07 16:47 arm-unknown-linux-gnueabi-as -> /root/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-as
lrwxrwxrwx 1 root root 29 2010-03-07 16:55 arm-unknown-linux-gnueabi-cc -> arm-unknown-linux-gnueabi-gcc
-rwxr-xr-x 1 root root 243502 2010-03-07 16:55 arm-unknown-linux-gnueabi-cpp
-rwxr-xr-x 2 root root 241135 2010-03-07 16:55 arm-unknown-linux-gnueabi-gcc
-rwxr-xr-x 2 root root 241135 2010-03-07 16:55 arm-unknown-linux-gnueabi-gcc-4.3.2
-rwxr-xr-x 1 root root 16536 2010-03-07 16:55 arm-unknown-linux-gnueabi-gccbug
-rwxr-xr-x 1 root root 33287 2010-03-07 16:55 arm-unknown-linux-gnueabi-gcov
lrwxrwxrwx 1 root root 72 2010-03-07 16:47 arm-unknown-linux-gnueabi-ld -> /root/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld
lrwxrwxrwx 1 root root 75 2010-03-07 16:47 arm-unknown-linux-gnueabi-strip -> /root/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-strip
und versucht hello.c zu kompilieren, aber ohne Erfolg:
[root@fedora-dev bin]# ./arm-unknown-linux-gnueabi-gcc -Wall -o hello /opt/devel/hello.c
/root/x-tools/arm-unknown-linux-gnueabi/bin/.arm-unknown-linux-gnueabi-ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status

[Artemis1121]

ich hab gerade mal ein wenig gesucht und für den im qnap verwendeten arm926ej-s ein ct-ng config script gefunden (http://sourceware.org/ml/crossgcc/2008-06/msg00031.html). werde das mal compilieren lassen, aber da das bei mir ja so 12 stunden dauert kommt das helloworld erst morgen.

---

edit: irgendwas stimmt damit nicht. nach dem laden wird es als alpha architecture angezeigt. und nach angeblich erfolgreichem speichern steht immer noch die alte config drin.

./ct-ng show-tuple
arm-unknown-linux-gnueabi

[Artemis1121]

via crosstool-ng kann man direkt arm-unknown-linux-gnueabi auswählen und bauen. damit kann man dynamisch gelinkt für den sheevaplug bauen.
(cyberwolfs bereits veröffentlichter static decoder läuft auf dem sheevaplug. der dynamisch gelinkte nutzt zu alte libs)

mit der synology toolchain kann man für qnap cubestation bauen (auch dynamisch gelinkt?)

cyberwolf, wär es ok beides zu machen?

[spamkiller]

auch dynamisch

[Artemis1121]

Ich will mir perspektivisch schon auch eine Sheeva zulegen.

hol dir den nachfolger, guruplug server (http://www.globalscaletechnologies.com/c-4-guruplugs.aspx) plus, der hat noch 2 sata anschlüsse! (gibt auch noch einen mit hdmi) (cpu etc. ist identisch) :)

(ich ärgere mich das ich kein sata hab) :(

[spamkiller]

Ich habe auch schon mit dem Gedanken gespielt. Allerdings wäre das für mich reinste Spielerei (schnief), da alles notwendige schon die teure Cube Station erledigt. :-/
Aber jucken tut's schon...

[KojiKui]

Passiert hier noch etwas? Es klang so vielversprechend, nur mal eben kompilieren ;) wär so super wenn das auch für die CS407 laufen würde.

[spamkiller]

hmm, ich weiss nicht. cyberwolf hat etwas von einem letzten Arbeitstag erzählt... :(

Ich habe schon mehrfach gefragt, auch im easy Decoder Thread, aber bisher ohne Erfolg. Ich weiss noch nicht einmal, ob es beim Kompilieren des Decoders noch Probleme gibt oder ob man uns einfach vergessen hat :(

[KojiKui]

ich hoffe dann doch mal nur der letzte Arbeitstag vor seinem wohlverdienten Urlaub... wir sind so nah dran :-) das ist ja wie verhungern am Rand der Oase.

[Kev1]

Hat sich das Thema erledigt oder wird es noch eine decoder Version für die Sheevaplug geben?

[spamkiller]

Ich habe mehrere Tage in eine Little endian Version für sheevaplug/Cube Station investiert und jetzt kommt noch nicht mal mehr eine Antwort seitens OTR. :mad:

ich habe wenig hoffnung, dass da noch was passiert. Ich wünschte nur, die hätten mir das vorher gesagt, dass sie kein interesse haben!

Sorry

[Artemis1121]

Ich habe mehrere Tage in eine Little endian Version für sheevaplug/Cube Station investiert und jetzt kommt noch nicht mal mehr eine Antwort seitens OTR. :mad:

ich habe wenig hoffnung, dass da noch was passiert. Ich wünschte nur, die hätten mir das vorher gesagt, dass sie kein interesse haben!

Sorry

+1

sehr schade :(

[Klaus1978]

Jap... wirklich schade habe mich so darauf gefreut!

[Kev1]

hm, wenn das so ist, bliebe wohl als letzte Möglichkeit, um das Sheevaplug für die Dekodierung zu benutzen, nur noch das Reverse Engineering des (x86) bins übrig.

Sehr schade, dass hier so wenig von OTR kommt.

Ich finde es auch sehr merkwürdig, dass hier mittels eines geheimen Verfahrens anstelle eines Geheimnisses verschlüsselt wird. Dabei lernt doch jeder Informatiker in der ersten Vorlesung über Sicherheit, dass dies prinzip bedingt weniger sicher ist, als wenn das Verfahren allseits bekannt und es dank des Geheimnisses weiterhin als sicher gilt. Wer hier persönlichen Nachholbedarf erkennt, der sollte sich mal mit Kerckhoffs’ Prinzip näher beschäftigen.
Wäre es ein sicheres, auf einem Geheimnis basierendes Verfahren, könnte OTR ohne Bedenken dieses Verfahren veröffentlichen und sich dann jeder nach Lust und Laune seinen eigenen Decoder schreiben, für jede beliebige Architektur, und trotzdem wäre ein Missbrauch ausgeschlossen.

Man beachte bitte den Konjungtiv des ersten Satzes. Nicht, dass mir hier noch etwas unterstellt wird.

[Artemis1121]

die gleiche fehlermeldung bekommen klaus und ich auf dem sheevaplug auch.

das teil ist ja leider nur ein testbuild.. und sobald das format oder die api ein wenig geändert/erweitert wird wars das...
und auf den qnaps ist das auch nicht lauffähig, da diese nicht über hardwarefloating point verfügen..

[DonBambus]

PUSH: Tut sich da noch was? Ich währe immernoch an sonem Ding für ein ARM basiertes Qnap NAS interessiert. ( in meinem Fall: TS-110 )

[MCMUPPET]

Ahoi!

Kein Spam
Das Erstellen von so genannten Spamming-Beiträgen ist nicht erwünscht. Folgende Verstöße hiergegen werden geahndet:

* Pushen von Threads

Bei Verstoß werden die entsprechenden Texte editiert/gelöscht und/oder eine Verwarnung gegen den User ausgesprochen. Eine Ausnahme besteht für den Off-Topic, dort darf im gesitteten Rahmen gespammt werden. Bitte beachten. Danke!

Das hier Interesse an diesem Dekoder besteht, ist überhaupt keine Frage. Nur durch das Pushen wird es nicht schneller, wenn überhaupt, zu einer Bereitstellung kommen.

mfg mcmuppet

[Artemis1121]

aber ne info ob sich da noch was tut, ob es auf eis liegt oder ob vieleicht doch jemand im hintergrund arbeitet den man vielleicht unterstützen könnte wäre schön!

[danzbox]

Ist das so ein großer Entwicklungsaufwand für OTR den Code für die verschiedenen ARM Prozessoren anzupassen, dass sich hier seit Monaten nix tut?

[SGE]

Ist das so ein großer Entwicklungsaufwand für OTR den Code für die verschiedenen ARM Prozessoren anzupassen, dass sich hier seit Monaten nix tut?


Hat OTR denn noch einen Entwickler? Der Letzte, der sich hier noch gekümmert hat, ist doch anscheinend von Bord...........................................

[worfroz]

Nach einem Hinweis per PN von spamkiller habe ich die Frage nochmals an die Admins weitergegeben.

[DonBambus]

Und? Hat sich schon etwas getan? Ist der Decoder in Planung?

[spamkiller]

:thinking: Ich vermute, OTR sind die Programmierer ausgegangen. Nur schade, dass nicht wenigstens ein anderer Offizieller mal sagt, was los ist.

[nivekznews]

Gibt es immer noch keine Antwort?

[spamkiller]

Nein. :-|

[Artemis1121]

Nach einem Hinweis per PN von spamkiller habe ich die Frage nochmals an die Admins weitergegeben.

könntest du noch einmal nachhaken? ist ja fast wieder nen monat rum. :)

[spamkiller]

Öhm, kann nach 15 Tagen bitte wieder einer nachhaken?
Hört eh keiner mehr zu...

[Artemis1121]

ja, leider...

[PeterRies]

schade, habe gerade angefangen mich für das Thema zu interessieren. Habe noch so eine alte ASUS WLHDD rumstehen (so was wie eine NSLU) und wollte mir jetzt mal was bauen, was das runterladen etc. automatisiert.

Dabei bin ich auch auf die Sheeva gestossen. Vor allem wegen der 5-8Watt.

Aber wie ich das verstanden habe geht der decoder nun doch nicht???

[Artemis1121]

der letzte testdecoder läuft aktuell auf dem sheevaplug.. aber sobald mal wieder was geändert wird, wirds das dann gewesen sein.

./otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148/otrdecoder -h
Decoder for otrkey files.
Usage: ./otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148/otrdecoder [global options] [-i FILE|URL [input options]] ...

global options:
-h prints this screen
-v prints version
-e EMAIL use EMAIL to fetch the key directly from otr
-p PASSWORD use PASSWORD to fetch the key directly from otr
-b BUFFERSIZE use BUFFERSIZE*blocksize as size for the IO buffer.
0 disables IO buffering. (default: 1024)
-o DIRECTORY use DIRECTORY as default output directory (default: .)
-q don't verify input file before processing.
If this is turned off, it is possible to decode partially
downloaded otrkeys in the new format
-f force overwriting of output file
-U enable user interaction

input options:
-i FILE use FILE as input file
-o DIRECTORY use DIRECTORY as output directory (default: .)