.titleBar { margin-bottom: 5px!important; }

[Problem] FB 7490 - freetz-trunk - Neues Freetz Image funktioniert nicht

Dieses Thema im Forum "Freetz" wurde erstellt von JokerGermany, 31 Aug. 2017.

  1. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ich nutze ein Ubuntu 16.04 und habe es seit dem letzten Image erstellen neuinstalliert.
    Habe jetzt svn up gemacht um die neueste Revision zu bekommen und ein paar packages dazu ausgewählt.
    Wollte jetzt von
    7490_06.83-freetz-devel-14163M.de_20170318-133702.image
    auf
    7490_06.83-freetz-devel-14389M.de_20170831-213639.image
    wechseln

    Ich mache das Update über Freetz und wähle aus alles anzuhalten.

    Ausgabe ist:
    1. Box
    Code:
    ./var/
    ./var/chksum
    ./var/info.txt
    ./var/tmp/
    ./var/tmp/filesystem.image
    ./var/tmp/kernel.image
    ./var/.packages
    ./var/install
    ./var/.config
    ./var/regelex
    
    2.Box
    Code:
    install: have Kernel 3.10.73 - set kversion '3.10' and FlashUpdateTool '/lib/modules/3.10.73/kernel/drivers/char/flash_update/flash_update.ko'
    install: check and install new firmware ...
    OEM=
    ANNEX=B
    testing acceptance for device Fritz_Box_HW185 ...
    korrekt install type: mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
    device has installtype mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
    OK - accept this update for device Fritz_Box_HW185 ...
    testing acceptance for device Fritz_Box_HW185 done
    curr: 113.06.83  new: xx.06.83
    debug: curr: 113.06.83
    debug: new: "XX.06.83"
    major_currFWver=113
    middle_currFWver=6
    minor_currFWver=83
    middle_newFWver=6
    minor_newFWver=83
    check Firmware Version: xx.06.83
    DEBUG: 6 >= 6
    DEBUG: 83 >= 83
    Accept Firmware Version: xx.06.83
    install: 3.10 check files...
    read 0xd4f7567 MACIG 0xc453de23
    File already contains the checksum, verifying
    [cs_calc_sum] sum 0xd4f7567
    Calculated checksum is D4F7567
    Saved checksum is D4F7567
    Checksum validation successful!
    chksum for file /var/tmp/filesystem.image ok
    size for file /var/tmp/filesystem.image ok
    read 0x22751fb MACIG 0xc453de23
    File already contains the checksum, verifying
    [cs_calc_sum] sum 0x22751fb
    Calculated checksum is 22751FB
    Saved checksum is 22751FB
    Checksum validation successful!
    chksum for file /var/tmp/kernel.image ok
    size for file /var/tmp/kernel.image ok
    install: 3.10 getting mtds to install...
    install: --mtd------------------------------------------------
    install: --assert---------------------------------------------
    install: --addr+size------------------------------------------
    install: kernel_start=0x00000000
    install: kernel_size=4194304
    install: kernel_image_size=2505736
    install: filesystem_start=0x00400000
    install: filesystem_size=50331648
    install: filesystem_image_size=26894600
    install: 3.10 writing commands to install...
    install: check for old settings ...
    set INFO led to blink (modul=7, state=4)
    
    3.Box
    Code:
    #! /bin/sh
    echo $0: start
    sleep 1
    killall run_clock
    if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
    if ps | grep -v grep | grep -q telnetd ; then killall telnetd ; fi
    echo skip deleting language from env
    echo MODE=update > /dev/avm_power
    echo "disable" > /dev/watchdog
    echo still running:
    ps
    lsmod
    sleep 1
    update_state=good
    echo Erase mtd partitions '2' and '3' ...
    /sbin/update_kernel -o /dev/mtd2
    /sbin/update_kernel -o /dev/mtd3
    echo Copy kernel image...
    /sbin/update_kernel -i /var/tmp/kernel.image  -o /dev/mtd2
    [ $? -ne 0 ] && echo failed with error "$?" && update_state=bad
    echo Copy filesystem image ...
    mkdir -p /var/tmp/fs
    mkdir -p /var/tmp/fs_mtd
    mount -t squashfs /var/tmp/filesystem.image /var/tmp/fs
    mount -t yaffs2 /dev/mtdblock3 /var/tmp/fs_mtd
    var_mount_squashfs=`mount | grep "/var/tmp/fs type squashfs"`
    if [ -z "$var_mount_squashfs" ] ; then
        echo filesystem.image: cannot mount squashfs, trying ext2 ...
        mount -t ext2 -o loop,offset=256 /var/tmp/filesystem.image /var/tmp/fs
        if ! mount | grep -q "/var/tmp/fs type ext2" 2>/dev/null; then
        dd if=/var/tmp/filesystem.image of=/var/tmp/fsimage.ext2 bs=256 skip=1
        [ "$?" -eq 0 ] && mount -t ext2 /var/tmp/fsimage.ext2 /var/tmp/fs && rm -f /var/tmp/filesystem.image
        fi
        var_mount_ext2=`mount | grep "/var/tmp/fs type ext2"`
        [ -n "$var_mount_ext2" ] && echo filesystem.image: ... mount ext2 done
    fi
    var_mount_mtd=`mount | grep /dev/mtdblock3`
    if [ -z "$var_mount_squashfs" ] && [ -z "$var_mount_ext2" ] ; then echo failed to mount filesystem.image ; update_state=bad; fi
    [ -z "$var_mount_mtd" ] && echo failed to mount /dev/mtdblock3 && update_state=bad
    if [ "$update_state" = "good" ] ; then
        echo Copy filesystem ...
        cp -R /var/tmp/fs/* /var/tmp/fs_mtd
        [ $? -ne 0 ] && echo failed with error "$?" && update_state=bad
        echo ... Copy filesystem done
    fi
    if [ "$update_state" = "good" ] ; then
        echo Setting linux_fs_start mirror...
        echo linux_fs_start 1 > /proc/sys/urlader/environment
    else
        echo Setting linux_fs_start skipped due to errors...
    fi
    umount /var/tmp/fs
    umount /var/tmp/fs_mtd
    rmdir /var/tmp/fs
    rmdir /var/tmp/fs_mtd
    echo clear_id 95 >/proc/tffs
    echo clear_id 96 >/proc/tffs
    exit 0
    
    Ergebnis:
    Fritz!Box startet neu, Power/DSL leuchte leuchtet sofort dauerhaft.
    Rechner bekommt kurz Netzwerk, verliert es wieder und bekommt wieder Netzwerk.

    Sonst passiert nichts.
    Fritzbox ist wie tod.

    Über die linux_fs_start kommt man dann ans Backup...
     

    Anhänge:

  2. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Das hat zwar vermutlich mit dem Start nichts zu tun, aber was veranlaßt Dich denn, bei einer 06.83 (wo AVM auch die 1.0.1 verwendet) auf einmal eine OpenSSL-Version 0.9.8 benutzen zu wollen?

    Ansonsten ist ohnehin die Beschreibung des Startvorgangs etwas zu dünn für eine echte Idee, ob da am Ende der Kernel überhaupt geladen wird oder ob das Dateisystem nicht gelesen werden kann oder, oder, oder ... die Möglichkeiten sind vielfältig und aus der Beschreibung kann man dazu praktisch nichts entnehmen.

    Bei solchen Problemen braucht es die Stoppuhr, den Notizzettel (meinetwegen auch elektronisch) und ein paar Versuche, damit man die protokollierten Zeiten und die Reaktionen der LEDs auch noch einmal selbst verifizieren kann, bevor man sie hier aufschreibt.

    Der Bootloader ist ja offenbar nicht defekt und dann kann es eigentlich kaum sein, daß die Power-LED gleich konstant leuchtet ... die Box müßte wenigstens erst einmal für einige Sekunden blinken, während EVA auf die FTP-Verbindung wartet.
     
  3. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Keine Ahnung, vermute die kommt aus dem OpenVPN Paket?

    Sie blinkt aber gar nicht...
     
  4. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @opto:
    Heißt das, irgendetwas aus dem Fork von Gene funktioniert beim "avm_kernel_config" nicht wie vorgesehen? Ich habe das nicht weiter verfolgt. Oder ist es ein anderes Paket, was da betroffen ist? Aber auch dann sollte die 7490 halt noch blinken, während EVA auf die FTP-Verbindung wartet.

    @JokerGermany:
    Also zumindest auf den ersten Blick ist das OpenVPN-Paket daran unschuldig: https://github.com/Freetz/freetz/blob/master/make/openvpn/Config.in - direkt in dessen Konfiguration gibt es auch keine anderen Optionen (z.B. irgendwelche lange überalterten Verfahren, die von der 1.0.2 nicht mehr unterstützt werden), die einen solchen Rückschritt erfordern würden ... zumindest sehe ich keine (offensichtlichen).

    Ein weiterer Punkt, der dagegen spricht, ist die Feststellung, daß ich selbst auch eine Freetz-Konfiguration mit OpenVPN übersetzt habe (an dieser Stelle ändert mein Fork nichts) und da sehr wohl die 1.0.2 enthalten ist und das auch ohne gesondertes Umstellen an irgendeiner Stelle.

    Allerdings habe ich mir die anderen Pakete in Deiner .config nicht angesehen ... vielleicht braucht tatsächlich eines davon die alte Version. Dann solltest Du entweder auf dieses Paket verzichten oder selbst versuchen, es mit einer moderneren Version zu erstellen.

    Von der Benutzung der 0.9.8 in Verbindung mit neuerer Firmware kann man nur ganz dringend abraten ... diese Version erhält bereits seit längerer Zeit auch keine Bugfixes mehr und sollte nur noch dann zum Einsatz kommen, wenn wirklich, wirklich alte AVM-Firmware (die selbst noch diese Version benutzt) als Vorlage für das Freetz-Image dient - denn dann ist es praktisch egal, ob eine dort enthaltene Lücke in den AVM-Komponenten oder in Freetz-Paketen klafft.
     
  5. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    nein.


    Wie finde ich das heraus?
     
  6. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @JokerGermany:
    Ich denke fast, es gibt gar kein Paket, was diese Auswahl erzwingt ... zumindest zeigt ein
    Code:
    grep -r OPENSSL_VERSION_0
    
    über einen frisch ausgecheckten Trunk keine Fundstelle, die irgendwie danach aussehen würde.

    Damit bleibt eigentlich nur noch die Erklärung übrig, daß Du entweder nicht wirklich mit einer leeren Konfiguration begonnen hast (so hatte ich zumindest #1 verstanden) oder dann doch manuell die 0.9.8 ausgewählt wurde.

    Wenn die erste Option der Fall gewesen sein sollte, würde ich vor der weiteren Suche nach der Ursache für das Nichtstarten erst noch einmal ein Image bauen, das wirklich auf der Basis einer neuen .config erstellt wurde.

    Wer etwas mehr Zeit hat (der erste Build-Run ist ja nicht verschenkt, weil die dabei erstellten Pakete nicht erneut übersetzt werden müssen), der beginnt mit einer kleinen Konfiguration ohne irgendwelche zusätzlichen Pakete (oder nur mit dem Nötigsten) und testet erst einmal das dabei entstandene Image.

    Das sieht auf den ersten Blick wie verschwendete Zeit aus, spart aber bei einem späteren Fehler wieder viel davon ein, weil man dann sicher weiß, daß irgendetwas zwischen diesen beiden Builds für das Problem verantwortlich ist.
     
  7. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Doch, das Build ist übernommen, habe jeweils immer den Ordner gesichert und weitergenutzt.

    Also reicht es die .config zu löschen? (Was schon nicht wenig arbeit ist, schauen welche Pakete ausgewählt waren, welche Optionen usw....)
     
  8. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #8 PeterPawn, 1 Sep. 2017
    Zuletzt bearbeitet: 1 Sep. 2017
    Ziemlich offensichtlich schleppst Du ja Einstellungen durch die Gegend, die bei einer 7490 schon vor 6 Monaten (da gab's in etwa das CS, auf welches Du Dich in #1 beziehst) mit "fragwürdig" noch freundlich umschrieben sind - der Support für OpenSSL 0.9.8 wurde nämlich bereits zum 31.12.2015 eingestellt und alle in 2016 gefixten Probleme (aus den 1.0.x-Versionen) sind dort noch vorhanden.

    Da ist das "viel Arbeit" (bzw. Du schreibst "nicht wenig") dann eigentlich nur in Deinem eigenen Interesse ... denn mehr oder weniger waren Deine älteren Images dann durchaus problematisch und wenn sich daraus kein echtes (Sicherheits-)Problem ergab, dann liegt das sicherlich zu einem guten Teil auch daran, daß sich niemand die Mühe machen wollte - was aber nicht heißt, daß niemand es gekonnt hätte.

    Etwas OT, aber mal als "Grundsatz" zu Freetz und Updates:
    Das alles bezieht sich jetzt nur auf die - ziemlich offensichtlich - veraltete OpenSSL-Version. An den anderen Stellen, wo bei einem Paket eine neuere parallel zu einer älteren Version existiert (OpenVPN wäre so ein Beispiel), verwendest Du bei diesem Vorgehen (auch nach längerer Zeit immer wieder mit einer - nun wirklich alten - vorhandenen .config zu arbeiten) dann automatisch immer die älteren Versionen (hier dann sicherlich OpenVPN 2.3, obwohl 2.4 jetzt schon seit 8 Monaten unterstützt wird - auch wenn natürlich nicht jeder sofort die neue Version nutzen muß, solange die alte noch unterstützt wird).

    Man sollte entweder die Historie der Änderungen permanent im Blick behalten (wie will man sonst mitbekommen, ob es für ein verwendetes Paket ein dringendes Sicherheitsupdate gibt?) und dann entscheiden, ob eine Änderung Auswirkungen auf das eigene Image hat oder man beobachtet gleich selbst die Upstream-Versionen der zusätzlich verwendeten Software, ob es da wichtige Security-Fixes gibt. Anders als bei der AVM-Firmware gibt es ja bei Freetz keine Releases, wenn da Entscheidendes geändert wurde ... dafür ist nun mal der Benutzer selbst verantwortlich.

    Als Beispiel sei hier mal das "dropbear"-Paket genannt (auch wenn Du das nicht ausgewählt hast) ... die dort im Mai 2017 gefixten Lücken (das ist jetzt schon wieder 4 Monate her) sollten eigentlich jeden Freetz-Benutzer veranlassen, sich direkt bei der Aktualisierung des Trunks Gedanken über ein neues Image zu machen, wenn er eine bestimmte Konstellation beim SSH-Service verwendet (gesonderte Konten für "untrusted" - oder "not fully trusted" - Benutzer) und wenn er die Beschreibung der Auswirkungen der gefixten Lücken nicht verstanden hat (die erlauben nur bereits erfolgreich angemeldeten Benutzern die Ausweitung von Rechten), dann erst recht.

    Es wird von Freetz sicherlich keine gesonderten "Sicherheitswarnungen" für die verwendeten Pakete geben und so muß man sich schon selbst (und regelmäßíg) darum kümmern - das ist der Preis, den man für die zusätzlichen Funktionen zahlt. Es gibt kein "Auto-Update" auf irgendeine gefixte Version, wie das ggf. bei der AVM-Firmware funktioniert, wenn man es zulassen will und wer seine Freetz-Images nur auf Basis des Erscheinens einer neuen AVM-(Release-)Firmware aktualisiert, der riskiert in den zusätzlich installierten Programmen auch mal erhebliche Sicherheitslücken ... und lange nicht jede davon wird auch "durch die Presse" so bekannt gemacht, daß der (uninteressierte) Freetz-Benutzer das zwangsweise mitbekommen muß - die "dropbear"-Lücke dürfte das beste Beispiel sein, die blieb weitgehend unbemerkt.

    Die großen Distros haben halt ein Update nachgeschoben (z.B. Debian für Jessie: https://www.debian.org/security/2017/dsa-3859, wovon dann auch RasPi-Installationen - als mögliche "dropbear"-Anwendungen - profitieren), bei kleineren oder handgemachten Systemen, die sich für irgendetwas auf SSH-Konten mit beschränkten Rechten verlassen (z.B. für einen SFTP-Server), kann das schnell ins Auge gehen.

    Das alte Motto "never touch a running system" ist - in der heutigen Zeit - ziemlicher Blödsinn ... ein System mag zwar klaglos arbeiten und man darf darüber auch froh sein, aber sowie es Kontakt zu anderen aufnehmen kann (dazu muß es nicht einmal selbst ins Internet dürfen, es reicht bereits die Möglichkeit, von einem anderen LAN-Client angesprochen zu werden), dann ist das Betreiben mit bekannten Lücken ziemlich fahrlässig. Ein Angreifer klopft die erreichbaren Systeme ja automatisiert auf mögliche Schwachstellen ab und der interessiert sich erst einmal gar nicht dafür, was das angegriffene Gerät jetzt wirklich ist und ob das nur die Fernbedienung für den Großbild-TV ersetzen soll oder dann doch die Alarmanlage steuert.
     
  9. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Also reicht es die .config weg zu schmeißen und dann erneut make menuconfig anzuschmeißen?

    Naja, wäre schon schön, wenn Freetz beim nächsten kompilieren den Nutzer dabei unterstützt.
    Weil jedes mal die .config weg zu schmeißen ist ja ziemlich aufwendig. Wäre toll, wenn freetz die alte .config einliest und feststellt, dass sich da Sachen geändert haben und einem drauf hinweist...

    Ich bin bisher davon ausgegangen, dass man alles neu bekommt (soweit es denn ausgereift ist, siehe openvpn unten), wenn man neu kompiliert.

    OpenVPN habe ich übrigens dieses mal bewusst in 2.3.17 gelassen, weil hinter der 2.4.3 Experimental dahinter steht und ich geglaubt habe, dass das irgendwann mal entfernt wird wenn es nicht mehr so ist.
    Wenn OpenVPN nach einem freetz update nicht mehr funktioniert, habe ich nur noch das Internet, was über Proxy möglich ist und die Server Fritzbox ist etwa 300km entfernt, da überlegt man sich genau ob man Experimental auswählt.
    Insbesondere da ich "freetz-trunk" verwende, bin ich bei Experimental nochmal vorsichtiger ;)

    Auch jetzt würde ich lieber die 2.3.17 Version nehmen, auch wenn es 8 Monate her sein mag, seit dem 2.4 unterstützt wurde, heißt es ja nicht, dass es nicht mehr experimental ist....

    BTW:
    Wo genau sehe ich denn was in Freetz geändert wurde?
    Wie halte ich mich da auf dem laufenden?
     
  10. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Ja, einfach die .config löschen bzw. normalerweise würde man nach einer Neuinstallation des Build-Hosts (so steht es ja in #1) das SVN-Repo klonen und dann gibt es noch keine .config.

    Auch das "make clean" müßte (so genau kenne ich die Make-Targets vom Freetz aber auch nicht) eigentlich alles löschen, also "dirclean", "distclean" und "download-clean" umfassen - wenn ich den Sinn dieser Targets richtig interpretiere. Auch das "download-clean" ist gar nicht so überflüssig, wie das auf den ersten Blick aussehen mag - immerhin bleiben ansonsten die ganzen älteren Versionen irgendwelcher Upstream-Pakete, die zwischenzeitlich durch neue Versionen ersetzt wurden, dann weiter im "dl"-Ordner liegen, wenn man nicht von Hand aufräumt.

    Gerade dann, wenn man die Änderungshistorie nicht ständig im Blick hat, sollte man ohnehin bei jedem Build von vorne beginnen ... es gibt eben immer mal wieder auch Changesets, die eine neue Toolchain o.ä. brauchen und wo die Änderungen erst nach entsprechenden Aufräumarbeiten mit daraus folgenden zusätzlichen Build-Aktionen wirksam werden. Wer das nicht wirklich selbst durchschaut und einschätzen kann, sollte besser die zusätzliche Zeit für ein "clean build" investieren - ansonsten kann er sie ggf. hinterher in erheblich größerem Umfang bei einer Fehlersuche investieren, wenn er nur ein wenig Pech hat.

    Vielleicht findet sich ja tatsächlich jemand, der eine Lösung baut, wo die Konfiguration in einzelne Pakete gesplittet werden kann (die Symbolnamen würden das ja hergeben) und dann diese einzelnen Pakete nur noch als "diff" auf die gesamte .config für Freetz angewendet werden. Das würde zumindest bei der "Unsitte", ältere .config (ungeprüft) für neue Builds zu benutzen, etwas mehr "Ruhe" in die Konfiguration bringen - wobei mit "make oldconfig" ja auch schon eine Möglichkeit besteht, eine neue Konfiguration auf der Basis einer älteren zu erstellen und dabei auf der Konsole angezeigt zu bekommen, welche Optionen hinzugekommen sind und wo ggf. neue Entscheidungen/Überlegungen erforderlich sind. Das gibt es also durchaus schon in Kconfig ... ob es für alle Freetz-Benutzer geeignet und ausreichend ist, kann ich nicht einschätzen.
     
  11. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ok danke, hab auf nem anderen Rechner ein komplett neues Image erstellt (und die make menuconfig von dem anderen Rechner "abkopiert).
    Funktioniert nun.
    Auch wenn ich vergessen hatte, das Freetz den http-proxy bei openvpn deaktiviert und ich in der openvpn.mk die betreffende Zeile auskommentieren musste und dann nochmal kompilieren durfte.
    Wobei ich mich ernsthaft frage warum der Standardmäßig deaktiviert ist.
    Ist es echt nur wegen der 9216 Bytes die man dadurch spart? oO

    Wobei mich nach deinen Äußerungen zu OpenVPN 2.4 jetzt echt interessieren würde warum das noch Experimental ist.
    Habe jetzt wieder OpenVPN 2.3 ausgewählt...
     
  12. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Ich denke mal, das liegt beim OpenVPN u.a. auch an zu wenig positiven Rückmeldungen ... das kann ja ein Einzelner unmöglich alles selbst austesten.

    In Anbetracht der mit 2.4 eingeführten elliptischen Kurven (auch wenn ich das nicht richtig verfolgt habe und daher nicht weiß, ob da "nur" die NIST-Kurven nutzbar sind (oder welche davon genau) oder auch ED25519 unterstützt wird) und der Beschleunigung, die sich daraus auf einem eher schwachbrüstigen Router ergeben sollte (ungetestete Annahme meinerseits beim OpenVPN), hätte ich auch mehr "Enthusiasmus" beim Umstieg erwartet und auch mehr (am besten positive) Erfahrungsberichte.
     
  13. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    #13 JokerGermany, 1 Sep. 2017
    Zuletzt bearbeitet: 1 Sep. 2017
    Ist 2.4 zu 2.3 abwärtskompatibel?

    Würde mit dem nächsten Meshupdate dann erstmal den Client austauschen und ca. nen monat später dann den server...

    Das Problem am VPN ist , dass man immer nur an einem Standort gleichzeitig sein kann und wenn es dann kracht, hat man ein Problem und das zurückwechseln ist nicht so einfach.
    Vermute deswegen.
    Jedenfalls ist es so bei mir und da der http-proxy bei 2.3 ja schon auskommentiert ist, bin ich bei 2.4. wahrscheinlich garantiert der erste, der es ausprobiert...
     
  14. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #14 PeterPawn, 2 Sep. 2017
    Zuletzt bearbeitet: 2 Sep. 2017
    @JokerGermany:
    Dann probiert man das eben erst mal mit einer lokalen Box ... nur "auf Verdacht" ein Freetz-Image zu bauen und dann entfernt irgendwo einzuspielen, ist ohnehin riskant. Das ist nun mal eine Grundeigenschaft des Trunks, daß wirklich JEDE Änderung dazu führen kann (und darf), daß die damit erzeugten Images nicht wie erwartet funktionieren. Das ist schließlich der Entwicklerzweig und nur das Fehlen neuerer Stable-Versionen macht das ja überhaupt zur "best practice", da mit der Entwicklerversion zu arbeiten.

    @opto:
    Welcher Commit ist es denn nun, der das "replace kernel" scheitern läßt? Gibt es einen Grund für "Geheimniskrämerei"? Oder habe ich irgendeinen neuen Ticket-Kommentar übersehen (ich habe auch keinen Account mehr im Trac, aber ich dachte eigentlich, Du ebenfalls nicht)?

    Das mit der OpenSSL-Version habe ich ja inzwischen begriffen ... aber auch Freetz rüstet keine "back-ported patches" für alte 0.9.8-OpenSSL-Versionen nach und solange Freetz-Pakete dann mit der alten Version arbeiten (und ich zähle 23 Pakete mit "grep", die auf OpenSSL bauen oder es zumindest könnten), sind halt diese auch angreifbar. Ich weiß es nicht mehr ganz genau, aber aus dem Gedächtnis hatten wir bei OpenSSL in 2016 im Januar, im März, im Mai und im September heftigere Lücken, die auch schon mal mit "high severity" bewertet waren. Die sind m.E. in der 0.9.8 auch in Freetz natürlich nicht geschlossen worden. Das muß auch noch nicht heißen, daß da tatsächliche Gefahren bestehen für eine FRITZ!Box oder gar konkret eine 7490 (nicht für jede der Lücken gibt es PoC oder Metasploit-Module zum Nachtesten oder ähnliches), aber ich traue mich definitiv nicht, da irgendwelche Aussagen zu treffen, ob das nun auf MIPS32R2 irgendwelche Konsequenzen hat oder nicht - zumindest nicht, solange es nicht in der "Vulnerability"-Liste ausdrücklich auf andere Plattformen begrenzt ist.

    EDIT: Angesichts dessen, daß AVM eigentlich nur den GUI-Zugang und auf Anforderung den FTPS-Zugang überhaupt extern mit TLS absichert (und nach innen praktisch nichts), sind das bei AVM sogar deutlich weniger "Verbraucher", die hinter einer OpenSSL-Version hängen und von ihr dann auch die Probleme erben.
    EDIT2: Ne ... den TR-064-Zugang (und ggf. den TR-069-Zugang, wobei hier die Box eher Client als Server ist) habe ich jetzt unterschlagen bei den Benutzern einer TLS-Verbindung.
     
  15. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Tja, die Natur der Sache ist aber bei VPN das man 2 Boxen braucht um es aus zu probieren^^

    Ich bin momentan in der Glücklichen Lage jeweils eine FB7490 zu besitzen. (Im Februar wird allerdings wahrscheinlich die eine auf 7590 geupgraded)
    Natürlich prüfe ich erstmal ob das Update bei mir klappt.
    Aber bei VPN hilft das leider nicht...
     
  16. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Du kannst das OpenVPN doch mit einer Box und jedem beliebigen Rechner mit einem OpenVPN-Client ausprobieren - wozu braucht es da zwei Boxen?
     
  17. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    449
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
  18. f666

    f666 Neuer User

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    95
    Zustimmungen:
    8
    Punkte für Erfolge:
    8
    Ich kann heute Abend mal spontan RK auf meiner 7490 ausprobieren. Es war mir nicht bekannt, dass es zwischenzeitlich wieder kaputt gegangen ist.
     
  19. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    914
    Zustimmungen:
    5
    Punkte für Erfolge:
    18
    Aber du nutzt es doch. D.h. du hast es behoben und weiß woran es liegt. Sei so nett, verrate es uns, wir werden den dafür verantwortlichen Commit schon selbst raussuchen.

    p.s. cuma at his best worst
     
  20. f666

    f666 Neuer User

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    95
    Zustimmungen:
    8
    Punkte für Erfolge:
    8
    RK tut bei mir (Revision 14434).