Pinephone: Wie man Fedora installiert

Da sich Andreas eine Anleitung auf Deutsch gewünscht hat, machen wir das einfach mal.

Pinephone: Wie man Fedora installiert

Das ist eigentlich ganz einfach, wir brauchen:

1x SD-Kartenleser
1x „Gnome-Disks“ zu Deutsch „Laufwerke“ oder für die Konsole „dd“
1x Fedora Image

Das Image bekommt man hier:

https://github.com/nikhiljha/pp-fedora-sdsetup/releases/tag/v0.4.0

Es gibt zwar neuere Images, aber das ist ist meine aktuelle Basis im Pinephone, die funktioniert und ist mit einem DNF-Update auf meinem Softwarestand. Die ganzen Tricks die ich anwende sind da noch nicht dabei.

Wie findet man das passende Device für den SD-Kartenleser?

Für Anfänger: seht im Laufwerketool nach!
Für Konsolenfans: cat /proc/partitions am einfachsten vor und nach dem Einstöpseln des Lesers vergleichen!

Die Installation

Erst einmal in der Konsole:

  • Imagedatei entpacken: xz -d filename.tar.xz;tar xf filename.tar
    Hinweis: das nimmt schnell mal viel Platz weg
  • SD-Karte in den Leser stecken und schauen welches Device der Leser hat! Wer da nicht drauf achtet, der könnte sich sein System unrettbar überschreiben. Deswegen empfehle ich da eher das Laufwerketool zu benutzen, das warnt einen eindringlich:
    dd if=fedora.img of=/dev/<YOUR_SD_CARD>
  • Nun müssen wir noch die letzte Partition so vergrößern, so das Sie die ganze SD-Karte füllt. Es empfiehlt sich „parted“ und/oder „gparted“ zu installieren und es ggf. grafisch zu tun. Nun geht Ihr genau das hier ein und ersetzt dabei nur Euer Device an der richtigen Stelle:
    • sudo parted /dev/<your_sd_card_device>
    • (parted) resizepart 2 100%
    • (parted) quit
    • sudo resize.f2fs /dev/<the_second_sd_card_PARTITION>

Das war es schon. Die letzte SD-Karten-Partition ist die mit der höchsten Nummer! Die sieht man aber in /proc/partitions erst, wenn das Image geschrieben und die Partitionstabelle synchronisiert wurde.

Jetzt die Karte in das Pinephone stecken und Booten.

Login als „pine“ mit „123456“. Job Nummer 1 ist das Passwort wechseln. Erst danach loggt man sich ins WLAN ein!

Entweder Ihr loggt Euch per SSH von außen ein, oder macht ein Terminal auf. Nicht Verzagen „Kings Cross“ ist das gesuchte Programm. Nicht fragen, ist längst raus geflogen, weil Gnome-Terminal problemlos funktioniert.

Root werden: „sudo su“  + Eurer neues Passwort

Das Masterupdate: „dnf -y update“. Dann gleich Rebooten und soweit ausgestanden 😉

Die grafische Installation

Weil das Schreiben des Images auf USB genauso funktioniert wie das Schreiben auf eine SD-Karte:

Linux – ISO Image brennen

 

Einfach dort nachlesen. Wenn Ihr fertig seid ohne Eure Systemfestplatte gekillt zu haben, startet Ihr GParted, wählt die SD-Karte aus, klickt auf die letzte Partition weist Gparted an, diese Partition zu vergrößern ( rechter Mausklick ). Befehl abnicken, warten, fertig.

Ich empfehle

Danach den „maxbattery“ Tweak, den „ModemManager“ Tweak, das Flashlight und SuspendGuardian zu installieren. Fast alles hier zu finden:  https://github.com/Cyborgscode/pinephone

Das nackte Pinephone aufmotzen

Die Autoscreenrotation braucht Ihr nicht mehr, die ist in Phosh jetzt funktional.

Der ModemManager-Tweak hat es noch nicht auf die Seite geschafft

Legt eine Datei namens: /etc/systemd/system/ModemManager.service an und schreibt das hier rein:

[Unit]
Description=Modem Manager
After=
Requires=

[Service]
Type=dbus
BusName=org.freedesktop.ModemManager1
ExecStart=/usr/sbin/ModemManager –test-no-suspend-resume
StandardError=null
Restart=on-abort
CapabilityBoundingSet=CAP_SYS_ADMIN
ProtectSystem=true
ProtectHome=true
PrivateTmp=true
RestrictAddressFamilies=AF_NETLINK AF_UNIX
NoNewPrivileges=true
User=root

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.ModemManager1.service

danach „systemctl daemon-restart“ „systemctl restart ModemManager“ . Fertig. Jetzt bleibt das Modem im Pinephone im System-Suspend in Betrieb und Ihr könnt angerufen werden 😉 SIM Karte vorausgesetzt.

PS: GPS geht auch nur mit SIM-Karte, weil ohne gehts Modem gar nicht.

 

Pinephone: Daily Driver Status rückt näher

Ich hab es gewagt: Mein Androidgerät ist seit 48h aus. Eigentlich Unbeteiligte wurden unfreiwillig zu Pinephonetestern und haben es nicht mal gemerkt 😉

Pinephone: Daily Driver Status rückt näher

Der von der Fedora SIG Mobility verteilte Stand ermöglicht es einem tatsächlich ein Pinephone mit zur Arbeit zu nehmen, ohne Angst haben zu müssen, auf dem Weg zum Auto die Batterie zu leeren.

Pinephone: DANKE ModemManager!

Hier ist das vorläufige Testergebnis:

Das Pinephone verliert mit dem aktivierten ModemManager Patch in 8h ca. 10 % Akkuladung. Damit käme man unter günstigen Umständen 3 Tage ohne Laden aus. Mit dabei waren auch einige nicht zu intensive Nutzungen des Telefons. In der Realität werden es damit wohl eher 2 Tage sein, es sei denn, Ihr braucht eigentlich gar kein Smartphone, weil Ihr nur ein „Ich ruf Dich an, nicht Du mich“ Nutzertyp seid 😉

Das Telefon wacht erwartungsgemäß auf, wenn ein Anruf kommt und läßt es auch klingeln. Mein persönliches Highlite, der Bug mit dem „ich klingel bis das MP3 zu ende ist“ scheint weg zu sein, oder ich hatte Glück 🙂

SMS sind eine andere Geschichte, die wecken das Telefon auf, aber leider bekommt Chatty keinen Tip und holt die SMS erst beim nächsten Neustart beim Modem ab. Da ist aber im Upstreamprojekt bereits ein Patch in der Mache. Dann wäre das Pinephone „Feature complete“.

Wenn da nicht GPS wäre, da läuft bislang eher nur mit Gnome. Ich weiß auch so, wo ich bin 🙂

Außerdem habe ich das Highlite gefunden:Die neue ModemManager UI

Damit lassen sich auch SMS Schreiben und empfangen, die SIM Karte auslesen und vieles nützliche mehr. Es sollte auf keinem Smartphone fehlen 😉

Kleine Anmerkung zum Stromverbrauch:

Fluffychat hat nicht nur einen „ich schreib rückwärts“-Bug, es hat auch tierischen Spaß 150% CPU Leistung zu verbrennen wenn es läuft. Ich glaube das braucht mehr als ein Update ( trotzdem netter Matrix-Client ).

Außerdem sollte man sich für das Pinephone einen USB-C mit 3-4A kaufen, mit 2A dauert das echt lange 🙁

Anleitung für einen eigenen Klingelton

Da der Bug mit dem Klingeln-so-lange-die-Tondatei-halt-dauert weg ist, kann man jetzt endlich vernünftige Kingeltöne aufs Pinephone zaubern:

sshfs root@pinephone:/ mnt
ffmpeg -i VERZEICHNIS/FILENAME.mp3 -codec:a libvorbis -qscale:a 8 mnt/usr/share/sounds/freedesktop/stereo/phone-incoming-call.oga

Denkt an ein Backup des echten Klingeltons, auch wenn es um den nicht schade ist.

Natürlich muß man nicht ffmpeg nehmen, man könnte auch oggenc benutzen, aber das hat eine sehr beschränkte Auswahl an Quellformaten.

WIFI: Die FRAGATTACK Apokalypse

Ja, der Titel wäre Click-Bait, wenn es nicht wirklich so schlimm wäre, wie es ist: praktisch jeder Wifi-Stack der bis heute produziert wurde, ist für die FragAttack anfällig.

WIFI: Die FRAGATTACK Apokalypse

Der Name FragAttack ist hier nicht wie sonst üblich ein Akronym für irgendwas langes, sondern bezieht sich ausnahmsweise mal auf die Grundlage des Angriffs: Fehler bei Zusammenfügen von Paketfragmenten.

„Fragmentierung“ meint, daß einzelne große Datenpakete, die nicht durch das Netz/Kanal passen, in kleinere Pakete aufgeteilt und beim Empfänger wieder zusammen gesetzt werden. Das passiert bei IP-Datenpaketen im normalen Netz auch laufend, ist an sich nicht besonderes.

Die Schwachstellen sind in praktisch jeder Implementierung von WEP bis WPA3 enthalten, wobei nicht jede davon überall sein muß.

12 Fehler sollt Ihr sein

Insgesamt wurden 12 Schwachstellen in verschiedenen Implementierungen bzw. dem Wifi-Protokoll an sich gefunden;

CVE-2020-24588: Akzeptieren von nicht-SPP A-MSDU-Frames
CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden
CVE-2020-24586: Fragmente werden nicht aus dem Speicher gelöscht, wenn eine (erneute) Verbindung zu einem Netzwerk hergestellt wird
CVE-2020-26145: Akzeptieren von Klartext-Broadcast-Fragmenten als vollständige Frames (in einem verschlüsselten Netzwerk)
CVE-2020-26144: Akzeptieren von Klartext-A-MSDU-Frames, die mit einem RFC1042-Header mit EtherType EAPOL beginnen (in einem verschlüsselten Netzwerk)
CVE-2020-26140: Akzeptieren von Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26143: Akzeptieren von fragmentierten Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26139: Weiterleitung von EAPOL-Frames, obwohl der Absender noch nicht authentifiziert ist
CVE-2020-26146: Wiederzusammensetzen von verschlüsselten Fragmenten mit nicht-fortlaufenden Paketnummern
CVE-2020-26147: Wiederzusammensetzen von gemischten verschlüsselten/Klartext-Fragmenten
CVE-2020-26142: Verarbeitung von fragmentierten Frames als vollständige Frames
CVE-2020-26141: Keine Verifizierung des TKIP-MIC von fragmentierten Frames

„CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden“ Ist ein Paradebeispiel dafür, daß ganz schlicht jemand einfach mal eine kleine „if ( oldkey == actualkey)“ Abfrage im Code vergessen hat. Wenn man den Testfall nicht dabei hat, weil man nur ein Netz mit nur einem Schlüssel hat, dann kann das schon einmal passieren.

Die Hacker News schreiben dazu, daß Mathy Vanhoef, ein Sicherheitsforscher der New York University Abu Dhabi, die Probleme auf weit verbreitete Programmierfehler zurückführt.

„Ein böser Akteur kann diese Schwachstellen ausnutzen, um beliebige Netzwerkpakete zu injizieren, Benutzerdaten abzufangen und zu exfiltrieren, Denial-of-Service-Angriffe zu starten und möglicherweise sogar Pakete in WPA- oder WPA2-Netzwerken zu entschlüsseln.“

Es sind sogar Angriffe denkbar bei denen  in das Netz oder am Netz beteiligte Rechner eingebrochen werden kann. Dabei wären dann Geräte interessant die keine Updates mehr bekommen haben, wie z.B. so ziemlich jedes Androidgerät älter als 2 Jahre, Windows XP/7 oder Macs.

Die Wifi-Allianz hat in einer mehr als neunmonatigen konspirativen Aktion sukzessive die Gerätehersteller kontaktiert und Updates verteilen lassen. Wohl dem, der die noch bekommt.

Für Windows wurden die Updates schon eingespielt, bei Linux sind auch bereits Patche in den Kernel eingeflossen, müssen aber noch etwas reifen. Da die Lücken nicht ganz so leicht auszunutzen sind, wie das vielleicht klingen mag, ist das „erst einmal“ kein Problem… bis es dann zum Problem wird 😉

Exploits sind nicht auszuschließen, also kümmert Euch am besten auch um Eure ganzen IoT Geräte, DSL-Router, Access-Points und Uralt-Androids.. wenn Ihr noch könnt.

Quelle: https://thehackernews.com/2021/05/nearly-all-wifi-devices-are-vulnerable.html