Verbindungsabbrüche bei Lenovo Thinkpad Yoga und OneLink Pro Dock

Mein Thinkpad Yoga hat im Zusammenspiel mit dem OneLink Pro Dock das Problem, dass der in der Dockingstation verbaute USB3-Hub öfters neu gestartet wird und somit etwa neben angeschlossenen USB-Sticks auch die am Dock vorhandene, per USB-zu-Ethernetadapter realisierte LAN-Schnittstelle die Verbindung verliert. Getestet hatte ich bereits zwei verschiedene Dockingstationen, um einen Hardwaredefekt auszuschließen. Außerdem hat mein parallel installiertes Windows 10 diese Probleme nicht.

Wie auch schon im Ubuntuusers-Forum dargestellt, bekomme ich in diesem Fall folgende Meldungen bei udevadm monitor:

KERNEL[620.462898] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
KERNEL[620.462987] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
KERNEL[620.463081] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
UDEV  [620.465372] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
UDEV  [620.465449] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
UDEV  [620.469248] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
KERNEL[620.488358] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
UDEV  [620.489213] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
KERNEL[620.508182] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[620.508368] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509552] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
UDEV  [620.509591] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509612] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.509658] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
UDEV  [620.510619] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[620.510669] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [620.510699] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.511233] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[620.996518] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[621.198346] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[621.920579] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[621.922551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
UDEV  [622.010547] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [622.013885] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[622.314107] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[622.314926] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0 (usb)
KERNEL[622.316478] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0 (net)
KERNEL[622.316523] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/rx-0 (queues)
KERNEL[622.316551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/tx-0 (queues)
KERNEL[622.316998] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.1 (usb)

Nach langem Suchen, Probieren und Testen mit verschiedenen Linux-Distributionen und Kernelversionen (getestet mit Ubuntu 14.04 LTS, Kubuntu 15.04, SystemRescueCd, GParted Live CD jeweils mit den Standard-Kerneln, sowie unter Kubuntu 15.04 zusätzlich mit den Kerneln 4.1 und 4.2), konnte ich das Problem lösen.

Ich kann es mir zwar nicht erklären, aber Abhilfe schafft es tatsächlich, die Energieverwaltung für die Soundkarte des Laptops zu aktivieren! Dies wird zwar zum generellen Energiesparen von powertop empfohlen, jedoch hätte ich dies nie im Zusammenhang mit der Dockingstation erwartet.

Die Einstellung lässt sich bspw. mittels

echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';

in der Datei /etc/rc.local realisieren.

Eine etwas elegantere Variante wäre per UDEV-Regel. Dazu wird die Datei /etc/udev/rules.d/99-Yoga-Powermanagement.rules mit folgendem Inhalt angelegt:

SUBSYSTEM=="module", ACTION=="add", KERNEL=="snd_hda_intel", TEST=="parameters/power_save", ATTR{parameters/power_save}="1"

Die dritte und für Thinkpads meiner Meinung nach beste Variante ist die Benutzung des Tools tlp. Installationsanleitungen sind hier zu finden. Hier lassen sich viele Optionen zum Energiesparen relativ leicht einstellen.

Wichtig für die Aktivierung des Powermanagements der Audio-Hardware, insbesondere bei Betrieb am Netzstrom ist die Einstellung

SOUND_POWER_SAVE_ON_AC=1

in der Datei /etc/default/tlp.

Kubuntu 14.10: Network-Manager startet nicht mehr automatisch

Nach dem Upgrade von Kubuntu 14.04 auf 14.10 funktionierte nach einem Neustart meine WLAN-Verbindung auf meinem Lenovo Thinkpad X220 nicht mehr.
Beim Booten kam die Meldung:

waiting for network configuration (kurz danach dann:)
waiting an additional 60 seconds for network configuration

Nach einiger Wartezeit startete KDE dann trotzdem, jedoch ohne eine Netzwerkverbindung aufzubauen.
Dann fiel mir auf, dass der Network-Manager nicht wie gewünscht automatisch gestartet ist.

Nach manuellen Starten des Network-Manager-Dienstes mittels

service network-manager start

funktionierten dann auch die Netzwerkverbindungen wieder.

Leider startete der Dienst beim Hochfahren nicht von alleine.

Eine Google-Suche brachte nur Hinweise darauf, dass die Datei /etc/network/interfaces evtl. falsche Einträge enthalte. Das tat sie bei mir nicht. Es standen lediglich die beiden Zeilen

auto lo
iface lo inet loopback

drin.

Ich habe dann festgestellt, dass lediglich das Upstart-Event „static-network-up“ aus irgendeinem Grund fehlte. Wenn ich nämlich im gestarteten System den Befehl

initctl emit static-network-up

aufrief, kam auch der Network-Manager hoch.

Nach einiger Zeit habe ich festgestellt, dass in der Datei /etc/init/networking.conf relativ weit am Anfang der Befehl „ifup -a“ aufgerufen wird, um die Netzwerkschnittstellen zu aktivieren.

Als ich ihn manuell ausführte, kam es bei mir allerdings zu einer Fehlermeldung, dass „bridge“ nicht aktiviert werden konnte (die genaue Meldung bekomme ich aus dem Gedächtnisprotokoll leider nicht mehr hin…).

Das Problem lag daran, dass im Ordner /etc/network/if-pre-up.d noch ein Symlink namens „bridge“ auf eine nicht mehr vorhandene Datei aus dem Paket „bridge-utils“ existierte, welches aber nicht (mehr?) installiert war.

Nach dem Löschen der fehlerhaften Verknüpfung klappt jetzt auch das Hochfahren des Rechners inklusive NetworkManager.

Man sollte also schauen, ob der Befehl

ifup -a

fehlerfrei durchläuft. Dann ist die Wahrscheinlichkeit hoch, dass auch das Upstart-Event „static-network-up“ emit-iert wird, woraufhin wiederum der NetworkManager automatisch startet.

SSH-Zugang ohne Passwort per Public-Key-Authentifizierung

Hier habe ich einen netten Einzeiler dazu gefunden, der auch noch auf das mounten entfernter Verzeichnisse per sshfs eingeht.

Zunächst mit

ssh-keygen

ein (passwortloses) RSA-Schlüsselpaar erstellen.

Dann einmal mit

cat ~/.ssh/id_rsa.pub | ssh user@server 'cat >>~/.ssh/authorized_keys'

auf dem Server einloggen.

Update: Alternativ macht dieser Befehl das gleiche:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Beim nächsten Zugriff per

ssh user@server

ist dann auch kein Passwort mehr notwendig.

SSL-Zertifikat mit Wildcard und ohne

Für meinen Webserver wollte ich ein SSL-Zertifikat haben, bei dem sämtliche Subdomains enthalten sind (wie z.B. http://notizen.stephangsell.de), aber auch die Hauptdomain selber (http://stephangsell.de, ohne www).
Damit das beides funktioniert, muss das Feld subjAltName im Zertifikat gesetzt sein.
Den nötigen Tipp hab ich hier gefunden.

Zunächst sollte ein Private Key erzeugt werden, aus welchem später das Zertifikat erstellt werden kann:
openssl genrsa -out ~/stephangsell.de.key 2048

Um für CACert.de eine Certificate-Signing-Request (CSR) zu erstellen, muss man zunächst eine Konfigurationsdatei für OpenSSL erstellen:

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[ v3_req ]
subjectAltName = $ENV::SUBJALTNAME
[ req_distinguished_name ]
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64

Wir erstellen die Datei und speichern sie z.B. unter ~/myopenssl.cnf ab.

Der anschließend notwendige Aufruf von openssl lautet
SUBJALTNAME='DNS:*.stephangsell.de,DNS:*.example.net' openssl req \
-config ~/myopenssl.cnf \
-subj '/CN=stephangsell.de/emailAddress=admin@example.com' \
-new -extensions v3_req -key ~/stephangsell.de.key

Als Ausgabe erhält man das CSR, welches nun in das entsprechende Feld, z.B. bei CACert, kopiert wird. Daraus wird schließlich das unterzeichnete Zertifikat berechnet.


[Update]
Alternativ zu der hier beschriebenen Vorgehensweise lässt sich auch der CSRGenerator vom CACert-Wiki verwenden:
http://wiki.cacert.org/wiki/CSRGenerator

WLAN und WPA mit WPA_supplicant

Mein neuer WLAN-USB-Stick, ein Digitus DN-7003GT erzeugt mit lsusb folgende Ausgabe:

Bus 002 Device 003: ID 0bda:8189 Realtek Semiconductor Corp

Seit Kernel 2.6.27 funktioniert dieser Adapter tadellos mit dem Kernel-Modul RTL8187.

Das Programm iwconfig aus dem Paket net-wireless/wireless-tools listet den Stick unter dem Namen wlan0 auf.

Damit dieser sich auch mit einem WPA-Verschlüsselten Netzwerk verbinden kann sind folgende Schritte nötig:

Zunächst einmal muss das Paket net-wireless/wpa_supplicant installiert werden.

Anschließend wird die Datei /etc/conf.d/net.wlan0 mit folgendem Inhalt erstellt:

# wlan0 abschalten, wenn eine Netzwerkkabelverbindung gefunden wurde
# von http://www.gentoo-wiki.info/Wireless/Configuration#WPA
preup() {
if [[ ${IFACE} == „wlan0“ ]]; then
if ifplugstatus | grep -q ‚eth0: link beat detected‘; then
ewarn „Wired connection on eth0 detected, aborting configuration on ${IFACE}“
return 1
fi
fi
return 0
}

modules=( „wpa_supplicant“ )
wpa_supplicant_wlan0=“-D wext -c /etc/wpa_supplicant/wpa_supplicant.conf“


Zunächst Außerdem wird mit dem Befehl

ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0

ein Init-Skript erzeugt.

Die Konfigurationsdatei für wpa_supplicant liegt unter /etc/wpa_supplicant/wpa_supplicant.conf

Sie erhält folgenden Inhalt:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=users
update_config=1

network={
ssid=“WPA-AP“
psk=“DAS_WPA_PASSWORT“
priority=5
}

network={
ssid=“WEP-AP“
key_mgmt=NONE
wep_key0=11111111111111111111111111
wep_tx_keyidx=0
priority=5
# auth_alg=SHARED
}

Nun sollte sich der WLAN-Stick mittels

/etc/init.d/net.wlan0 start

mit dem konfigurierten Netzwerk verbinden können.

Netzwerk: WLAN nur aktivieren, wenn kein Netzwerkkabel eingesteckt ist

Um seine WLAN-Karte (oder WLAN-USB-Stick) nur zu aktivieren, wenn gerade kein Netzwerkkabel eingesteckt ist, kann man folgende Schritte ausführen.

(Annahme: die WLAN-Karte firmiert unter dem Namen wlan0)

Inhalt der Datei /etc/conf.d/net.eth0

# wlan0 einschalten, wenn das Netzwerkkabel nicht eingesteckt wurde
preup() {
if ethtool „${IFACE}“ | grep -q ‚Link detected: no‘; then
ewarn „No link on ${IFACE}, aborting configuration“
/etc/init.d/net.wlan0 start
fi
return 0
}

#config_eth0=( „dhcp“ )
config_eth0=( „192.168.0.10/24“ )
routes_eth0=(
„default via 192.168.0.1“ # IPv4 default route
)

Für den Inhalt der Datei /etc/conf.d/net.wlan0 siehe vorherigen Post.

Danach sollte man das Paket sys-apps/ifplugd installieren. Es ermöglicht es festzustellen, ob an der Netzwerkkarte ein Kabel angeschlossen ist und reagiert automatisch auf Veränderungen des Zustands.

Anschließend sollte man die Datei /etc/ifplugd/ifplugd.action dahingehend abändern, dass beim Entfernen des Netzwerkkabels automatisch das wlan0-Interface gestartet wird und entsprechend beim Einstecken des Netzwerkkabels wieder gestoppt wird.

Ausschnitt aus der Datei /etc/ifplugd/ifplugd.action (siehe dazu auch das gentoo-wiki.info)

case „$2“ in
up)
if [ „${INITNG}“ = „yes“ ]
then
ARGS=“-u net/$1″
else
ARGS=“–quiet start“
#wenn ein Netzwerkkabel eingesteckt wurde, soll wlan0 gestoppt werden
/etc/init.d/net.wlan0 –quiet stop
fi
;;
down)
if [ „${INITNG}“ = „yes“ ]
then
ARGS=“-d net/$1″
else
ARGS=“–quiet stop“
#wenn das Netzwerkkabel gezogen wurde, soll wlan0 gestartet werden
/etc/init.d/net.wlan0 –quiet start
fi
;;
*)
echo „$0: wrong arguments“ >&2
echo „Call with “ >&2
exit 1
;;
esac

Um zu verhindern, dass wlan0 automatisch beim Hochfahren gestartet wird, kann man in der Datei /etc/rc.conf die Zeile

rc_plug_services=“!net.wlan0″

einfügen.

On-Board-Netzwerkkarte Realtek 8111/8168

UPDATE:
Mit Kernel 2.6.27 läuft der Netzwerkchip auch mit dem Modul r8169.
Bei einem Mainboardtausch reicht es also aus, die Datei
/etc/udev/rules.d/70-persistent-net.rules
zu säubern oder ganz zu löschen. Das Kernel-Modul sollte den Chip voll unterstützen.

Untenstehendes ist also überholt!

==============================================================

Mein neues Mainboard hat einen neuen Netzwerk-Chip namens Realtek 81111C. Der Treiber dafür entspricht wohl dem des Realtek 8168.
Dafür gibt es einen Linux-Treiber von Realtek.
Treiber runterladen

wget ftp://152.104.238.19/cn/nic/r8168-8.009.00.tar.bz2

und mit

make clean modules

kompilieren. Anschließend kann das Modul mit

make install

installiert werden.

Es kann sein, dass das im Kernel vorhandene Modul r8169 versucht, sich die Netzwerkkarte fälschlicherweise unter den Nagel zu reißen. Dies wird mit der Zeile

blacklist r8169

in der Datei

/etc/modprobe.d/blacklist

verhindert.

Unter Gentoo sollte man nun noch (nachdem das neue Kernel-Modul r8168 installiert wurde) einmal

update-modules

ausführen. Dies sorgt dafür, dass es von modprobe gefunden wird.
Anschließend wird das Modul mit

modprobe r8168

geladen.
Falls es nun statt wie erwartet unter eth1 statt eth0 firmiert, kann man die Datei
/etc/udev/rules.d/70-persistent-net.rules säubern (oder komplett löschen).

Nun sollte sich das Netzwerk mit

ifconfig eth0 up

aktivieren lassen. Bei Bedarf kann man noch mit

dhclient eth0

eine IP-Adresse per DHCP beziehen.