Beiträge von SHF

    Nach dem ISDN Adapter hatte ich noch gar nicht näher geschaut.

    Ich versuche gerade eine vertrauenswürdige Übersicht zu finden, über Features der einzelen AMD-CPUs zu finden. Besonders, was die Virtualisierungs-Funktionen angeht.

    Bei Intel ist das kein Problem, aber bei AMD finde ich gar nichts.



    Bei dem ISDN Adapter, sieht es wohl leider wirklich so aus, dass der nur mit speziellen Speedport Modellen an einem Telekom-Anschluss geht. Damit ist der also auch raus.

    Schade eigentlich, die Dinger sind bei Ebay schon für unter 10€ zu bekommen. (Wenigstens weiss ich jetzt aber warum die so günstig sind. :gap)

    Natürlich indem man davon ausgeht das die Box auf "fritz.box" hört.

    Logisch, hätte ich selbst drauf kommen können.

    Auch wenn dieses Javascript-Zeug ist nicht mein Ding. :wand


    Man könnte auch noch die IP der Defaultroute probieren, wenn man da dran kommt. Da wird man in den aller meisten Fällen auf das Konfigutationinterface des Routers treffen.




    Oder halt der 883 von Lancom.

    Der ist doch etwas über meiner Preisklasse.


    So weit ich informiert bin hat die Digitalisierungsbox von der Telekom einen S0 Anschluß mit dem die ISDN TK Anlage weiterbetrieben werden könnte.

    Ja, die Telekom hat so einen "einfachen" ISDN-Adapter für ~60€ im Angebot.

    Das ist bislang der einzige reine Konverter, den ich finden konnte.


    Ich hab hier auch noch einer unbenutzte s100 mit PCI-Slot rum stehen. Da würde eine ISDN-Karte rein passen.

    Vielleicht etwas gewagt, das Vorhaben :/.


    Abgesehen von der beschi.... DECT Sendeleistung der Fitzbox und den schlechten Empfang der FritzFons läuft das super.

    Hab ich auch schon Klagen darüber gehört. Das gibt so merkwürdige Aussetzer beim Telefonieren.

    Zum Glück interessiert mich da DECT nicht.



    Bei der Suche nach Firewall-Distributionen bin ich auf IPFire gestossen. Das ist wohl irgendwie aus IPCop entstanden und sieht nicht schlecht aus.

    Hat da jemand Erfahrungen damit?



    Angäblich sollen IPFire und FLi4l unter XEN als domu laufen.

    FLi4l bietet einen speziellen Kernel an (warum auch immer).


    Was würde man denn für ein System für eine minimal DOM0 verwenden?

    Ich bin immer auf AlpineLinux gestossen, ist das zu empfehlen?


    Wie sieht es bei XEN mit dem durch reichen von PCI-Geräten aus. Generell soll das gehen, aber auch auf einem PC Engines apu2 Board?

    Bei AMD tu ich mich schwer Daten dazu zu finden, bei Intel ist das viel besser gelöst.

    PCI-Passthrough wäre für die Wlan Karte, dass man da die Einstellungen ändern kann.


    Meine Motivation ist nebenbei noch eine zweite DOMU mit einem minimalen Debian als Printserver laufen zu lassen.

    CUPS ist immer irgendwie zickig, wenn unterschiedliche Versionen auf Client und Server verwendet werden. Das würde das Updaten vereinfachen.

    Naja, aber auch niemand anderes ...

    Einen Hacker hält das aber nicht auf.

    Mich hindert es aber daran die Firewall gescheit zu konfigurieren, so dass nur das absolut nötigste auf der Box erreichbar ist.


    Nebenbei traue ich SSH etwa 100mal mehr als so einem hingefrickelten Router-Webinterface.

    Und selbst wenn es in SSH eine ausnutzbare Lücke gibt, gibt es viele wesentlich interessantere Ziele als meinen Heimrouter. Die Lücke wird also bald auffallen.



    Von außen eher schwer anzugreifen.

    Der letzte Angriff kam aber von innen über den Browser.

    (Wenn ich den folgenden C't Artikel richtig interpretiert habe)

    Es handelt sich um einen Buffer Overflow in dem Dienst dsl_control, der im lokalen Netz der Fritzbox auf Port 8080 lauscht.

    [...]

    Diesen Überlauf kann er zum Ausführen beliebigen Codes mit Root-Rechten ausnutzen.

    [...]

    die Lücke {lässt sich} aber auch über speziell präparierte Webseiten ausnutzen, die auf den Dienst im lokalen Netz verweisen (Cross Site Request Forgery, CSRF)

    Von den Fritzboxen gibt es halt leider so viele, dass es interessant ist auch eigentlich lange geschlossene Sicherheitslücken immer wieder mal zu probieren.





    Wobei ich die seit die einigen Jahren nicht mehr ganz so interessant finde wie am Anfang.

    Die neuen Atom-CPUs haben da in Sachen Stromaufnahme aufgeschlossen und bieten mehr Leistung fürs Geld.

    Wenn man die aktuellen RAM-Preise bedenkt und die Tatsache, dass PC Engines inzwischen Intel LAN-Chips verbaut, sind deren Boards noch immer nicht unninteressant.


    Laut cpu-world.com unterstützt der Prozessor sogar AMD-V Virtualisierung.

    Wunder wird man da nicht erwarten können, aber zwei drei kompakte virtuelle Maschinen mit Sachen wie fi4l, IPCop, einem Druckerserver oder was ähnlichem sollten schon gehen. Immerhin hat die CPU 4 Kerne.

    openwrt auf AVM Boxen ist möglich: LINK

    Die Seite kenne ich.

    Die meisten von der Liste sind aber nicht unterstützt. Da wird dann auf freetz verwiesen.


    Der letzte commit im freetz git ist gerade mal ein paar Tage alt.

    Danke. Da hatte ich die wohl zu früh abgeschrieben.

    Einer von den Links zum Git im Wiki geht sogar. Man muss ihn nur finden.

    Bin gespannt für welche Möglichkeit du dich entscheidest

    ... und ich erst :lachen3.


    Du brauchst sowas wie einen "Voip S0 Gateway". An den kannst du deine bisherige ISDN Infrastruktur anschließen. Davor einen Router. Falls noch nicht vorhanden, guck dir mal die SBCs von PC Engines an. Das APU z.b., darauf läuft u.A. auch openwrt. Und davor brauchst du ein Modem. Entweder eine billige kleine Fritzbox im full bridge Modus, eine 7412 z.b., oder ein DrayTek Vigor.

    Auf sowas wird es aber wohl hinauslaufen.

    Besonders, da ich bei dem einen Provider ohnehin so eine billige kleine Fritzbox gestellt bekommen würde.


    Die Boards von PC Engines beobachte ich schon länger. Wobei ich die seit die einigen Jahren nicht mehr ganz so interessant finde wie am Anfang.

    Die neuen Atom-CPUs haben da in Sachen Stromaufnahme aufgeschlossen und bieten mehr Leistung fürs Geld.



    Zitat

    Ich vergaß zu erwähnen, dafür taugt natürlich jede "alte" Fritzbox mit internem S0

    Da das Teil kommuniziert mit dem Internet, ist da halt wieder die Sache mit dem Firmware-Support.


    Ich muss mich wohl mal näher mit freetz beschäftigen, ob das ältere Boxen unterstützt.

    Mal sehen, ob man bei freetz alles raus schmeissen kann, was nicht unbedingt für so einen "Voip S0 Gateway" benötigt wird.

    Bei welchem Provider bist du denn?

    Bei uns gibt es zwei Netze zur Auswahl:

    Das von der Telekom und dann noch ein regionales, wo die Gemeinden irgendwie mit drin stecken.


    Bislang war ich, wegen des ISDN, im Netz der Telekom. Da werde ich aber nicht bleiben, weil das hier nicht mal die vollen 16Mbit schafft, die man zahlen müsste.


    Bei dem regionalen Netz hat man die Auswahl zwischen zwei Providern: Entega-Medianet und MySpeedy, beides Tochterunternehmen von lokalen Energieversorgern.

    Viel geben die sich nicht, MySpeedy ist aber etwas günstiger, daher tendiere ich zu denen.


    Auch beim Router macht das wenig Unterschied.

    Bei Entega muss ich den kaufen. Sie bieten aber eine FirtzBox 7590 für 150€ an (wahlweise mit Finanzeinungsmöglichkeit).

    Myspeedy stellt eine FirtzBox 7430 (die würde ich dann als Modem verwenden)

    und vermietet eine 7490 für 5€ im Monat. Wobei ich vor ein paar Wochen auf einer Bau-Messe mit denen gesprochen habe und schwören könnte, dass die sagten, dass es jetzt die 7590 gibt.


    Und lies mal was über Freetz.

    Ernsthaft?

    Freetz war mir natürlich schon aufgefallen, ist auch schwer zu übersehen.

    Einen wirklich guten Eindruck hat das auf mich aber nicht gemacht:

    Downloads steinalt, Link zur Seite mit den Unterstützten Geräten tot,...


    Sah irgendwie nicht wirklich brauchbar aus, kann mich aber auch täuschen, allzuviel Zeit hab ich da dann nicht mehr verbracht. Kann auch sein, dass ich nur den Einstieg nicht gefunden habe.


    VoIP geht immer über PPP, ist leider so.

    Dann bräuchte ich also zwei parallele PPPoE Verbindungen, eine fürs Telefon und eine fürs Internet. Technisch geht das, über eine DSL-Verbindung.

    Ich bin aber mal gespannt, was die sagen, wenn ich mit dem Wunsch komme :mua.


    Der Bug hat nur den Fernzugriff betroffen und wurde auch über den Supportzeitraum hinaus gepatcht.

    Das war der eine Bug von 2014, was sich auch anhand der Firmware-Updates nachvollziehen lässt.

    Eine Firmware mit "Fernzugriff-Patch"gibt es zB. auch für die 7170, obwohl der Support eigentlich schon beendet war.


    Der Fernzugriff gehört IMHO aus Sicherheitsgründen sowieso abgeschaltet.

    Allenfalls für Wartungsarbeiten sollte man den kurzzeitig aktivieren.



    Die erwähnte Fw Lücke ging auch trotz deaktivierter Fernwartung wenn ich mich recht erinnere...

    Ich hab den Artikel wieder gefunden:

    Das war die zweite Lücke, von 2016: AVM-Router: Fritzbox-Lücke erlaubt Telefonate auf fremde Kosten


    So wie ich das verstehe half da auch die Firewall nicht.

    Keine Ahnung, wie man die Box da schützen soll, ausser durch ein Update. Allenfalls in ein eigenes Netzwerk packen und jeglichen Zugriff unterbinden.


    Ich würde eine supportete Box nehmen.


    Sofern die Box irgendwie in Internet kommt unbedingt.

    Problem ist halt nur, dass der Support nicht allzu lange geht, weshalb ich ja eigentlich was offenes suche.


    Wenn die Box nur als SIP-Telefon hinter der gestellten Fritzbox hängt, halte ich aber auch eine nicht mehr supportete Box für vertretbar.

    Dann müsste schon ein Bug im SIP-Protokoll sein und gleichzeitig die vom Provider gestellte Fritzbox den auch noch durch reichen.



    Darum letztes Mal auch die Frage, ob man so eine Fritzbox als "IP-Telefon" hinter einer anderen Fritzbox betreiben kann.


    Die 7390 bekam im Oktober noch ein Update. Allerdings ist meine welten von stabil im Betrieb.


    Angeblich ist der Support für die 7390 inzwischen aber eingestellt worden, sehe ich gerade.


    Und instabil ist natürlich gar nichts. Wenn das Telefon nicht geht, gibts prompt Mecker.


    Man könnte auch mit Geld nach dem Problem werfen und sich eine be.ip plus von Bintec zulegen


    Da sehe ich jetzt nicht, was der mir gegenüber einer Fritzbox 7590 mehr bieten sollte.

    4 analoge Telefone reichen nicht und meine vorhandene Anlage kann ich auch an die Fritzbox anschliessen.


    Ausserdem ist das auch wieder so ein "alles in einem Gerät", was man weg schmeissen kann, wenn der Firmware-Support ausläuft.




    Wenn "alles in einem Gerät", dann virtualisiert und auf einem gescheiten Computer.

    Mit einzelnen virtuellen Maschinen für jede Funktion (Router, Telefon, usw.), lässt sich das auch gut warten, denke ich.

    Für meine Anwendung sollten virtuellen Maschinen das trotz Spectre wohl auch sicher genug sein.

    Während für Router (und ggf. NAS) mehrere spezialisierte Distros zu finden sind, sieht es bei Telefonanlagen eher schlecht aus.

    Am Ende hänge ich auch da wohl wieder an der Telefonie-Hard- und Software :motz4.


    Zu erst einmal vielen Dank fürs Feedback!

    Das hat mir echt geholfen.

    ... auch wenn nicht so wirklich das raus gekommen ist, was ich hören wollte. Irgendwie hatte ich das aber schon befürchtet :gap.


    Dein Kompromiss hier wäre die FW, die von AVM kommt.

    Damit hab ich prinzipiell kein Problem.

    Was mich aber massiv stört ist deren komischer Eigenbau-Paketfilter, der den Router selber nicht absichert und die Tatsache, dass ich keinen Root-Zugang zur Box habe.


    Klar, das kann man das irgendwie nachrüsten das, nach dem was ich bislang gelesen habe.

    Das scheint mir aber ein Gefrickel unter Ausnutzung von Lücken in der Firmware zu sein und die Anpassungen sind nach einem Update auch wohl weg. Und ob das nach einem Update dann noch geht ist auch immer die Frage. Ich weiss nicht, ob ich mir das antun will.


    Nimm für VOIP den Router, den Dein Provider stellt, dann gibt‘s da auch keine Diskussionen bei Leitungsproblemen etc.


    Das dürfte Heute in den meisten Fällen eine Fritz oder eine BinTec (Digibox) sein.

    Ich bekomme wohl irgendeine Fritzbox gestellt, allerdings ohne S0.

    Wenn ich was mit ISDN will, müsste ich das selbst kaufen oder für teuer Geld monatlich mieten.


    Mein Plan war die Gratis-Box zum Modem zu degradieren. Da können die bei Leitungsproblemen eigentlich nicht meckern. Dank pppoe passthrough soll das gehen.


    Asterisk deckt natürlich alles in jeglicher Hinsicht. Je nachdem wie fit du in dem Thema bist kann es schnell gehen mit den Einstellungen.


    Wenn du nicht fit bist dann ists recht hart (wie bei mir)...

    Vor dem Thema VOIP hab ich mich bislang erfolgreich gedrückt :versteck.

    -> Nahezu 0 Ahnung.


    Asterisk scheint mir aber, bei der Anwendung auch irgendwie mit Kanonen auf Spatzen geschossen zu sein.

    Darum die Frage ob es Alternativen gibt.


    Der Einarbeitungsaufwand für Asterisk ist hoch, und wenn man einen Fehler macht, hat man eine Sicherheitslücke.

    Da ich nur die Verbindung zu dem Server des Providers brauche, sollten man die Angriffsfläche klein halten können. Vorausgesetzt die Box hat einen anständigen Paketfilter.


    Wenn weitergehender Schutzbedarf vorhanden ist, kannst Du ja dahinter noch was anderes einsetzen, um Dein internes Netz abzusichern.

    Das würde dann doch auf 2x NAT hintereinander hinauslaufen?

    Sollte man das denn nicht eher vermeiden?


    Bester Ansatz für Neuanschaffungen ist übrigens direkt VoIP-Telefone zu kaufen. Die laufen direkt an einem beliebigen LAN-Anschluss.

    Das scheidet bei mir aus.

    Die Verkabelung fehlt und wegen der Teilintegration der Haustelefon-Anlage, würde es auch richtig teuer werden.

    Ausserdem bin ich mit dem aktuellen System zufrieden und es läuft seit Jahren zuverlässig ohne dass ich jemals was machen musste.


    Da ich keine ISDN-Telefone habe, käme eventuell eine VOIP-Telefonanlage mit mindestens 10 herkömmlichen, analogen Nebenstellen infrage. Vorraussetzung ist, dass eine Integration des alten Siedle-Haustelefons möglich ist.

    So ganz durch bin ich da noch nicht, aber es scheint, das das entweder auch teuer wird oder mit dem Haustelefon Probleme macht.

    Und letzteres rühre ich garantiert nicht an, so was zuverlässiges bekommt man heute nicht mehr.


    Nimm nen guten Eigenbau Router

    Welche Basis würdest du bevorzugen?

    WRT, x86, oder was anderes?

    Und was an Software?

    Nimm nen guten Eigenbau Router und dann eine beliebige gebrauchte Fritzbox danach.
    [...]
    "Dahinter" geht alles was man bei ebay billig bekommt.

    An sowas hatte ich auch schon gedacht.


    Gibt es da Typen die besonders zu empfehlen sind, zB. durch geringen Stromverbrauch?


    Pollin hat derzeit gebrauchte 7390 für ~50.-€. Ist das ein gutes Angebot?



    Als FritzBox dahinter würde ich ne 7170 empfehlen.

    [...]

    eine 7170 als ISDN-Adapter über LAN anhängen. Das hatte ich jahrelang bei Kunden und läuft super.

    Da die 7170 jetzt zweimal erwähnt wurde: Warum gerade die?

    (Bei den FritzBoxen hab ich 0 Überblick.)


    Laut "router-faq.de" braucht die 7170 weniger Strom als die ältere 5050 von daher hätte die einen Vorteil.

    Preislich dürften die sich auch nicht viel tun. Inzwischen müssten beide ja kurz über Elektro-Schrott-Kilopreis zu bekommen sein :).


    Habt ihr da eine Bezugsquelle, oder muss man in der Bucht fischen gehen?

    Und wenn nach welcher Version, bei der 7170 gibt es anscheinend mindestens 4 unterschiedliche.


    Firmware Update für die 7170 scheint schon seit ~5 Jahren eingestellt zu sein. (Für die 5050 noch länger.)

    Ist das ein Problem, wenn man die nur als ISDN-Adapter verwenden will?

    Zwischenzeitlich gab es doch diese Geschichte mit den gehackten Fritzboxen, wo teure Anrufe nach sonstwo getätigt wurden.

    Oder betraf das die VOIP-Funktion der Box nur mittelbar? Ich habe damals nicht verfolgt, was da genau die Ursache war.


    Ich hätte dann vor, die ISDN-Adapter-Box als ein VOIP-Telefon (mit zwei Amtsleitungen und mehreren Nummern) an der gestellten Box vom Provider einrichten zu lassen. Geht das?

    Ich will auf jeden Fall vermeiden, das die ISDN-Adapter-Box direkten Zugang zum Internet bekommt.





    Eine blöde Frage hätte ich dann noch:

    Hab ich richtig verstanden, dass nach der Umstellung die VOIP-Daten dann über die gleiche PPP-Verbindung wie das Internet laufen?

    Momentan kann ich die DSL-Verbindung trennen, bzw. neu starten während dessen das Telefon weiterhin funktioniert.

    Wie stelle ich es jetzt an, die PPP-Verbindung fürs Internet neu zu starten (zB. um eine andere IP zugewiesen zu bekommen), ohne das das Telefon zusammen bricht?

    Sofern der Video-Decoder unterstützt ist, sollte auch so ein Stick gehe, die CPU muss dann nicht mehr viel tun.

    AFAIK sind die Video-Decoder bei den neueren x86-Atoms unter Linux unterstützt, ich wüsste nicht von Ausnahmen.


    Ob das das Problem mit dem WLAN löst bin ich aber skeptisch.

    Hallo zusammen!


    In den nächsten Monaten steht nun auch bei mir die lange vor mir her geschobene Umstellung auf VOIP (zwangsweise) an.

    Da ich wohl einer der letzten bei der Umstellung bin und mich mit dem Thema VOIP vorher noch nie beschäftigt habe, hoffe ich auf ein paar wertvolle Tipps von Euch.


    Im Haus eine umfangreiche ISDN-Telefonanlage (inkl. Türsprechstellen usw.) installiert ist und soll es auch bleiben. Ich benötige also einen Router mit S0 Anschluss. Das engt die Auswahl schon gewaltig ein.
    Ich suche dazu einen offenen Router, bei dem nicht an die Firmware des Herstellers gebunden ist und eine gut gepflegte Alternative gibt (zB. openWRT).

    Den heutigen Abend habe ich mit suchen im Internet verbracht und nichts brauchbares gefunden.


    Alternative wäre ein Eigenbau auf x86-Basis (zb. Atom), da wäre man Software-Seitig mit einer Distro nach Geschmack dabei und bekommt problemlos Updates.

    Router mässig kein Problem, PPPoE, NAT, usw, das hatte ich schon mal so am laufen.

    Nur wie sieht es VOIP auf ISDN aus?

    ISDN-Karten mit PCI-Interface findet man recht häufig, bei PCIe wird es schwieriger. Bzw. das was ich gefunden habe zielt eindeutig auf professionelle Anwender.

    Und wie sieht es mit der mit der da Software aus? Asterisk?


    Weitere Optionen?

    Ich habe das folgende Testscript gebastelt und bei mir geht das unter Debian 9. Auch als root.

    Das Script zeigt auch ganz schön den Unterschied von "$*" und $*.


    Die Ursache des Fehlers muss wohl wo anders liegen.

    Vielleicht hilft das ja jemandem, das tatsächliche Problem zu erkennen.

    Auch wenn ich es nicht ganz nachvollziehen kann, vermute ich, das das mit dem von mir o.ä. commit zusammenhängt.
    Da muss wohl ein Fehler bei Timeout drin gewesen sein, so dass readdata() zu lange auf wartet.



    Genau die Seite suchte ich verzweifelt! :respekt

    Jetzt musst du mit nur verraten, wie man da hin kommt.


    Die haben das gesamte Timing in dem Modul umgestellt, da wird sich wohl der Fehler mit eingeschlichen haben.




    Zu den Schnittstellen nur noch so viel:

    Primär verwende ich die noch für diese Bitbang-Programmierkabel und ähnliche Geschichten. Mit denen kann man viel machen für kleines Geld.

    Wenn es über USB gehen soll wird es deutlich teurer und/oder aufwändiger.

    Er wartet anscheinend auf den "trailing pulse", aber dann kommt ihm ein Timeout dazwischen.

    Timeout ist das Stichwort:

    https://github.com/torvalds/li…vers/media/rc/serial_ir.c

    (3. Commit von unten)

    Es ist also ein Kernel-Update angesagt.


    Das erklärt dann aber auch, warum nicht alle die Probleme haben. Das wird nur bei einigen "langsamen" FBs mit langen Codes Probleme machen.

    RC-5 ist beispielsweise so schnell, dass es praktisch unmöglich ist den Tasten-Code nur einmal zu senden.


    Wobei laut dem Link das "serial_ir"-Modul lediglich das umbenannte "lirc_serial" ist.

    Was dann bedeuten müsste, dass es auch da einige Versionen betreffen müsste, oder der Fehler erst ab der Änderung auftritt.

    Leider konnte ich auf die Schnelle keine Historie zu "lirc_serial" finden, das hätte mich schon interessiert.


    Heutzutage ist der gängigere Weg einen Mikrocontroller zwischen I/O und den USB Port zu bauen. Billig und im Zeitalter von Arduino auch nicht schwer zu erlernen.

    Das ist bei vielen Problemen auch eine gute Lösung.

    Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.

    Möglicherweise ist das, was da am Ende des von 'mode2 -s 500' dargestellten Diagramms zunächst fehlt und erst beim nächsten Tastendruck erscheint, ja dieser lange "space" zwischen den Tastendrücken.

    Ja, das ist der "space".

    Ich war nur nicht mehr sicher, ob der "space" erst mit dem nächsten Code kommt, oder ob er schon vorher, durch einen Timeout, kommen sollte.

    Aber das Verhalten ist so korrekt.


    Das würde dann aber heißen, dass der Fehler im lircd passiert,

    Das ist der logische Schluss.

    was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...

    Eventuell betrifft es nur spezielle Fernbedienungen (mit "trailing pulse"?).

    Die Erkennung geht ja bis zum "trailing pulse" korrekt.


    Hast du mal versucht "ptrail" auf genau 563 zu setzen?
    Wobei die geringe Abweichung eigentlich aufgefangen werden müsste.


    Was ich aber auch noch immer nicht verstehe ist, dass es bei längerem Tastendruck geht.

    Die FB sendet den Code ja nur einmal und dann den "repeat code". D.h. die Erkennung des Codes am Anfang muss funktioniert haben.

    Also, bei mir enden die Signale auch immer mit einem pulse.

    Das sollte also nicht das Problem sein.

    Ein kurzer Tastendruck, Code plus eine Wiederholung.

    ( -s kennt meine Version von mode2 nicht)


    Es ist doch immer wieder schön, wenn etwas, das lange Zeit gut funktioniert hat, durch etwas neues ersetzt wird, das erstmal nicht mehr funktioniert... :-(.

    Und wenn das dann endlich funktioniert, soll lirc durch rccore abgelöst werden.


    Zu SuSE und den Kerneln kann ich nichts sagen, da bin ich zu lange raus.

    4.12 ist aber schon länger EOL, merkwürdig, dass der noch läuft. Ich hätte da einen LTS-Kernel (4.9 oder 4.14) mit aktiven Support erwartet. Eventuell klappt da generell was mit den Updates nicht.

    http://download.opensuse.org/r…HEAD/standard/kernel-repo

    Der link geht im Browser zumindest mal nicht.

    Oder gibt es eine Möglichkeit, lediglich das serial_ir Modul upzudaten?

    Früher konnte und musste man die lirc-Module per out of tree bauen.

    Ob das noch immer geht, konnte ich nicht in Erfahrung bringen.

    Den Kernel upzudaten wird inzwischen aber die einfachere Option sein, schätze ich.

    Generell sagt der Preis wenig über die Qualität von so einer Karte aus, im Vergleich mit einem Receiver sind die alle nämlich viel zu teuer.

    Der Connexant-Chip ist weit verbreitet und gilt als zuverlässig (ich hab selbst eine Karte damit).
    Wie die Tuner von der Karte ausfallen weiss ich aber



    Bei DMAX, 3sat, ZDFinfo gehen HD-Kanäle nicht und WDR macht Macken?


    Die Kanäle liegen alle weit "oben" im High bzw. Low-Band, haben also an der Karte eine hohe (Zwischen-)Frequenz.

    Es ist typisch, dass da zuerst Probleme auftreten, wenn der Empfang grenzwertig ist. Im hohen Frequenzbereich wirken sich Kabeldämfung usw. am stärksten aus.


    Ob der Tuner defekt ist, oder die Signalqualität einfach an der Grenze ist, kann ich nicht sagen.

    Eventuell halfen bessere Kabel oder ein Sat-Verstärker mit Entzerrung. Kann aber auch sein, dass letzterer es schlimmer macht.

    Der letzte "-" müsste der trailing pulse sein oder ein Teil davon sein.

    Was fehlt ist dann eigentlich nur die Lücke. Merkwürdig, dass es nicht geht.


    Ein Vergleich mit dem RaspberryPi wäre aufschlussreich, wie es da auch aussieht.
    Bei unterschieden auch mal die nicht graphische mode2-Ausgabe mit den Signalzeiten vergleichen, dann weiss man genau, was da am Ende fehlt.

    "ptrail" könnte man testweise mal auskommentieren. Keine Ahnung das was da bringt, aber vielleicht gibt es zumindest eine andere Fehlermeldung.



    VDR berücksichtigt den Wiederholcounter durchaus. [...]

    Mir ist es jedenfalls nicht gelungen, es so einzustellen, dass x einzelne Tastendrücke die Funktion auch immer x mal ausführen und es trotzdem bei längerem Druck nicht zum nachlaufen kommt.

    Gegen doppelte Eingaben bei einem kurzen Tastendruck haben die beiden Einstellungen auch nicht geholfen, es sei denn ich hab sie so hoch gedreht, dass die FB unerträglich langsam wurde. "suppress_repeat" in der lircd.conf hat es dann gebracht.

    Was ist denn das für ein Transponder? (Frequenz)

    Eventuell kann man mit den LNB-Werten was tunen.

    Besonders, wenn er in der nähe der SLOF liegt, bringt eine Veränderung oft was.

    Die Idee die Cache-Verwaltung in ein Skript auszulagern ist keine schlechte Idee, gefällt mir :thumbup:!


    Das Quoting von Dateinamen einfach weglassen, weil es mit nicht läuft, ist nicht gut. Das kann zu Problemen führen, wenn Leerzeichen ins Spiel kommen.

    Bei Debian tippe ich auf BASH als Ursache für das Problem, standardmässig ist die Shell nämlich gar nicht installiert und der Ersatz kann nicht alles. Man muss lediglich das Paket nachinstallieren, dann sollte es gehen.


    Was bei dem Skript IMHO noch fehlt ist eine regelmässige Kontrolle der Belegung der Cache-Partition.

    Nicht dass einem bei einem Aufnahme- oder Schnitt-Marathon der Platz ausgeht.


    Statt "nice" sollte man "ionice" setzen. Bei einem Verschiebebefehl mit viel HDD-Zugriff, kann es nicht schaden auch den nice zu machen.


    Und was passiert eigentlich, wenn der VDR auf die Aufnahme gerade zugreift, während sie verschoben wird?

    Fängt mv das schon ab?


    Die Anzeige des freien Platzes dürfte aktuell auch nicht korrekt sein?

    Da wird man momentan nur den Platz auf der Cache-Partition sehen, denke ich.

    Aber mode2 (und inzwischen auch xmode2) liefert exakt die richtigen Impulsdiagramme. Alles weitere sollte doch eigentlich nur noch Software-Sache sein. Irgendwie macht anscheinend 'irw' (und damit auch der lircd) aus dem Impulsen nicht die richtigen Codes.

    Bei irw werden die also schon nicht angezeigt? Die eigentliche Anwendung (VDR) ist dann also schon raus.


    Ich frage, weil der VDR die Daten von Lirc irgendwie merkwürdig verarbeitet.

    Der Wiederholcounter von LIRC liefert wird anscheinend ignoriert und statt dessen mit Wiederholverzögerung und -intervall versucht das irgendwie in den Griff zu bekommen.

    Nach dem Umstieg vom Remote-Plugin hab ich eine ganze Weile gebraucht die Parameter so einzustellen, dass es einigermassen lief. Symptome waren etwa wie hier beschrieben.


    Wenn es schon bei LIRC liegt, könnte man noch versuchen "gap" etwas zu verringern.

    Wenn der Wert zu gross ist, kann das dazu führen, dass der empfangene Tastencode verworfen wird.


    "repeat" müsste doch bedeuten, dass die FB nur so einen speziellen Code als Tastenwiederholung sendet und nicht den Code mit invertiertem Togglebit wiederholt?

    Irgendwie ist es für mich dann merkwürdig, dass ein längerer Tastendruck helfen hilft.


    Wundert mich ehrlich gesagt, dass man noch ohne Verrenkungen ein Board bekommt, das die "Legacy-Ports" noch hat...

    Mich wundert das weniger, ich würde mir nie ein Board ohne kaufen.

    Diese "alten" Schnittstellen sind noch immer die einzige Möglichkeit, wenn es um Hardware nahe, direkte Ein- und Ausgabe geht. (Zumindest, wenn es sich preislich im Rahmen bleiben soll.)

    Die Schnittstellen selber sind dazu in allen Multi-IO-Bausteinen drin, Mehrkosten sind also nur die Stiftleisen.