Posts by SHF

    Beim Start von VDR (Öffnen der Devices?) passiert wohl etwas, das das Flag setzt.

    Beim reinen öffnen des Devices hätte ich das jetzt nicht erwartet. Da sollte die Firmware der Karte die ganze Zeit laufen.

    Eher beim laden des Treibers, das könnte mit einem Firmware-Rest der Karte verbunden sein.


    Aber wenn man es zurücksetzt, dann bleibt es zurückgesetzt.


    Starte ich den rsync, geht es nach kurzer Zeit auf CorrErr+ und einige Sekunden danach kommen die I2C-Fehler.

    Das deckt sich mit den anderen Beobachtungen.


    UncorrErr bleibt aber die ganze Zeit auf '-'.

    Dieser UncorrErr wird von der Karte gesetzt wird.

    Wenn die Firmware abgestürzt, oder der Link zusammengebrochen ist, kann es sein, dass man den schon nicht mehr auslesen kann.


    Eventuell geben da die Werte von der Gegenstelle (00:13.1) mehr Aufschluss.

    Wenn der Link unzuverlässig ist, würde ich da auch Fehler erwarten.

    Da auch mehr Daten Richtung Computer laufen, sollte "CorrErr" da eigentlich sogar früher kommen.


    Im Fehlerzustand sollte man auch mal schauen, ob es sonst noch Fehler auf dem PCIe-Bus gibt.

    lspci -vv | grep DevSta:

    Wenn es da noch mehr Fehler gibt, liegt es wohl am Mainboard.

    Wenn es nur den einen Link, mit der DD-Cine, betrifft, würde ich auf diese tippen. Die Netzwerkkarte läuft in dem Slot ja.



    BZW.:

    Ist der Stromstecker eigentlich an der Cine angeschlossen?

    Wenn nicht unbedingt mal versuchen mit, auch wenn die an einem Multiswitch hängt.

    -d wäre Hersteller:DeviceID. (liefert lspci -n)


    Du müsstest "-s" nehmen, wenn du die Busadresse verwendest.


    Die Busadresse wirkt auf die Karte in dem bestimmten Slot, Hersteller:DeviceID auf alle passenden Geräte egal in welchem Slot.

    Ist Geschmackssache, was man verwendet, je nach dem, was praktischer ist.

    Was ich noch gesehen habe: beim NIC ist 'MaxReadReq 4096', bei ddbridge 'MaxReadReq 512'.

    Ich würde letzteres auch gerne mal auf 4096 setzen, das klappt aber nicht (siehe hier).

    Das klappt bei mir leider auch nicht, wie ich inzwischen festgestellt habe.


    "Firmware Test Suite" werde ich mir mal ansehen.


    Das kommt hier bereits unmittelbar beim Start von VDR, ohne dass sonst ein Problem aufgetreten wäre.

    Die Frage ist, kommt es wieder, wenn man es mit setpci -d xxxx:xxxx CAP_EXP+0xa.w=0x000f löscht.

    Das Löschen klappt bei meiner PCI-Bindge (s.o.), das habe ich probiert.


    Wenn das Bit nach dem löschen unmittelbar wieder gesetzt wird, ist irgendwas mit der Verbindung faul und das Hardware nah.

    In dem Fall braucht man sich mit den Timing-Geschichten garnicht erst beschäftigen.

    Das war ja leider nicht so erfolgreich :(.


    Nach etwas lesen habe ich aber heute festgestellt, dass lspci auch Auskunft über den PCIe Kink gibt:

    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Die Zeile gibt an, ob es zu Fehlern gekommen ist und ob sie korrigierbar waren.


    Bei ras steht alles auf "-", das bedeutet keine Fehler.

    Bei kls sind korrigierbare Fehler aufgetreten:

    DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Und die bei der DD Cine und auch der zugehörigen PCIe-Bridge. Man muss immer beide Seiten der Verbindung betrachten.

    Das muss nicht zwingend was bedeuten, da die Register nicht gelöscht werden, kann es auch nur ein einziger uralter Fehler sein. Um es beurteilen man muss man die Register löschen und warten, ob erneut ein Fehler auftritt.


    (Bei mir war bei einem Device, natürlich der berüchtigten ASM PCI-Bridge ;D, UncorrErr+ drin gestanden. Nach dem Löschen ist der aber bislang nicht wieder gekommen. Daher wird das wohl von der Initialisierung her kommen und unkritisch sein.)


    Hier ist das alles noch mal ganz schön erklärt: billauer.co.il...pcie-tlp-dllp-retransmit-data-link-layer-error

    Mit ECAP_AER hat es bei mir nicht immer funktioniert, CAP_EXP ging aber und sollte reichen zu beurteilen wie häufig Fehler auftreten. Man muss das Skript entsprechend anpassen.

    Die interessanten Devices sind 02:00.0 (DD) und 00:13.1 (Bus: primary=00, secondary=02).

    Dann sollte man noch die Netzwerkkarte im Auge behalten (01:00.0 00:13.0). Evtl. das auch noch mal mit der Intel-NIC durchführen um den Slot zu überprüfen.

    Wenn man dabei die Fehler protokolliert, sollte man am Ende eigentlich wissen ob die Ursache am PCIe-Link liegt und an welchem.


    Testen kann ich mangels DD-Karte leider nicht, aber trotzdem eine Frage dazu:

    Rsync läuft auf ein, per nfs, samba oder was-auch-immer, gemountetes Verzeichnis, oder rsync direkt übers Netzwerk?

    Keine Ahnung ob das einen Unterschied macht, aber besser man testet es auch genau so.


    kpti=off nopcid nopti nospectre_v1 nospectre_v2 nospec_store_bypass_disable pr_spec_disable_noexec

    Mit den Optionen sollten eigentlich alle Spectre-Geschichten deaktiviert sein. (Das hoffe ich zumindest mal.)

    Ist einen Versuch wert, denke ich.


    Da es auch mit einer anderen Netzwerkkarte zu den Problemen kommt, könnte man noch an den PCIe-Parametern drehen.

    Ich vermute, dass die Cine wegen der vielen Pakete von der Netzwerkkarte zu selten an die Reihe kommt um ihren internen Puffer ganz leer zu bekommen. Eine Weile geht das, aber irgendwann kommt noch ein Ereignis, der Puffer läuft über und die Karte oder der Treiber hängt sich (warum auch immer) auf.

    In dem Zusammenhang wäre es echt interessant, was die LED bedeutet.

    Meine Vermutung ist, die hat mit dem Füllstand des FIFO auf der Karte zu tun. Das würde passen.


    Das Problem trat so ähnlich schon bei den PCI-Karten auf. Bei den FF-Karten brachte ein erhöhen der PCI-Latency bei mir auch immer was an Stabilität. Mit der voreingestellten Latency konnten die Karten den internen Puffer nicht in einem Zug leeren, wenn er ganz voll war.


    An den PCIe-Parametern habe noch nicht rumschrauben müssen, kann also nicht so genau abschätzen was es bringt.

    Ich würde aber mal versuchen die MaxReadReq der Cine, nach dieser Anleitung, auf 4096 zu erhöhen.

    Man könnte auch noch versuchen die MaxReadReq Netzwerkkarte auf 512 zu senken.



    Eventuell könnte man auch die Priorität des DD-Treibers erhöhen.

    Ob das auf Kernel-Ebene geht weiss ich aber nicht.

    Soeben kam im Log diese Meldung:


    kernel: [ 6046.137805] r8169 0000:01:00.0: invalid large VPD tag 7f at offset 0

    Das kommt bei meinem Arbeitsrechner auch.

    Ist mir aber eben erst aufgefallen. Probleme gibt es keine, auf dem System läuft aber kein VDR.


    Sieht hier genau so aus.

    r8169 am Arbeitsrechner, r8168 am VDR.

    Warum ich da den r8168 weiss ich nicht mehr. Wird aber einen Grund gehabt haben.


    Merkwürdig ist, dass der r8168 keine Firmware braucht. Da ist nicht mal was dazu erwähnt.

    Witziger weise laufen die Karten auch mit dem r8169 ohne Firmware. Das Phänomen ist mir vor Jahren mal aufgefallen.

    Es gibt eine Fehlermeldung beim Laden des Moduls, gehen tut es aber trotzdem.


    Das ganze sagt aber nicht unbedingt was aus. Es könnte sich um unterschiedliche Chips handeln, es gibt da so viele Varianten und Versionen.


    Glaub zwar nicht, dass es dir viel hilft ...

    Wirklich sinnvoll ist es nur die Ausgaben der DD- und der Realtekkarten auf möglichst ähnlichen Boards zu vergleichen.


    Ein PCIe-Slot wäre zwar frei, der Einbauplatz ist aber belegt durch eine Receiver-Karte.

    Könnte man die Huckepackkarte nicht testweise ausbauen oder verlängern?

    Eine andere Netzwerkkarte wäre die einfachste Option das Problem einzugrenzen.

    Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?

    Ist nicht drauf.

    Ausserdem hat nur die Rev. 01 den Fehler und die wird seit mindestens Mitte 2013 nicht mehr verbaut.

    Bei neueren Mainboards sollte man sicher sein.

    Meine beiden mit Rev. 03 laufen auch seit Jahren zuverlässig.



    Bei der Suche bin ich zufällig auf diesen Artikel gestossen:

    Der r8169-Treiber für den Realtek-Netzwerkchip funktioniert bis zur Kernelversion 4.16 nicht immer korrekt. Es können Timeouts entstehen, die Netzwerkkarte zwischen den Zuständen link up/link down wechseln sowie Bandbreitenprobleme oder sogar Systemabstürze vorkommen.


    Eine Lösung des Problems besteht in der Installation des offiziellen r8168 Treibers von Realtek statt dem r8169 des Linux Kernels. Er kann aus Fremdrepositories nachinstalliert oder selbst kompiliert werden. Alternativ kann der Kernel auf Version 4.17+ aktualisiert werden.


    [...]

    Falsche Kernel-Header? Ist aber nur geraten.

    Im Zweifelsfall alle deinstallieren, die nicht verwendet werden sollen.

    Die LEDs zeigen, daß der PCIe-Link instabil wird

    Gibt es eine Beschreibung was die genau anzeigen?

    ich konnte nichts finden.


    Code
    1. lspci -vv

    Gibt einiges an Einstellungen der PCIe Geräte aus.

    Das könnte man auch noch vergleichen, vielleicht sieht man da Unterschiede.


    Zum BIOS:

    Das jeweilige vom J3355M und J3455M ist binär identisch.

    Daran kann es jedenfalls nicht liegen, dass es bei rjkm geht und bei kls nicht.

    Da es ja bei rjkm geht, könnte es auch am Kernel liegen.

    Anfangs gab es Probleme, weil die Boards noch nicht unterstützt waren, das sollte aber jetzt von Tisch sein.

    Dann meine ich mich zu erinnern, dass es auch mit den Spectre/Meltdown Patches und einigen PCIe Devices Ärger gab.

    Die sollte man zum Test mal deaktivieren. Aber allein das ist wohl schon ein umfangreicheres Thema: Ubuntu: MitigationControls

    SuSE ist da, zumindest anfangs, einen eigenen Weg gegangen. Die haben da einiges an zurück portiert.

    Im Zweifelsfall würde ich es noch mit einem neuen Kernel, bzw. einer anderen Distro (am besten der von rjkm ) versuchen.

    Bei 60°C sollte thermal throttling eigentlich kein Thema sein.

    Die Interruptverteilung sieht für mich auch grob sinnvoll aus. eth0 und DDbridge sind auch unterschiedlichen CPUs zugeordnet.

    Die Zahlenwerte sind die aufgetretenen Interrupts seit Systemstart. Da ist es etwas schwer festzustellen, wenn ein Gerät amok läuft.

    Da müsste man schauen, ob einer der Zähler ungewöhnlich schnell hoch (>1000/s) läuft.


    Die Gesamtzahl der Interrupts pro Sekunde zeigt auch :

    Code
    1. vmstat 1

    (Das 1 aktualisiert sekündlich, die Ausgabe in eine Datei umleiten ist also nicht verkehrt.)

    Auch die anderen Werte von system und cpu könnten interessant sein. Erklaerung und Beurteilung der ausgegebenen Werte

    Wenn der Fehler auftritt müsste man eigentlich irgendwas sehen. Eventuell kann man aus dem Zustand in dem die CPU dann läuft Rückschlüsse ziehen was da passiert.


    Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem. Möglicherweise kommen da aber nicht so viele Daten in so kurzer Zeit zusammen wie bei einem rsync.

    Was passiert denn, wenn man den Prozessor etwas traktiert

    Code
    1. nice -n19 cat /dev/zero > /dev/null

    Natürlich einmal je CPU-Kern.


    Wenn das alleine keine Probleme verursacht, dann zusammen mit rsync.


    Unter Umständen verbessert sich die Stabilität dabei, weil der Prozessor nicht mehr runter taktet.

    Selbst das Ausführen des Reboots dauert eine Weile. Aber immerhin schafft er es, wieder hochzukommen. Ein Reset ist nicht nötig.

    Man könnte versuchen, ob es reicht nur den VDR zu beenden und die Kartentreiber zu entladen

    (runvdr).


    Zur Belüftung des Gehäuses habe ich einen langsam drehenden Lüfter in Betrieb, so dass ein Wärmestau eigentlich auch ausgeschlossen sein dürfte.

    Trotzdem können einzelne Komponenten zu warm werden, wenn sie nicht genug Luft abbekommen.
    DVB-Hardware würde ich bei den geschilderten Symptomen inzwischen für unwahrscheinlich halten.


    Wenn der Prozessor zu warm wird und ins throttling gerät könnte das aber passen.

    Die CPU-Temperatur ist aber einfach zu überprüfen.



    Da jetzt einige Meldungen mit Interrupts kamen, wäre es interessant mal zu schauen, was sich da tut.

    Code
    1. watch -tn1  cat /proc/interrupts

    Wenn die Meldungen stimmen, muss irgend ein Gerät das System mit Interrupts fluten. Das müsste man eindeutig sehen können.


    Da der Fehler durch kopieren von Daten über das Netzwerk zu provozieren ist, gerät die Netzwerkkarte auch in Verdacht.

    Zu dem RTL8111 gibt es auch einen alternativen Treiber (r8168), der nicht im Kernel ist. Der könnte einen Versuch wert sein.

    Den musste ich anfangs (einige Jahre her) verwenden, weil der aus dem Kernel (r8169) noch nicht so recht wollte. Debian bietet den r8168 als DKMS-Paket (non-free) an, SuSE weiss ich leider nicht.


    Verteilen sich die Interrupts denn einigermassen gleichmässig über die CPU-Kerne?


    Was wäre denn als Alternative zum Asrock J3455M geeignet? Sinnvollerweise wohl von einem anderen Hersteller.

    Von Asrock gibt es einen Nachfolger mit J4105 Celeron (µATX).

    Mit der oder einer ähnlichen CPU gibt es sonst nur ITX-Boards. D.h. du hättest nur einen Slot.

    Da ist die Auswahl aber recht übersichtlich, ein zwei Boards pro Hersteller, insgesamt keine 10.

    Wenn man Asrock ausklammert, sieht es bei den aktuellen CPUs aber (noch?) schlecht aus.


    Bei den aktuellen Sockel 1151v2 Boards hat Fujitsu zwei im Angebot, recht interessant aussehen: D3642-B und D3643-H

    Intel NIC, sehr schön aufgeräumt und sparsam sollen die auch sein.

    Die Boards erinnern mich an die, die Intel früher selber verkauft hat.


    MSI hat auch "kleine", nicht überladene 1151v2 Boards mit Intel-NIC am draussen.

    Wenn der Rechner mal in diesem Zustand ist, hilft nur noch ein kompletter Reboot.

    Ein entladen und neu laden der Kernel-Module bringt nichts?

    Oder ist das schon nicht mehr möglich?


    "kompletter Reboot" heisst Linux mit reboot herunter fahren?

    Oder ist es nötig Reset zu drücken?



    Obwohl anscheinend viel in Richtung BIOS deutet:

    Die üblichen Verdächtigen, wie lose Kabel und Überhitzung der Tuner kann man ausschliessen?

    Irgendwann hatte jemand auch Probleme mit den Kabeln zu den Tunern. Abschirmen mit Alufolie hat da angeblich geholfen. Den Thread hab ich aber eben nicht finden können.

    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.



    Quote

    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.