Nach dem Kauf des Druckers Canon Maxify MB5450, ließ sich unter Windows 10 der Treiber für den Betrieb des Druckers im LAN klaglos installieren. Leider funktionierte der Ausdruck der Testseite der Windows Druckereinstellungen nicht einmal. In einem kleinen Umfang schien der Drucker Daten zu bekommen, aber konnte den Job nicht verarbeiten. Er signalisierte das durch die nun blinkende Statusleuchte links am Bedienfeld.

Der MAxify MB5450 funktionierte auf einem Windows basiertem Gerät mit WLAN allerdings doch und auf Mac OS-Geräten ebenso. Alle Geräte werden mit dem Kaspersky Virenscanner betrieben. Nachdem ich schon  mit dem HP-Support einen Disput über die Druckerkommunikation mit WSD hatte, schaltete ich zuerst nur die Firewall am betroffenden Gerät aus. Der Drucker funktionierte mit ausgeschlateter Firewall am Rechner anstandslos. Im nächsten Test deaktivierte ich eine Schutzfunktion des Kaspersky-Virenscanners nach der anderen. Es kristallisierte sich heraus, dass der Web-Anti-Virus das Verhalten des Druckers beeinflusste.

Das Problem war durch das Hinzufügen der Drucker IP inklusive Wildcard (*) unter Einstellungen-->Web-Anti-Virus-->erweiterte Einstellungen-->Vertauenswürdige Webadressen anpassen ohne weitere Probleme zu lösen!

Auf dem betroffenen Rechner zeigte sich mit Wireshark, das dass WSD-Protokoll des Druckers munter HTTP und HTTP/XML usw. hin und her schickte. Warum das im WLAN nicht geprüft wird? Ich weiss es bisher noch nicht. Ich kann mich  dunkel daran erinnern, dass ein HP Pro 8500 Plus seine Multicast-Pakete am DD-WRT basierenden Router in der Firewall verlor und so seinen Dienst versagte und es eine WSD-Verbindung war.

Wer Beispielsweise die Prozessorgrafik von einem AMD10 nutzt und den VGA-Ausgang anstatt des HDMI- oder DVI-Ausgangs nutzt, sieht zur Bootzeit später nichts oder seltsame Grafikfragmente.
In der /etc/default/grub ist beispielsweise GRUB_CMDLINE_LINUX_DEFAULT="video=VGA-1:1280x1024-24@75" festzulegen. Hier ist die Spezifikation des Grafikausgangs mit VGA-1 wichtig, da ansonsten HDMI oder DVI genutzt werden.

Die Einrichtung eines MultiWAN ist unter Openwrt denkbar einfach. Mein Multiwan ist in diesem Fall ohne Load-Balancer konfiguriert, um Aussfallsicherheit und WAN-Vorauswahl zu ermöglichen. Beim Umstellen vom einfachen WAN-Betrieb zum MultiWAN Betrieb hängt jedoch dann ein OpenVPN-Server mit der Fehlermeldung "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)".

Die Lösung, so dachte ich, ist auch denkbar einfach, in dem ich mit in der openvpn.conf mit "local name.ddns.host" das Interface namentlich über die IP-Adresse des DDNS-Hostnamen fxiere auf dem auch der VPN-Traffic eingeht. Der Fehler war damit alleine jedoch nicht behoben.

Erst mit dem Einstellen der Metrik auf den Gateways des der WAN-Verbindungen zeigte sich der Erfolg. In meinen Beispiel setzte ich die Metrik des VPN-WAN-Gateway auf 1 und des anderen WAN-Gateway auf 20.

Welches Kernel Image ist das best für HyperV?

Mittlerweile sind wohl linux-image-generic und linux-image-virtual baugleich und daher funktionsgleich. Das Paket linux-image-virtual hat ein paar Kernelmodule weniger und ist daher zu empfehlen.
(Quelle und mehr Infos: http://askubuntu.com/questions/503020/linux-image-virtual-packages-empty-in-14-04-trusty/503034#503034)

 

Bildschirmauflösung erhöhen, aber wie?

Ubuntu bekommt über /etc/default/grub einige Einstellungen für den Bootloader mit auf den Weg. Der Eintrag GRUB_CMDLINE_LINUX_DEFAULT wird nun um video=hyperv_fb:1920x1080 ergänzt.

Beispielsweise so:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1920x1080"

Danach ist auf der Konsole update-grub aufzurufen.

 

Etwas entsetzt war ich nach der Installation von Openwrt (Barrier Breaker) auf dem Asus RT-N16. Das WLAN funktionierte mit maximal 54MBit im G-Mode und die Datentransferrate lag bei ca. 3MByte/s, anstatt bei gewohnten 9-10 Mbyte/s im N-Mode. Die im OpenWrt-Wiki vorgeschlagene Lösung mit dem Kernelmodul brcmsmac brachte zwar mehr Geschwindigkeit.  Aber bei ca 6 MByte/s war dann auch Schluss.
Die Lösung war die Installation des originalen Broadcom-Kernelmoduls. Leider müssen auch nach der Installation des Broadcom-Kernelmoduls einige Probleme gelöst werden, wie die korrekte Einstellung der Region oder auch der MAC-Adressenfilter. Davon mal abgesehen, dass das WLAN mit dem originalen Broadcom-Kernelmodul erst gar nicht korrekt startete.