Alle Beiträge von adlerweb

YubiKey: GPG-Kartenfehler / Sharing Violation unter Windows

Ugh – Windows und Sicherheitsfunktionen passt irgendwie immer noch nicht zusammen. Schon länger nutze ich einen YubiKey als GPG-Smartcard um E-Mails zu signieren und entschlüsseln. Das funktionierte mit GPG4Win und Thunderbird bisher auch recht brauchbar – also bis auf den Windows-GPG-Agent-Bug.

Wie gesagt: Bisher. Heute dann ein etwas seltsamer Bug:

# gpg --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error

Wat. Schnell nochmal den Daemon durchstarten: Nix. Im Log findet man folgende Info:

scdaemon: pcsc_connect failed: sharing violation (0x8010000b)
scdaemon: reader slot 0: not connected

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/wp-1485952629803-300×225.jpgWait. Sharing violation? Greift sonst noch wer zu? Jepp, natürlich tut das Jemand. Ich hatte zwischenzeitlich auf dem YubiKey für ein anderes System X.509-Zertifikate (aka PIV) eingerichtet. Diese kommen z.B. zur Authentifizierung zum Einsatz und können unter Windows auch z.B. für Remote-Logins und das entschlüsseln von Bitlocker-Festplatten verwendet werden. Entsprechend hat nun also auch Windows die PIV-Smartcard gefunden und belagert das Device dauerhaft – somit ist der Zugriff für gpg nicht mehr möglich. Abhilfe schafft hier den Dienst „CertPropSvc“ (aka „Zertifikatverteilung“) zu beenden bzw. neuzustarten. In letzterem Fall bleibt das Gerät frei bis man die nächste Software mit PIV-Zugriff (z.B. Remotedesktop) startet.

Also als weiterer Punkt auf dem nicht enden wollenden Wunschzettel für einen würdigen Nachfolger für die leider sicherheitstechnisch bedenklich gewordenen YubiKeys: Parallelität der SC-Reader…

STDOUT verdoppeln mit ftee

Mal wieder eine etwas andere Anforderung: Für eine automatische Verarbeitung soll eine Audioquelle durch eine Software auf der Konsole ausgewertet werden. Die Software ist hierbei für die Analyse von Dateien ausgelegt, kann allerdings auch von STDIN lesen. So weit kein Problem – arecord kümmert sich um die Aufnahme und per STDOUT/Pipe geht es in die Analysesoftware. Leider gibt es hier einen Haken: Es funktioniert nicht zuverlässig. Um zu prüfen ob die Audioquelle oder die Analyse das Problem verursacht müsste ich die eingehenden Audiodateien abhören. Am PC ginge das mit Pulseaudio recht einfach, am Server möchte ich auf dieses Ressourcen- und Dependency-Monster jedoch vorzugsweise verzichten.

Dann halt per File

Meine erste Idee: tee. Mit diesem Befehl kann man die Dateien einer Pipe in eine zusätzliche Datei „abzwacken“:

arecord hw:1,0 | tee test.daten | analyzer -

Was prinzipiell funktioniert hat jedoch einen entscheidenden Nachteil: Es landet alles in der Datei. Dauerhaft. Möchte man nicht, dass die Festplatte voll läuft, muss man nach dem reinhören das Konstrukt abbrechen und ohne tee-Befehl neu starten. Eher unschön, denn das heißt auch Deattime, also eine kurze Zeitspanne in der ich möglicherweise Ereignisse verpasse.

Und was ist mit FIFO?

Als Alternative eignet sich ein FIFO, auch als named Pipe bezeichnet. Diese lassen sich mit mkfifo anlegen und stellen sozusagen einen „Puffer“ zur Verfügung, über den sich Prozesse verbinden lassen. Hier können wir im ersten Terminal z.B. wie folgt starten:

mkfifo test.fifo
arecord hw:1,0 | tee test.fifo | analyzer -

und im Zweiten den Stream abgreifen

cat test.fifo > test.daten

Dummerweise gibt es auch hier Probleme: Es blockiert. Der Analyzer im ersten Terminal wird erst gestartet, wenn wir im Zweiten beginnen den Puffer zu lesen. Schlimmer noch: Brechen wir im zweiten Terminal das Mitlesen ab wird auch der Analyzer beendet. Nicht wirklich was ich suche.

Dauer-Interimslösung

Nunja, da mir die Ideen ausgingen und das Internet auf den ersten Blick nichts passendes lieferte blieb es erst mal bei der dauerhaften Dateiaufzeichnung auf einen speziell limitierten Ordner. Lief alle paar Wochen die zugehörige Partition voll brach die Software ab und ich startete per Hand neu. Auf der Todo-Liste stand etwas von automatischen Neustarts oder einem Gebastel um nur bei Bedarf die Ausgabe zur named Pipe zu starten. Dieser Zustand hielt nun für etwa 2 Jahre.

Rettung bei Stackoverflow

Heute ging es dann um die Behebung. Ich hatte grade ein Rendering gestartet und entsprechend etwas Leerlauf als die altbekannte Mail kam: Partition voll, die Erkennung steht. Jetzt reicht es. Also schnell auf Google und etwas in die Verwendung von Named Pipes einlesen.

Moment.

Nach kurzer Recherche landete ich bei Stackoverflow (wo auch sonst). Nach „Linux non-blocking fifo“ erkundigt sich der Autor „Dronus“ und beschreibt ein Szenario, welches recht Nah an meine Andorderungen heran kam. Und Beantworter „racic“ lieferte auf ganzer Linie: „ftee“ nennt sich sein überschaubarer C-Code, welcher das verhalten von tee nachmacht, jedoch für den FIFO nicht blockiert. Auch wird SIGPIPE, welches beim Abbrechen des Lesevorgangs der Pipe ausgelöst wird, nicht beachtet, der Analyzer läuft also fleißig weiter. Greift man später erneut auf die Pipe zu erhält man wieder die aktuellen Daten.

Wer „wichtige“ Daten nutzt kann alternativ auf das ebenfalls dort zu findende bftee von Fabraxias zurückgreifen, welches bei einem Abbruch der Verbindung alle eingehenden Daten zwischenspeichert und bei der nächsten Verbindung erst einmal nachliefert.

Für mich ist die nicht gepufferte Variante ideal – alte Audiodaten sind für mich nicht relevant. Das Kompilieren ist mit aktuellem GCC schnell erledigt und allein das ersetzen von tee gegen ftee im vorherigen Beispiel löst alle Probleme. Der Analyzer läuft und ich kann bei Bedarf in den Audiostream reinhören ohne eine Unterbrechung der Auswertung zu bekommen. Fein.

FRITZ!Box per Konsole auslesen (PHP/TR64)

Statistiken sind toll. Wäre fein, wenn man auch der FRITZ!Box einiges entlocken könnte. Das Zauberwort lautet TR64 und ist über HTTP/SOAP im LAN erreichbar. Hierzu müssen in den Netzwerkeinstellungen die Anwendungszugriffe und Statusinformationen aktiv sein.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/01/fbox-300×137.png

Allgemeine Infos wie die aktuell verwendete Bandbreite lassen sich von jedem Abrufen, andere Bereiche konnte ich bisher nur über /control abrufen – hier werden die Zugangsdaten eines FB-Nutzers benötigt.

Über das Protokoll lassen sich neben IP, Verbindungsstatus und Bandbreiten auch erweiterte Infos wie Dämpfungen & Co aufzeichnen. Technisch kann man sogar Aktionen wie einen Reconnect oder komplette Konfigurationsänderungen durchführen, das würde hier jedoch den Rahmen sprengen. Einige Infos gibt es in der Wiki von WeHaveMoreFun oder das ausgiebigere Perl-Modul von FHem.

Hier mal mein Notizzettel, welcher eine Abfrage per PHP erlaubt:

<?php



function FbSOAP($url, $urn, $method='GetInfo', $user='', $pass='') {
    $parameter = array(
        'location'   => $url,
        'uri'        => $urn,
        'noroot'     => True
    );

    if($user != '') $parameter['login'] = $user;
    if($pass != '') $parameter['password'] = $pass;

    $client = new SoapClient(
        null,
        $parameter
    );
    $status = $client->$method();
    return $status;
}

$host = 'http://fritz.box:49000';
$user = 'nutzer';
$pass = 'geheim';

//Aktuell verwendete Bandbreite, Traffic seit Boot, DNS-Konfiguration (kein Passwort nötig)
var_dump(FbSOAP($host.'/igdupnp/control/WANCommonIFC1', 'urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1', 'GetAddonInfos'));

/*
  ["NewByteSendRate"]=>
  string(5) "20709"
  ["NewByteReceiveRate"]=>
  string(5) "21372"
  ["NewPacketSendRate"]=>
  string(1) "0"
  ["NewPacketReceiveRate"]=>
  string(1) "0"
  ["NewTotalBytesSent"]=>
  string(9) "986828869"
  ["NewTotalBytesReceived"]=>
  string(10) "1140825575"
  ["NewAutoDisconnectTime"]=>
  string(1) "0"
  ["NewIdleDisconnectTime"]=>
  string(2) "30"
  ["NewDNSServer1"]=>
  string(14) "217.237.15.1"
  ["NewDNSServer2"]=>
  string(14) "217.237.14.2"
  ["NewVoipDNSServer1"]=>
  string(14) "217.237.15.1"
  ["NewVoipDNSServer2"]=>
  string(14) "217.237.14.2"
  ["NewUpnpControlEnabled"]=>
  string(1) "0"
  ["NewRoutedBridgedModeBoth"]=>
  string(1) "1"
*/

//Verbindungsstatus und Typ (kein Passwort nötig)
var_dump(FbSOAP($host.'/igdupnp/control/WANCommonIFC1', 'urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1', 'GetCommonLinkProperties'));

/*
Achtung - MaxBitRate ist nicht konsistent

array(4) {
  ["NewWANAccessType"]=>
  string(3) "DSL"
  ["NewLayer1UpstreamMaxBitRate"]=>
  string(7) "1073000"
  ["NewLayer1DownstreamMaxBitRate"]=>
  string(7) "2304000"
  ["NewPhysicalLinkStatus"]=>
  string(2) "Up"
}
*/

//DSL-Sync-Status, DSL-Datenraten und Dämpfungen
var_dump(FbSOAP($host.'/upnp/control/wandslifconfig1', 'urn:dslforum-org:service:WANDSLInterfaceConfig:1', 'GetInfo', $user, $pass));

/*
array(15) {
  ["NewEnable"]=>
  string(1) "1"
  ["NewStatus"]=>
  string(2) "Up"
  ["NewDataPath"]=>
  string(11) "Interleaved"
  ["NewUpstreamCurrRate"]=>
  string(3) "224"
  ["NewDownstreamCurrRate"]=>
  string(4) "2304"
  ["NewUpstreamMaxRate"]=>
  string(4) "1196"
  ["NewDownstreamMaxRate"]=>
  string(4) "4736"
  ["NewUpstreamNoiseMargin"]=>
  string(3) "270"
  ["NewDownstreamNoiseMargin"]=>
  string(3) "130"
  ["NewUpstreamAttenuation"]=>
  string(3) "290"
  ["NewDownstreamAttenuation"]=>
  string(3) "490"
  ["NewATURVendor"]=>
  string(8) "41564d00"
  ["NewATURCountry"]=>
  string(4) "0400"
  ["NewUpstreamPower"]=>
  string(3) "502"
  ["NewDownstreamPower"]=>
  string(3) "500"
}
*/

//DSL-Fehlerstatistiken
var_dump(FbSOAP($host.'/upnp/control/wandslifconfig1', 'urn:dslforum-org:service:WANDSLInterfaceConfig:1', 'GetStatisticsTotal', $user, $pass));

/*
array(15) {
  ["NewReceiveBlocks"]=>
  string(1) "0"
  ["NewTransmitBlocks"]=>
  string(1) "0"
  ["NewCellDelin"]=>
  string(1) "0"
  ["NewLinkRetrain"]=>
  string(1) "9"
  ["NewInitErrors"]=>
  string(1) "0"
  ["NewInitTimeouts"]=>
  string(1) "0"
  ["NewLossOfFraming"]=>
  string(1) "0"
  ["NewErroredSecs"]=>
  string(3) "637"
  ["NewSeverelyErroredSecs"]=>
  string(2) "54"
  ["NewFECErrors"]=>
  string(7) "3932348"
  ["NewATUCFECErrors"]=>
  string(1) "9"
  ["NewHECErrors"]=>
  string(4) "7289"
  ["NewATUCHECErrors"]=>
  string(2) "10"
  ["NewCRCErrors"]=>
  string(4) "1635"
  ["NewATUCCRCErrors"]=>
  string(2) "13"
}
*/

//Gerätemodell, Softwareversion, Seriennummer, Logfile
var_dump(FbSOAP($host.'/upnp/control/deviceinfo', 'urn:dslforum-org:service:DeviceInfo:1', 'GetInfo', $user, $pass));

/*
array(12) {
  ["NewManufacturerName"]=>
  string(3) "AVM"
  ["NewManufacturerOUI"]=>
  string(6) "00040E"
  ["NewModelName"]=>
  string(28) "FRITZ!Box Fon WLAN 7390 (UI)"
  ["NewDescription"]=>
  string(37) "FRITZ!Box Fon WLAN 7390 (UI) 84.06.51"
  ["NewProductClass"]=>
  string(9) "FRITZ!Box"
  ["NewSerialNumber"]=>
  string(12) "C02506210000"
  ["NewSoftwareVersion"]=>
  string(8) "84.06.51"
  ["NewHardwareVersion"]=>
  string(28) "FRITZ!Box Fon WLAN 7390 (UI)"
  ["NewSpecVersion"]=>
  string(3) "1.0"
  ["NewProvisioningCode"]=>
  string(0) ""
  ["NewUpTime"]=>
  string(7) "2375523"
  ["NewDeviceLog"]=>
  string(15974) "03.01.17 02:32:46 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxxx, DNS-Server: 217.237.150.xx und 217.237.148.xx, Gateway: 87.186.225.xx, Breitband-PoP: xxx05-asr
03.01.17 02:32:46 Internetverbindung wurde getrennt.
03.01.17 02:32:43 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
…
*/

//Software-Update verfügbar?
var_dump(FbSOAP($host.'/upnp/control/userif', 'urn:dslforum-org:service:UserInterface:1', 'GetInfo', $user, $pass));
/*
array(9) {
  ["NewUpgradeAvailable"]=>
  string(1) "0"
  ["NewPasswordRequired"]=>
  string(1) "0"
  ["NewPasswordUserSelectable"]=>
  string(1) "1"
  ["NewWarrantyDate"]=>
  string(19) "0001-01-01T00:00:00"
  ["NewX_AVM-DE_Version"]=>
  string(0) ""
  ["NewX_AVM-DE_DownloadURL"]=>
  string(0) ""
  ["NewX_AVM-DE_InfoURL"]=>
  string(0) ""
  ["NewX_AVM-DE_UpdateState"]=>
  string(8) "NoUpdate"
  ["NewX_AVM-DE_LaborVersion"]=>
  string(0) ""
}
*/

//WLAN-Konfiguration und Status
var_dump(FbSOAP($host.'/upnp/control/wlanconfig1', 'urn:dslforum-org:service:WLANConfiguration:1', 'GetInfo', $user, $pass));

/*
array(17) {
  ["NewEnable"]=>
  string(1) "0"
  ["NewStatus"]=>
  string(8) "Disabled"
  ["NewMaxBitRate"]=>
  string(4) "Auto"
  ["NewChannel"]=>
  string(2) "13"
  ["NewSSID"]=>
  string(17) "ADLERWEB-TEST"
  ["NewBeaconType"]=>
  string(3) "11i"
  ["NewMACAddressControlEnabled"]=>
  string(1) "0"
  ["NewStandard"]=>
  string(1) "n"
  ["NewBSSID"]=>
  string(17) "C0:25:06:00:00:00"
  ["NewBasicEncryptionModes"]=>
  string(4) "None"
  ["NewBasicAuthenticationMode"]=>
  string(4) "None"
  ["NewMaxCharsSSID"]=>
  string(2) "32"
  ["NewMinCharsSSID"]=>
  string(1) "1"
  ["NewAllowedCharsSSID"]=>
  string(95) "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~"
  ["NewMinCharsPSK"]=>
  string(2) "64"
  ["NewMaxCharsPSK"]=>
  string(2) "64"
  ["NewAllowedCharsPSK"]=>
  string(22) "0123456789ABCDEFabcdef"
}
*/

//DSL-Status und Konfiguration
var_dump(FbSOAP($host.'/upnp/control/wandsllinkconfig1', 'urn:dslforum-org:service:WANDSLLinkConfig:1', 'GetInfo', $user, $pass));

/*
array(9) {
  ["NewEnable"]=>
  string(1) "1"
  ["NewLinkStatus"]=>
  string(2) "Up"
  ["NewLinkType"]=>
  string(5) "PPPoE"
  ["NewDestinationAddress"]=>
  string(9) "PVC: 1/32"
  ["NewATMEncapsulation"]=>
  string(3) "LLC"
  ["NewAutoConfig"]=>
  string(1) "0"
  ["NewATMQoS"]=>
  string(3) "UBR"
  ["NewATMPeakCellRate"]=>
  string(1) "0"
  ["NewATMSustainableCellRate"]=>
  string(1) "0"
}
*/

//DSL-Statistiken
var_dump(FbSOAP($host.'/upnp/control/wandsllinkconfig1', 'urn:dslforum-org:service:WANDSLLinkConfig:1', 'GetStatistics', $user, $pass));

/*
array(4) {
  ["NewATMTransmittedBlocks"]=>
  string(1) "0"
  ["NewATMReceivedBlocks"]=>
  string(1) "0"
  ["NewAAL5CRCErrors"]=>
  string(1) "0"
  ["NewATMCRCErrors"]=>
  string(1) "0"
}
*/

//PPP-Status (incl. externer IP!)
var_dump(FbSOAP($host.'/upnp/control/wanpppconn1', 'urn:dslforum-org:service:WANPPPConnection:1', 'GetInfo', $user, $pass));

/*
BitRate auch hier nicht nachvollziehbar

array(31) {
  ["NewEnable"]=>
  string(1) "1"
  ["NewConnectionStatus"]=>
  string(9) "Connected"
  ["NewPossibleConnectionTypes"]=>
  string(21) "IP_Routed, IP_Bridged"
  ["NewConnectionType"]=>
  string(9) "IP_Routed"
  ["NewName"]=>
  string(8) "internet"
 ["NewUptime"]=>
  string(5) "57428"
  ["NewUpstreamMaxBitRate"]=>
  string(7) "1083169"
  ["NewDownstreamMaxBitRate"]=>
  string(7) "4289207"
  ["NewLastConnectionError"]=>
  string(10) "ERROR_NONE"
  ["NewIdleDisconnectTime"]=>
  string(1) "0"
  ["NewRSIPAvailable"]=>
  string(1) "0"
  ["NewUserName"]=>
  string(40) "deineid@t-online.de"
  ["NewNATEnabled"]=>
  string(1) "1"
  ["NewExternalIPAddress"]=>
  string(13) "91.35.130.0"
  ["NewDNSServers"]=>
  string(30) "217.237.150.0, 217.237.148.0"
  ["NewMACAddress"]=>
  string(17) "C0:25:06:00:00:00"
  ["NewConnectionTrigger"]=>
  string(8) "AlwaysOn"
  ["NewLastAuthErrorInfo"]=>
  string(0) ""
  ["NewMaxCharsUsername"]=>
  string(3) "128"
  ["NewMinCharsUsername"]=>
  string(1) "3"
  ["NewAllowedCharsUsername"]=>
  string(87) "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-._@()#/%[]{}*+§$&=?!:;,"
  ["NewMaxCharsPassword"]=>
  string(2) "64"
  ["NewMinCharsPassword"]=>
  string(1) "3"
  ["NewAllowedCharsPassword"]=>
  string(87) "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-._@()#/%[]{}*+§$&=?!:;,"
  ["NewTransportType"]=>
  string(5) "PPPoE"
  ["NewRouteProtocolRx"]=>
  string(3) "Off"
  ["NewPPPoEServiceName"]=>
  string(0) ""
  ["NewRemoteIPAddress"]=>
  string(0) ""
  ["NewPPPoEACName"]=>
  string(10) "xxxx05-asr"
  ["NewDNSEnabled"]=>
  string(1) "1"
  ["NewDNSOverrideAllowed"]=>
  string(1) "1"
}

*/


?>

 

Amdroid/CM: Eingehende SMS werden nicht angezeigt

Die Älteren unter euch können sich eventuell erinnern: SMS. Ein System um Textnachrichten an Mobiltelefone zu senden. Begrenzte Textlänge, hohe Gebühren und nicht verschlüsselt. Eigentlich heute Obsolet, aber einige Anbieter denken immer noch, dass dieses Verfahren modern sei – auch wenn es seit fast 7 Jahren als unsicher eingestuft wird. Hallo Banken. Es kam wie es kommen musste: Ich sah mich genötigt ein Produkt über eine dieser Gesellschaften zu bezahlen und – nichts. Während die Webseite freudig vermeldete, dass ich eine passende TAN erhalten hätte machte mein Handy keinen Mucks. Toll, ich hab ein Zahlungsziel. Aber auch nichts ungewöhnliches – im Telefonica-Netz kommt es ja nicht unbedingt selten zu Störungen, also warten wir halt.

Einige Stunden später noch immer nichts, also müssen wir wohl selbst Hand anlegen. Erste Anlaufstelle: Test-SMS senden. Gar nicht so einfach, denn SMS-Funktion hab ich eigentlich auf keinem anderen Gerät mehr installiert. Glücklicherweise habe ich noch einen „echten“ Telefonanschluss ohne VoIP und konnte daher per Modem ein SMS-Gateway erreichen. Allerdings ohne Erfolg. Also machen wir mal ein altes Handy fit und versuchen es da – woho, SMS. Es muss also an meinem Endgerät liegen.

Per ADB zeigt sich nach einigem (teuren) Geteste folgender Fehler:

12-14 11:07:05.216  3179  5307 W MmsSmsDatabaseHelper: Upgrading database from version 64 to 67.
12-14 11:07:05.216  3179  5307 E SQLiteLog: (1) table sms_restricted already exists
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper: table sms_restricted already exists (code 1): , while compiling: CREATE VIEW sms_restricted AS SELECT * FROM sms WHERE type=1 OR type=2;
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper: android.database.sqlite.SQLiteException: table sms_restricted already exists (code 1): , while compiling: CREATE VIEW sms_restricted AS SELECT * FROM sms WHERE type=1 OR type=2;
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:889)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:500)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:58)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteStatement.<init>(SQLiteStatement.java:31)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1677)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1608)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at com.android.providers.telephony.MmsSmsDatabaseHelper.upgradeDatabaseToVersion66(MmsSmsDatabaseHelper.java:1721)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at com.android.providers.telephony.MmsSmsDatabaseHelper.onUpgrade(MmsSmsDatabaseHelper.java:1466)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:256)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:187)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at com.android.providers.telephony.SmsProvider.query(SmsProvider.java:160)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.content.ContentProvider.query(ContentProvider.java:1020)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.content.ContentProvider$Transport.query(ContentProvider.java:239)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper:  at android.os.Binder.execTransact(Binder.java:565)
12-14 11:07:05.218  3179  5307 E MmsSmsDatabaseHelper: Destroying all old data.

Das kommt mir doch irgendwie bekannt vor… Schade, dass der Fehler nicht in der GUI erscheint und man so vermutet, dass alles ohne Störung funktionieren würde. Also löschen wir auch hier die kaputte Datenbank. Leider nicht ganz so einfach, denn zu dieser Meldung schweigen sich die Suchmaschinen aus und auch im Log wird der Dateiname der betroffenen Datenbank leider nicht erwähnt. Abhilfe schafft „Self Rubber Ducking“ , welcher augenscheinlich sehr von Migrationscode angetan ist. Fündig wurde ich dann im Ordner, welcher sich auch schon bei der Telefonie als Verursacher zeigte – hätte man drauf kommen können. Meh.

Also – leicht angepasst:

adb shell
su -
rm -rf /data/user_de/0/com.android.providers.telephony/databases/mmssms.*

Nach einem Reboot kann dann auch der Fintechler wieder mit mir kommunizieren. Ich wäre ja dafür langsam mal offene Standards für sowas zu schaffen – sowas wie U2F mit angezeigten Transaktionsdaten…

Amdroid/CM: com.android.phone force-close nach Update

Ja, schmutzig ist praktisch – zumindest wenn es um Updates geht. Obwohl die meisten Entwickler empfehlen möglichst bei jedem Update mit einem frischen System zu beginnen versuche ich meine Daten so lange wie möglich mitzuschleifen („Dirty Flash“) – leider gibt es noch immer unzählige Apps, welche keine brauchbare Backup-Funktion bieten und auch systembasierte Lösungen wie Titanium Backup sind leider nicht unfehlbar.

Zuletzt war ich etwas nachlässig – mein Handy war noch auf Version 2, aktuell Version 9 meiner aktuellen ROM. Zeit zum Aktalisieren, vor allem da Dirty Cow gerade bekannt wurde.

Also, Sideload drüber und – narf. „Telefon reagiert nicht mehr“. Gemeint ist hierbei die Telefon-App, also jene, welche Sprachtelefonie ermöglicht. Brauch ich zwar normal nicht, aber die Popups nerven doch etwas.

Über ADB ließ sich folgendes im Log erspähen:

12-06 16:43:32.820  3708  3708 E AndroidRuntime: FATAL EXCEPTION: main
12-06 16:43:32.820  3708  3708 E AndroidRuntime: Process: com.android.phone, PID: 3708
12-06 16:43:32.820  3708  3708 E AndroidRuntime: java.lang.IllegalArgumentException: column 'user_network_mode' does not exist
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at android.database.AbstractCursor.getColumnIndexOrThrow(AbstractCursor.java:333)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at android.database.CursorWrapper.getColumnIndexOrThrow(CursorWrapper.java:87)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.telephony.SubscriptionController.getSubInfoRecord(SubscriptionController.java:293)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.telephony.SubscriptionController.getSubInfoUsingSlotIdWithCheck(SubscriptionController.java:1631)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.telephony.SubscriptionInfoUpdater.updateSubscriptionInfoByIccId(SubscriptionInfoUpdater.java:593)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.telephony.SubscriptionInfoUpdater.handleSimLoaded(SubscriptionInfoUpdater.java:421)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.telephony.SubscriptionInfoUpdater.handleMessage(SubscriptionInfoUpdater.java:338)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:102)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:154)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6140)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:888)
12-06 16:43:32.820  3708  3708 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:778)

Dankenswerterweise gibt es einen passenden Post von Daan, welcher die Ursache genau beschreibt und einen passenden Befehl zum zurücksetzen der defekten Datenbank anbietet. Hierbei gehen ggf. Einstellungen verloren, diese muss man ggf. später von seiner Datensicherung wieder einspielen.

adb shell
su -
rm -rf /data/user_de/0/com.android.providers.telephony/databases/telephony.*

Nach dem Befehl war dann Ruhe und sogar das telefonieren funktioniert wieder. Fein.

Windows/GPG/Smartcard – GPG mit Powershell bei SC-Verbindung neu starten

Beim Thema E-Mail-Verschlüsselung ist GPG weit verbreitet. Die Gundfunktionen sind z.B. mit Thunderbird und Enigmail oder gar eine Appliance auch für Einsteiger nutzbar und durch das WoT erstpart man sich die Abhängigkeit von – teils Zweifelhaften – zentralen Zertifizierungsstellen. Ich selbst nutze seit einiger Zeit keinen Softwareschlüssel sondern ein dediziertes HSM (Hardware Security Module) in Form eines YubiKey. Hiermit befindet sich der Key nicht mehr auf dem PC und auch die Verschlüsselung/Signierung läuft in Teilen auf dem Prozessor des YubiKey. Was unter Linux ohne große Änderungen funktioniert macht bei Windows eher wenig Spaß. Zwar ist auch GPG4Win in der Lage mit CryptoCards & Co umzugehen, häufiges Ein- und Ausstecken führt jedoch schnell zu einem hängenden GPG-Agent oder Absturzen der scdaemon.exe (GPG SmartCard Daemon). Einzige Abhilfe: Alle GPG-Prozesse beenden und neu starten. Da Verschlüsselung und Windows ohnehin eher selten zu finden ist sind auch Informationen dazu dünn gesät. Da ich teilweise um das System aus Redmond nicht herum komme und ein Fix in GPG4Win nicht in Sichtweite ist muss also wieder einmal der Holzhammer her: Irgendwie muss beim Einstecken des USB-Gerätes das GPG-System zurückgesetzt werden.

Also frisch ans Werk. Als Sprache soll mal wieder Powershell herhalten – direkt verfügbar, halbwegs systemnah, sollte passen. Über WMI kann man sich auch über ab- und angesteckte Geräte informieren lassen. Leider konnte ich keine Möglichkeit finden weitere Infos wie z.B. Hersteller oder Treiber gleich mit zu erhalten. Da sonst eher wenig Gerätefluktuation zu erwarten ist ziehe ich die „passt scho“-Karte und werde das GPG-System bei jedem neu auftauchenden Gerät einmal zurücksetzen.

#Requires -version 2.0
Register-WmiEvent -Class Win32_DeviceChangeEvent -SourceIdentifier deviceChange
write-host (get-date -format s) " Beginning script..."
do {
    $newEvent = Wait-Event -SourceIdentifier deviceChange
    $eventType = $newEvent.SourceEventArgs.NewEvent.EventType
    $eventTypeName = switch($eventType) {
        1 {"Configuration changed"}
        2 {"Device arrival"}
        3 {"Device removal"}
        4 {"docking"}
    }
    write-host (get-date -format s) " Event detected = " $eventTypeName

    $newEvent.SourceEventArgs.NewEvent | fl

    if ($eventType -eq 2) {
            write-host (get-date -format s) " Starting task in 3 seconds..."
            start-sleep -seconds 3
            taskkill /T /F /IM gpg-agent.exe
            taskkill /T /F /IM scdaemon.exe
            taskkill /T /F /IM kleopatra.exe

            start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized
    }
    Remove-Event -SourceIdentifier deviceChange
} while (1-eq1) #Loop until next event
Unregister-Event -SourceIdentifier deviceChange

Das Grundkonstrukt selbst scheint von Andy.L13 zu stammen, die kläglichen versuche von Mass-Storage auf andere USB-Geräte umzustellen stammen von mir. In Zeile 24 kann man für WindowStyle statt Minimized auch Hidden nutzen um das Ganze im Hintergrund laufen zu lassen – ich bevorzuge ein optisches Feedback. Das Script kann passend in Autostart oder als geplanter Task verstaut werden.

Sicher keine saubere Lösung, aber „works for me“.


Edit: Stackoverflow (bzw warriorpostman) liefert

Das folgende Script reagiert nur noch auf den vom YubiKey emulierten Smartcard-Reader. Das Objekt $Event.SourceEventArgs.NewEvent.TargetInstance sieht wie folgt aus – die Informationen für’s Query sollten sich im Gerätemanager finden lassen:

__GENUS                     : 2
__CLASS                     : Win32_PnPEntity
__SUPERCLASS                : CIM_LogicalDevice
__DYNASTY                   : CIM_ManagedSystemElement
__RELPATH                   : Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002"
__PROPERTY_COUNT            : 24
__DERIVATION                : {CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER                    : TESTRECHNER
__NAMESPACE                 : root\CIMV2
__PATH                      : \\TESTRECHNER\root\CIMV2:Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002"
Availability                : 
Caption                     : Microsoft Usbccid-Smartcard-Leser (WUDF)
ClassGuid                   : {50dd5230-ba8a-11d1-bf5d-0000f805f530}
CompatibleID                : {USB\Class_0b&SubClass_00&Prot_00, USB\Class_0b&SubClass_00, USB\Class_0b}
ConfigManagerErrorCode      : 0
ConfigManagerUserConfig     : False
CreationClassName           : Win32_PnPEntity
Description                 : Microsoft Usbccid-Smartcard-Leser (WUDF)
DeviceID                    : USB\VID_1050&PID_0116&MI_02\6&***&0&0002
ErrorCleared                : 
ErrorDescription            : 
HardwareID                  : {USB\VID_1050&PID_0116&REV_***&MI_02, USB\VID_1050&PID_0116&MI_02}
InstallDate                 : 
LastErrorCode               : 
Manufacturer                : Microsoft
Name                        : Microsoft Usbccid-Smartcard-Leser (WUDF)
PNPDeviceID                 : USB\VID_1050&PID_0116&MI_02\6&***&0&0002
PowerManagementCapabilities : 
PowerManagementSupported    : 
Service                     : WUDFRd
Status                      : OK
StatusInfo                  : 
SystemCreationClassName     : Win32_ComputerSystem
SystemName                  : TESTRECHNER
PSComputerName              : TESTRECHNER

Ich werde mich am Service WUDFRd (aka Gerät mit Windows SmartCard-Treber) orientieren. Prinzipiell könne man aber auch auf die USB-ID triggern uns so Scripte bauen, welche bei einstecken eines USB-Sticks ein Backup durchführen oder bei verbinden einer unbekannten USB-Tastatur entsprechend reagieren (böse Ente). Das zugehörige Script:

$query =  "Select * FROM __InstanceCreationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_PnPEntity' AND TargetInstance.Service = 'WUDFRd'"

if( Get-EventSubscriber | Where-Object {$_.SourceIdentifier -eq "YubiHammer"}) {
    Unregister-Event YubiHammer
}

Register-WmiEvent -Query $query -SourceIdentifier YubiHammer -Action{
    $Global:RemoteProcMon=$event 

    start-sleep -seconds 3
    taskkill /T /F /IM gpg-agent.exe
    taskkill /T /F /IM scdaemon.exe
    taskkill /T /F /IM kleopatra.exe

    start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized
}

 

HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen

HTTPS, vorzugsweise mit gültigen Zertifikaten, sollte heute eigentlich Standard sein – erst recht wenn man mehr oder weniger kritische Infrastrukturen darüber verwalten möchte. Auch wenn ich eher ein Verfechter von SSH bei der Konfiguration von Switchen bin, so wird doch oft auch ein Webinterface gefordert. Bei HP/HPE/Aruba/Procurve ist dies in der Standardkonfiguration unverschlüsselt per HTTP erreichbar. HTTPS lässt sich aktivieren, die Einrichtung von etwas anderem als self-signed ist jedoch leider nicht so intuitiv wie ich das gerne hätte. Also gehen wir die Schritte mal durch. Im CLI natürlich.

Erst muss ein „Trust Anchor“ erstellt werden. Dies ist sozusagen die Zertifikatsdatenbank des Switches. Da mehrere vorhanden sein können wird er mit einem aussagekräftigem Namen (her „MEINNETZ„) versehen.

# crypto pki ta-profile MEINNETZ

Anschließend wird das Zertifikat der Zertifizierungsstelle (CA) importiert. Leider ist dies bei vielen  Geräten nur per TFTP und nicht über USB-Stick, Terminal  o.Ä. möglich. Auch dieses bekommt zur besseren Auffindbarkeit einen Namen (hier „MYCA„). Die angegebene IP entspricht der des TFTP-Servers, unter Windows lässt sich hierzu z.B. TFTPD32 nutzen. Der Switch selbst muss hierfür natürlich bereits eine passende Netzwerkkonfiguration besitzen und den PC erreichen können, ohne passende Konfiguration sucht er sich eine Adresse per DHCP auf dem Standard-VLAN.

# copy tftp ta-certificate MYCA 192.168.0.123 meineca.crt

Im Anschluss kann die Zertifikatsunterschriftanfrage (CSR) generiert werden. Wichtig für ein gültiges Zertifikat ist hierbei im Feld „common-name“ den späteren Hostname oder die IP-Adresse des Switches anzugeben, welche letztendlich für das Management verwendet werden soll..

# crypto pki create-csr certificate-name HTTPS ta-profile MEINNETZ usage web key-type rsa key-size 2048 subject common-name switch123.adlerweb.local org "BitBastelei" org-unit "IT" locality "Koblenz" state RLP country DE

Zu beachten ist, dass je nach Modellgeneration die Verfügbaren Cryptomethoden limitiert sein können. Das hier genutzte Modell unterstützt so leiglich RSA-Schlüssel mit bis zu 2048 Bit. Die verfügbaren Optionen lassen sich wie immer durch „?“ abrufen. Das Erstellen kann je nach verbautem Managementprozessor einige Zeit in Anspruch nehmen, im Anschluss erscheint die Anfrage als Text.

-----BEGIN CERTIFICATE REQUEST-----
MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkVOMQ0wCwYDVQQIDARub25lMQ0wCwYD
VQQHDARub25lMRIwEAYDVQQKDAlXaWtpcGVkaWExDTALBgNVBAsMBG5vbmUxGDAW
BgNVBAMMDyoud2lraXBlZGlhLm9yZzEcMBoGCSqGSIb3DQEJARYNbm9uZUBub25l
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP/U8RlcCD6E8AL
PT8LLUR9ygyygPCaSmIEC8zXGJung3ykElXFRz/Jc/bu0hxCxi2YDz5IjxBBOpB/
kieG83HsSmZZtR+drZIQ6vOsr/ucvpnB9z4XzKuabNGZ5ZiTSQ9L7Mx8FzvUTq5y
/ArIuM+FBeuno/IV8zvwAe/VRa8i0QjFXT9vBBp35aeatdnJ2ds50yKCsHHcjvtr
9/8zPVqqmhl2XFS3Qdqlsprzbgksom67OobJGjaV+fNHNQ0o/rzP//Pl3i7vvaEG
7Ff8tQhEwR9nJUR1T6Z7ln7S6cOr23YozgWVkEJ/dSr6LAopb+cZ88FzW5NszU6i
57HhA7ECAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4IBAQBn8OCVOIx+n0AS6WbEmYDR
SspR9xOCoOwYfamB+2Bpmt82R01zJ/kaqzUtZUjaGvQvAaz5lUwoMdaO0X7I5Xfl
sllMFDaYoGD4Rru4s8gz2qG/QHWA8uPXzJVAj6X0olbIdLTEqTKsnBj4Zr1AJCNy
/YcG4ouLJr140o26MhwBpoCRpPjAgdYMH60BYfnc4/DILxMVqR9xqK1s98d6Ob/+
3wHFK+S7BRWrJQXcM8veAexXuk9lHQ+FgGfD0eSYGz0kyP26Qa2pLTwumjt+nBPl
rfJxaLHwTQ/1988G0H35ED0f9Md5fzoKi5evU1wG5WRxdEUPyt3QUXxdQ69i0C+7
-----END CERTIFICATE REQUEST-----

Diese Anfrage kopiert man aus dem Terminal und reicht sie als .csr-Datei an die gewünschte Zertifizierungsstelle weiter bzw. signiert diesen selbst mit seiner lokalen CA. Als Ergebnis erhält man ein Zertifikat, üblicherweise im PEM-Format (meist .pem oder .crt), welches im Switch importiert werden muss. Erhält man stattdessen eine DER oder P7B-Datei kann diese an einem PC z.B. mit openssl konvertiert werden. Nach Eingabe des Importbefehls erwartet der Switch den Inhalt der PEM-Datei als Texteingabe. Unter Windows mit PuTTy kann mit einem Rechtsklick eingefügt werden.

# crypto pki install-signed-certificate
Paste the certificate here and enter:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Mit Erkennen der „END CERTIFICATE„-Zeile kehrt der Switch automatisch zur Konfigurationsoberfläche zurück.  Das Zertifikat sollte nun in der Liste der installierten Zertifikate zu sehen sein.

# show crypto pki local-certificate
Name Usage Expiration Parent / Profile
-------------------- ------------- -------------- --------------------
HTTPS Web 2345/06/07 MEINNETZ

Zuletzt wird HTTPS ein- und HTTP ausgeschaltet. Das zuvor installierte und somit einzige Zertifikat sollte automatisch verwendet werden.

# web-management ssl
# no web-management plaintext

Somit ist der Switch nicht mehr unverschlüsselt verwaltbar und die zuständigen „Administratoren“ teilen ihr Passwort nicht mehr zwangsläufig allen Lauschern im Netz servierfertig mit. Mit etwas Glück spart das Ganze am Ende mehr Arbeit als das turnusmäßige Auffrischen der Zertifikate verursacht. Wenn nicht schont der nicht mehr vorhandene HTTP-Login  immerhin meine Nerven.

Kurztest VP9 vs. X.265

Rendering fertig und nächstes Projekt kopiert noch, also mal ein schneller Blick wie sich VP9 inzwischen schlägt.

Quellmaterial sind 85 Sekunden Video, davon 8 Sekunden Standbild und 12 Sekunden 50:50. Das Rendering erfolgt über MLT mit x265 1.9 bzw. libvpx 1.5.0 auf einem Intel Xeon W3680 Hexacore. Beide werden mit einem CRF von 23 angesteuert (jaja, ist übertrieben hoch).

VP9 ist beim Encoding klar im Nachteil, da standardmäßig nur ein einziger Kern genutzt werden kann.

VP9 benötigt für das Rendering 18:40 Minuten, die Zieldatei belegt 141MB. Die Bitrate liegt bei durchschnittlich 13491kb/s.

X265 liegt mit 09:40 Minuten knapp darunter. Die Zieldatei ist mit 37MB jedoch deutlich kleiner. Die Bitrate liegt im Schnitt bei 3475kb/s.

Die Bildqualität können andere beurteilen, ich sehe mit dem Auge nichts.

 

Windows Server 2012R2: Dienststörung durch Shellhardwareerkennung (ShellHWDetection)

Wieder ein roter Kasten im Server Manager: Ein kritischer Fehler bei den Diensten mehrerer Server: Die „Shellhardwareerkennung“ aka „ShellHWDetection“ wäre nicht gestartet.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/09/shellhw01-300×214.png

Dienstkunde

Erste Frage: Was macht der Dienst denn? Nunja, er kümmert sich um „lebenswichtige“ Dinge wie Autostart von CD, Erkennung von SD-Karten oder das Management von Dockingstationen eines Laptops. Wegen seiner Kritikalität wird der Dienst unter Windows auch nur dann gestartet, wenn ein Nutzer aktiv am Rechner oder per RDP angemeldet ist. Der Fehler im Servermanager wird also immer dann ausgelöst, wenn kein Nutzer interaktiv am Rechner arbeitet.

Stummschaltung

Kurzfassung: Ruhe bitte. Der gestoppte Dienst ist ein Normalzustand und sollte folglich auch nicht als Fehler angekreidet werden. Um die Meldung zu unterdrücken öffnen wir im Servermanager das Dashboard und suchen die Gruppe/Box „Alle Server„. Durch einen Klick auf „Dienste“ öffnet sich die Detailansicht in einem neuen Fenster. Dort kann man im Dropdown-Menü „Dienste“ den Haken der Shellhardwareerkennung entfernen. Die Meldungen sollten nun verschwinden und fortan bei keinem Entscheider mehr Stirnrunzeln verursachen können.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/09/shellhw02-300×214.png

Hat man selbst weitere Servergruppen definiert muss man die Schritte für jede entsprechend wiederholen.

Cisco ASA via TFTP starten

17Cisco-Geräte starten üblicherweise von einer Firmwaredatei, welche auf einem internen Flash-Laufwerk gespeichert ist. Ist der Flash beschädigt oder möchte man nur temporär eine andere Version testen kann es nützlich sein einen anderen Weg einzuschlagen: Über den eingebauten Bootmanager, auch ROMMON genannt, lässt sich eine Firmwaredatei von einem TFTP-Server starten.

Als Voraussetzung sollte im Netz ein TFTP-Server vorbereitet und eine gültige ASA-Firmware dort hinterlegt sein. Unter Windows kann hierzu z.B. TFTPD32 verwendet werden. Auch muss bereits eine serielle Verbindung per COM (9600-8N1) oder USB-Kabel und einem Terminalclient wie PuTTy hergestellt werden.

Um den Bootloader zu starten wird während des Hochfahrens auf die Ausgabe der seriellen Schnittstelle geachtet. Hier erscheint nach kurzer Zeit ein entsprechender Hinweistext mit 10-Sekunden-Countdown. Durch drücken der ESC-Taste lässt sich der Start unterbrechen und in den Bootloader wechseln.

Cisco Systems ROMMON Version xxxxxx
Use BREAK or ESC to interrupt boot.Use SPACE to begin boot immediately.
Boot in 10 seconds.
                                                
Boot interrupted.

Management0/0
Link is DOWN
MAC Address: xxxxxx


Use ? for help.

Als nächstes muss die lokale IP (hier .10), die IP des TFTP-Servers (hier .11) und ein Gateway festgelegt werden. Befinden sich TFTP-Server und Router im selben Netz ist als Gateway der TFTP-Server und nicht der lokale Router einzutragen. Es folgen der Dateiname der Imagedatei und – wenn die Verbindung nicht über den Management-Port hergestellt werden soll – die Passende Netzwerkschnittstelle.

rommon #0> ADDRESS=192.168.0.10
rommon #1> SERVER=192.168.0.11
rommon #2> GATEWAY=192.168.0.11
rommon #3> IMAGE=asa962-smp-k8.bin
rommon #4> PORT=GigabitEthernet0/1
GigabitEthernet0/1
Link is UP
MAC Address: xxxxxx

rommon #5>

Um sicherzugehen, dass alle Einstellungen korrekt sind lassen sich mit set nochmal alle Parameter prüfen.

rommon #5> set
ROMMON Variable Settings:
  ADDRESS=192.168.0.10
  SERVER=192.168.0.11
  GATEWAY=192.168.0.11
  PORT=GigabitEthernet0/1
  VLAN=untagged
  IMAGE=asa962-smp-k8.bin
  CONFIG=
  LINKTIMEOUT=20
  PKTTIMEOUT=4
  RETRY=20

Um den das Laden und Starten der Datei einzuleiten gibt man schlussendlich tftp ein.

rommon #6> tftp
ROMMON Variable Settings:
  ADDRESS=192.168.0.10
  SERVER=192.168.0.11
  GATEWAY=192.168.0.11
  PORT=GigabitEthernet0/1
  VLAN=untagged
  IMAGE=asa962-smp-k8.bin
  CONFIG=
  LINKTIMEOUT=20
  PKTTIMEOUT=4
  RETRY=20

tftp asa962-smp-k8.bin@192.168.0.11 via 192.168.0.11
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[...]
Received 89837568 bytes

Launching TFTP Image...

Execute image at 0x14000
Cisco Security Appliance admin loader xxxxxx
Platform ASAxxxx

Loading...
IO memory blocks requested from bigphys 64bit: xxxxxx

INIT: version 2.88 bootingStarting udev
Configuring network interfaces... done.
Populating dev cache
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
[...]