Dotaz: Qemu oscam a prístup na /dev...

[rudo]

Páni potrebujem rozbehať mipsel oscam na PC Linux(latest ubuntu) stroji. Malo by to ísť cez Qemu, no nie je mi jasné ako. Podarilo sa mi spustiť cez qemu-mipsel binarku oscamu, ale problém je prístup na externú čítačku /dev/ttyUSB. Nie je mi celkom jasné, čo všetko a ako treba emulovať.

Odpovědi

[Jendа]

A jakou chybu to hlásí? Případně dodej strace (hm, asi chceš MIPSové i strace emulátoru a porovnat)

[rudo]

Podotýkam, že nespúšťam nič iné, len

sudo qemu-mipsel -L ./ oscam -c config/

po zapnutí čítačky

qemu: uncaught target signal 8 (Floating point exception) - core dumped

[Jendа]

Tak tohle bude na gdb a zjistit co se tam děje. Bez zdrojáků se to bude dělat dost blbě.

[rudo]

Ja len, či nie je potrebné spustiť ešte niečo iné. Niečo ako qemu-system-mipsel, kde by sa nejakým spôsobom tie /dev naportovali.

[rudo]

Zatial som sa nikde nedopátral, či je možné takýmto spôsobom(bez použitia VM-virtual machine) pristupovať na /dev/tty*.

[rudo]

Tak sa mi medzičasom ako som sa pustil do inšt. VM(qemu-system-mipsel) podarilo spustiť qemu-mipsel. Padalo to na nastavení frekvencií čítačky, a chytilo sa to na takpovediac default nastavení (3,57MHz). A šlape to, až na zlú odozvu, ale to je už druhoradé.

[rudo]

Ešte k tej odozve, je to divné a neviem ako tomu pomôcť. Bežne odpovedá oscam nejak takto:

2018/06/04 16:13:03 7F46A228 c (ecm) test (0D96&000004//1B80/80:D74FE2087CD9B1062885C572146AE866): found (103 ms) by reader

a hodnota ms sa nemení (+-5ms).

ale cez qemu:

2018/06/04 16:13:04 2A32B5D9 c (ecm) vdr (0624&/0000/1F41/64:05663FAA603219AB58C43F5BC450465A): found (3090 ms) by newcamd_vdr - CT 1 HD

je to prevažne cca 3000ms, pričom ale napr.:

2018/06/04 16:15:14 2A32B5D9 c      (ecm) vdr (0624&/0000/1F41/64:9031E3A402662E9669F2B91419028BA6): found (3138 ms) by newcamd_vdr - CT 1 HD
2018/06/04 16:15:14 2A32B5D9 c      (ecm) vdr (0624&/0000/1F42/61:BC39544934DEDDEF6D80B19E887E3C42): found (3115 ms) by newcamd_vdr - CT 2 HD
2018/06/04 16:15:23 2A32B5D9 c      (ecm) vdr (0624&/0000/1F41/64:9031E3A402662E9681DB3995AEB38EEF): found (2461 ms) by newcamd_vdr - CT 1 HD
2018/06/04 16:15:23 2A32B5D9 c      (ecm) vdr (0624&/0000/1F42/61:BC39544934DEDDEF99184EFF7A8C3238): found (2454 ms) by newcamd_vdr - CT 2 HD
2018/06/04 16:15:31 2A32B5D9 c      (ecm) vdr (0624&/0000/1F41/64:6154E59A596735F581DB3995AEB38EEF): found (329 ms) by newcamd_vdr - CT 1 HD

sa vie dostať aj hlboko pod 1000ms.

a pritom emm ins. sa zapisuju normalne:

2018/06/04 16:23:35 71946BF7 r   (reader) citacka2_next [irdeto] acamd emmtype=global, len=36 (hex: 0x24), cnt=0: written (84 ms)
2018/06/04 16:23:35 71946BF7 r   (reader) citacka2_next [irdeto] acamd emmtype=global, len=36 (hex: 0x24), cnt=0: written (74 ms)
2018/06/04 16:23:36 71946BF7 r   (reader) citacka2_next [irdeto] acamd emmtype=global, len=37 (hex: 0x25), cnt=0: written (98 ms)
2018/06/04 16:23:36 71946BF7 r   (reader) citacka2_next [irdeto] acamd emmtype=global, len=37 (hex: 0x25), cnt=0: written (100 ms)

Kde by to mohlo "drhnúť"?

[Luboš Doležel (Doli)]

OSCAM je open source, proč spouštíte nějakou pofidérní binárku z netu?

[rudo]

Tá binárka nie je ničim pofidérna - je to svn oscam s pridanou podporou pre čítanie istého typu kariet. A pre mňa osobne je to veľmi zajímavý objav - spúšťať jeden typ binárneho súboru na rôznych platformách. Teraz mi to beží tak na PCLinux, ako aj na ARM(OrangePi). Myslím, že by sa takto dali spúšťať aj iné emulátori - napr. cccam na ARM_och. Problém nebude ani tak v čítačkach, skôr v DVB_API.

Ešte k tej odozve - skúšal som rôzne binárky, napr. oscam_atv, ktorý používa jednu knižnicu inú(libcrypto.so.1.0.0) a časy odpovedí sa líšia. Takisto som testoval kartu v móde irdeto aj cryptoworks, a tiež je tam rozdiel (pri irdete dochádza k tzv. postdecryptu). V každom prípade to sem tam vyskočí na tých 3000ms

napr. oscam_atv a karta v crw mode:

    2018/06/05 08:35:01 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:7FA94465D95D452FBF499E5B05B46F1A): found (395 ms) by citacka2_next
    2018/06/05 08:35:01 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:745B187810B321ABA42CF7E965F70880): found (194 ms) by citacka2_next
    2018/06/05 08:35:11 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:7EC71F0A3BF7A9C64EDD4AA875BD356E): found (413 ms) by citacka2_next
    2018/06/05 08:35:11 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:FBB00D9AC7F25C32A801A59D5762C8AB): found (407 ms) by citacka2_next
    2018/06/05 08:35:21 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:F3263276CEF9CC1807E673EC679F944B): found (247 ms) by citacka2_next
    2018/06/05 08:35:24 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:47E9FA4E9BD9B0A1069861658F51EFB6): found (3139 ms) by citacka2_next
    2018/06/05 08:35:31 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:C82F3CE34CCB09B202D5F8635A102B0E): found (256 ms) by citacka2_next
    2018/06/05 08:35:31 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:3FDE59AB84BDFEE5419FB55542733D65): found (238 ms) by citacka2_next
    2018/06/05 08:35:41 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:0BD762B8DD92C22F466C8EAD1552110E): found (284 ms) by citacka2_next
    2018/06/05 08:35:41 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:5228DDD4B4AAF417CE61AED910176A08): found (205 ms) by citacka2_next
    2018/06/05 08:35:51 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:A072954AAEFAAE78E5CA7470C13F368F): found (583 ms) by citacka2_next
    2018/06/05 08:35:52 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:785186C03BC3A7C77383945EB85529BC): found (927 ms) by citacka2_next
    2018/06/05 08:36:01 143D54CF c      (ecm) acamd (0D96@000004/0000/1F41/80:94D7E65D40F0D2457FAA4D92459DD56E): found (222 ms) by citacka2_next
    2018/06/05 08:36:01 143D54CF c      (ecm) acamd (0D96@000004/0000/1F42/80:C83C53D2B345ECB72385826DAD86FCBD): found (643 ms) by citacka2_next

Mal by existovať niečo ako akcelerátor qemu(KQEMU), no zdá sa, že už nie je podporovaný. Nemá s tým niekto skúsenosť?

[Peter Golis]

Samotná emulácia je pribižne 20x pomalšia ako hostiteľove CPU, v pr8pade niektorých špecifických typov inštrukcií to môže kolísať. Ty si mal výsledné odozvy 1:30, ako keby si používal NEON alebo inú špecifickú inštrukčnú sadu.

Akcelerátor kqemu nebol na emuláciu, ale bol na virtualizáciu. Teda, keď si chcel spúšťať x86/64 VM na x86/64 hostiteľovi, alebo PPC64 VM na PPC64 hostiteľovi. V prípade emulácie ARM na x86/64 ti nepomôže ani keby si sa rozkrájal keďže nštrukcie pre ARM niesú v CPU x86/64.

PS: Ak to chceš na ARMe, tak si to pichni do RPi. Ušetríš si dosť nervov, a elektriky.

[rudo]

Práveže na ARM_e(teda mipsel verzia) mi to už fachčí. Trochu by tomu pomohlo pretaktovanie karty, no asi veľmi nie. A na inej frekvencii ako 3,57MHz to nechce vôbec behať.

Podarilo sa mi lokálne rozbehať DVB_API (dvb-s2 karta). Ale len cez TCP/IP socket - minisatip. Cez univerzálnejší camd.socket mi to hádže chybu:

13:59:59 1E3A5370 c   (dvbapi) Demuxer 2 trying to descramble PID 0 CAID 0624 PROVID 000000 ECMPID 0474 ANY CHID PMTPID 0000 VPID 0000
13:59:59 1E3A5370 c   (dvbapi) ERROR: Can't open device /dev/dvb/adapter2/demux2 (errno=2 No such file or directory)
Unsupported ioctl: cmd=0x803c6f2b
13:59:59 1E3A5370 c   (dvbapi) ERROR: Could not start demux filter (api: 0 errno=89 Function not implemented)

Čo je ale pre mňa trochu mätúce je toto:

2018/06/05 14:10:19 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:436F41821E6CCF1468A94684ACB72638): found (138 ms) by citacka2_next
2018/06/05 14:10:20 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:CF2F0DEABAF73789CBE13C1ECFA45D33): found (135 ms) by citacka2_next
2018/06/05 14:10:23 506E2B3D c      (ecm) acamd (0624@000000/0000/1F41/64:BAFFB08BBD088CF1C74EB173DC1AD9DF): found (3004 ms) by citacka2_next
2018/06/05 14:10:30 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:3C96722805ECFD478CEBFEE199D5DAB9): found (149 ms) by citacka2_next
2018/06/05 14:10:33 506E2B3D c      (ecm) acamd (0624@000000/0000/1F41/64:AC9E14A3BEE8EEA470A28B87D8275489): found (3005 ms) by citacka2_next
2018/06/05 14:10:40 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:81F58C9E3182F9BBD096AF866B33712A): found (210 ms) by citacka2_next
2018/06/05 14:10:41 506E2B3D c      (ecm) acamd (0624@000000/0000/1F41/64:EB1C4A587F1E03D270FC6C03A7CEB817): found (1134 ms) by citacka2_next
2018/06/05 14:10:50 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:DBA2E1160D9E2347AF804FCEE52AB295): found (141 ms) by citacka2_next
2018/06/05 14:10:51 506E2B3D c      (ecm) acamd (0624@000000/0000/1F41/64:D2D26B47D83D7E3A4DD089DC98CB75E6): found (1155 ms) by citacka2_next
2018/06/05 14:11:00 12061BDF c      (ecm) local (0624@000000/0000/1F44/61:E74A33E67C7F156A680AD62FB0E1446A): found (147 ms) by citacka2_next
2018/06/05 14:11:02 506E2B3D c      (ecm) acamd (0624@000000/0000/1F41/64:1F53EA4CE2355A0A8853F86A1FA5496C): found (1564 ms) by citacka2_next

Zatialčo lokálne cez DVB_API klienta(local) sú časy ok (a bez "kolísania"), remote klient(acamd) cez newcamd protokol má takú odozvu o akej som písal vyššie. A to aj napr. cez cs378x(camd35), ktorý nepoužíva žiadne šifrovanie(aspom si myslím). Inak by som predpokladal, že tá vyššia odozva je spôsobená práve tou protokolárnou réžiou.

[Peter Golis]

ARM a MIPS sú rozdielne architektúry.

[rudo]

Tak to som nepochopil. A ako čo? Asi si nepobral o čo ide.

Stále mi hlava neberie to správanie sa čítačky. Lokálne na ecm odpovedá správne, na emm odpovedá (lokálne aj remote) správne, ale remote ecm dotaz je neviem prečo delay. Doterajšie chápanie a písanie o protokolárnej réžii bolo asi nesprávne, táto by sa mohla skôr preukázať na klientovi.???

[rudo]

Pravdepodobnou príčinou popisovaného správania sa je asi redundancia pri komunikácií remote_klient<->server(pri akomkoľvek protokole):

2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.
2018/06/05 19:53:53 00000000      (cache) {client acamd, caid 0624, srvid 1F41} [check_cache] cyclecheck passed ecm in INT. cache.

No na to, ako sa toho zbaviť, som zatial neprišiel. Pre usera síce existuje prepínač "Disable Cycle Check", no asi tam je len na okrasu. Možno bude potrebné zabŕdnuť do zdrojákov.

[Peter Golis]

ARM_e(teda mipsel armel verzia) ak si myslel ARM endianless.

[marian34]

Aha, myslel som že na ARM_e(orangePi) beží cez qemu mipsel verzia oscamu.

[Peter Golis]

Ak Ti na ARMe beží v qemu binárka mipsel, tak to máš emulované (cca 20x pomalšie) a kqemu ti je naprt.

[rudo]

Kqemu už neriešim, riešim prečo pri komunikácií server-remote_klient dochádza k tomu oneskoreniu(pričom z logov je zrejmé, že karta odpovedá normálne (1xxms)). Nemyslím si, že je to o tom "20x pomalšie" - to by sa prejavilo aj pri komunikácií server-lokal_klient.

Dochádza tam k nejakej anomálií - možno cachovaním ecm - ale to už je skôr otázka pre tvorcov oscamu, sám to asi nedám.

[Jendа]

strace, gdb, perf

[Peter Golis]

svn, patch, make, pcsc-lite

[rudo]

jebal, pes, kočku...