Archive for Februar 2016

Installationsdatum seines Windows ermitteln und die neuen Probleme mit Windows 10

18 Februar 2016

Man kann in der Eingabeaufforderung sehr einfach ermitteln, wann eine Windowsversion installiert wurde:

systeminfo|findstr /i install

Systeminfo ermittelt jede Menge Infos zum Rechner aber was uns hier interessiert ist nur das Installationsdatum. Die Angabe mit /i und nur install sorgt dafür, dass neben deutschen auch englische Windowsversionen so ihr Datum preisgeben.

Die Variante funktioniert von XP bis Windows 10 und auch bei den Servervarianten von 2003 bis 2012 R2, ebenso Hyper-V Server.

Soweit ist alles gut und schön. Dumm nur, dass durch die neue Microsoft Updatepolitik jährlich bis zu drei größere Updates zu erwarten sind und diese jeweils das Installationsdatum hochprügeln. Das tolle daran ist, man kann darüber nun sehr einfach feststellen, wann z. B. aktuell die Version v1511 eingespielt wurde.

Bei Windows 10 kann man also nicht mehr feststellen, was das ursprüngliche Installationsdatum war. Schade, schade…

Probleme beim Abruf von Internet Seiten durch Meldung: Bad Request–HTTP Error 400

17 Februar 2016

Wenn man Probleme mit der Meldung

Bad Request – Request Too Long


HTTP Error 400. The size of the request headers is too long.

bekommt, kann es daran liegen, dass der Überwachungsapparat einem zu viel Daten unterjubelt. Gemeint sind Cookies, welche von den Webservern an die Browser gesendet werden. Sammeln sich davon zuviele, weil z. B. ein Systemwechsel auf Serverseite stattgefunden hat und dabei das Ablaufdatum der alten Cookies nicht nah genug beschränkt waren, so kann es schon mal zu einem Überlauf kommen. Wie immer findet man dann kryptische Fehlermeldungen, die einen dumm dastehen lassen.

Was ist also zu tun? Browsercookies löschen!

Man kann auch z. B. in Chrome gezielt mit F12 die Entwicklertools aufrufen und dort bei Ressourcen unter Cookies diese nach der Größe sortieren lassen. Dann kommen da schnell so Brocken mit 2KB zum Vorschein, davon abgesehen, dass nicht ein, zwei sondern gleich zig Cookies zugegen sein können.

Raspberry Pi kennt kein nslookup

16 Februar 2016

Wer an seinem Raspberry Pi mit Raspbian Jessie auf Probleme mit einem DNS-Server stößt, der möchte diese als eingefleischter Windowsbenutzer mit nslookup lösen:

mypi:~ $ nslookup
bash: nslookup: command not found

Aber standardmäßig ist kein nslookup installiert. Wobei die Profis unter Linux benutzen sowieso dig:

mypi:~ $ dig mydomain.net SPF
bash: dig: command not found

OK, dahinter muss System stecken. Also muss das betreffende Programm installiert werden:

mypi:~ $ sudo apt-get install nslookup
Reading package lists… Done
Building dependency tree
Reading state information… Done

E: Unable to locate package nslookup

Jetzt muss man wissen, dass nslookup zusammen mit dig und nsupdate in einem Paket mit Namen dnsutils steckt: https://packages.debian.org/de/jessie/dnsutils. Also einfach dieses installiert:

mypi:~ $ sudo apt-get install dnsutils

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
libc-ares2 libv8-3.14.5
Use ‘apt-get autoremove’ to remove them.
Suggested packages:
rblcheck
The following NEW packages will be installed:
dnsutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 112 kB of archives.
After this operation, 324 kB of additional disk space will be used.
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main dnsutils armhf 1:9.9.5.dfsg-9+deb8u3 404 Not Found [IP: 5.153.225.207 80]
E: Failed to fetch http://mirrordirector. raspbian.org/raspbian/pool/main/b/bind9/dnsutils_9.9.5.dfsg-9+deb8u3_armhf .deb 404 Not Found [IP: 5.153.225.207 80]
E: Unable to fetch some archives, maybe run apt-get update or try with – -fix-missing?

Na super, da ist man auf der richtigen Spur aber es klappt nicht. Die Lösung ist aber zum Glück einfach, man muss vorher seine Installation mit aktuellen Paketupdates vorsorgen:

mypi:~ $ sudo apt-get update

Danach hat die Installation mittels sudo apt-get install dnsutils geklappt und dig und nslookup stehen zur Verfügung.

Raspberry Pi Raspbian Jessie und der Überlauf von /var/log/messages

13 Februar 2016

Hab ich mich eigentlich schon mal über die Flut an unnötigen Windows Ereignisanzeigeeintragungen beschwert? Nun so etwas gibt es auch bei Debian, hier speziell Debian Jessie auf einem Raspberry Pi.

Wenn man sich mittels

cat /var/log/messages

die LOG-Einträge anzeigen lässt, gibt es eine Vielzahl von LOG-Eintragungen mit dem Hiweis:

rsyslogd-2007: action ‚action 17‚ suspended, next retry is Sat Feb 13 20:28:26 2016 [try http://www.rsyslog.com/e/2007 ]

Auf der Seite www.rsyslog.com/e/2007 gibt es auch welche, die das Problem haben, scheint generell so zu sein. Dabei ist wichtig zu wissen, die Nummer 17 im obigen Beispiel kann auch eine andere Zahl darstellen und stellt letzten Endes den Konfigurationseintrag in der config-Datei dar.

Wenn man sich mittels

cat /etc/rsyslog.conf

die Einstellungen anschaut, dann taucht bei der Standardinstallation unten eine Zeile mit |/dev/xconsole auf. Genau hier liegt das Problem.

Um dies zu ändern, ruft man

sudo nano /etc/rsyslog.conf

auf und kommentiert die Zeilen ab daemon.*;mail.*;\ bis |/dev/xconsole mittels # aus. Anschließend muss man noch den rsyslog-Dienst neu starten:

sudo service rsyslog restart

Nun sollte die Log-Datei in Zukunft die wesentlichen Punkte zeigen.

Eigentlich könnte man das Problem auch lösen, indem man für die /dev/xconsole sorgt aber das darf jemand anderes machen…

Noch ein Hinweis: In der conf-Datei sind Dateinamen für die Log-Dateien angegeben. Dort findet man immer wieder die Angabe von – vor dem Dateinamen. Dies bedeutet, dass ein neuer Logeintrag nicht sofort auf die Festplatte geschrieben wird und somit im Falle eines Stromausfalls Eintragungen verloren gehen können: http://www.rsyslog.com/doc/v8-stable/configuration/actions.html#regular-file. Das Minus bedeutet nicht, dass keine LOG-Datei geführt werden soll.

Unicodezeichen in Powershell benutzen bzw. die Suche nach dem Daumen nach oben

8 Februar 2016

Möchte man bestimmte Zeichen in Powershell benutzen, die nicht direkt per Tastatur verfügbar sind, kann man den Datentyp [char] benutzen.

So erhält man z. B. durch Eingabe von

[char]0x2122

das Trademark-Symbol ™. Soweit so gut. Schwieriger wird es aber mit Zeichen, welche nicht direkt als Unicode zur Verfügung stehen.

Da gibt es z. B. den Daumen nach oben. Laut dieser Seite http://www.iemoji.com/view/emoji/56/people/thumbs-up-sign wäre der Code 0xd83ddc4d als UTF-16 also Unicode. Allerdings erhält dabei:

[char]0xd83ddc4d
Der Wert "-667034547" kann nicht in den Typ "System.Char" konvertiert werden. Fehler: "Der Wert für ein Zeichen war zu groß oder
zu klein."
In Zeile:1 Zeichen:1
+ [char]0xd83ddc4d
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvalidCastIConvertible

Was kann man tun? Nun die Tabelle bei der Webseite bietet noch UTF-32 an. Und UTF-32 kann man so benutzen:

[char]::ConvertFromUtf32(0x1f44d)

und erhält dafür!

Daraus kann man dann Konstrukte basteln wie dieses:

"Ich finde das gut $([char]::ConvertFromUtf32(0x1f44d))"

Was “Ich finde das gut ” ergibt.

Wenn es trotz allem nicht klappen sollte, hilft dieser Artikel noch weiter: https://mnaoumov.wordpress.com/2014/06/14/unicode-literals-in-powershell/

Telekom All-IP VoIP Spezifikationen

1 Februar 2016

Es führt kein Weg dran vorbei und die meisten werden direkt oder indirekt mit den VoIP Geschichten des Telekom Next Generation Network (NGN) zu tun bekommen.

Interessant ist, dass die Telekom unter https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/schnittstellenbeschreibungen-fuer-hersteller Technische Richtlinien veröffentlicht.

Unter der Rubrik Anschlusstyp IP (VoIP SIP) findet man alle Infos in Sachen SIP. Dabei werden Abkürzungen wie 1TR118 oder 1TR114 benutzt. TR steht für Technische Richtlinie.

In den Richtlinien findet man z. B. welche Codecs die Telekom benutzt. Dies sind aktuell G.711a (A-Law) und G.722. Auch wie mit Faxübertragungen umgegangen wird, wird z. B. in 1TR114 Amendment 4 beschrieben. Dabei gilt allgemein, dass 1TR114 für die direkte Anbindung der einzelnen Geräte steht und 1TR118 die Anbindung eines SIP-Trunks für komplette Telefonanlagen (SIP PBX) beschreibt. 1TR112 beschreibt den eigentlichen xDSL-Zugang, egal ob es sich um ADSL, VDSL oder ähnliches handelt. Dabei ist interessant, dass die Telekom für QoS IEEE 802.1D-2004 Annex G verwendet. 1TR127 behandelt die Anbindung von ISDN-Geräten an NGN als SIP-Client.

Wer Probleme mit seiner Telekom VoIP-Anbindung hat, kann da sicherlich jede Menge hilfreiche Informationen finden.

Dabei fällt auf, dass eines der wichtigsten Dokumente für 1TR114 eine von der Telekom abgewandelte Variante von 3GPP TS 24.229 ist, welches eigentlich für Mobiltelefone verwendet wird. Der Hintergrund ist, das am Ende alles in ein Netz konvergiert, egal ob die Anbindung mittels Mobil, Festnetz oder Internet stattfindet.

Was man bei der komplexen Geschichte mit NGN immer beachten muss ist, dass sogenannte IMS (IP Multimedia Subsystem). Wenn ein SIP User Agent nicht an ein NGN IMS angebunden werden kann, dann liegt dies meist an fehlender Unterstützung für Private und Public User Identities, SIP Digest mit AKAv1 (https://tools.ietf.org/html/rfc3310) bzw. AKAv2 (https://tools.ietf.org/html/rfc4169) , Path- und Service-Route Header, QoS-Aushandlung des SIP Precondition Framework. Einen guten Überblick in die Arbeitsweise eines IMS findet man in http://www.e-technik.org/sip/.

Weitere wichtige Links: http://www.sipforum.org/
https://www.bitkom.org/Bitkom/Publikationen/SIP-Trunking-Empfehlung.html
SIPConnect 1.1: http://www.sipforum.org/component/option,
com_docman/task,cat_view/gid,43/Itemid,75/

http://www.3gpp.org/