[archimedes] Re: HTTPServer bzw. SSL
- From: Raik Fischer <raik_fischer@xxxxxxxx>
- To: archimedes@xxxxxxxxxxxxx
- Date: Wed, 25 Jun 2014 23:42:10 +0200
Das was gleich ist, daß beide "Abholer/Sender" (Netfetch, POP3S/SMTPS)
sich vergleichbar unterscheidlich auf der Pandora(=xM) und dem RPi
verhalten. Deshalb die Frage nach der Bibliothek.
Unwahrscheinlich. R-Comps Version ist, wie wir wissen, von 2000/2001,
Alexanders ist "etwas" neuer. Auch der Compiler könnte eine Rolle spielen.
Womit R-Comps-Version erstellt wurde, weiß ich nicht (mehr).
Wie geschrieben, ich stelle nur fest :-( Zum Programmieren bin ich zu doof.
Wenn der Fehler in der Bibliothek "verortet" ist und warum auch immer
die Hardware auch Einfluß hat... "Gute Nacht".
Zu früh dazu irgendwas zu sagen. Natürlich gibt RISC OS Operationen, wie z.B.
memcpy in C, die über Hardware abgearbeitet werden können. Aber Fehler traten
doch auf allen Maschinen auf oder? Weder BB xM, noch RPi oder Panda waren
sauber. Ob noch jemand den Iyonix bemüht hatte, weiß ich nicht, aber ich
könnte ihn nochmal anschmeissen und testen, ob meine Problemdateien auch auf
ihm zerhacktstückt werden. Außerdem bleibt die Frage warum Du mit Messenger
Pro 6 nie Probleme gehabt hast, obwohl SecureSockets gleich war (oder habe
ich das falsch in Erinnerung!?!).
Sauber war bei mir keine Hardware. Iyonix habe ich nicht.
Ich habe für alle Tests das gleiche Secure-Module aus Netfetch 3.66
genommen. Es sind mehrere vorhanden. Ich habe das genommen, was geladen
wird, wenn RISC OS 5 erkannt wird.
Evt. kann Alexander ja mal von Grundverständnis her sagen, ob der Fehler
überhaupt in der Verschlüsselung liegen kann (was ich nicht so recht glaube).
Bei mir fehlten bei den kaputten Dateien im Attachment (ok 1MB Text als
Nachricht hat bislang keiner von uns geschrieben ...) immer ganze Abschnitte.
Es war nie versetzt, sondern es fehlte ganz einfach was. Das erscheint mir
für eine Verschlüsselung (wie handhabt man dabei eigentlich verlorene Pakete,
wo man die Codierungssequenz wieder aufsetzen muß?) unlogisch. Wenn da was
faul wäre, würde ich eher erwarten, daß ab einer bestimmten Stelle alles
komplett anders aussehen würde. So sieht es eher so aus, als ob ein ganzer
Block einfach nicht weitergereicht wird (eine Art "magische Sequenz" die
irgendeinen Teil massakriert, ggf. als Folge einer RISC OS
Konfigurationseinstellung, die nicht offensichtlich ist. Ich meine ich hätte
im Diff aber damals nichts Derartiges bemerkt, war vielleicht aber auch zu
oberflächlich bei der Analyse). Wenn es was im OS wäre, müßten wir dies auch
bei normalen Netzwerktransfer unverschlüsselten Mails etc. bemerken. Dem ist
nicht so. Ich tippe eher auf Messenger. Erinnert sich jemand an den
Unterschied zwischen MPro 6 und MPro7? Hattest Du Deine Problemmails über
Messenger versandt oder waren nur Alexanders Tools im Spiel (Abgang/Zugang)?
Was der wirkliche Unterschied bei Mro 6 und 7 ist, kann ich nicht sagen.
Kleine Änderungen in der Oberfläche. Der "UniCode"-Versuch und Hermetic
"eingebaut" als Fetcher. Hermetic hat eine andere Version des
Hermes-Modules als Netfetch.
Mit etwas Tricksen kann aber auch MPro6 mit Hermetic und MPro7 mit Netfetch.
Ich habe von Andrew zwei wesentliche Aussagen bekommen...
1. MPro 7 unterstützt SSl/TLS nicht offiziell. Die Menues gibt es zwar
aber der securesocked ist offiziell nicht aktiv. Wenn man es von Hand
lädt gehts aber. Mit den bekannten Fehlern.
2. Wenn die erstellten Base64-Dateien unmittelbar vor dem Senden ok
sind, kann es nicht an MPro liegen.
Die Dateien sind i.o. Hab ich hundertfach kontrolliert. Trotzdem kommt
"Müll" an (nachgeprüft mit WIN und Linux). Text der Mail ist i.o. Anhang
Schrott. Pandora und xM getestet.
Beim RPi und MPRo7 war es das erstem mal, daß das Gesendete i.o. in Win
und Linux angekommen ist (Anhänge konnte ich öffnen) und das RISC OS
empfangene war wieder Schrott.
MailProgramm war immer MPro7. Gesendet / Abgeholt habe ich mal so (Alex)
und mal so (Hermetic). Immer vergleichbare Ergebnisse.
Dem Empfangenen fehlen einige Bytes und im Editor angeschaut (Base64)
gibt es mitten im "Anhang-Block" sichtbare Unterschiede zum letzem Stand
vor dem Senden.
Bei den ersten Tests mit SMTPS trat der Fehler mit meiner 500kB
Testdatei nicht auf. Aber später mit einer 1MB Datei (beides Zip-Files).
Was mich vermuten lässt, daß die "Schwelle" bei SMTPS höher liegt. Das
ist aber auch der einzigste Unterschied.
Raik
Other related posts:
