Smartlink-Modem / Failed to open /dev/ttySL0
Hallo, ich wollte nun auch mein Modem unter SuSE 9.1 mit dem anhand der SuSE-Sourcen selbstkompilierten 2.6.5.7-95-Kernel zum Laufen bringen. Bin in Yast2 auf Modem gegangen, und YaST2 hat selbständig das Paket smartlink-softmodem installiert. Habe die Modem- und Providerkonfiguration abgeschlossen, doch kinternet meldet im Log "pppd[0]: Failed to open /dev/ttySL0: No such device or address. Nach Rumsuchen ist mir aufgefallen, daß Yast2 das Paket km_smartlink-softmodem ("A package for building the SmartLink Modules in k_deflt and k_athlon") nicht installiert hat. Nach Installation besteht allerdings der Fehler weiter. Unter /usr/share/doc/packages/smartlink-softmodem/README steht, wie man das tar.gz-Paket installiert. Obwohl YaST2 dies doch bereits anhand des rpm getan hat, meldet 'modprobe slamr' "FATAL: Module slamr not found". Wie gehe ich nun am besten vor, ohne das System durcheinander zu bringen? Handelt es sich um einen Installationsfehler von YaST2, den man manuell ausbessern kann, oder soll ich besser das tar.gz herunterladen und drüberinstallieren? Oder kann ich irgendwie Schritt für Schritt vergleichen, was YaST2 getan hat, und was eigentlich passiert sein müßte? Vielen Dank, Christian P.S. Anhand anderer Mailinglistenbeiträge habe ich ttySL0 umbenannt und einen symbolischen Link von ttySL0 auf /dev/modem gesetzt. Worauf kinternet im Log meldet "pppd[0] died: pppd options error (exit code 2).
Am Samstag, 21. August 2004 05:22 schrieb Christian (aka Neodaxus):
Hallo,
ich wollte nun auch mein Modem unter SuSE 9.1 mit dem anhand der SuSE-Sourcen selbstkompilierten 2.6.5.7-95-Kernel zum Laufen bringen.
Bin in Yast2 auf Modem gegangen, und YaST2 hat selbständig das Paket smartlink-softmodem installiert. Habe die Modem- und Providerkonfiguration abgeschlossen, doch kinternet meldet im Log "pppd[0]: Failed to open /dev/ttySL0: No such device or address.
Nach Rumsuchen ist mir aufgefallen, daß Yast2 das Paket km_smartlink-softmodem ("A package for building the SmartLink Modules in k_deflt and k_athlon") nicht installiert hat. Nach Installation besteht allerdings der Fehler weiter.
Denkfehler: km_smartlink-softmodem installiert nur die Sourcen für das Module nach /usr/src/kernel-modules/km_smartlink_softmodem. Du must dann noch das Module bauen (Ungetestet: make modules;make install).
Christian (aka Neodaxus) wrote:
ich wollte nun auch mein Modem unter SuSE 9.1 mit dem anhand der SuSE-Sourcen selbstkompilierten 2.6.5.7-95-Kernel zum Laufen bringen.
Wenn Du Deinem eigenen Kernel die gleiche UTS_RELEASE verpasst hast wie dem SuSE-Default-Kernel (sprich: "uname -r" liefert in beiden Faellen das Gleiche), dann war das schon der erste grobe Fehler...
Bin in Yast2 auf Modem gegangen, und YaST2 hat selbständig das Paket smartlink-softmodem installiert. Habe die Modem- und Providerkonfiguration abgeschlossen, doch kinternet meldet im Log "pppd[0]: Failed to open /dev/ttySL0: No such device or address.
Nach Rumsuchen ist mir aufgefallen, daß Yast2 das Paket km_smartlink-softmodem ("A package for building the SmartLink Modules in k_deflt and k_athlon") nicht installiert hat. Nach Installation besteht allerdings der Fehler weiter.
Die km_*.rpm Pakete beinhalten stets Quellcode fuer Kernelmodule. Das Installieren des Paketes reicht natuerlich nicht, sondern Du musst das entsprechende Modul auch noch erstellen und installieren. Unter /usr/src/kernel-modules solltest Du eigentlich ein entsprechendes Unterverzeichnis finden, in dem Du fuer Deinen eigenen Kernel das slamr Kernel-Modul erstellen und dann installieren musst.
Unter /usr/share/doc/packages/smartlink-softmodem/README steht, wie man das tar.gz-Paket installiert. Obwohl YaST2 dies doch bereits anhand des rpm getan hat, meldet 'modprobe slamr' "FATAL: Module slamr not found".
Das installieren von Quellcode liefert Dir kein Kernel-Modul, es ist also nicht verwunderlich, dass es nicht vorhanden ist.
Wie gehe ich nun am besten vor, ohne das System durcheinander zu bringen? Handelt es sich um einen Installationsfehler von YaST2, den man manuell ausbessern kann, oder soll ich besser das tar.gz herunterladen und drüberinstallieren?
Siehe oben.
[...] P.S. Anhand anderer Mailinglistenbeiträge habe ich ttySL0 umbenannt und einen symbolischen Link von ttySL0 auf /dev/modem gesetzt. Worauf kinternet im Log meldet "pppd[0] died: pppd options error (exit code 2).
Das ist eine unsinnige Aktion. Das Device ttySL0 sollte bestehen und der Link /dev/modem sollte auf das Device ttySL0 verweisen, so denn der Link existiert. CU, Th.
Thomas Hertweck wrote (ähnlich wie Markus Kossmann):
Die km_*.rpm Pakete beinhalten stets Quellcode fuer Kernelmodule. Das Installieren des Paketes reicht natuerlich nicht, sondern Du musst das entsprechende Modul auch noch erstellen und installieren. Unter /usr/src/kernel-modules solltest Du eigentlich ein entsprechendes Unterverzeichnis finden, in dem Du fuer Deinen eigenen Kernel das slamr Kernel-Modul erstellen und dann installieren musst.
Danke! 'make' gibt jedoch folgendes aus: cp /amrlibs.o /amrlibs.o cp: cannot stat '/amrlibs.o': No such file or directory make: *** [/amrlibs.o] Error 1 'make KERNEL_DIR=/lib/modules/2.6.5-7.95-neodef1/build' oder 'make KERNEL_DIR=/usr/src/linux-2.6.5-7.95/' führt zum gleichen Fehler. Hat jemand einen Tipp? TIA, Christian P.S. 'uname -r' liefert "2.6.5-7.95-neodef1".
Am Montag, 23. August 2004 04:14 schrieb Christian (aka Neodaxus):
Thomas Hertweck wrote (ähnlich wie Markus Kossmann):
Die km_*.rpm Pakete beinhalten stets Quellcode fuer Kernelmodule. Das Installieren des Paketes reicht natuerlich nicht, sondern Du musst das entsprechende Modul auch noch erstellen und installieren. Unter /usr/src/kernel-modules solltest Du eigentlich ein entsprechendes Unterverzeichnis finden, in dem Du fuer Deinen eigenen Kernel das slamr Kernel-Modul erstellen und dann installieren musst.
Danke! 'make' gibt jedoch folgendes aus: cp /amrlibs.o /amrlibs.o cp: cannot stat '/amrlibs.o': No such file or directory make: *** [/amrlibs.o] Error 1
'make KERNEL_DIR=/lib/modules/2.6.5-7.95-neodef1/build' oder 'make KERNEL_DIR=/usr/src/linux-2.6.5-7.95/' führt zum gleichen Fehler.
Hat jemand einen Tipp?
Versuch es mal mit export KERNEL_SOURCE=/usr/src/linux-2.6.5-7.95 make install Das hat hier (mit anderen Kernelsourcen )funktioniert. Wenn du aber zuvor durch ein "make clean" das Binärobjekt amrlibs.o aus km_smartlink_softmodem gelöscht hast, must du die Sourcen nochmal neu installieren.
Bitte keine Privatkopie von Listenemails verschicken - so erhaelt man immer alles doppelt. Siehe auch die Etikette dieser Liste! Christian (aka Neodaxus) wrote:
Thomas Hertweck wrote (ähnlich wie Markus Kossmann):
Die km_*.rpm Pakete beinhalten stets Quellcode fuer Kernelmodule. Das Installieren des Paketes reicht natuerlich nicht, sondern Du musst das entsprechende Modul auch noch erstellen und installieren. Unter /usr/src/kernel-modules solltest Du eigentlich ein entsprechendes Unterverzeichnis finden, in dem Du fuer Deinen eigenen Kernel das slamr Kernel-Modul erstellen und dann installieren musst.
Danke! 'make' gibt jedoch folgendes aus: cp /amrlibs.o /amrlibs.o cp: cannot stat '/amrlibs.o': No such file or directory
Hier laeuft etwas schief, da fehlt eine Pfadangabe! Die Datei amrlibs.o liegt sicherlich nicht im Oberverzeichnis /, da gehoert ein Pfad davor. Das ist dann die Ursache fuer die Fehlermeldung.
make: *** [/amrlibs.o] Error 1
'make KERNEL_DIR=/lib/modules/2.6.5-7.95-neodef1/build' oder 'make KERNEL_DIR=/usr/src/linux-2.6.5-7.95/' führt zum gleichen Fehler.
Hat jemand einen Tipp?
$> cd /usr/src/kernel-modules/km_smartlink_softmodem $> KERNEL_SOURCE=/usr/src/linux make modules [...] $> KERNEL_SOURCE=/usr/src/linux make install [...] That's it. Gruesse, Th.
Thomas Hertweck wrote:
Unter /usr/src/kernel-modules solltest Du eigentlich ein entsprechendes Unterverzeichnis finden, in dem Du fuer Deinen eigenen Kernel das slamr Kernel-Modul erstellen und dann installieren musst. Danke! 'make' gibt jedoch folgendes aus: cp /amrlibs.o /amrlibs.o cp: cannot stat '/amrlibs.o': No such file or directory Hier laeuft etwas schief, da fehlt eine Pfadangabe! Die Datei amrlibs.o liegt sicherlich nicht im Oberverzeichnis /, da gehoert ein Pfad davor. Das ist dann die Ursache fuer die Fehlermeldung.
Meinst Du, daß das Makefile einen Fehler enthält? Ich zitiere den m.E. relevanten Teil: $(obj)/amrlibs.o: cp $(src)/amrlibs.o $(obj)/amrlibs.o amrlibs.o befindet sich in /usr/src/kernel-modules/km_smartlink_softmodem/ Sind .o-Module nicht sowieso obsolet, da ich einen 2.6er-Kernel habe?
'make KERNEL_DIR=/lib/modules/2.6.5-7.95-neodef1/build' oder 'make KERNEL_DIR=/usr/src/linux-2.6.5-7.95/' führt zum gleichen Fehler. Hat jemand einen Tipp? $> cd /usr/src/kernel-modules/km_smartlink_softmodem $> KERNEL_SOURCE=/usr/src/linux make modules [...] $> KERNEL_SOURCE=/usr/src/linux make install [...]
Ist der Schritt mit dem 'make modules' mit 'make' identisch? In /usr/share/doc/packages/smartlink-softmodem/README steht nichts von 'make modules', allerdings soll man im Makefile die KERNEL_DIR-Zeile anpassen, wenngleich eine solche Zeile im Makefile garnicht vorkommt (deswegen habe ich ja vor Deinem Vorschlag KERNEL_DIR dem Kommando 'make' mitgegeben). Während jedenfalls 'KERNEL_SOURCE=/usr/src/linux make' weiterhin den amrlibs-Fehler produziert, klappt 'make modules' und 'make install'. Dabei wird auch slamr.ko erwähnt, 'modprobe slamr' ergibt jedoch "FATAL: Module slamr.ko not found." locate 'slamr.ko' findet das Modul in /lib/modules/2.6.4-52-default/extra/ und in /lib/modules/2.6.5-7.95-default/extra/ uname-r ergibt 2.6.5-7.95-neodef1 Warum steckt slamr.ko im falschen Verzeichnis? Nach dem Kopieren von slamr.ko nach /lib/modules/2.6.5-7.95-neodef1/extra/ ergibt 'modprobe slamr' aber die gleiche Fehlermeldung (s.o.). Markus Kossmann wrote:
Versuch es mal mit export KERNEL_SOURCE=/usr/src/linux-2.6.5-7.95 make install
Müßte ich vor dem 'make install' nicht 'make modules' ausführen? Dein EXPORT-Vorschlag funktioniert jedenfalls für 'make modules' und 'make install' genauso wie Thomas Hertwegs Vorschlag, nicht jedoch für 'make'. Das Ergebnis ist aber leider auch, daß slamr nicht gefunden werden kann. Warum sind eigentlich km_smartlink-softmodem und smartlink-softmodem zwei verschiedene Pakete? Würden Kernelmodule nicht ausreichen, um das Modem zu verwenden? Nochmals vielen Dank, Christian P.S. Unter smlink.com gibt es übrigens schon das 2.9.9-tar.gz, aber ich denke daß SuSE einen Grund dafür haben wird, eine ältere Version auszuliefern, und bei Euch klappt es ja auch...
Christian (aka Neodaxus) wrote:
Thomas Hertweck wrote:
[...] Hier laeuft etwas schief, da fehlt eine Pfadangabe! Die Datei amrlibs.o liegt sicherlich nicht im Oberverzeichnis /, da gehoert ein Pfad davor. Das ist dann die Ursache fuer die Fehlermeldung.
Meinst Du, daß das Makefile einen Fehler enthält? Ich zitiere den m.E. relevanten Teil:
$(obj)/amrlibs.o: cp $(src)/amrlibs.o $(obj)/amrlibs.o
amrlibs.o befindet sich in /usr/src/kernel-modules/km_smartlink_softmodem/
Bei Deinem Aufruf ist wohl sowohl $(src) als auch $(obj) im Makefile undefiniert, was dann bei Dir den Aufruf "cp /amrlibs.o /amrlibs.o" erzeugt, der schlicht unsinnig ist und natuerlich nicht funktioniert. Ich weiss nicht genau, was hier gemacht werden soll, anscheinend soll das erstellte Object-File aus einem Quellverzeichnis in ein Verzeichnis mit Object-Files kopiert werden. Das Makefile sieht IMHO jedenfalls sehr zweifelhaft aus...
Sind .o-Module nicht sowieso obsolet, da ich einen 2.6er-Kernel habe?
Nein, zunaechst werden auch hier normale Object-Files erstellt, die dann spaeter zu Kernel Object-Files gelinkt werden. Das ergibt hier z.B. Ausgaben wie CC /usr/local/src/slmodem-2.9.9/drivers/slamr.mod.o LD [M] /usr/local/src/slmodem-2.9.9/drivers/slamr.ko Wie Du siehst, sind das zwei Schritte und nicht einer...
$> cd /usr/src/kernel-modules/km_smartlink_softmodem $> KERNEL_SOURCE=/usr/src/linux make modules [...] $> KERNEL_SOURCE=/usr/src/linux make install [...]
Ist der Schritt mit dem 'make modules' mit 'make' identisch?
Nein, in diesem Falle nicht. Rufst Du ein "make" auf, so wird das erste Target im Makefile ausgefuehrt. Das lautet in diesem Falle $(obj)/armlibs.o: cp $(src)/armlibs.o $(obj)/armlibs.o und produziert (siehe oben) die Fehlermeldung. Ein "make modules" hingegen ist ein anderes Target im Makefile.
In /usr/share/doc/packages/smartlink-softmodem/README steht nichts von 'make modules', allerdings soll man im Makefile die KERNEL_DIR-Zeile anpassen, wenngleich eine solche Zeile im Makefile garnicht vorkommt (deswegen habe ich ja vor Deinem Vorschlag KERNEL_DIR dem Kommando 'make' mitgegeben).
Wie gesagt, das Makefile scheint von etwas anderem abzuhaengen, da z.B. auch die Variablen $(CONFIG_X86) aus der Kernel-Konfig abgefragt werden. Allerdings wird die Kernel-Konfig niergends "gesourct", sodass ich mich Frage, woher das Makefile dann die Variablen nehmen will. Gleiches trifft auf $(src) und $(obj) zu, die undefiniert sind. Also, wie schon gesagt, das Makefile mutet mir recht seltsam an. Wenn Du kein KERNEL_SOURCE setzt an der Kommandozeile, wird es uebrigens auch schief gehen, weil der Aufruf $(MAKE) -C $(KERNEL_SOURCE) $@ ... lautet und das wird dann zu "make -C modules", was natuerlich schief geht, weil dann ein *Verzeichnis* modules gesucht wird... Nee, also das Makefile ist IMHO daneben!
Während jedenfalls 'KERNEL_SOURCE=/usr/src/linux make' weiterhin den amrlibs-Fehler produziert, klappt 'make modules' und 'make install'. Dabei wird auch slamr.ko erwähnt,
Du solltest genau schauen, was mit den Modulen passiert und wohin sie kopiert werden. Falls sie tatsaechlich kopiert werden, aber an die falsche Stelle, dann stimmt evtl. Deine Kernel-Source Angabe nicht oder der Kernel-Source ist nicht korrekt konfiguriert.
'modprobe slamr' ergibt jedoch "FATAL: Module slamr.ko not found."
Dann ist es wohl nicht richtig installiert worden, was zu Deiner Aussage oben passt. Ein "depmod -a" lief ja vermutlich nach der Installation, oder?!
[...] Warum steckt slamr.ko im falschen Verzeichnis? Nach dem Kopieren von slamr.ko nach /lib/modules/2.6.5-7.95-neodef1/extra/ ergibt 'modprobe slamr' aber die gleiche Fehlermeldung (s.o.).
Module kopieren hat i.d.R. nie einen Sinn, weil eine Versionsueberpruefung beim Laden gemacht wird. Das wird scheitern, selbst wenn ein Modul mit dem richtigen Namen gefunden wird.
[...] Warum sind eigentlich km_smartlink-softmodem und smartlink-softmodem zwei verschiedene Pakete? Würden Kernelmodule nicht ausreichen, um das Modem zu verwenden?
Das km_* RPM Paket enthaelt den Quellcode fuer das Kernel-Modul. Das andere Paket legt einige Device-Nodes an und beinhaltet noch ein Init-Skript sowie die Doku zu softmodem.
P.S. Unter smlink.com gibt es übrigens schon das 2.9.9-tar.gz, aber ich denke daß SuSE einen Grund dafür haben wird, eine ältere Version auszuliefern, und bei Euch klappt es ja auch...
Ich habe die Version von SuSE nicht wirklich probiert. Ich habe mir das 2.9.9 Paket gezogen und installiert. Dort ist ein ordentliches Makefile dabei, was einwandfrei funktioniert - was sich SuSE hier manchmal denkt, ist mir schleierhaft. Es ist nicht das einzige km_*.rpm Paket mit einem sehr seltsam anmutenden Makefile. Ich konnte mich gestern nach der Installation auf einem Samsung Laptop mit AC97 Modem auch ueber Freenet ins Internet einwaehlen und einige Homepages aufrufen - schnell ist allerdings anders :-) Aber zur Not geht es. CU, Th.
Thomas Hertweck wrote:
(...) - was sich SuSE hier manchmal denkt, ist mir schleierhaft. Es ist nicht das einzige km_*.rpm Paket mit einem sehr seltsam anmutenden Makefile.
Da bin ich ja froh daß ich als relativer Neuling anscheinend nicht allein schuld bin :-). Mit den 2.9.9-Sourcen von smlink.com funktioniert es nun auch bei mir. Ich danke Dir für die ausführliche Antwort und werde Deine Mail mit Deinem Einverständnis mit einen paar einleitenden Zeilen als Bug-Report an SuSE schicken. Weißt Du ob das was bringt? Ich habe manchmal den Eindruck, daß die viel zu sehr mit anderen (sicherlich auch nicht ganz unwichtigen) Dingen beschäftigt sind... Z.B. habe ich vor ca. 2 Monaten eine Anregung eingesendet bezüglich Partitions-/Root-/Swap-Verschlüsselung (anscheinend hat die SuSE-Implementation ja einige Schwachstellen, s.u.). Es hieß damals daß ich noch ggf. Post vom Entwicklerteam bekomme. Kam aber nichts, was bedeuten kann daß es entweder keinen besonders interessiert (fände ich sehr bedenklich) oder daß die Anregung noch "verarbeitet" wird (einen Patch oder eine Warnung wegen der Schwachstelle gab es anscheinend noch nicht). Any comments? CU, Christian P.S. Aus Jari Ruusu's http://loop-aes.sourceforge.net/loop-AES.README 8. Security levels ~~~~~~~~~~~~~~~~~~ Loop encryption key can be set up in different ways. Just in case it isn't obvious how these different ways rank security wise, here is a list of security levels from 1 (highest security) to 4 (lowest security). 1) gpg encrypted 'multi-key' key file and/or gpg public+private keys are stored on separate removable USB dongle that is not available to attacker. If USB dongle and its key files are available to attacker, security level is equivalent to level 2. (Example 2) 2) gpg encrypted 'multi-key' key file and gpg public+private keys are stored on disk that is available to attacker. This assumes that included gpg patch is applied to gpg and symmetric cipher encrypted key file or private keyring password was created/changed with patched version. (Example 3) 3) Loop is used in single-key mode. Random password seed and iteration count are used to slow down optimized dictionary attacks. This level is vulnerable to watermark attacks. Watermarked files contain special bit patterns that can be detected without decryption. (Example 4) 4) Loop is used in single-key mode. Neither password seed nor gpg encrypted key file are used. This level is vulnerable to optimized dictionary attacks as well as watermark attacks. (mainline cryptoloop and dm-crypt are examples of this type of backdoored crypto)
Eines vorweg: es reicht, eine Email *einmal* an suse-linux zu schicken, *dreimal* ein- und dieselbe Email zu schicken halte ich doch fuer reichlich uebertrieben... Christian (aka Neodaxus) wrote:
[...] Da bin ich ja froh daß ich als relativer Neuling anscheinend nicht allein schuld bin :-). Mit den 2.9.9-Sourcen von smlink.com funktioniert es nun auch bei mir. Ich danke Dir für die ausführliche Antwort und werde Deine Mail mit Deinem Einverständnis mit einen paar einleitenden Zeilen als Bug-Report an SuSE schicken.
Hmm, Du solltest das lieber komplett selbst schreiben und meine etwas genervten Kommentare rausnehmen, sonst wird das vermutlich direkt ignoriert. Das Problem solltest Du ja konkret beschreiben koennen, und eine Loesung dazu ja auch. Es gibt da uebrigens das Feedback-Formular auf SuSE's Homepage, das man fuer solche Zwecke nutzen sollte.
Weißt Du ob das was bringt? Ich habe manchmal den Eindruck, daß die viel zu sehr mit anderen (sicherlich auch nicht ganz unwichtigen) Dingen beschäftigt sind...
Das Feedback-Formular ist ein grosses schwarzes Loch, bei dem Du nie weisst, was mit Deinen Eingaben passiert: es koennte sein, dass sich nach 5 min bereits ein SuSE-Mitarbeiter mit Deiner Eingabe befasst und versucht, evtl. beschriebene Probleme zu loesen, es koennte aber genau so sein, dass die Formular-Daten direkt nach /dev/null geschickt werden. Du bekommst es ja nicht mit. Da man in der Regel *nie* Feedback zurueck bekommt als Anwender, der dort etwas eingegeben hat, ist leider der Eindruck mit /dev/null doch vorherrschend...
Z.B. habe ich vor ca. 2 Monaten eine Anregung eingesendet bezüglich Partitions-/Root-/Swap-Verschlüsselung (anscheinend hat die SuSE-Implementation ja einige Schwachstellen, s.u.). Es hieß damals daß ich noch ggf. Post vom Entwicklerteam bekomme. Kam aber nichts, was bedeuten kann daß es entweder keinen besonders interessiert (fände ich sehr bedenklich) oder daß die Anregung noch "verarbeitet" wird (einen Patch oder eine Warnung wegen der Schwachstelle gab es anscheinend noch nicht). Any comments?
Siehe oben. CU, Th.
Thomas Hertweck wrote:
(...) - was sich SuSE hier manchmal denkt, ist mir schleierhaft. Es ist nicht das einzige km_*.rpm Paket mit einem sehr seltsam anmutenden Makefile.
Da bin ich ja froh daß ich als relativer Neuling anscheinend nicht allein schuld bin :-). Mit den 2.9.9-Sourcen von smlink.com funktioniert es nun auch bei mir. Ich danke Dir für die ausführliche Antwort und werde Deine Mail mit Deinem Einverständnis mit einen paar einleitenden Zeilen als Bug-Report an SuSE schicken. Weißt Du ob das was bringt? Ich habe manchmal den Eindruck, daß die viel zu sehr mit anderen (sicherlich auch nicht ganz unwichtigen) Dingen beschäftigt sind... Z.B. habe ich vor ca. 2 Monaten eine Anregung eingesendet bezüglich Partitions-/Root-/Swap-Verschlüsselung (anscheinend hat die SuSE-Implementation ja einige Schwachstellen, s.u.). Es hieß damals daß ich noch ggf. Post vom Entwicklerteam bekomme. Kam aber nichts, was bedeuten kann daß es entweder keinen besonders interessiert (fände ich sehr bedenklich) oder daß die Anregung noch "verarbeitet" wird (einen Patch oder eine Warnung wegen der Schwachstelle gab es anscheinend noch nicht). Any comments? CU, Christian P.S. Aus Jari Ruusu's http://loop-aes.sourceforge.net/loop-AES.README 8. Security levels ~~~~~~~~~~~~~~~~~~ Loop encryption key can be set up in different ways. Just in case it isn't obvious how these different ways rank security wise, here is a list of security levels from 1 (highest security) to 4 (lowest security). 1) gpg encrypted 'multi-key' key file and/or gpg public+private keys are stored on separate removable USB dongle that is not available to attacker. If USB dongle and its key files are available to attacker, security level is equivalent to level 2. (Example 2) 2) gpg encrypted 'multi-key' key file and gpg public+private keys are stored on disk that is available to attacker. This assumes that included gpg patch is applied to gpg and symmetric cipher encrypted key file or private keyring password was created/changed with patched version. (Example 3) 3) Loop is used in single-key mode. Random password seed and iteration count are used to slow down optimized dictionary attacks. This level is vulnerable to watermark attacks. Watermarked files contain special bit patterns that can be detected without decryption. (Example 4) 4) Loop is used in single-key mode. Neither password seed nor gpg encrypted key file are used. This level is vulnerable to optimized dictionary attacks as well as watermark attacks. (mainline cryptoloop and dm-crypt are examples of this type of backdoored crypto)
Thomas Hertweck wrote:
(...) - was sich SuSE hier manchmal denkt, ist mir schleierhaft. Es ist nicht das einzige km_*.rpm Paket mit einem sehr seltsam anmutenden Makefile.
Da bin ich ja froh daß ich als relativer Neuling anscheinend nicht allein schuld bin :-). Mit den 2.9.9-Sourcen von smlink.com funktioniert es nun auch bei mir. Ich danke Dir für die ausführliche Antwort und werde Deine Mail mit Deinem Einverständnis mit einen paar einleitenden Zeilen als Bug-Report an SuSE schicken. Weißt Du ob das was bringt? Ich habe manchmal den Eindruck, daß die viel zu sehr mit anderen (sicherlich auch nicht ganz unwichtigen) Dingen beschäftigt sind... Z.B. habe ich vor ca. 2 Monaten eine Anregung eingesendet bezüglich Partitions-/Root-/Swap-Verschlüsselung (anscheinend hat die SuSE-Implementation ja einige Schwachstellen, s.u.). Es hieß damals daß ich noch ggf. Post vom Entwicklerteam bekomme. Kam aber nichts, was bedeuten kann daß es entweder keinen besonders interessiert (fände ich sehr bedenklich) oder daß die Anregung noch "verarbeitet" wird (einen Patch oder eine Warnung wegen der Schwachstelle gab es anscheinend noch nicht). Any comments? CU, Christian P.S. Aus Jari Ruusu's http://loop-aes.sourceforge.net/loop-AES.README 8. Security levels ~~~~~~~~~~~~~~~~~~ Loop encryption key can be set up in different ways. Just in case it isn't obvious how these different ways rank security wise, here is a list of security levels from 1 (highest security) to 4 (lowest security). 1) gpg encrypted 'multi-key' key file and/or gpg public+private keys are stored on separate removable USB dongle that is not available to attacker. If USB dongle and its key files are available to attacker, security level is equivalent to level 2. (Example 2) 2) gpg encrypted 'multi-key' key file and gpg public+private keys are stored on disk that is available to attacker. This assumes that included gpg patch is applied to gpg and symmetric cipher encrypted key file or private keyring password was created/changed with patched version. (Example 3) 3) Loop is used in single-key mode. Random password seed and iteration count are used to slow down optimized dictionary attacks. This level is vulnerable to watermark attacks. Watermarked files contain special bit patterns that can be detected without decryption. (Example 4) 4) Loop is used in single-key mode. Neither password seed nor gpg encrypted key file are used. This level is vulnerable to optimized dictionary attacks as well as watermark attacks. (mainline cryptoloop and dm-crypt are examples of this type of backdoored crypto)
participants (3)
-
Christian (aka Neodaxus) -
Markus Kossmann -
Thomas Hertweck