Dezbatere OSCAM oldpost.

[r2005rom]

@cipryDXfeed nu am creat nici un user , cum am dat configurarile mai sus asa sunt si la mine:

oscam.user

[account]
user = A
pwd = B
group = 1
uniq = 2
au = focussat
caid = 0B02
ident = 0B02:000000
keepalive = 1

si acesta se conecteaza doar un singur receiver atat , daca il mai bag si pe al doilea , al treilea nu mi da cheile...

@lao , cum as putea sa fac asta ?

multumesc frumos.

[cipryDXfeed]

pai simplu dai copy/paste la account si schimbi user si parola si pui in receiverul care zici ca nu merge.

[r2005rom]

cipryDXfeed , lao , multumesc frumos , am rezolvat , greetings.

[bumbu]

Salut, dupa cum se vede, merge si mai bine cardul freesat, pe oscam svn 9021:

16/11/2013 20:36:16 8B93CB8 c misu (0500&025900/08E2/0005/2F:98AE6168360CB78B3C8C12B50CEE7D0B): found (66 ms) by Freesat - Pro TV

Numai bine

[zildan]

S-a implementat blueven cache HT patch incepand cu versiunea 9093 !
Detalii :

Hi people!
Finally, after 3 months we got a stable HT implementation!
This patch make changes mainly over cache handler, but also add other usefull stuff in oscam.

These are overall changes:

- Cache is now stored in Hash Table! Cpu load dropped!
The "TommyDS" library (http://tommyds.sourceforge.net/) is used for hash tables implementation.
It implments a chained linear hash table, called "tommy_hashlin".
Anyway, it should be tested on different systems.

- Cache is stored in HT using only csp_hash. To match ecm with cws, we use only csp_hash without check on caid/prid/srvid!

- Now, cheking cw in cache is done each 10ms. So, answer from cache could happen at any time, if ecm not answered yet.
By default, each different cw (max 10) for same hash is stored in cache, and only cw with highest counter (that is, most received cw) is served at checking cache.
This help avoid fake cws. Obviously, we should have more than one cacheex peer to let counters increase.
It will works only with cacheex cws, cw from normal reader have priority and are considered good!
To force a specific counter, we can handle it with these new parameters in cache section:
- "check_cw_count" : set minimum cw counter to allow cw is used.
Default=1, use default behaviour: use cw with highest counter when cache is checked.
e.g. check_cw_count=2 -> use cw only if its counter is equal 2 (That is, 2 same cw received)
- "check_cw_count_mode" : specify behaviour for "check_cw_count".
Possible values:
0: when wait_time expires, serve highest counter's cw got anyway, even if no check_cw_count reached.
1: never serve cw (coming from cacheex) stored in cache if its counter not reaches check_cw_count. When wait_time expires, requests will go to normal readers! Only when a cw reaches check_cw_count, it can be served to clients.
Default 0.

- Each different cw is now pushed to cacheex peers only ONE time! No more risk same cw is pushed twice for same client!
Anyway this depends on max_time parameter, because if a cw arrives after its ecm hash is freed from cache, we lost pushing out informations for clients. So, you should set max_time as cw life at least to be sure this works properly.

- CAMD35 and CS378X:
- add keepalive stuff (handled only by reader).
Parameter: "keepalive", 1 to enable it, 0 disabled (default).
When keepalive is used, reconnetiontimeout is set to 60s, because it cannot be checked before keepalive exchange (each 30s).
On server side, the clientmaxidle parameter > 30-40s should be used (deafult is 120s, so can you leave default value). If not, client will close connection and reader will reopen it each 30s.
- fix a bug (existing in svn) reading packets.
- Revisited all packets exchange in cacheex mode 2 and 3.

Compatibility with svn oscam is ok.
But, to let keepalive stuff works properly, both oscam client and server have to run this patch.

- Added in cache and in cacheex protocols(camd35 and cccam) odd/even byte info.
As bowman told me, this will let CSP able to fix problem in 0963, because now oscam send odd/even byte to it.
In fact, in CSP, it's required all cws sent trough UDP port oscam->CSP have this byte set. If not, CSP cannot detect correct cw part to swapp.
So, if you send cache (from cacheex) to CSP, make sure you and all your peers (and peers of yours peers...) run this version, to correctly send 0963 cache to CSP.
Anyway this require a new CSP plugin, that use this new byte for correctly swap cws. Ask to CSP developers fot it.
Atm, commit at #9036 is keeping here, until this patch will be spreaded. After, it could be removed without problems, because now CW swapp for cache is done in cache handler itself, using odd/even byte.

- Fix cacheex mode 2 for camd35.
REAL problem of mode 2 was that without CONNECTED status, clients would not push cws, because starting connection is done by reader and (if cacheex_allow_request=0) it does not send nothing (ecm requests) for initializing connection.
This is reason mode 2 camd35 readers are NOT WORKING CORRECT in svn atm. They receive nothing if NOT connected.
With cccam this is not a problem, because it connects at startup and have keepalive stuff.
For this reason i add "keepalive" parameter in reader section to work with camd35(tcp and udp) readers. It will connect reader at startup and will take connection alive. It works for all camd35(tcp and udp) readers, cacheex and "normal".
Keepalive stuff is mandatory for cacheex mode 2 readers. ("keepalive=1" for camd35, and "ccckeepalive=1" for cccam)
For cacheex (mode 2/3) camd35 (tcp and udp) readers, it is now enabled by default.
Camd35 keepalive send msg and check connection each 30s, and if network failure, it will re-conenct reader.
When used on a cacheex mode 2/3 readers, it will send its nodeid as keepalive msg. So nodeid is updated each 30s. No more request/answer keepalive msgs each 256 cws pushed as svn.
This decrease network traffic and make communication more cleaned.
On server side, the clientmaxidle parameter > 30-40s should be used (deafult is 120s, so can you leave default value). If not, client will close connection and reader will reopen it each 30s.

- To filter incoming and outgoing cache, now we use caid, ident and services parameters.
"cacheex_ecm_filter" is leaved for compatibility with svn oscam. But we can use caid/ident/services now.
Take attention, filters on prid will be ignored for cache coming from csp, because csp cache not send prid information (prid=0 always).

- Added check on block_same_name and block_same_ip to avoid cacheex loopback in cacheex mode 1.

- Added new parameter "no_wait_time" in user section. E.g. If we would a client that ask real readers without wait for cache, we could use this parameter.
This could be also usefull e.g. for cacheex mode 2 client when cacheex_allow_request=1. If client receive ecm request (when cacheex_allow_request=1), it should not wait because no cw was pushed to it and it would search for real readers. But obviously, thid depends from configuration.
Possible values:
0: use wait_time set in cache config
1: no use wait_time
Default 0.


- Added config parameter "reconnectdelay" for max tcp connection block delay, in milliseconds (reader section). Default 60000 ms (1min, as always been in svn)

- check in cache for "oscam.cacheex" file for mode1 readers removed. Miss documentation about it and maybe no one use that file.

- Fix always accept prid=000000 for services. It has to be explicity set.

- added column to show number of requests per minute in webif user page.

- move reader table pending to max 4096. So now you can set -p4096 when start oscam.

- In webif, if one of stats overflow (become negative), reset all stats automatically.

- Try fix some random crashes found in svn too.

- This patch revert CWC Check changes in svn #9037, #9059, #9061, #9062: code changes are not compatible with this new code. New re-code is nedeed.

- ATM, this patch revert changes in svn #9066, #9067, #9070, #9071: See my posts here: http://www.streamboard.tv/wbb2/threa...threadid=39787.


Most of the new parameters are not in the webif (yet), it will be added later by me or by some voluntary Zunge raus


Considerations:
Initially i thinked to remove cacheex mode 3, because now mode 2 works great. But, for compatibility with svn oscam, i leave it in code.
My advise: use cs378x protocol and cacheex mode 2! It is more clean and light. Now cacheex works very well with it!
With this patch, you will see your cache size grown than svn, be quite that all is normal because now oscam process MORE cws per second and cws are taken more time in cache, because free happens at (last cw got time+max_time), while before was (first cw got time+max_time).
Also, you can see now cw diff increases more, it is normal because now each new cw is compared with the heighest "counted" cw, that can be change at each cw arrived.

Special thanks goes to Capncook, support me in development ideas and tests. A lot of nights without sleep! smile
Also thanks to Gorgone, Mo0211 and mumbua, helped me a lot with tests.

Sursa

[ovidiumarius]

Singura problema e ca de vreo 3 zile de cand s-a implementat noul patch in trunk "desteptii", care habar n-au sa isi compileze sau sa configureze un oscam, baga in continuu strambe iar blueven s-a cam saturat ... asa ca s-ar putea sa nu continue munca buna ce a inceputo cu acest patch pentru cacheex.
Oricum de cand l-a implementat si pana in momentul de fata oscam-ul merge excelent cu acest nou patch.

[puidezmeu]

HT a fost implementat incepand cu 9021(pentru teste in versiuni private).
Si tot zmeul asta are patch-urile pt 9cd HD si Dolce care vad ca nu prea vrea sa le faca publice.
E bine ca a facut public HT-ul .si nu e doar pt cache.....

[ovidiumarius]

Nu e doar pentru cache dar e in special facut pentru a scade incarcarea CPU, incarcare ce apare de obicei la oscam-urile ce ruleaza si cacheex.

[zildan]

- Cache is stored in HT using only csp_hash. To match ecm with cws, we use only csp_hash without check on caid/prid/srvid!

Practic nu se mai ia dupa caid/prid/srvid, se cauta doar hash. ia vedeti daca nu cumva avand un canal luminat de pe un TP, pe schema asta faci lumina pe tot TP-ul?
In acest moment oscamul e cu ani de zile in fata cccam la sharing.
Se sapa intens si la bugurile din DVB-api.

[puidezmeu]

Hehe,nu faci lumia pe tot tp-ul,
Si partea cu hash e valabila la cache,in rest tot dupa cele 3(CID,PID,SID) se ia.Cum spune si Ovi mai sus ,marele avantaj e low cpu usage la oscame care folosesc mult cache-ex.
Si cei care au asa ceva pot baga si patch-ul de cwc cycle pe cache-ex care se gaseste tot la ei pe forum..altfel degeaba ai cache size 180mii daca ai si mortaciuni prin el(face freeze)

[piccolo08]

Nu e doar pentru cache dar e in special facut pentru a scade incarcarea CPU, incarcare ce apare de obicei la oscam-urile ce ruleaza si cacheex.

Exact si punctat corect.
Mai e si problema cu schimbarea frecventei de citire la card functie de attr unde pe multi "sharisti de dumineca" i-a lasat in ceata totala.
Au revenit la versiuni vechi,pentru ca "merg mai bine", au legat iar magareata de 3C si au facut un raha* mare si frumos.

[michael86]

... asa de duminica . daca aveti dureri de cap cu noile versiuni setati freq de citire a cardului cu diferitele cititoare pe care le aveti .
nu am fost curios decat pentru cardul ''national'' 1802 folosit cu versiunea de PPC a oscamului si configul este urmatorul (singura modificare in oscam.server ) :

[reader]
label = card
detect = cd
protocol = internal
device = /dev/sci0
services =digi_tv_popular,digi_tv_baza,digi_tv_maxpak,digi_tv_digifilm,digi_tv_extra_i,digi_tv_extra_ii
boxkey = xxxxxxxxxxxxxxxxxxx
rsakey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mhz =525
cardmhz = 3150
caid =1802
ident = 1802:000000,002011,002111
group = 1
emmcache = 1,3,2

2013/12/29 15:51:45 10108EF8 r card [internal] Reader initialized (device=/dev/sci0, detect=cd, pll max=31.50 MHz, wanted mhz=5.25 MHz
2013/12/29 15:51:46 10108EF8 r card [internal] card detected
2013/12/29 15:51:47 10108EF8 r card [internal] ATR: 3F FF .......................................
2013/12/29 15:51:47 10108EF8 r card [internal] Init card protocol T1, FI=9, F=512, D=16, N=255
2013/12/29 15:51:47 10108EF8 r card [internal] TEST tempo mhz check = 500 mhz
2013/12/29 15:51:47 10108EF8 r card [internal] Calculated work ETU is 6.10 us reader mhz = 525
2013/12/29 15:51:47 10108EF8 r card [internal] PLL Reader: ATR Fsmax is 5 MHz, clocking card to 5.25 Mhz (nearest possible mhz specified reader->cardmhz)
2013/12/29 15:51:47 10108EF8 r card [internal] Card responded ok for ifsd request of 251
2013/12/29 15:51:48 10108EF8 r card [internal] detect native nagra card
2013/12/29 15:51:48 10108EF8 r card [internal] found card system nagra

din interfata web a oscam :

Detect:
MHz:	desired clockspeed or auto if autospeedbox is checked(auto only applies to smargo or dreambox yet)
Autospeed:	Sets mhz according to atr for smargo readers and dreambox internal readers. Default is checked
Card MHz:	Dreambox Mipsel: 2700, PPC: 3150, DM7025: 8300 ELSE set wanted cardinit speed. Default 357

[piccolo08]

Explicati-le de 1000 de ori sau puneti o regula fundamentala a configurarii OSCAM si anume folosirea web-if-ului la configurarea oscam si nu copy/paste de prin te miri ce miriste.A zis-o pe aici ovidiumarius de nustiu cate zeci de ori.
Cum vreti voi.
Romanul nu mai studiaza deloc, copie tot precum chinezii.Prostiile scrise de altii prin configuri datand de 2-3 ani genereaza tot felul de warning-uri pe versiunile noi tocmai din aceasta cauza.
Am amici, mai vechi prin forumuri care si ei se chinuie sa contribuie la pasiunea noastra cu niste "carti", numai ca...noile versiuni i-au cam dat peste cap.
Cine foloseste oscam doar sa citeasca cardul si sa-l dea mai departe in porcaria numita cccam pot folosi si versiuni mai vechi.
In plus configureaza in continuare aiurea schimbul de cache-ex.
PS:
Nu am gasit unul care sa configureze corect.
Cine a raspandit tutorilale in privat pe la prieteni ar fi bine sa le actualizeze.
Mi-e sila sa vad un carnat de grupuri.
Loopback-ul a fost depasit de mult.
Na, e mai usor sa faci copy-paste decat sa iti pui capul la treaba.

[zildan]

Aici dezbatem ! nu ne batem!

[laleauaneagra]

@picolo eu am impresia ca de multe ori nu prea sti ce vorbesti si te agiti mereu,datorita faptului ca iti permiti sa ma jignesti neintrebat si nechemat la o discutie cu mine pe alte forumuri si datorita faptului ca ai un precedent si pe acest forum de vreo 10 pagini in care nu ai postat macar o setare minune a oscamului si trimiti mereu la wiki imi permit si eu sa fac acelasi lucru si sa te intreb si eu ceva,nu intru in detalii de cache si cum il genereza oscam si de unde,cat e de valabil si cat te ajuta(asta in cazul userilor seriosi)
1.schimbu de linii pe care il faci tu il ai prin protocolu RAHATULUI asta de cccam da?ce te ai face tu cu oscam daca nu ar exista RAHATU asta de protocol cccam?
2.ti ai fura parteneri prin protocol camd si newcamd?si ar fi doar un bun cititor de carti?

cand exista acest RAHAT cccam exista un share curat sa nu mai amintesc de gbox,pe urma un bou a lansat minunea cu N si usor au inceput smecheri sa iasa la iveala,insa acesta smecheria se putea combate usor...si cam atat era in RAHATU asta de cccam smecherie

pe urma au iesit pe piata tot felu de emulatoare,oscam,multics etc care au scos la iveala parsivi si hoti in share care fura si modifica liniile altora dupa placu lor si genereaza cache banuiesc ca fara acordul partenerilor.....banuiesc ca nu e nevoie sa vorbim despre cache cardului personal ca nu are rost

tu nu poti impune nimanui ce emu sa folosesca,fiecare foloseste si isi configureaza oscamu cum stie,personal sau prin copy/paste..unii dintre voi distrugeti share cu smecheri de care vorbim,altii il distrug prin configurare insa asta e rezultatu aruncari pe piata a acestor emulatoare minune,cand ne gandim ca scopul oscam era altu

asa ca dragi mei daca nu ar fi protocolu RAHATULUI cccam oscam ar fi 0 si voi nu ati avea schimb de linii.....decat CACHE(furat de la altii,binenteles)

ca incheiere si eu folosesc oscam total,cititor de card,server si client.......dar imi vad de treaba mea si culmea folosesc protocolu RAHATULUI de ccam fara de care as folosi oscam ca cititor de card

o zi buna