Tag Archives: Port

Fedora: Falscher Port bei Pulseaudio gesetzt

Posted on by

Wer beim Wechsel zu Fedora 34 auch plötzlich seine oder ihre Musik aus dem Kopfhörer hören mußte, dem kann wohl doch helfen.

Fedora: Falscher Port bei Pulseaudio gesetzt

Die Ursache habe ich zwar nicht finden können, aber es gibt eine automatische Lösung das Problem: Den Port beim Desktopstart umstellen.

Wir brauchen:

  1. Eine Desktopdatei für den Autostart
  2. ein kleines Bashscript
  3. eine dynamische Anpassung an sich verändernde PulseAudio Sinks.

~/.config/autostart/fixpipewire.desktop
[Desktop Entry]
Version=1.0
Name=Fixpipewire
GenericName=Fixpipewire
Comment=fixes audio port selection
Exec=/home/<username>/.local/bin/fixpipewire
Icon=pva
Terminal=false
Type=Application
StartupNotify=false
Categories=extras
Keywords=tools
X-Desktop-File-Install-Version=0.21
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=5

Das hier angegebene Script sieht dann so aus:

~/.local/bin/fixpipewire

#!/bin/bash

pactl list sinks | grep -B2 „Name: alsa_output.pci-0000_0a_00.4.analog-stereo“ | grep Ziel | sed -e „s/^.* #//g“ | awk ‚{print „pactl set-sink-port „$1″ analog-output-lineout“;}’| bash

Wie man an die Details kommt

Mehrere Details müssen wir erwähnen. Mit

$ pactl list sinks | less

bekommen wir eine Liste mit allen Sinks. Auf Deutsch heißen die Sinks leider „Ziel“.. keine Ahnung welches Genie da eine Übersetzung angebracht hat 🙁

Wir schauen nach folgenden Angaben:  Sink #, Name und .. Portid

Beispiel:

Ziel #48

Name: alsa_output.pci-0000_0a_00.4.analog-stereo
Beschreibung: Starship/Matisse HD Audio Controller Analog Stereo

Ports:
analog-output-lineout: Line-Ausgang (type: Line, priority: 9000, availability group: Legacy 4, not available)
analog-output-headphones: Kopfhörer (type: Kopfhörer, priority: 9900, availability group: Legacy 5, availability unknown)
Aktiver Port: analog-output-headphones

Der aktive Port ist die Stellung, die das Ausgabegeräte gerade hat. Im Beispiel oben ist das z.Z. „analog-output-headphones“, also wird der Ton auf den Kopfhörern ausgegeben. Das beheben wir so:

$ pactl set-sink-port 48 analog-output-lineout

Da wir das Script per Desktopdatei in den Autostart gebracht haben, mit einer Verzögerung von 5 Sekunden, wird der Port jetzt bei Desktoplogin umgestellt, egal wie oft man ein- und ausloggt.

Wie dämlich muß man sein…

Posted on by

Diese Logzeile habe ich grade aus dem Mailserver gezogen:

2018-10-09 10:44:35 SMTP protocol synchronization error (next input sent too soon: pipelining was not advertised): rejected „GET / HTTP/1.1″ H=[107.170.202.125] next input=“Host: mailserver:26\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n“

Ich übersetz mal :

GET / HTTP/1.1
Host: mailserver:26
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

Wenn man sich das genau ansieht, wobei „MAILSERVER“ unsere Mailserver IP war, wird man bei HOST das irritierende „:26“ entdecken. Die Portnummer gehört im HTTP Protokoll gar nicht in den „Host:“- Header rein, trotzdem hat dieses miserable Script es angehängt. Unser Glück, so kann man das aufklären 🙂

Es handelt sich offenbar um einen Portscanner, der bei „nicht-so-standart“-Ports wie „26“ , einfach mal austestet, ob da nicht ein Webserver zu finden ist. Vielleicht in der Hoffnung da was zu finden, was auf Port 80 nicht zu finden wäre, wer weiß. Auf Port 26 hat unser Mailserver einen Ausweichport, falls der DSL-Router des Kunden mal wieder Port 25 für alles außer T-Offline-Mailservern sperrt. Das hat sich in der Vergangenheit extrem gut bewährt, weil man im Mailprogramm nur statt Port 25 26 angeben brauchte und schon war diese leidige Routersperre umgangen.

Eingeführt haben die Routerhersteller das, damit die ganzen gehackten Windows-Pcs nicht ständig das Netz mit Spams beglücken. Das war aber nur bedingt erfolgreich 😉

Wie kam ich jetzt auf dämlich, achso ja, weil sich der Mailserver natürlich, wie auf Port 25 auch, sofort als Mailserver outet 🙂 Man muß also nicht erst HTML hinschicken um zu sehen was es ist 😀

Linux – wenn ssh nicht portforwarden will

Posted on by

Wenn SSH Euren Port trotz richtiger Angabe der Parameter nicht forwarden will, könntet Ihr Opfer des Fortschritts geworden sein.

Das Problem

Der Befehl :

ssh -g -R *:24007:192.168.178.1:24007 root@remoteserver.de

sagt dem entfernen Server normalerweise, daß der Remote-Server einen Port 24007 für alle zugänglich auf 0.0.0.0 binden soll und alles was reinkommt, soll an die lokale IP 192.168.178.1 Port 24007 weitergeleitet werden.

Wenn das aber immer im Netstat auf 127.0.0.1 angezeigt wird:

tcp 0 0 127.0.0.1:24007 0.0.0.0:* LISTEN 13927/sshd: root@pt….

dann ist Eure SSHD-Config zu alt 🙂 Vor einigen Jahren wurde eine neue Option eingeführt, so daß der SSHD zwingend konfiguriert sein muß, globale Ports binden zu können.

Die Lösung

Fügt in die /etc/ssh/sshd_config  die folgende Zeile ein und startet den Dienst neu:

GatewayPorts yes

Damit darf der SSHD das wieder für Euch erledigen und die Tunnelwelt funktioniert für Euch wieder.

Das könnte auch interessant sein:

SSH VPN mit den iproute2 Tools
UDP Traffic per SSH tunneln
TAR erfolgreich per SSH tunneln