Posts by Dr.Nop

Prinzipiell:

Die maßgebliche Anleitung für das Entbranden und Updaten der Cable Boxen ist hier (funktionierend und sicher!):

https://www.ip-forum.eu/howto-…ei-fritz-box-cable-160-50

Dein Fall:

Die 6490 bietet über die Oberfläche nur den Router Betrieb (also NAT und Firewall zwischen dem "Internet" und dem internen Netz).

Das "Internet" kann entweder am anderen Ende des Kabelmodems sein, oder an LAN1.

Du willst aber eine Bridge zwischen allen LAN Anschlüssen und dem WLAN.

Deiner 6490 einfach eine IP-Adresse aus deinem lokalen Netzwerk geben, den DHCP Server abschalten und sie völlig ohne box-eigene Internetverbindung zu nutzen sollte möglich sein und deinen Zweck erfüllen.

Die Chancen stehen gut, dass mit der neuen FritzOS Version 7 das Problem der Vergangenheit angehören wird:

[Info] FRITZ!Box 6590 Cable / FRITZ!OS 7.00 vom 28.08.2018

Wenn es nicht all zu dringend ist, einfach noch etwas Geduld, bis die für die 6490 erscheint.

Bei IPv6 ist es so vorgesehen, dass der Dyndns Dienst auf deinem Server läuft. Die Fritzbox kümmert sich nur um die Löcher in ihrer Firewall und um sich selbst.

Du hast offensichtlich auf deinem Server die IPv6 Privacy Extensions aktiviert. Dadurch werden nach Ablauf einer gewissen Zeit immer wieder neue IPv6 Suffixe erzeugt. Für einen Server taugt das nicht.

Wenn die Privacy Extensions deaktiviert sind, erzeugt der Host eine dauerhaft konstantes Suffix aus der MAC Adresse der Netzwerkschnittstelle. Die FritzBox bekommt es hin, dass entsprechende Portfreigaben nach einem Präfixwechsel erhalten bleiben. Man erkennt diese Adresse an den Bytes FF:FE in der Mitte des Suffixes.

Je nach OS hat man auch mit aktivierten PEs eine zusätzliche konstante Adresse. Dann reicht es, in der FritzBox diese einzusetzen.

Ich benutze momentan ein T6963C basiertes Display am Parallelport. Da diese Lösung jedoch nicht zukunftsfähig erscheint und eventuell auch bald ein Umstieg auf einen Raspberry Pi notwendig wird, hätte ich sehr Interesse an solch einer Lösung.

Das Display an sich ist noch schön und praktisch ist es auch, vor allem wenn man nur Radio hören will.

dd .... oflag=sync ... schaltet das Caching ab.

Aus der "Tabelle" wird mir nicht zu 100% klar, wie genau deine Installation aufgebaut ist, aber ich vermute, dass auf dem Raspberry Pi der"Rückweg" fehlt, also keine Route in das 35er Netz existiert. Somit kommen die Pakete am Raspberry Pi an, aber die Antworten nicht.

Probier doch zuerst mal alle Verbindungen Schritt für Schritt mit Ping aus. Mich würden die Netzwerk Devices mit ihren IP Adressen und die Routen auf den ganzen Stationen interessieren, um gezielt helfen zu können.

Hier noch ein Hinweis:
serial_ir aus dem Kernel 4.10 hat noch diverse Fehler (z.B. werden Tastendrücke falsch wiederholt, speziell wenn man den rc5 Decoder aus dem Kernel benutzt).
Entweder auf 4.11 warten oder media_build benutzen.

Hallo,
hat jemand zufällig gerade eine Stückliste mit den benötigten Bauteilen parat, die er hier posten kann ?

Der Multiproto Treiber unterstütz DVB-S2.

Es gibt den Hauptzweig, da kommt alles rein, was in den Kernel übernommen werden soll. Immer wenn Linus das Mergewindow öffnet, werden die Änderungen mit den DVB-Treibern im Kernel synchronisiert.
Dann gibt es noch diverse Zweige, wo Leute Dinge programmieren, die eher experimentellen Charakter haben, und deshalb noch nicht in den stabilen Hauptzweig übernommen werden.
Einer ist z.B. der multiproto-Zweig, in dem Änderungen enthalten sind, welche unter anderem den Empfang von DVB-S2 ermöglichen. Leider gab es Streit zwischen den Entwicklern des Hauptzweiges und dem von Multiproto, weshalb es vermutlich noch mehrere Monate dauern wird, bis multiproto in den Hauptzweig übernommen wird.

Das wird leider nicht funktionieren, da ein CD-Brenner beim Brennen mit speziellen Befehlen angesteuert werden muss, welche Samba nicht übers Netzwerk transportieren kann. Es gibt aber irgendein Brennprogramm, welches übers Netzwerk funtioniert. Auf dem Server läuft ein Dämon und für den Client gibts eine Java Applikation, leider habe ich den Namen vergessen, mit Google sollte man es aber finden können.

a) Lass mal memtest laufen. Einfach so, um für den Fall der Fälle Speicherfehler ausschließen zu können.
b) Ist es ein Netzwerkchip von VIA ? Ich hatte mehrfach so ein Verhalten bei diesen Chips, manchmal konnte ich es durch den Austausch des Netzteils beheben. Offensichtlich reagieren die empfindlich.

Ich geh morgen.

Quote

Original von TomK79

Ist zu erwarten, dass dieses Mainboard mit allen Features, also der Hardwarebeschleunigung, unter Linux laufen wird?

Nein. Nicht kurz- und nicht mittelfristig. Schon alleine deshalb weil es noch kein fertiges API gibt für nicht-MPEG2-Videobeschleunigung, was mal die Grundlage wäre für so ziemlich alles andere.

Könnte man den cuttime-Patch in den hlcutter-Patch integrieren ? Wäre eine kleine Vereinfachung.

Ich bin auf 2 Probleme gestoßen im Zusammenhang mit dem LiveBuffer Patch. Ich verwende VDR 1.5.13 und den LiveBuffer-Test2.
1) Die Option -a funktioniert bei mir nicht mehr. VDR startet einfach das angegebene Programm nicht.

2) Lässt man den Puffer im Arbeitsspeicher anlegen und startet das MPlayer Plugin, wird der VDR wegen Speichermangel getötet. Das MPlayer Plugin startet mit fork() einen neuen VDR Prozess, der gesamte verbrauchte Speicher wird dabei kopiert. Das reicht dann nicht mehr. Die Frage ist jetzt nur, wo man das am besten behebt.

Beim Laden der Treiber gab es Probleme mit Syscalls, welche durch das Frontend Modul registriert wurden. Ich habe die entsprechenden Stellen aus dem Quellcode entfernt, jetzt läufts.

Ich benutze ein 64bit LFS mit glibc-2.4 und gcc 4.2.0, Kernel 2.6.24-rc6.

Ich musste für den Kernel 2.6.24-rcX Anpassungen an den bisher veröffentlichen Treibern vornehmen. Ich habe alles mal hier hingepackt. Möglicherweise geht es ja so.

So ein Quatsch. Ich habe mehrere 2.6.24-rcX Kernel auf verschiedenen VDRs am Laufen, Änderungen am System mussten nicht durchgeführt werden.