immerwieder freezer :-(

[skapi]

hallo leute!

ich hab das problem das bei meinen clientboxen immerwieder freezer auftreten und ich komm einfach nicht dahinter warum...
ich hab einen igel 3200 lx mit einem könig hub, 3 smargos (fw 1.5) mit hd+(01), sky s02 und orf ice. benutze oscam #5343 zum einlesen der karten und cccam 2.1.3 zum weitersharen. emm's sind aus und mach ich einmal im monat auf.

hier meine configs...

cccam.cfg

Spoiler

Show

F: XXX XXX 5 1 0 { 0:0:1 } { }



#ORF ICE
L: 127.0.0.1 20197 orf orf 0D95 00000 256


#HD01
N: 127.0.0.1 34100 cccamhdplus hdplus 01 02 03 04 05 06 07 08 09 10 11 12 13 14 256

#Sky
N: 127.0.0.1 34102 cccamsky sky 01 02 03 04 05 06 07 08 09 10 11 12 13 14 256






PROVIDERINFO FILE : /var/keys/CCcam.providers
CHANNELINFO FILE : /var/keys/CCcam.channelinfo



AUTOROLL FILE: /var/keys/AutoRoll.Key
SOFTKEY FILE: /var/keys/SoftCam.Key
STATIC CW FILE: /var/keys/constant.cw







SERVER LISTEN PORT : XXX

WEBINFO LISTEN PORT : XXX
WEBINFO USERNAME : XXX
WEBINFO PASSWORD : XXX








#Allgemeine Einstellungen
ALLOW TELNETINFO: no # Ansonsten ist PORT 16000 offen
MINIMUM DOWNHOPS: 1 # Nur Karten annehmen die weitergegeben koennen
DISABLE EMM : no # Ansonsten kommen keine Updates auf die Karten
EXTRA EMM LEVEL : no # EMM-Updates von HOP2 Clients werden angenommen
SHOW TIMING : yes # Antwortzeiten der Karten anzeigen

Oscam.conf

Spoiler

Show

[global]
serverip = 127.0.0.1
logfile = /var/log/ipc/OScam.log
clientmaxidle = 86400
nice = -1
maxlogsize = 2480
saveinithistory = 1

[monitor]
port = 0
nocrypt =
hideclient_to = 15
appendchaninfo = 0

[newcamd]
port = 34100@1830:003411,008011;34102@1702:000000,000001,000002,000003
serverip = 127.0.0.1
key = 0102030405060708091011121314
allowed = 0.0.0.0-255.255.255.255

[cs357x]
port = 20197

[webif]
httpport = XXX
httphelplang = de

httpuser = XXX
httppwd = XXX
httpallowed = 0.0.0.0-255.255.255.255

Oscam.server

Spoiler

Show

[reader]
label = orf
protocol = mouse
device = /dev/Reader1
services = orfcw
smargopatch = 1
caid = 0D95
detect = cd
mhz = 368
cardmhz = 357
group = 1
emmcache = 1,3,2


[reader]
label = hdplus
protocol = mouse
device = /dev/Reader2
services = hdplus
caid = 1830
rsakey = XXX
boxkey = XXX
detect = cd
mhz = 357
cardmhz = 368
ident = 1830:003411,008011
group = 2
emmcache = 1,3,2


[reader]
label = sky
protocol = mouse
device = /dev/Reader3
services = skyall
caid = 1702,1833
boxkey = 1122334455667788
detect = cd
mhz = 800
cardmhz = 600
ident = 1702:000000,000001,000002,000003;1833:000000
group = 3
emmcache = 1,3,2

Oscam.user

Spoiler

Show

[account]
user = orf
pwd = orf
group = 1
uniq = 3
au = orf
services = orfcw

[account]
user = cccamhdplus
pwd = hdplus
group = 2
hostname = localhost
monlevel = 1
au = hdplus
services = hdplus
caid = 1830
ident = 1830:003411,008011

[account]
user = cccamsky
pwd = sky
group = 3
hostname = localhost
monlevel = 1
au = sky
services = skyall
caid = 1702,1833
betatunnel = 1833.006A:1702,1833.006B:1702,1833.006F:1702,1833.0070:1702,1833.0071:1702,1833.0072:1702,1833.0075:1702,1833.0077:1702
ident = 1702:000000,000001,000002,000003;1833:000000
OScam.services

Oscam.services

Spoiler

Show

[skyall]
caid = 1702,1833
srvid = 0008,0009,000A,000B,000C,000D,000E,0010,0011,0012,0013,0014,0015,0016,0017,0018,0019,001A,001B,001C,001D,0021,0022,0023,0024,0025,0026,0027,0029,002A,002B,0032,0034,0035,0037,0038,0039,003A,003B,003C,003D,003E,003F,0040,0041,0042,0043,0044,0045,0046,0075,0077,0078,0079,007A,007B,007C,007D,007E,007F,0080,0081,0082,0083,0084,0096,0097,0098,0099,009A,009B,009C,00A8,00DD,00DE,00DF,00FB,00FC,00FD,00FE,0105,0106,0107,0108,010F,0110,0111,0119,011A,011B,0123,0124,0125,012D,012E,012F,0137,0138,0139,0141,0142,0143,014B,014C,014D,0156,0159,0160,0163,016B,016D,0175,0201,0203,0204,0206,07FF,2EFE,3331,4461,4462,6FF1,7001,7009,700A,0071,006A,006B,0072,0070,006F

[orfcw]
caid = 0D95
provid = 000000,000004,000010
srvid = 132F,1330,32C9,32CA,32CB,32CC,32CD,32CE,32CF,32D0,32D1,32D2,32D3,32D4,3332,4E27

[hdplus]
caid = 1830
srvid = EF10,EF11,EF14,EF15,EF74,EF75,EF76,EF77,5273

achja, als router hab ich einen wrt610n. ich nehme mal an das der router auch nicht das problem ist. pingtest hab ich auch gemacht liegt bei ca 20-50 ms.

wäre super wenn jemand einen rat hätte!
lg

[feissmaik]

Unabhängig deiner Cam konfiguration kann es auch am Linux oder an der Hardware liegen

Mit dem König HUB gibts öfter mal Probleme -> geh mal bitte ins BIOS und stell USB 1.1 ein (also kein usb 2.0) ... dann teste nochmal obs dann immernoch passiert .... oder den HUB mal komplett weg lassen

Ansonsten wär auch wichtig welches Linux du benutzt bzw welchen Kernel du verwendest


das einzige was mir an deinen configs auffällt bzw was ich anders machen würde, wär bei den Benutzern: monlevel = 0 und uniq = 0


//EDIT:
Haben NUR deine Clients ruckler oder hast du bei dir lokal auch welche?

Und wieso bindest du 2 deiner 3 Karten über newcamd ein aber die ORF nochmal seperat über cs357x?

[skapi]

ich hab debian 6.0.1 drauf mit kernel 2.6.32-5-486.

moonlevel hab ich schon auf 0 gestellt, uniq auf 3 hab ich nur für den orf weil manchml im oscam webif bei user orf eine duplicate meldung kommt und er sonst nicht mehr funktioniert. das könig hub hab ich mir gekauft weil es im internet hochgelobt wurde das es mit den smargos super funktionieren sollte.

wegen den configs...

die hab ich mir im internet irgendwo gesucht und dann für mich zurechtgebastelt. bin leider kein porfi auf dem gebiet und hab mir die configs durch viel, viel, viel lesen und probieren in den letzten paar monaten zurechtgemacht.
wenn du für mich eine bessere lösung hast bin ich natürlich sehr interessiert!


ich hab im lokalen netzwerk manchmal ruckler und meine freunde natürlich auch. hab meien cccam.log ein bisschen beobachtet und mir ist aufgefallen das wenn ich einen receiver neustarte das es dann zu freezern kommt und im log steht

Jul 9 12:22:49 Server CCcam: login from x.x.x.x
Jul 9 12:22:49 Server CCcam: user xxxxxxxxx login attempt from x.x.x.x
Jul 9 12:22:49 Server CCcam: double login (xxxxxxx), (previous x.x.x.x), reject
Jul 9 12:22:49 Server CCcam: kick x.x.x.x(), bad command
Jul 9 12:22:49 Server CCcam: kick x.x.x.x(xxxxxxxx), bad command

[feissmaik]

...in den foren wo dir zum könig hub geraten wurde - in den selben foren wirst du auch probleme mit/wegen des könig-hubs lesen können... weil das is ehrlich gesagt völliger schwachsinn, jeder andere aktive hub funktioniert genauso gut oder schlecht wie der könig bzw bei dem könig ist der dort verbaute FTDI chip das problem der mit so alten kisten wie dem Futro oder Igel eben probleme verursacht in verbindung mit USB 2.0... zu dem könig wird nur ständig geraten weil das einer der wenigen 7 port usb-hubs is...


Wenn du einen Receiver neu startest dann bleibt der "alte" natürlich noch verbunden weil sich dieser nicht sauber abmeldet - idlet also als "ghost" noch herrum und sobald sich der "neue" dann anmeldet wird entweder der alte oder beide gekickt - kommt auf die CCcam version an .... das ist also völlig normal und beabsichtigt

kann auch sein das dein server überlastet is und er nicht genug Power hat sich um alle 3 karten zu kümmern - vllt zu wenig Ram oder es läuft noch irgendwas anderes im Hintergrund wie zb torrentdreck...


...wie gesagt, an den configs versteh ich nich so ganz wieso du 2 verschiedene protocolle nutzt....
ich hab aber ehrlich gesagt nicht wirklich lust mich in Eure konfiguration hinein denken zu müssen .... wie du selber merkst verschlingt das ne menge Zeit und ich bin wirklich froh das bei mir alles zZt funktioniert, das hat bereits auch seine Zeit gedauert.....

...deine karten sind im LAN und du hast LAN-clients? dann is dein Internet-Ping übrigends nebensächlich

Also, stell dein BIOS auf usb 1.1 und das Problem könnte geschichte sein... Ansonsten poste bitte auch Logs von den Cams zur betreffenden Zeit der Ruckler...

[skapi]

mir wurde nicht in irgend einem anderen forum zum könig hub geraten sondern ich hab das nur gelesen und mich dann darauf verlassen. wie auch immer... auf jeden fall werd mich mir deinen tipp mit dem umstellen auf usb 1.1 zu herzen nehmen und mal das probieren. danke auf jeden fall für diesen tipp!!!

mit dem gekickt werden in cccam ist auch einläuchtend. mir ist es eben nur zufällig aufgefallen das genau dann u.a. freezer sind.

auf meinem igel ist nur debian und euer ipc installiert (danke an dieser stelle für dieses für diese super arbeit!). der igel hat 533 mhz und 512 mb ram wobei in der regel nur ca 60% des ram speichers genützt wird. was würdest du vorschlagen was ich mir sonst kaufen sollte als server?

das cmd3 protokoll hab ich von meiner dreambox übernommen weil das damals das einzig war das funktioniert hat. würde es natürlich gerne mit newcamd auslesen, hab aber keine config für caid 0d95 gefunden. mir wäre es auch recht wenn ich nicht 2 verschidene protokolle nützen müsste. ich gebe dir auch absolut recht das dass eine menge zeit verschlingt und ich erwarte mir auch nicht das mir alles auf dem presentierteller zur verfügung gestellt wird! Es ist halt nur so das ich auf den fehler einfach nicht draufkomme der die freezer verursacht.

ich habe nicht nur lan clients...

ich werde dann bescheid geben wenn ich auf usb 1.1 umgestellt habe ob die ruckler weg sind.

[skapi]

so...

hab jetzt mal das hub weg genommen und die smargos direkt am igel angeschlossen, nach wie vor das selbe problem.

ich hab auch im bios nachgeschaut, hab aber nichts gefunden wo man von usb 2.0 auf usb 1.1 umstellen kann. unter welchen punkt sollte das denn zu finden sein?

lg

//eidt:

heute morgen war es ganz schlimm mit den freezern

hier der cccam log

Spoiler

Show

Jul 11 08:02:41 Server CCcam: client xxxxxx ecm request for handler 0x3 0x1702(0x0) sid 0x1a ok: 0 (took 0.0002 seconds)
Jul 11 08:02:41 Server CCcam: client xxxxxx ecm request for handler 0x3 0x1702(0x0) sid 0x1a ok: 0 (took 0.0002 seconds)
Jul 11 08:02:42 Server CCcam: xxxxxxx ecm request for handler 0x3 0x1722(0x0) sid 0x1a ok: 0 (took 0.0002 seconds)
Jul 11 08:02:42 Server CCcam: nagra2 emu can't decode ecm (key: 0, ident: 0) no key
Jul 11 08:02:42 Server CCcam: client xxxxxx ecm request for handler 0x6 0x1834(0x0) sid 0x1a ok: 0 (took 0.0011 seconds)
Jul 11 08:02:42 Server CCcam: nagra2 emu can't decode ecm (key: 1, ident: 0) no key
Jul 11 08:02:42 Server CCcam: client xxxxxxxxx ecm request for handler 0x6 0x1861(0x0) sid 0x1a ok: 0 (took 0.0010 seconds)
Jul 11 08:02:43 Server CCcam: client xxxxxx ecm request for handler 0x3 0x1702(0x0) sid 0x1a ok: 0 (took 0.0003 seconds)
Jul 11 08:02:43 Server CCcam: client xxxxxxx ecm request for handler 0x3 0x1702(0x0) sid 0x1a ok: 0 (took 0.0003 seconds)
Jul 11 08:02:44 Server CCcam: client xxxxxxx ecm request for handler 0x3 0x1722(0x0) sid 0x1a ok: 0 (took 0.0003 seconds)
Jul 11 08:02:44 Server CCcam: nagra2 emu can't decode ecm (key: 0, ident: 0) no key
Jul 11 08:02:44 Server CCcam: client xxxxxxx ecm request for handler 0x6 0x1834(0x0) sid 0x1a ok: 0 (took 0.0012 seconds)
Jul 11 08:02:44 Server CCcam: nagra2 emu can't decode ecm (key: 1, ident: 0) no key
Jul 11 08:02:44 Server CCcam: xxxxxxx ecm request for handler 0x6 0x1861(0x0) sid 0x1a ok: 0 (took 0.0010 seconds)

hab jetzt das hub wieder dran und jetzt gehts wieder halbwegs. wenn der server wirklich zu schach sein sollte, was würdest vorschlagen das ich mir kauf?

lg

[feissmaik]

Irgendwas von wegen "USB Legacy" oder so ist auch nicht im BIOS?

mmmh ansonsten vielleicht mal einen älteren Kernel (2.6.26) ausprobieren, weil bei den neueren sind alte Treiber rausgeflogen etc...

Allerdings sieht das Log ein wenig seltsam aus - entweder fehlen Zeilen die du nicht gepostet hast oder deine Karte ist überlastet weil innerhalb 3 Sekunden 10(!) Anfragen (request) eintrudeln... Die ECM Zeiten sehen aber auch nicht normal aus... "0.0002 seconds" ist ein bischen zu schnell für eine normale Karten Antwort, solche Zeiten sprechen eher für Anfragen sie aus dem Cache beantwortet wurden

Bei mir sieht das Log (syslog) so aus - ohne irgendwelche Zeilen zu löschen: (CCcam 2.1.1)

Code: Alles auswählen

Jul 11 09:58:08 xx CCcam: local ecm -> card /dev/KD 0x1722(0x000) sid 0xd161
Jul 11 09:58:08 xx CCcam: local ecm <- card /dev/KD ok
Jul 11 09:58:08 xx CCcam: client cooli ecm request for handler 0x404 0x1722(0x0) sid 0xd161 ok (took 0.4872 seconds)
Jul 11 09:58:10 xx CCcam: emm already handled (found in cache)
Jul 11 09:58:10 xx CCcam: client dbox emm OK 0x1722(0x0) (took 0.0011 seconds)
Jul 11 09:58:13 xx CCcam: emm already handled (found in cache)
Jul 11 09:58:13 xx CCcam: client dbox emm OK 0x1722(0x0) (took 0.0012 seconds)
Jul 11 09:58:18 xx CCcam: local ecm -> card /dev/KD 0x1722(0x000) sid 0xd161
Jul 11 09:58:18 xx CCcam: local ecm <- card /dev/KD ok
Jul 10 22:18:18 xx CCcam: client cooli ecm request for handler 0x404 0x1722(0x0) sid 0xd161 ok (took 0.2575 seconds)

und wenn er was nicht finden kann:

Code: Alles auswählen

Jul 10 06:56:31 xx CCcam: local ecm -> card /dev/KD 0x1722(0x000) sid 0x00b
Jul 11 06:56:31 xx CCcam: local ecm <- card /dev/KD error
Jul 11 06:56:31 xx CCcam: local ecm -> card /dev/KD 0x1722(0x000) sid 0x00b
Jul 11 06:56:31 xx CCcam: local ecm <- card /dev/KD failure from cache
Jul 11 06:56:31 xx CCcam: client rc ecm request for handler 0x404 0x1722(0x0) sid 0xb failed (took 0.1873 seconds)
Jul 11 06:56:31 xx CCcam: client rc2 ecm request for handler 0x404 0x1722(0x0) sid 0xb failed (took 0.0375 seconds)

btw: Arbeitsspeicher (RAM) ist dazu dar genutzt zu werden (siehe IPC Hilfe), das sagt eben nichts darüber aus ob der Rechner ausgelastet ist... das erkennst du zb über den Befehl top oder htop

wenn du eine CompactFlash Karte als Festplatte nutzt, solltest du auch auf jedenfall das OnlineScript tmp2ram.sh (und ggf logmini.sh) nutzen weil sonst könnte die CF Karte schnell kaputt gehen... Um so weniger auf der CF geschrieben und gelesen wird, um so besser...
Das betrifft vorallem auch jene die eine CF und Munin nutzen, weil Munin alle 5 Minuten neue html Dokumente generiert - abhilfe dabei würde das auslagern von /var/cache/munin/www/ auf einen tmpfs mount schaffen, dann würde es künftig im RAM liegen

[skapi]

ich hab den cccam log 1:1 übernommen, ausser die clientennamen natürlich. tmp2ram hab ich natürlich aktiv um die cf karte zu schonen. logmini hab ich auch gemacht. munin hab ich nicht installiert. seit heute morgen ist es ganz schlimm mit den freezern und bei mir leutet seit dem permanent das telefon.....

mir ist im cccam webif aufgefallen das zuerst der caid 1702 abgefragt wird, der wird mit ok beantwortet. kurz darauf wird auf einmal mit einem anderen caid eine abfrage gestartet und dann kommt natürlich ein nok.

wie kann ich den kernel wechseln?

was würdest du als server vorschlagen weil du gemeint hast das meinen kiste zu wenig power hat?

achja,...
ecm zeiten sind bei rund 0,5-07 sec. bzw hd+ 0,3 sec bzw. orf 0,2sec.

[feissmaik]

Ob die Kiste zu wenig Power hat weiss ich nicht - ich weiss ja nicht wirklich was du alles installiert hast oder mit der Kiste machst - ob er auch als NAS herhalten muss oder sogar als Mediaplayer, kA

Ich selber nutze einen Futro S300 - der hat aber auch das FTDI Problem - der hat aber auch nur 256MB Ram und ne 800Mhz x86-emulations-CPU also nicht wirklich 800mhz.... Besser wär ein Futro S400


Wie gesagt, das Log kann so nicht i.O. sein weil dort keine einzige Zeile von der Karte steht.... entweder es hat sich zwischenzeitlich so arg geändert das sowas nicht mehr im Log angezeigt wird oder deine locale karte wird nie angesprochen...

erst stehen die aktionen der karte im log und danach kommt erst die zeile von wegen "client hat caid xyz und sid abc abgefragt, welche sounsolange gedauert hat..." und da diese "antwortzeit" viel zu kurz ist als dass sie von einer Karte stammen kann, glaub ich mittlerweile eben das du NICHT über locale karten guckst sondern über EMU und das der nicht wirklich freezfree is, sollte bekannt sein....



CCcam macht nicht einfach so eine Anfrage - wenn du zb auf SAT.1 schaltest dann verlangt dieser Sender nach bestimmten CAIDs mit denen er hell wird - bei mir 1801, 1722, 1834 und 09c4 ... mein Server stellt aber nur 1722 und 1834 zur verfügung also wird auch keine Anfrage auf 09c4 eingehen weil die nicht auf dem Server verfügbar ist
Ob bzw welche CAIDs in welcher Reihenfolge abgefragt werden sollen können auch über die CCcam.prio gerelt werden, aber CLIENTSEITIG weil serverseitig regelt das der Server bereits selber

Ob die locale oder eine remote karte die ecm anfrage beantwortet hat, steht eben auch normalerweise im Log, nur bei dir irgendwie nicht...


Wie du den kernel wechselst steht hier

[skapi]

mein igel ist nur als cs server vorgesehen und macht auch nichts anderes (hardware 533mhz, 512 mb ram). hab mir den futro s400 auch schon ins auge genommen.

ich werd dann mal einen längeren log von heut früh posten, viellicht ist da sonst noch was auffälliges. mit ist natürlich auch aufgefallen das mit den antwortzeiten was nicht stimmen kann, viel zu kurz eben. aber wie schon gesagt ist mir halt im webif aufgefallen das er die von mir zuerst zur verfügung gestellte karte benutzt hat und dann auf einmal mit selber sid und anderem caid eine abfrage gemacht hat und das aber nur ein paar sekunden später und nicht im 7 sekunden takt.

das mit der prio ist mir auch klar, hab die aber bei meinen clienten noch nicht drauf.

bei mir am server sind nur lokale karten und das keyfile das ich übers script geladen hab.


was mir wirklich schleierhaft ist, ist wenn sich eine box verbindet das dadurch ein freezer entsteht...