FrOSCon 2017
- Details
- Erstellt: Mittwoch, 02. August 2017 12:10
Am 19 und 20.08 ist es wieder so weit. Die FrOSCon öffnet ihre Türen. https://www.froscon.de/
Ich bin in diesem Jahr auch wieder dort wer noch? :-D
FreeBSD CPU Microcode Updates
- Details
- Erstellt: Mittwoch, 02. August 2017 09:49
Das es auch mal in einer CPU Fehler geben kann ist nicht jedem bewusst. Da es aktuell sehr durch die Presse geht, inzwischen vielleicht schon einigen Menschen mehr als vorher. Das diese Fehler in CPUs sogar recht oft vorkommen, daran denken die wenigsten. Ich kann mich noch an einen Intel Prozessor erinnern bei dem man einfach mit dem Windows Taschenrechner testen konnte ob ein bestimmte Bug vorliegt. Diese CPU durfte man sogar zurückgeben weil es sich nicht durch ein simples Update fixen lässt.
Update? Ja man kann den sogenennten Microcode der CPU updaten. Ja der Microcode ist fest in der CPU "eingebrannt" ein solches Update muss also jedes mal gemacht werden, wenn die CPU erneut eingeschaltet wird. Daher lösen es die meisten Mainbordhersteller über ein Bios Update. Wenn ihr also mal die Changelogs eurer Bios Updates durchgeht werdet ihr immer mal wieder etwas von CPU und oder Microcode lesen. Das ist dann genau so etwas. Setzt man ein älteres Mainboard ein gibt es auch kein Update :-D Setzt man Linux ein installiert man sich die Microcode Updates und bei jedem Start bekommt die CPU so ihr Update. Bei FreeBSD geht dieses natürlich ebenfalls. Da diese Frage bei mir schon ein paar mal angekommen ist, dieser Beitrag.
Das Paket nennt sich devcpu-data und findet sich in der Ports und ebenfalls auch als Binary:
$ pkg install devcpu-data
Damit es aktiviert ist und beim Booten geladen wird, ja ihr erratet es... Folgendes muss in die /etc/rc.conf :
microcode_update_enable="YES"
Dann lässt sich alles einmal anstarten und direkt sehen ob es erfolgreich ist:
$ /usr/local/etc/rc.d/microcode_update start Updating cpucodes... /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl0 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl2 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl4 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl6 from rev 0x28 to rev 0x29... done. Done.
Wie man sieht, er konnte ich ein Update vom Microcode durchführen und es gab auch eines. Es kommt immer mal wieder vor das Fehler gefunden werden daher dieses immer aktuell halten.
DNSSEC edns und path maximum transmission unit (PMTU) size beim bind - Fehlermeldung dnsviz
- Details
- Erstellt: Mittwoch, 05. Juli 2017 10:11
Mir ist in der letzten Zeit an ein paar Systemen ein kleines "Problem" im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:
domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)
Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es "dauert" nur etwas länger....
Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk....) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?
Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:
$ dig +short rs.dns-oarc.net txt rst.x490.rs.dns-oarc.net. rst.x499.x490.rs.dns-oarc.net. rst.x457.x499.x490.rs.dns-oarc.net. "2001:310:6000:f::1fc7:1 sent EDNS buffer size 512" "Tested at 2017-07-05 08:23:52 UTC" "2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"
Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:
options {
[....]
edns-udp-size 512;
max-udp-size 512;
[....]
};
edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.
So long...
Neue DNSSEC Keys
- Details
- Erstellt: Donnerstag, 06. Juli 2017 11:24
Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht :-)
FreeBSD WLAN und der Ländercode
- Details
- Erstellt: Mittwoch, 31. Mai 2017 13:16
Nutzt man auf seinem FreeBSD das WLAN so funktioniert es in der Regel ohne Probleme. Wenn man aber an ein WLAN gerät das Kanal 12 oder 13 benutzt, so funktioniert das irgendwie nicht. Warum? Ganz einfach... im Standard kommt ein FreeBSD mit dem Ländercode US für USA hoch. Dort ist leider essig mit Kanal 12 und 13. Daher muss man seinem FreeBSD erstmal sagen das es sich in Deutschland befindet. Dieses geht wie folgt:
$ ifconfig wlan0 list channel $ ifconfig wlan0 down $ ifconfig wlan0 ecm $ ifconfig wlan0 regdomain ETSI $ ifconfig wlan0 country DE $ ifconfig wlan0 up $ ifconfig wlan0 list channel
Zeile 1 zeigt einem dabei die aktuellen Kanaleinstellungen, Zeile 2 schaltet das die Karte für die Umstellungen ab, Zeile 3 bis 5 bringen uns nach Europa und Deutschland, Zeile 6 schaltet das wlan wieder ein und Zeile 7 gibt uns nun die aktuellen Kanäle einmal aus.
Möchte man dieses nun nicht immer einstellen sondern fest bei jedem Start mit eingebaut haben hilft folgende Zeile in der /etc/rc.conf:
create_args_wlan0="ecm regdomain ETSI country DE"
Möchte man mehr erfahren kann man sich die Datei: /etc/regdomain.xml anschauen oder besser noch:
$ ifconfig wlan0 list regdomain
Dieses geht natürlich ebenfalls mit dem country:
$ ifconfig wlan0 list countries
Tjo... Viel Spaß wa?
