71_LISTENLIVE mit LL Firmware 1.5x

[betateilchen]

(http://up.picr.de/17025894rk.jpg)

Da offenbar ein paar ganz grundsätzliche Änderungen in der neuen Firmware 1.5 vorgenommen wurde, und damit die Modulentwicklung künftig leichter hier im Bereich gefunden werden kann, dieser neue Thread.

Erste Feststellung nach dem Firmwareupgrade: Es gibt offenbar keinen http Port mehr

Code Auswählen Erweitern


# nmap -sT -p 1-65535 192.168.123.228

Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-12 00:28 CET
Nmap scan report for 192.168.123.228
Host is up (0.035s latency).
Not shown: 65533 closed ports
PORT    STATE SERVICE
23/tcp  open  telnet
111/tcp open  rpcbind
MAC Address: 00:0A:EB:AA:EE:26 (Shenzhen Tp-Link Technology Co;)

Nmap done: 1 IP address (1 host up) scanned in 44.47 seconds


Auf UDP siehts nicht besser aus.

Naja, immerhin telnet, also mal schauen, was es da zu sehen gibt...

Code Auswählen Erweitern


# ps
  PID  Uid        VSZ Stat Command
    1 root       4176 S   init       
    2 root            SW< [kthreadd]
    3 root            SW< [ksoftirqd/0]
    4 root            RW< [events/0]
    5 root            SW< [khelper]
   32 root            SW< [kblockd/0]
   40 root            SW< [kseriod]
   44 root            SW< [kmmcd]
   66 root            SW  [pdflush]
   67 root            SW  [pdflush]
   68 root            SW< [kswapd0]
   69 root            SW< [aio/0]
   70 root            SW< [cifsoplockd]
   71 root            SW< [cifsdnotifyd]
  149 root            SW< [udc_workqueue]
  171 root            SW< [wpen_workqueue/]
  193 root            SW< [fm_rda580x_work]
  207 root            SW< [mmcqd]
  242 root       3288 S < /sbin/udevd --daemon
  279 root       4176 R   /sbin/telnetd
  282 1          2588 S   /sbin/portmap
  297 root            DW< [SDIO Helper]
  301 root            DW< [SDIO IrqHelper]
  314 root      35928 S   ./jz-media-app
  315 root       4240 S   -sh
  350 root      35928 S   ./jz-media-app
  369 root      35928 S   ./jz-media-app
  370 root      35928 S   ./jz-media-app
  375 root       2188 S   ./wpa_supplicant -i eth0 -D wext -c /mnt/mtdblock7/w.conf -B
  558 root       4240 S   udhcpc -i eth0 -h iRadioAAEE26 -p /etc/upi
  610 root       4240 S   -sh
  616 root       4240 R   ps
#


[betateilchen]

Ein paar Experimente weiter...

Also ein paar der "alten" HTML Befehle scheinen doch noch zu funktionieren. Ich kann z.B. mit POWER das Gerät ausschalten. Aber das Einschalten mit dem gleichen Befehl funktioniert nicht, da das Gerät wirklich AUS ist und nicht im Standby. Damit fällt dann auch die Netzwerkverbindung komplett aus.

Achja: Man sollte die Netzwerkfernsteuerung nicht vergessen einzuschalten - das war mein erster Fehler nach dem Firmwareupdate

Code Auswählen Erweitern


Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-12 02:12 CET
Invalid target host specification: 1-65535
Nmap scan report for 192.168.123.228
Host is up (0.0064s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE
23/tcp   open  telnet
111/tcp  open  rpcbind
8080/tcp open  http-proxy
MAC Address: 00:0A:EB:AA:EE:26 (Shenzhen Tp-Link Technology Co;)

Nmap done: 1 IP address (1 host up) scanned in 2.73 seconds


[betateilchen]

Es gibt ein paar neue Remote-Kommandos:

MENUINFO  > supposed to report info about the menu position
LISTINFO > supposed to report the display list data
METAINFO > supposed to report data displayed in the player (like track name etc)
MESSAGE xxxx > supposed to display xxx in a popup

VERSION will reply VER=xxxx  (string eg. 1.51, 1.52b, 1.52 ..)
VOLUME will reply VOL=99  (integer range 0-255, 0=muted)
POWERSTATE will reply STATE=NIGHT (nightstand mode) or STATE=ON  (normal operation)

Eigentlich sollten die ersten 4 Kommandos bereits in 1.51 verfügbar sein - aber funktionieren tun die bei mir nicht, es kommt immer nur ein OK zurück.
Die letzten 3 Kommandos werden in 1.52 implementiert.

[Rince]

Bin ja gespannt wie ein Flitzebogen, aber so nach großem Wurf sieht es noch nicht aus?

[betateilchen]

nö, nicht wirklich.

Ein Haufen Bugfixing, aber kaum was essentiell neues. Dafür neue Probleme.

[betateilchen]

very strange... im Moment scheinen die network-remote-commands komplett zerschossen zu sein.

(http://up.picr.de/17063751kp.jpg)

Code Auswählen Erweitern


C: => command
R: => answer
2014.01.15 19:14:09 3: C: LISTINFO R: Li
2014.01.15 19:14:42 3: C: METAINFO R:
2014.01.15 19:15:18 3: C: MENUINFO R: Me
2014.01.15 19:16:32 3: C: OK R: OK
2014.01.15 19:16:42 3: C: BLUBBER R: UN
2014.01.15 19:16:54 3: C: EXIT R: OK
2014.01.15 19:18:16 3: C: POWER R: OK
2014.01.15 19:18:58 3: C: POWER R: OK
2014.01.15 19:19:29 3: C: POWERSTATE R: ST
2014.01.15 19:20:53 3: C: MESSAGE R:
2014.01.15 19:21:39 3: C: VOLUME R:
2014.01.15 19:22:28 3: C: VERSION R:


[betateilchen]

Zumindest das Nachrichtenschicken funktioniert weitestgehend.

(http://up.picr.de/17064272ad.jpg)

Das heißt, mein Radiowecker kann mich ab sofort mit "Guten Morgen, draußen regnets!" begrüßen... 

[Rince]

Na, das ist doch schon mal was. Zumindest taugt es auf jeden Fall schon als Textdisplay

Ich drück dir die Daumen.

[betateilchen]

ich sag mal so: Seit das Messaging funktioniert, funktionieren sämtliche alten remote Kommandos nicht mehr...

Wenn die neuen Funktionen wirklich alle funktionieren würden, käme man schon ein ganzes Stück weiter. Obwohl z.B. auch die Bestätigung des Geräte auf ein remote-Kommando häufig ausbleibt - so ein richtig zuverlässiges "Protokoll" ist das bei weitem noch nicht.
Verstehen tu ich das Ganze nicht. Die Firmware beinhaltet einen kompletten Webserver (der im Normalfall aber inaktiv ist) und man könnte damit ein sehr viel stabileres http-Protokoll fahren als die krude Socket-Kommunikation, deren gesamtes Timing absolut hardwareabhängig ist. Ich habe hier zwei Xoro HMT350 mit zwei völlig unterschiedlichen Timing-Verhalten. Bei einem der beiden muss ich die "Pause" auf fast den 10-fachen Wert stellen um eine stabile Reaktion zu bekommen.

Ich hoffe, man kann William irgendwann davon überzeugen, an diesem Punkt nochmal grundsätzlich Hand anzulegen.

[Rince]

Ich kann William schlecht einschätzen.
Die Frage ist, warum wirft er den Code nicht auf github sondern hält ihn closed source?


Aber die Alternative wäre schlicht, ne eigene Toolchain zusammenzubauen und den ganzen Unsinn selber zu schreiben. Das ist wohl eher außerhalb der Reichweite

[betateilchen]

Aber die Alternative wäre schlicht, ne eigene Toolchain zusammenzubauen und den ganzen Unsinn selber zu schreiben.

Die toolchain ist ja gar nicht das Problem, die ist öffentlich verfügbar. Das Problem ist die Zeit.
Und warum William das nicht open-source macht? Ich könnte mir gut vorstellen, dass irgendwann sein gesamter Dienst nicht mehr kostenlos bleiben wird...

[Rince]

Stimme dir zu, diese Gedanken hatte ich auch mal.

[herrmannj]

Hallo Jungs,

Damit (also Reverse Engineering, toolchain, etc) hatte ich schonmal begonnen. Das geht auch, in einem poc konnte ich alle wesentlichen Teile ansprechen (Display Sound keys backlight). Die RTC war noch offen. Irgendwo hab ich auch noch Infos dazu rumliegen.

Das ist aber echt viel Arbeit wenn man die fw. komplett aufsetzen möchte. Da die Nachfolger der Radios jetzt schon mit Android verfügbar sind hatte ich beschlossen das Projekt mit der Listenlive Firmware nicht mehr weiter zu verfolgen sondern auf phonegap und die neuen zu setzen.

Ich denke das skaliert wesentlich besser, da kannst du mit angepassten floorplans draufgehen und das was man dafür entwickelt skaliert wieder für tablets etc. 

Vg
Jörg

[betateilchen]

ich hab aber nunmal zwei Xoros rumstehen 

[herrmannj]

Geht mir genauso (leider). Eins hat keine 30 Betriebsminuten...

Letztendlich muss das jeder für sich entscheiden. Wenn du das weitertreiben möchtest bin ich dir dankbar, wenn du Infos aus dem Reverse Engineering brauchst helfen ich gern.


Vg
Jörg