Skip to content

FritzBox Labor Version 7.39

Linux
  • Voller Vorfreude die Beta-Version installiert.

    FRITZ!OS: 07.39-94697 BETA - Version aktuell

    1cd7a526-5438-4675-9415-54c45439252f-grafik.png

    Nach einer Stunde erfolglosem rumprobieren, kam mir dann doch etwas sehr merkwürdig vor. Also nochmal aufmerksam die AVM Seite durchgesucht. Und dann das hier gefunden.

    c42d333f-693d-47a1-a549-5f68fe04f5c6-grafik.png

    Ähm, wollt ihr mich verars........? 😠

    Quelle: https://avm.de/fritz-labor/frisch-aus-der-entwicklung/bekannte-probleme/

  • Die Antwort von AVM, ich hatte schon eine Anfrage gestellt bevor ich das oben gezeigte gefunden hatte.

    Die von Ihnen geschilderten Probleme kennen wir bereits. Unsere Entwicklung arbeitet auch schon an einer Lösung, die wir dann mit einem kommendem Update bereitstellen werden.
    Ich danke Ihnen für Ihre Unterstützung!

  • Neuer Versuch 😉

    bd02967a-94a0-4432-9dad-7a251683b8bd-grafik.png

  • Zufällig mal nachgesehen und da ist doch glatt ein Update angekommen. Schnell mal installiert, kurzer Test.

    5577a494-e3de-4911-94fb-4370cda692f4-grafik.png

    Da ist der QR-Code, das ging vorher nicht. Da kam immer die Fehlermeldung. Hier der Screenshot mit der funktionierenden Verbindung.

    Bildschirmfoto vom 2022-03-28 19-36-49.png

    Wenn ihr das kennt, den QR-Code scannen und die Installation des Wireguard Tunnels ist auf dem Smartphone fertig. Das schaut in der Wireguard App dann wie folgt aus.

    Screenshot_20220328-194131_WireGuard.jpg

    Und mal eben einen lokalen Teilnehmer erreichen.

    Screenshot_20220328-194025_Firefox.jpg

    Das soll es mal für einen Schnelltest gewesen sein. Ich komme da aber sicher noch drauf zurück 🙂

  • Bitte beachten, das diese VPN-Verbindung ein Problem hat, Stichwort DNS leak. Ursache ist der gesetzte DNS-Server in den Wireguard Einstellungen. Der zeigt auf die Fritzbox, die benutzt im Normalfall den DNS des Internetproviders. Nicht perfekt. Aber auch das lässt sich lösen....

    Bildschirmfoto vom 2022-03-28 20-06-15.png

  • Wer mich kennt, weiß das ich das so nicht lassen kann 🙂

    Screenshot_20220330-180940_Firefox.jpg

    Auch noch mit einem anderen Dienst gegen getestet, alles gut, so muss das 😉

    Dazu habe ich einen Rechner (wofür liegen die Platinen hier alle rum?), genau genommen einen Quartz64, mit einem Unbound Server ausgestattet.

    /etc/unbound/unbound.conf.d/user.conf

    server:
      interface: 0.0.0.0
      interface: ::0
      access-control: 127.0.0.0/8 allow
      access-control: 192.168.178.0/16 allow
      prefetch: yes
      hide-identity: yes
      hide-version: yes
      qname-minimisation: yes
    

    Restart nicht vergessen.

    service unbound restart
    

    Danach noch auf dem Smartphone in der Wireguard-Konfiguration, die Adresse des Unbound-Servers eintragen -fertig!

  • Da das o.g. sehr gut funktioniert, habe ich den Wireguard Server, den ich in der Hetzner Cloud dafür betrieben habe, heute abgeschaltet.

    Das erspart mir 4,98€ ( 4,15€ + 20% für Backups), macht 59,76€ / Jahr. In Zeiten mir hoher Inflation nicht so unwichtig. Der Proxmox bei mir zu Hause, auf dem der Dienst jetzt läuft, ist hier sowieso an der macht ja noch so einiges anderes...

  • Debian Bug auf Arm64

    Linux
    1
    0 Stimmen
    1 Beiträge
    82 Aufrufe
    Niemand hat geantwortet
  • Standby Problem mit Mediatek MT7921e

    Linux
    1
    0 Stimmen
    1 Beiträge
    154 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12.8 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    131 Aufrufe
    Niemand hat geantwortet
  • Fedora erhebt KDE zur offiziellen Workstation Alternative

    Linux
    1
    0 Stimmen
    1 Beiträge
    119 Aufrufe
    Niemand hat geantwortet
  • Fedora 41 - Standby Problem

    Linux
    4
    +1
    0 Stimmen
    4 Beiträge
    528 Aufrufe
    FrankMF
    Es hatte bis jetzt leider gar nichts vernünftig funktioniert. Nachdem Manjaro den Kernel 6.10 rausgeschmissen hat (EOL), stand ich auf dem Schlauch. Alles nach 6.10 ging nicht, zwischenzeitlich war ich auf 6.6., da ging es, aber ist auch keine Lösung. Also, mal wieder überall rein gelesen. Hier findet man die Lösung. https://discussion.fedoraproject.org/t/kernel-6-11-3-200-fc40-unable-to-resume-from-suspend-when-bluetooth-enabled/134008/18 File /etc/systemd/system/bluetooth-fix.service anlegen [Unit] Description=Disable Bluetooth before going to sleep Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/rfkill block bluetooth ExecStop=/usr/sbin/rfkill unblock bluetooth [Install] WantedBy=sleep.target Aktivieren systemctl enable bluetooth-fix.service Danach geht mein Standby auch wieder mit höheren Kernel-Versionen. uname -a  ✔  20s  Linux frank-manjaro 6.12.1-4-MANJARO #1 SMP PREEMPT_DYNAMIC Mon, 25 Nov 2024 05:36:03 +0000 x86_64 GNU/Linux Frank wieder zufrieden Das ist jetzt zwar nur ein Workaround, aber besser als gar nichts. Was weiß ich, wann welche Firma jetzt mal das Problem anfasst und fixt!? Für mich hat der Workaround auch keine negativen Auswirkungen. Zumindestens ist mir noch nichts aufgefallen. Ich werde berichten.
  • Wireguard - Tunnel zur Fritz!Box 6591 Cable Part 2

    Angeheftet Wireguard
    1
    +1
    0 Stimmen
    1 Beiträge
    376 Aufrufe
    Niemand hat geantwortet
  • FRITZ!Box 6591C

    Allgemeine Diskussionen
    1
    +3
    0 Stimmen
    1 Beiträge
    180 Aufrufe
    Niemand hat geantwortet
  • Liste von Linuxbefehlen

    Angeheftet Linux
    4
    +0
    0 Stimmen
    4 Beiträge
    728 Aufrufe
    FrankMF
    Anzeige des Speicherplatzes als Ersatz für df -h ~ duf  ✔ ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ 8 local devices │ ├─────────────────┬────────┬────────┬────────┬───────────────────────────────┬───────┬─────────────────────────────────┤ │ MOUNTED ON │ SIZE │ USED │ AVAIL │ USE% │ TYPE │ FILESYSTEM │ ├─────────────────┼────────┼────────┼────────┼───────────────────────────────┼───────┼─────────────────────────────────┤ │ / │ 435.4G │ 154.6G │ 274.6G │ [#######.............] 35.5% │ btrfs │ /dev/luks-5336cabc-29f1-4af2-8a │ │ │ │ │ │ │ │ 31/dd411a9a1599 │ │ /boot/efi │ 299.4M │ 728.0K │ 298.7M │ [....................] 0.2% │ vfat │ /dev/nvme0n1p1 │ │ /home │ 435.4G │ 154.6G │ 274.6G │ [#######.............] 35.5% │ btrfs │ /dev/luks-5336cabc-29f1-4af2-8a │ │ │ │ │ │ │ │ 31/dd411a9a1599 │ │ /mnt/1TB │ 916.7G │ 821.8G │ 48.3G │ [#################...] 89.7% │ ext4 │ /dev/sda1 │ │ /mnt/Backup │ 457.4G │ 125.3G │ 308.8G │ [#####...............] 27.4% │ ext4 │ /dev/sdc1 │ │ /mnt/Backup_PVE │ 3.6T │ 718.3G │ 2.7T │ [###.................] 19.6% │ ext4 │ /dev/sdb1 │ │ /var/cache │ 435.4G │ 154.6G │ 274.6G │ [#######.............] 35.5% │ btrfs │ /dev/luks-5336cabc-29f1-4af2-8a │ │ │ │ │ │ │ │ 31/dd411a9a1599 │ │ /var/log │ 435.4G │ 154.6G │ 274.6G │ [#######.............] 35.5% │ btrfs │ /dev/luks-5336cabc-29f1-4af2-8a │ │ │ │ │ │ │ │ 31/dd411a9a1599 │ ╰─────────────────┴────────┴────────┴────────┴───────────────────────────────┴───────┴─────────────────────────────────╯ ╭──────────────────────────────────────────────────────────────────────────────────────────────────╮ │ 1 network device │ ├────────────┬────────┬────────┬────────┬───────────────────────────────┬──────┬───────────────────┤ │ MOUNTED ON │ SIZE │ USED │ AVAIL │ USE% │ TYPE │ FILESYSTEM │ ├────────────┼────────┼────────┼────────┼───────────────────────────────┼──────┼───────────────────┤ │ /mnt/NAS │ 786.4G │ 327.0G │ 419.3G │ [########............] 41.6% │ nfs4 │ 192.168.3.19:/NAS │ ╰────────────┴────────┴────────┴────────┴───────────────────────────────┴──────┴───────────────────╯ ╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ 9 special devices │ ├─────────────────────────────────┬────────┬────────┬───────┬───────────────────────────────┬──────────┬────────────┤ │ MOUNTED ON │ SIZE │ USED │ AVAIL │ USE% │ TYPE │ FILESYSTEM │ ├─────────────────────────────────┼────────┼────────┼───────┼───────────────────────────────┼──────────┼────────────┤ │ /dev │ 30.2G │ 0B │ 30.2G │ │ devtmpfs │ dev │ │ /dev/shm │ 30.3G │ 21.9M │ 30.3G │ [....................] 0.1% │ tmpfs │ tmpfs │ │ /run │ 30.3G │ 2.0M │ 30.3G │ [....................] 0.0% │ tmpfs │ run │ │ /run/credentials/systemd-crypts │ 1.0M │ 0B │ 1.0M │ │ tmpfs │ tmpfs │ │ etup@luks\x2d3a8e1aea\x2d0d01\x │ │ │ │ │ │ │ │ 2d4e45\x2d940f\x2d63af54c3d7f0. │ │ │ │ │ │ │ │ service │ │ │ │ │ │ │ │ /run/credentials/systemd-crypts │ 1.0M │ 0B │ 1.0M │ │ tmpfs │ tmpfs │ │ etup@luks\x2d5336cabc\x2d29f1\x │ │ │ │ │ │ │ │ 2d4af2\x2d8a31\x2ddd411a9a1599. │ │ │ │ │ │ │ │ service │ │ │ │ │ │ │ │ /run/credentials/systemd-journa │ 1.0M │ 0B │ 1.0M │ │ tmpfs │ tmpfs │ │ ld.service │ │ │ │ │ │ │ │ /run/user/1000 │ 6.1G │ 4.4M │ 6.1G │ [....................] 0.1% │ tmpfs │ tmpfs │ │ /sys/firmware/efi/efivars │ 128.0K │ 62.8K │ 60.2K │ [#########...........] 49.1% │ efivarfs │ efivarfs │ │ /tmp │ 30.3G │ 954.6M │ 29.3G │ [....................] 3.1% │ tmpfs │ tmpfs │ ╰─────────────────────────────────┴────────┴────────┴───────┴───────────────────────────────┴──────────┴────────────╯