Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

Schmarrn schrieb:

welcher wert für den fallback bei der orf-karte (0D95) gesetzt werden soll?

Zum Vergrößern anklicken....

fallbacktimeout_percaid = 0D95:600

-supraracer

Also bei mir mit DLan sind alle Freezer verschwunden, seit ich einfach permanent von der Box meinen Router anpinge (oder irgendeinen anderen Rechner).

z.B. so hier:

Skript anlegen unter: /etc/init.d/ping_router.sh

#!/bin/sh
ping -q 192.168.1.1 &

Ausführungsrechte setzen: chmod 755 /etc/init.d/ping_router.sh

Startupskript anlegen: update-rc.d ping_router defaults oder update-rc.d ping_router.sh defaults (kommt aufs Box System an)

Ist es eigentlich egal was angpingt wird? ob router oder z.b. google mit 8.8.8.8 ?

Das ist Wurscht. Es geht ja eher darum, das die D-Lan-Dinger nicht in den Schlafmodus gehen.

MfG

beauty schrieb:

Ist es eigentlich egal was angpingt wird? ob router oder z.b. google mit 8.8.8.8 ?

Zum Vergrößern anklicken....

Ja, aber Router ist evtl. besser, da es ja dann "privat" bleibt. Kannst auch google.de anpingen. Durch das permanente Pingen können die DLan Dosen sich nicht mehr einfach abschalten zum Strom sparen, denke ich. Jedenfall klappt das einwandfrei.

Hab auch den Receiver aus Verkabelungsgründen per 1GB dlan (nominell, ich weiß) mit der Fritz verbunden. Hat nie Probleme gemacht, aber seit kurzem immer mal so Mini-Freezer von etwa 1s. Selten auch mal der komplette 7s Blackout. Easy am Raspi läuft prima. Hab die Ping-Sache getestet, aber das gab leider keine Abhilfe.
Werde jetzt mal 378 mit Fallback versuchen. Eigentlich hab ich es schon zig mal versucht, aber es ging einfach nicht.
Bis mir dann einfiel, dass ich im Schlankheitswahn die Oscam auf dem Pi nur mit ccshare kompiliert habe und sonst keine Protokolle.
Immerhin ist es mir nach Tagen eingefallen. So ein Mist ;-)

Muss man unbedingt einen zweiten User anlegen? Ich habe einfach den gleichen user genommen. Die 2. Abfrage per udp hat er gemacht.


Gesendet von iPhone mit Tapatalk

Nein muss man nicht unbedingt wenn am Server erlaubt ist sich mehrfach zu verbinden mit einem User.

-supraracer

Gerade wieder am experimentieren:

Client <-----WLAN-----> Accesspoint <-----dLAN-----> Accesspoint Richtantenne indoor <------ WLAN über ~500m -----> Accesspoint Richtantenne outdoor <----- GBit LAN -----> Server

Client Log:


Server Log:

user1 = cs378x TCP
user2 = cs357x UDP

Teilweise verrecken die TCP Verbindungen komplett oder kommen mehrere Sekunden zu spät beim Server an, trotzdem keine Freezer.

-supraracer

Sehr schönes HowTo und vielen Dank dafür.
Bin ehr der unsichtbare leser, habe den ganzen Thread gelesen aber dennoch Verständnisfragen.

1.) Zum Thema TCP/UDP:
Warum stellen wir die zweite Anfrage nicht auch per TCP? Warum per UDP? Ist es "grob erklärt" wie im Post #56 von scotty86 das beim TCP Protokoll erst auf die erste Anfrage gewartet werden muss (egal ob beantwortet oder der Verlust des Pakets festgestellt wird) und dann erst die zweite Anfrage bearbeitet wird, und wir mit der zweiten Anfrage per UDP diese "Warteschlange" umgehen?

2.) Ich habe bei meinem Server auch einfach mehrere Lines für einen Clienten gemacht. Quasi die "Breitschwert Methode". Hat auch ein bisschen was bewirkt. Wie verhält es sich da? Wird eine Anfragen gleichzeitig an alle Lines gesendet oder wird das nacheinander gemacht? Also erst die Line die ganz oben steht und dann die nächste usw.? Wenn es nacheinander gemacht wird und es diese "Warteschlange" gibt macht die "Breitschwert Methode" ja eigentlich keinen Sinn oder?
Muss das
aus Post #12 von hwmmc bei der "Breitschwert Methode" berücksichtigt werden?

3.) (Diese Frage erübrigt sich, wenn die Antwort auf Frage 1 lautet, dass wir diese "Warteschlange" damit umgehen wollen):
Können wir nicht einfach wie freddchen im Post #18 geschrieben hat in der oscam.conf
einfügen? Dann würde doch auch einfach wie beim Fallback eine zweite Anfrage bei Überschreitung von 500ms gesendet werden. Zwar mit dem gleich TCP Protokoll aber wenn es diese "Warteschlange" nicht gibt wäre das von der Einstellung her die einfachere Variante. Und man bräuchte nicht zwei User auf den Server einrichten. Sprich wenn man keinen Einfluss auf den Server hat wäre das doch eine gute Möglichkeit.
Man hat so zwar häufiger Timeouts im Log aber das würde an sich ja nicht stören.


Ich hoffe ich habe mich nun nicht mit dieser "Warteschlange" verhaspelt und hier total bekloppte Fragen gestellt, aber so mehr man über das Thema nachdenkt, desto mehr Fragen schwirren einen im Kopf.

1) Weil ich den zweiten Versuch lieber über einen Protokoll-Bruch mache wenn der Erste schon verreckt ist. Wie an anderer Stelle hier im Thread schon geschrieben kannst du den primär Reader auch UDP machen und den zweiten TCP wenn dir das besser gefällt.

2) Die gehen alle Simultan raus, genau das wollen wir eigentlich nicht haben, wenn zu exakt diesem Zeitpunkt ein Problem auftritt kommt keine davon am Server an.

3) Kann man auch so machen wenn man nur eine einzige caid nutzt, aber halt ohne Protokoll wechsel.

Sicher führen auch noch andere Wege nach Rom, ich hatte einiges experimentiert und wie unter #1 beschrieben die mit Abstand beste Erfahrung gemacht.

-supraracer

Zu 1.) Ja mir ist das schon klar und verstehe das auch. Ist auch wirklich eine super Idee mit dem zeitversetzten senden. Mir ging es eigentlich in erster Linie darum ob es diese "Warteschlange" gibt.

Zu 3.) Warum wenn man nur eine einzige CAID nutzt?

Weil der Parameter clienttimeout global ist.

-supraracer

Ah eigentlch logisch. Oder einfach die niedrigere Zeit nehmen. Kann ja eigentlich nichts passieren ausser das eine Karte dann mehr belastet wird.

Nochmal ne kurze Frage.
Muss man einen fallback bestimmen oder reicht die Parameter unter [global] aus? Also das der dann einfach über die gleiche Line nochmal anfragt (wenn man jetzt nicht die zweite Anfrage über UDP machen will).