CoreELEC Amlogic

    Besten Dank für den Tipp Raybuntu
    "Wait for network..." ist auf jeden Fall aktiviert, weil ich auch geschlussfolgert habe, dass es an dieser Stelle liegen muss. Allerdings verwende ich auch eine festeIP (eben weil ich dachte, dann ist das Netzwerk sofort da). Habe sogar schon eine "autostart.sh" mit

    Bash
    #!/bin/sh
ifconfig eth0 up
ifconfig eth0 192.168.x.x
route add default gw 192.168.x.x

    versucht. Aber auf DHCP zu setzen habe ich garnicht erst getestet. Bin leider gerade nicht Zuhause. Werde heute Abend nochmal Rückmeldung geben.

    Zitat von Raybuntu

    @infinity: Ich hab soweit alles abgeschlossen mit iptables und denke das ist jetzt ok so:
    https://github.com/Raybuntu/Libre…c506607afe40996
    Hab da nun noch einiges geändert wie die Regeln geladen werden.
    Erlaubt sind die privaten subnetze nur noch über eth+, en+ und wl+. Damit sollten alle physischen Adapter abgedeckt sein. Was ich jetzt noch gerne hätte wäre eine Einstellung in den LE Settings wo man die Filter allgemein abschalten kann. Wenn man zu viel spielt könnte man sich evtl. aussperren (mir selbst passiert).

    Ich bin leider auch in dieser Thematik ein Laie, jedoch kann ich zumindest einige der Regeln nachvollziehen und finde den Ansatz der Whitelist für eth+ usw. ziemlich logisch. Die "Backlist"-Regel für das tun+ aus deinem vorigen Post ist da nun nicht drin. Aber so wie ich das verstehe wäre sie deinem jetzigen Ansatz nach eher redundant, oder?
    -A INPUT ! -i tun+ -s 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 -m state --state NEW -j ACCEPT
    Wenn ich die dennoch hinzufügen wollen würde, an welcher Stelle könnte ich das machen? Ich lese bei iptables nämlich öfter den Hinweis, dass die Reihenfolge wichtig ist, da eine Regel an der chronologisch falschen Stelle alle davorliegenden aushebeln könnte.

    Ich finde ansonsten auch, dass diese Iptables-Filter zum LibreELEC Standardfeature gehören sollten. Am besten in dem LibreELEC Settings, da wo man auch den Network Delay und DHCP einstellen kann usw. Wie du schon sagst... man kann sich schnell mal aussperren (auch mir ist das schon passiert, haha) und wenn man zumindest die Option in der GUI hat, kann man das mit einer IR- oder CEC-Fernbedienung wenigstens noch rückgängig machen. Vielleicht wird ja jemand noch mal irgendwann ein Addon dazu machen.
    Momentan ist es sowieso klasse, dass du dir da die Mühe gemacht hast, das einzubringen und zudem dank der Readme auch die Funktionsweise zu dokumentieren, damit auch jemand wie ich versteht, wie man damit noch rumspielen kann. Habe nämlich bei deiner Krypton13 echt gegrübelt, wie ich Iptables nun eigentlich ausgeschaltet bekomme, wenn ich mal so einen cross-check machen will.

    Klasse und mal wieder danke für die super Arbeit!!

    @infinity Diese Regel würde ich nicht einfügen. Ich habe mich dagegen entschieden da sie nicht der Philosophie der Regeln entspricht die ich haben will. Grundsätzlich ist ja erstmal alles Verboten was nicht erlaubt ist. Die Reihenfolge ist auch sehr wichtig. Die Regel besagt: Akzeptiere neue Verbindungen aus folgenden Subnetzen auf allen Netzwerkschnittstellen die NICHT mit "tun" anfangen. Diese Schnittstellen Namen sind aber frei wählbar. Ich kann z.B für tun0 auch vpn0 nehmen. Deswegen hab ich mich lieber entschieden NUR explizit Schnittstellen Namen zu erlauben die für Ethernet und Wlan verwendet werden. Das sind unter LE: eth+ und wlan+. Um Zukunftssicher zu sein habe ich auch en+ und wl+ erlaubt. Das sind die neuen Schnittstellen Namen die von systemd vergeben werden. Ubuntu, ARCH Linux etc. nutzen diese neuen "Vorhersehbaren" Namen bereits. Soweit ich weiß macht LE das nicht jedoch kann ich nicht sicher sein das es in Zukunft auch so bleibt.

    Aaah! Das ist clever und sehr logisch. Zudem tolle Voraussicht, danke!

    Vielleicht könntest du das sogar in der Readme so erläutern? Finde das durchaus wichtig, sodass jeder die zugrunde liegenden Gedankengänge/Philosophie deiner Regeln versteht und somit auch die Struktur leichter verständlich ist. Dann fällt es jedem auch leichter bei Bedarf zusätzliche Regeln hinzuzufügen oder sowas wie tun+ wegzulassen. Ich bspw habe das natürlich nicht bedacht, dass das whitelisten nur bestimmter Interfaces viel allgemeingültiger ist, als das stumpfe blacklisten von tun+/vpn+, welches sich irgendwann evtl. Bezeichnungstechnisch ändert oder sowas.


    Zitat von Raybuntu

    Grundsätzlich ist ja erstmal alles Verboten was nicht erlaubt ist

    Dies erfasst dann auch generell alle Verbindungen die unaufgefordert durch ein tun+ etc. kämen, ja? Also egal was für ein subnetz (lokal, oder internet-global). Streaming (aufgefordert) sollte also durchkommen, aber jemand der einfach meine vpn ip abgreift und daraufhin über diese IP:8080 bzw. IP:22 oder auch nen "ping IP" durchführen will (dementsprechend unaufgefordert), kriegt nen timeout?

    Zitat von infinity

    Aaah! Das ist clever und sehr logisch. Zudem tolle Voraussicht, danke!

    Vielleicht könntest du das sogar in der Readme so erläutern? Finde das durchaus wichtig, sodass jeder die zugrunde liegenden Gedankengänge/Philosophie deiner Regeln versteht und somit auch die Struktur leichter verständlich ist. Dann fällt es jedem auch leichter bei Bedarf zusätzliche Regeln hinzuzufügen oder sowas wie tun+ wegzulassen. Ich bspw habe das natürlich nicht bedacht, dass das whitelisten nur bestimmter Interfaces viel allgemeingültiger ist, als das stumpfe blacklisten von tun+/vpn+, welches sich irgendwann evtl. Bezeichnungstechnisch ändert oder sowas.


    Dies erfasst dann auch generell alle Verbindungen die unaufgefordert durch ein tun+ etc. kämen, ja? Also egal was für ein subnetz (lokal, oder internet-global). Streaming (aufgefordert) sollte also durchkommen, aber jemand der einfach meine vpn ip abgreift und daraufhin über diese IP:8080 bzw. IP:22 oder auch nen "ping IP" durchführen will (dementsprechend unaufgefordert), kriegt nen timeout?

    Ja die Default policy ist DROP. In der Output Chain sind ja alle neuen Verbindungen erlaubt. In der Input Chain sind zudem established und related Verbindungen erlaubt. Das heißt es kommen nur Pakete durch die du selbst beantragt hast.

    Jemand der "nmap" nutzt um deine VPN IP zu scannen würde nicht sehen das du z.B Port 22 offen hast. Bei einem Reject würde man den Port als "filtered" sehen bei einem Drop kommt ein timeout. Pingen geht auch nicht.

    Super, das ist perfekt :)

    Wenn ich nun deine aktuellsten Regeln in deiner Krypton13 build nachtrage, werden die dann eigentlich überschrieben mit der irgendwann kommenden Krypton14 (wo sie dann ja im aktuellsten Stand drin sind)? In Krypton13 ist ja momentan noch dein erster Schwung an Regeln drin.
    Grundsätzlich gilt das auch für eigene Anpassungen der regel-dateien: Besser vor einem buildupdate ein Backup der beiden v4 und v6 regelfiles anlegen, oder? Wenn man eh selbst rumgefummelt hat, weiß man ja, dass man das bei Updates im Hinterkopf haben sollte.

    Zitat von infinity

    Super, das ist perfekt :)

    Wenn ich nun deine aktuellsten Regeln in deiner Krypton13 build nachtrage, werden die dann eigentlich überschrieben mit der irgendwann kommenden Krypton14 (wo sie dann ja im aktuellsten Stand drin sind)? In Krypton13 ist ja momentan noch dein erster Schwung an Regeln drin.
    Grundsätzlich gilt das auch für eigene Anpassungen der regel-dateien: Besser vor einem buildupdate ein Backup der beiden v4 und v6 regelfiles anlegen, oder? Wenn man eh selbst rumgefummelt hat, weiß man ja, dass man das bei Updates im Hinterkopf haben sollte.

    Ja ich hab das in k13 etwas anders gemacht. Da gab es nur die Regeln in /storage/.config/iptables/rules.v4 (v6). Das Problem ist wenn man die Datei löscht wird sie wieder neu angelegt. Wenn man sie ändert bleiben die Änderungen erhalten auch mit einem tar update. Jetzt hab ich das etwas "besser" gemacht. Die Regeln dich ich liefere liegen jetzt unter /etc/iptables/globalrules.v4 (v6). Diese werden immer geladen und auch geupdated. Der User kann seine eigenen Regeln in /storage/.config/iptables/localrules.v4 (v6) festlegen. Diese werden nicht überschrieben und wenn man die Datei wieder löscht werden die globalen Regeln geladen. Das heißt /storage/.config/rules.v4 (v6) macht dann nix mehr und man muss eigene Regeln dann in localrules.v4 migrieren.

    Du kannst in den localrules.v4 auch was komplett eigenes machen z.b Default policy accept und dann alles explizit verbieten (also genau andersrum als ich das mache).

    Perfekt. Also konform mit der generellen LibreELEC Handhabe was overriden von Systemeinstellungen für samba.conf, keyboard.xml und und und gilt. Default ist im ReadOnlyBereich und eigene können über die Storage Partition bei Bedarf eingesetzt werden. Genial :).

    Angenommen jemand wird diese Geschichte mal in der GUI als Button ermöglichen, dann wäre es da am sinnvollsten eine Art Timeout von 30s oder 60s zu machen. Wenn man in der Zeit seine Regeln nicht über einen Button bestätigt, werden die einfach wieder auf den vorigen Zustand zurückgesetzt, damit man sich nicht dauerhaft aussperrt. So ähnlich ist es bei manuellen Auflösungsänderungen ja auch bei vielen Geräten. Nur so als Spinnerei.


    Bitte Krypton14 mit diesem iptables system releasen, bitte bitte :D

    Ist es möglich, dass im Hyperion Package ein Fehler vorhanden ist? Denn mit Boblight habe ich kein Problem, dass mein Ambilight funktioniert.
    Ich habe jetzt verschiedene Szenarien getestet.
    HEVC + Echo 1 befehl + Hyperion = Ruckeln
    HEVC + ohne Echo 1 befehl + Hyperion = Ruckeln
    HEVC + ohne Echo 1 befehl + ohne Hyperion = kein ruckeln
    HEVC + Echo 1 Befehl + ohne Hyperion = kein Ruckeln
    HEVC + Echo 1 Befehl + Boblight = kein Ruckeln.

    Hallo Raybuntu,

    könntest du bitte beim Kernel das Modul usbserial und ftdi_sio aktivieren ? Es geht darum eine Smartmouse als Cardreader zu nutzen.

    [errorbox]
    [ 5057.599757@2] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
    [ 5057.705571@2] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
    [ 5057.705583@2] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 5057.705588@2] usb 1-1.3: Product: FT232R USB UART
    [ 5057.705593@2] usb 1-1.3: Manufacturer: FTDI
    [ 5057.705598@2] usb 1-1.3: SerialNumber: A7031YRI
    LibreELEC:~ # modprobe ftdi_sio
    modprobe: FATAL: Module ftdi_sio not found in directory /lib/modules/3.14.29
    [/errorbox]

    es geht darum, eine Schnittstelle ttyUSB0 zu bekommen

    Kannst du mir auch bitte ganz kurz erklären was die Unterschiede zwischen den branches sind (Krypton, 8beta und master) ?

    Kann es sein. dass der master Zweig ein "reines" 64bit System ist ?

    Danke, lg Martin

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden