Category Archives: Linux

DSL Ausfall bei 1und1 in Braunschweig – Linux rettet den Tag

Posted on by

(Stand 14:26) Seit 13:45 Uhr am 1.9. ist in Braunschweig das DSL Netz von 1und1 in unserem Bereich ausgefallen. Dank Linux kein Problem, selbst für Geräte ohne WLAN 😀

DSL Ausfall bei 1und1 in Braunschweig – Linux rettet den Tag

Die DSL-Vermittlungsstelle (DSLAM) ist derzeit nicht erreichbar und das mitten im Arbeitstag. Der Linuxer ist aber nicht hilflos, so er denn ein Handy mit Linux hat, oder ein Linux Laptop und ein Android Handy ( aka. Hotspot ) . Das man Laptops leicht per Hotspot über ein Handy ins Internet bringen kann, muß ich Euch ja nicht erklären. Aber damit ist nur das Laptop im Netz, was ist mit all den anderen Geräten im Lan?

Nun, da kommt uns Linux als Helfershelfer in der Not gerade Recht. Den Laptop, oder wie in meinem Fall, dem Surface Tablet mit Linux, muß man nur mit dem LAN per Kabel verbinden. Via der noch funktionierenden, aber mit dem INET nicht mehr verbundenen Fritzbox, gibt es die übliche IP Adresse im eigenen Lan. Nun verbindet man das Laptop mit dem Hotpot, idealerweise hatte man das früher schon mal gemacht, wenn man entspannt arbeiten konnte, aber ein Passwort werdet Ihr jetzt sicherlich auch korrekt eingeben können. Nun hat das Laptop eine Internetverbindung und kann vom Desktop PC angepingt werden, jetzt müssen wir den Datenstrom nur noch routen 🙂

Auf dem Laptop und dem Desktop müßt Ihr nun Root werden.

Auf dem PC ruft Ihr route auf:

# route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 enp7s0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 enp7s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0

Die sogenannte Defaultroute schiebt alle Pakete, die nicht direkt im Lan ein Ziel haben an die Fritz.Box und die ins Netz.

Diese Route müssen wir auf das Laptop(hier Tablet) umleiten:

# route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default surface.fast 0.0.0.0 UG 0 0 0 enp7s0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 enp7s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0

Das geht so:

route del default gw fritz.box
route add default gw surface.fast

(surface.fast steht in der /etc/hosts als Hostname für die IP vom LAN Anschluß des Tablets drin, es geht auch die IP direkt)

Auf dem Laptop/Tablet müssen wir noch das Routing und IP Masquerading aktivieren:

echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o wlp2s0 -j MASQUERADE;

Das WLAN Interface wlp2s0 könnte bei Euch anders heißen.

Damit routen die Pakete über das Tablet, jetzt brauchen wir noch einen anderen DNS-Server in Desktop PC in /etc/resolv.conf eintragen, z.b. 8.8.8.8 von Google ( in der Situation kann man das ruhig mal machen ). Damit ist der PC wieder am Netz.

Die Aufallzeit ist jetzt 1h05m, das ist ziemlich heftig für Tagsüber. Ich habe mir einen Spaß gemacht und einen Rückruf bei 1und1 gebucht, natürlich auf die Nummer mit dem Ausfall, damit die sofort Nachforschen 😉

Linux am Dienstag – Programm für den 31.8.2021

Posted on by

Sprechen wir doch mal über Sicherheitslücken, davon gibt es ja derzeit einige.

Linux am Dienstag – Programm für den 31.8.2021

Bei Linux am Dienstag am 31.8. 2021 geht es ab 19 Uhr u.a. um folgende Themen:

Linux wird 30!
OpenSSH – VPN mit SSH
OpenSSL – Buffer Overflow im SM2 Modul gefixt.
Security – Was ist eine XSS Schwachstelle?
Security – Was ist eine SQL Injection?

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Kleine Anmerkung: Die bisherigen Vorträge findet man jetzt unter https://linux-am-dienstag.de/archiv/ .

Pinephone: Streaming vom Pinephone

Posted on by

Das Pinephone ist um einen Anwendungsfall reicher: Livestreaming ( z.b. des Desktops ) über einen Desktoprechner mit OBS an einen HLS/RTMP Server.

Pinephone: Streaming vom Pinephone

Ja, Ihr seid richtig, ab sofort könnt Ihr Livestreaming von Eurem Pinephone an x-beliebige Dienste senden.

Das Pinephone unter Fedora wird mit Phosh und Wayland betrieben, was bedeutet, daß wir den Desktop über den Umweg wf-recorder streamen müssen. Das hat aber den Vorteil, daß das Encoden für den eigentlichen Streamdienst nicht auf dem Pinephone stattfinden muß, sondern an OBS auf dem Desktop oder Laptop outgesourced werden kann.

In der Theorie kann man natürlich auch gleich OBS auf dem Pinephone nehmen, wenn ihr einen ARM Build dafür findet. Wir nutzen jetzt den Weg „DesktopPC mit OBS“.

Schritt 1: Das Setup

Welche IP das Pine in eurem Netz hat, spielt keine Rolle. Wichtig ist nur die IP vom DesktopPC: 192.168.0.10

Auf welchem Port ihr das machen wollt ist Euch überlassen, alles ab 1024 dürfte funktionieren, sofern da nicht bereits jemand anderes arbeitet.

Schritt 2: Das Pinephone

macht eine SSH Session als Desktopuser ( Fedoradefault ist „pine“) oder ein Terminal auf. Gebt ein:

wf-recorder -a –muxer=“mpegts“ -f „udp://192.168.0.10:28081“

Schritt 3: OBS

Im OBS braucht Ihr eine neue Medien Quelle. Öffnet dazu eine neue NICHTlokale Medienquelle:

In die Eingabe kommt „udp://192.168.0.10:28081“. Drückt auf OK, richtet die Medienquelle im Bild so ein, wie Ihr das Pinebild positioniert haben möchtet ( Erfahrungen mit OBS sind von Vorteil ). Fertig.

Schritt 4: Das Streaming

Das kann ich Euch jetzt nicht mehr zeigen, weil das davon abhängt über welchen Dienst Ihr das Streamen wollt. OBS hat da diverse vorbereitete Dienste parat, die Ihr nur noch mit Euren Zugangsdaten füllen müßt.

Wenn es nicht gleich will…

…liegt das vermutlich daran, daß wf-recorder beim Muxen nicht laufend die nötigen Infos für einen Streamclienten wie OBS liefert. Am besten startet man erst die Medienquelle und dann erst wf-recorder auf dem Pine. Das kann man z.b. durch einen Szenenwechsel forcieren.

Auf dem Pine muß man normalerweise nicht darauf achten, daß das Audiodevice stimmt, aber schaden kann es nicht.

Ein Livebild der Kamera bekommt man in den Stream, in dem man einfach Megapixels startet 😉

Verzögerungen

Ja, das hat mich auch überrascht. 10 Sekunden Bildverzögerung liegen an den Medienquelleneinstellungen, aber der Ton brauchte 48 Sekunden bis er im Stream auf der Webseite ankam. Ob das an einem ungünstigen Kodierfehler beim wf-recorder liegt, oder ob OBS da nicht richtig sortiert ( unwahrscheinlich ) weiß ich leider nicht. Ich denke, dies wird man im wf-recorder ausbügeln müssen. Vielleicht lags auch am Wifi/UDP Lag .