Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

1

09.03.2017, 23:43

FTP(E)S Verbindung zur NAS dauerhaft unter Dolphin mounten

Ein spezielles Problem, worauf ich bisher keine Antwort noch einen Workaround gefunden habe. Folgendes Szenario: Bei mir in der Wohnung steht eine kleine NAS. Mit meinem heimischen PC und Win10 habe ich im Explorer diese als Netzlaufwerk eingebunden.
Auf dem Notebook mit Ubuntu 16.04 möchte ich dasselbe unter Dolphin erreichen, nur entsprechend als FTP-Server, damit ich von überall Zugriff habe (Uni, Arbeit, Unterwegs, Urlaub,...). Das Einbinden eines FTP-Zugangs ist kein Problem, hier mein aber:

Es ist ein FTPES-Zugang, sprich explizites TLS im passivem Modus mit einem komplett anderem Port als dem Standard-Port. Und egal, wie ich das auch anstelle, ich schaffe es nicht, diese Verbindung aufzubauen.
Klar gäbe es FileZilla und co, aber das ist keine Lösung, da auf der NAS u.a. auch Netzwerkkalender und andere Daten liegen, die ich von überall abrufen will, bzw. automatisch abgerufen werden.
Ein Beispiel: Thunderbird unter Windows greift auf die Kalender via Netzlaufwerk zu, das dauerhaft eingebunden ist. Klappt wunderbar.
Thunderbird auf dem Notebook kann es nicht, weil 1. kein dauerhafter FTPES-Zugang gemountet werden kann und 2. Thunderbird selbst anscheinend auch nicht in der Lage ist, einen iCal-Kalender via FTPES abzurufen.

Gibt's da einen Trick, oder ist das schlicht und einfach nicht möglich? Wäre die Verbindung eigentlich auch dauerhaft gemountet, sodass Programme auf die Daten der NAS zugreifen können, als ob sie direkt vor Ort lägen?
Mit meinem Smartphone und TotalCommander geht es zumindest, solange ich den Commander nicht beende. Da wird es auf nem Lappi doch auch einen Weg geben, oder?
Da wird die Verbindung (und auch in anderen Apps) via ftpes://meineDDNS.blablabla.de:999/NAS/Unterordner/DateiX aufgerufen mit den hinterlegten Zugangsdaten. Wobei meineDDNS entsprechend ein DDNS-Service ist und der Port 999 exemplarisch für meinen speziellen Port steht.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »HeeroYuy« (16.03.2017, 21:39)


Beiträge: 366

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: unbekannt

Desktop: unbekannt

Andere Betriebssysteme: Linux 3.16.0-4-686-pae GNU

  • Nachricht senden

2

10.03.2017, 12:50

Vielleicht hilft Dir dieser Link weiter. Erst in Ruhe lesen und verstehen und dann erst beginnen.

https://wiki.ubuntuusers.de/curlftpfs/
Kann man das Ende von Unity noch stoppen?

Was ich dazu sage: *klick*

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

3

10.03.2017, 12:59

Geil. Das scheint genau das zu sein, was ich brauche. Werd mich da nachher mal ransetzen und schauen, wie weit und gut das funzt. Danke dir erstmal.

Beiträge: 366

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: unbekannt

Desktop: unbekannt

Andere Betriebssysteme: Linux 3.16.0-4-686-pae GNU

  • Nachricht senden

4

11.03.2017, 23:59

... schon weiter gekommen? Soll etwas trickreich sein, was die optionen angeht-
Kann man das Ende von Unity noch stoppen?

Was ich dazu sage: *klick*

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

5

12.03.2017, 11:17

Ich bin nocht nicht dazu gekommen, da mein Notebook gerade in allen Einzelteilen rumliegt. Die RJ45-Buchse ist hinüber und ich habe keine Lust, alles zusammenzubauen um es dann bei Eintreffen der neuen Karte alles wieder auseinanderzunehmen und dann noch ein Mal zuzuschrauben.
Aber das Tutorial sieht an sich nicht so schwer aus. Sobald mein Gerät wieder geht (wahrscheinlich nächste Woche) werd ich mich ransetzen, sofern meine Prüfungen es zulassen.

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

6

14.03.2017, 17:50

So. Notebook geht wieder. Ich hab mich rangesetzt und eigentlich ist es ganz einfach. Ich habe dennoch ein paar Schwierigkeiten. Wenn ich nach runterladen der Zertifikate von example.org das Zertifikat von meinem FTP-Server haben will, kommt ein Error 140770: SSL routines_SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794: unable to load certificate.

Hier weiß ich schon mal nicht, was ich machen soll. Weiterhin kommt auch Error 0906D06C:PME_routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE

Versuche ich mich dennoch mal via ftps zu verbinden, erhalte ich "gmitls_handshake() failed: An unexpected TLS packet was received

Vielleicht hänt es mit meinem Passwort zusammen. Es soll ja nach dem Schema "USER:PASSWORT@server..." verbunden werden. sagen wir mal, ich habe Sonderzeichen wie $ und : im Passwort, sprich "USER:aaa$bbb:ccc@server...", dann sollte ich diese laut der Anleitung umschreiben. Ich bin aber auch gerade zu blöd, eine Tabelle mit entsprechenden Umschreibungen zu finden.
Ein bisschen Hilfe wäre jetzt tatsächlich gar nicht mal schlecht :D

7

14.03.2017, 23:30

--
Terminal-Ausgaben zur besseren Lesbarkeit bitte in Code-Blöcke setzen. Das funktioniert nur im Quelltext-Modus des Editors!
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

8

15.03.2017, 00:04

Sorry, ja natürlich. Ich bin schon mal einen Schritt weiter und habe die .netrc-Datei erstellt mit den Zugangsdaten. Das gibt schon mal einen Fehler weniger.
Hier die Übersicht

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
heeroyuy@LiMo1:~$ sudo chmod a+r /etc/fuse.conf 
heeroyuy@LiMo1:~$ curlftpfs -o ssl_control ftp://MEINFTPSERVER.com:5546/ ~/ARCHIV
Error connecting to ftp: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
heeroyuy@LiMo1:~$ echo | openssl s_client -connect example.org:443 | openssl x509 -out ~/serverzertifikat.pem
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, OU = Technology, CN = www.example.org
verify return:1
DONE
heeroyuy@LiMo1:~$ echo | openssl s_client -connect MEINFTPSERVER.com:5546 | openssl x509 -out ~/serverzertifikat.pem
139992656664216:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
unable to load certificate
139887466718872:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE
heeroyuy@LiMo1:~$ echo | openssl s_client -connect MEINFTPSERVER.com:443 | openssl x509 -out ~/serverzertifikat.pem
connect: Connection refused
connect:errno=111
unable to load certificate
140688109356696:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE


Wieso kann ich mir von meinem FTP-Server kein Zertifikat ziehen? Filezilla hats sofort bekommen. Irgendwo bin stehe ich gerade auf dem Schlauch.

9

15.03.2017, 16:09

Wieso kann ich mir von meinem FTP-Server kein Zertifikat ziehen?
Naiv gefragt: Hat er überhaupt eins?

Anderer Vorschlag wäre sshfs als unkompliziertere Alternative.

Nachtrag: curl beschwert sich daß es den Aussteller der Zertifikats nicht kennt. -> Selbst-signiert?
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

10

15.03.2017, 18:22

Filezilla wollte sich auch eins ziehen und bekam eins. Der FTP-Server ist Teil einer QNAP NAS. SSHFS hab ich bereits versucht, klappt aber leider nicht und die NAS lässt da nur den Admin ran.
Hier die Details des Zertifikats aus FileZilla

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »HeeroYuy« (15.03.2017, 18:29)


11

15.03.2017, 20:07

Filezilla wollte sich auch eins ziehen und bekam eins.
Woher?

SSHFS hab ich bereits versucht, klappt aber leider nicht
"klappt leider nicht" ist eine der vielen Fehlermeldungen, die wenig Ansatzpunkte zu einer Lösung bieten.

die NAS lässt da nur den Admin ran.
Ich kenne das System nicht, aber so ein Admin kann normalerweise User anlegen. Aber er hätte auch selbst Zugriff auf den Speicher. Macht natürlich nur Sinn, wenn mit guten Pubkeys abgesichert ist.

Zur aktuellen Frage:
Zu Clonezilla gibt es zwei Möglichkeiten:
A) Er kannte das Aussteller-Zertifikat. Wäre die Frage, woher. Da diese normalerweise am Client zentral abgelegt sind, würde es auch curl finden.
B) Es ist ihm egal, wer der Aussteller ist und er würde jedes Server-Zertifikat akzeptieren. curl würde mit der Option '-k' das gleiche tun. Eine Frage des eigenen Sicherheitsempfindens.

Der Frage vorgreifend, wie man einem Client das Aussteller-Zertifikat bekanntmacht -> https://www.qnap.com/en/tutorial/con_sho…showone&cid=218 Abschnitt 5.
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

12

16.03.2017, 21:38

Die Antwort ist so simpel:

Quellcode

1
curlftpfs -o ssl,no_verify_peer,no_verify_hostname ftp://FTP-Server.com:PORT/ ~/ARCHIV


Das wars. Kein Zertifikat notwendig, keine Kontrolle, nix und läuft.

Allerdings bekomm ich das nicht per automount integriert. Da will fuse mit dem Eintrag in der etc/fstab nicht so richtig warm werden. Naja soll erstmal reichen bis ich einen Workaround gefunden habe.

13

17.03.2017, 02:36

Kein Zertifikat notwendig, keine Kontrolle
Eine Frage des eigenen Sicherheitsempfindens.

Immer wieder faszinierend zu sehen, wie verlockend der Weg des geringsten Widerstands ist...
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

14

18.03.2017, 23:46

Entweder den einfachen Weg, oder einen, der fast unmöglich zu passieren ist...
Ne ernsthaft. Ich weiß, welcher FTP-Server am anderen Ende der Leitung auf mich wartet. Da brauch ich mich nicht mit einer unnötigen Hostname-Abfrage plagen, nur weil curl meint, dass der DDNS-Name nicht zur NAS passt. Da brauch ich jetzt nicht an irgendwelchen Schrauben rumdrehen und mach es nachher schlimmer.

Interessant ist allerdings die Beobachtung, dass das Mounten via LAN/WLAN keine Probleme bereitet, aber Dolphin es nicht gebacken bekommt, wenn man das ganze über einen UMTS-Stick mit LTE-Verbindung machen möchte.

15

19.03.2017, 01:03

Das Problem ist die menschliche Lernfähigkeit und Eigenart, einmal Gelerntes nicht mehr zu hinterfragen. Wenn der einfache Weg einmal funktioniert hat, wird er wieder angewandt, selbst wenn es nicht mehr so sicher ist ob der richtige Server dran ist. Man denkt nicht mehr darüber nach, weil das positive Erfolgserlebnis im Gedächtnis bleibt. Man "weiß" ja schließlich schon, wie's geht.

Übrigens geht's bei SSL/TLS nicht (nur) um die Identifikation der Gegenstelle, sondern eigentlich um die Verschlüsselung. Wer das Zertifikat und den Key dazu hat, bestimmt über den Schlüsselaustausch und somit letztlich über die Sicherheit der Verbindung. (sagt dir Heartbleed etwas?) Wenn dein Client jedes Zertfifikat anerkennt, lässt er sich auch auf jede Verschlüsselung ein. So gesehen könntest du fast schon darauf verzichten. Wenn "sie" dich belauschen wollen, machst du es ihnen ohnehin nicht schwer. Wenn du für "sie" uninteressant bist, machst du es dir nur selbst schwerer.

Der "fast unmöglich zu passierende Weg" besteht im Kopieren einer Datei von einem System auf ein anderes. Die Hürde ist das Auffinden und Ablegen in den richtigen Verzeichnissen...

Zum Dolphin-Problem müsstest du schon genaueres sagen.
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

Beiträge: 366

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: unbekannt

Desktop: unbekannt

Andere Betriebssysteme: Linux 3.16.0-4-686-pae GNU

  • Nachricht senden

16

19.03.2017, 02:57

Zitat

no_verify_peer,no_verify_hostname


:)

Bin schon drin da! :)


Der Beitrag ist zu kurz. Der Beitrag muss mindestens 10 Zeichen lang sein und 5 Wörter enthalten.
Kann man das Ende von Unity noch stoppen?

Was ich dazu sage: *klick*

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

17

19.03.2017, 13:36

Zitat

Der "fast unmöglich zu passierende Weg" besteht im Kopieren einer Datei von einem System auf ein anderes. Die Hürde ist das Auffinden und Ablegen in den richtigen Verzeichnissen...

Ich schau mir gerade OpenSSL an und versuche mich daran, ein eigenes Zertifikat zu erstellen, bin aber gerade etwas verwirrt. Allerdings hab ich damit noch nie gearbeitet und kann mich aufgrund von Prüfungen die nächsten Wochen kaum da reinhängen.
Und bevor die Frage kommt, warum ich nicht einfach das NAS-Zertifikat kopiere. Das habe ich, aber curl regt sich über meine DDNS auf, die nicht im SSL-Zertifikat der NAS auftaucht. Genau deswegen bricht der Verbindungsaufbau immer ab und lediglich das Ignorieren des Hostnames bringt was.

Was Dolphin angeht: Ich verwende im Terminal denselben Befehl zum Mounten. Über LAN und WLAN wird der FTP-Inhalt entsprechend in den Ordner gemountet. Über einen UMTS-Stick (mit LTE-Verbindung) funktioniert der Befehl ohne Fehler, allerdings versucht Dolphin eine Ewigkeit, den Ordner zu Mounten bzw. den Inhalt vom FTP-Server darzustellen. Das ganze geht soweit, dass Dolphin dann irgendwann nicht mehr reagiert und abschmiert.
An der Geschwindigkeit kann es kaum liegen, die lag zu dem Zeitpunkt nahe an der Übertragungsrate meiner WLAN-Verbindung.

Da das ganze aber ohne Fehler quittiert wird, sollte es eigentlich gehen.

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »HeeroYuy« (19.03.2017, 13:51)


18

19.03.2017, 15:30

Das mit dem hostname sehe ich ein. Ich würde ja auch eher selbst ein Zertfikat bauen als das vorgefertigte nehmen. Wenn schon Paranoia, dann richtig. :)
Aber gerade wegen der Komplexität habe ich ja früher schon ssh vorgeschlagen.

Zum Problem von Dolphin müsste man genauer hinsehen, was da alles gemacht wird. Könnte mir denken, daß der den kompletten Verzeichnisbaum cachen möchte und daher alle Zweige durchgeht. Außerdem ist fuse im Spiel, das afaik auch gerne im Hintergrund caching betreibt. Verzeichniswechsel und Dateizugriffe sollen ja für den User flüssig ablaufen undschließlich soll der Baum im lokalen Verzeichnis gemountet, also permanent verfügbar sein.

LTE hin oder her, die Datenraten sind Brutto-Angaben und die aktuelle Kanalbreite bestimmt der Anbieter. Im LAN hast du kaum verlorene Pakete, bei Mobilfunk kann unterwegs viel passieren. Es ist TCP, also können verlorene Pakete wieder und wieder nachgefordert werden. Nicht zuletzt sind Geräte beteiligt, die du gar nicht kennst und die auch bremsen können (Firewalls, Switches, usw., usf. ...) Das alles resultiert in Latenz.
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu

  • »HeeroYuy« ist der Autor dieses Themas

Beiträge: 22

Registrierungsdatum: 08.03.2017

Derivat: Kubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Windows 10 Pro 64bit

  • Nachricht senden

19

19.03.2017, 16:28

Zitat

Zum Problem von Dolphin müsste man genauer hinsehen, was da alles gemacht wird. Könnte mir denken, daß der den kompletten Verzeichnisbaum cachen möchte und daher alle Zweige durchgeht. Außerdem ist fuse im Spiel, das afaik auch gerne im Hintergrund caching betreibt. Verzeichniswechsel und Dateizugriffe sollen ja für den User flüssig ablaufen undschließlich soll der Baum im lokalen Verzeichnis gemountet, also permanent verfügbar sein.


Es spielt aber keine Rolle, ob ich den kompletten Server einbinde oder nur einen Ordner aus dem Root mit einer Datei (wenige KB groß, sprich kein Verzeichnisbaum). Die Latenz geht in beiden Fällen gen unendlich. Das Einbinden via (W)LAN geht darüber hinaus auch von fremden Netzwerken aus (selbst das stets überlastete Uni-Netzwerk schafft das). Das Problem ist (warum auch immer) LTE-seitig.

Kann ich auslesen, was Dolphin beim Einbinden macht?

EDIT: Okay... Es muss an meinem Setup zuhause liegen. Ich habe gerade das Spiel mit LTE und einem FTP-Server im Netz probiert. Geht tadelös und Dolphin bindet alles sofort ein. Jetzt stellt sich die Frage, warum es dann bei meiner NAS nicht geht, obwohl alle anderen Programme, die via TLS darauf zugreifen keine Probleme haben.
Der Router stellt der NAS die höchste Priorität zu, Port Forwarding ist korrekt eingerichtet und funktioniert (sonst hätte ich mit anderen Programmen ja keinen Zugriff), es gibt keinen IP-Bann oder sonstige Restriktionen. Lediglich eine Sperre seitens der NAS, wenn in kurzer Zeit zu oft missglückte Login-Versuche stattfinden. Aber da steht auch nichts drin.

Auf der anderen Seite stellt sich die Frage, warum es mit (W)LAN geht, aber mit WWAN nicht? Das ist so absurd, dass ich nicht weiß, wo da der Fehler sein könnte 8|

EDIT 2: Der Stick nutzt IPv4 aber kein IPv6, daran wirds schon mal nicht liegen.

EDIT 3: Liegt es vielleicht am passiven Portbereich? Hier sind auch andere Ports eingetragen. Nur warum packt das die (W)LAN-Verbindung, die WWAN aber nicht?

Das hier spuckt Verbose aus, bei einer Verbindung mit no_verify. Sowohl für (W)LAN als auch WWAN. Nichts ungewöhnliches.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
~$ curlftpfs -v -o ssl,no_verify_peer,no_verify_hostname ftp://XXX.com:5546/ ~/ARCHIV/ 
*   Trying XX.XX.XXX.XXX...
* Connected to XXX.com (XX.XX.XXX.XXX) port 5546 (#0)
< 220 NASFTPD Turbo station 1.3.5a Server (ProFTPD) [::ffff:XXX.XXX.X.X]
> AUTH SSL
< 234 AUTH SSL successful
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 697 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: TS Series NAS (does not match 'XXX.com')
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=TW,ST=Taiwan,L=Taipei,O=QNAP Systems\, Inc.,OU=NAS,CN=TS Series NAS,EMAIL=q_support@qnap.com
*        start date: Fri, 08 Jul 2011 10:09:45 GMT
*        expire date: Mon, 05 Jul 2021 10:09:45 GMT
*        issuer: C=TW,ST=Taiwan,L=Taipei,O=QNAP Systems\, Inc.,OU=NAS,CN=TS Series NAS,EMAIL=q_support@qnap.com
*        compression: NULL
* ALPN, server did not agree to a protocol
> USER HeeroYuy
< 331 Password required for HeeroYuy
> PASS XXX
< 230 User HeeroYuy logged in
> PBSZ 0
< 200 PBSZ 0 successful
> PROT P
< 200 Protection set to Private
> PWD
< 257 "/" is the current directory
* Entry path is '/'
* ftp_perform ends with SECONDARY: 0
* Remembering we are in dir ""
* Connection #0 to host XXX.com left intact


EDIT 4: Hab eben mal 'nen Ping-Test gemacht. Mit dem LTE-Stick und einem FTP-Server im Internet ca. 50 ms. Mit dem LTE-Stick und der DDNS zur NAS 100 % Packet Loss, trotz Verbindungs-Aufbau von einem Vodafone-Stick zu einem Netzwerk mit Vodafone-Kabel Anschluss. der Witz: Selbst wenn ich die DDNS weglasse und meine momentane IP direkt anpinge, 100 % Packet Loss.
Jetzt die Pointe: Filezilla schafft es dennoch, sich per Stick einzuloggen und Daten zu beziehen. Ich bin raus. Keine Ahnung, woran das liegt, aber ich schieb die Schuld auf curl und fuse
.

Dieser Beitrag wurde bereits 14 mal editiert, zuletzt von »HeeroYuy« (19.03.2017, 21:10)


20

19.03.2017, 20:53

Das eine hat mit dem anderen nichts zu tun. Dein Modem/Router oder was auch immer vorne am Netz hängt, blockt halt ICMP-Anfragen. Warum soll deshalb kein FTP gehen und wieso schafft es filezilla "trotzdem". Das ist ja nichts besonderes.

Und wenn ein "richtiger" FTP-Server im Netz eine bessere Performance bietet als dein NAS daheim, zeigt es nur daß ein Heimnetz in dieser Richtung weniger performant ist. Da liegt der Schwerpunkt beim Down-stream, während die Up-speed eher bescheiden ist. Um die geht es aber bei deinem Vorhaben.

Nebenbei sind fuse und ähnliche Konstrukte nunmal so wie sie sind. Ein veraltetes Protokoll wie FTP wird deshalb nicht besser. Schon gar nicht, wenn man es durch eine Verschlüsselung zwängt. Darum zum dritten Mal der Hinweis, daß es heute besseres in jeder Hinsicht gibt (um nicht schon wieder die drei Buchstaben zu verwenden...)
Europäische Bürgerinitiative "Verbot von Herbiziden auf Glyphosat-Basis" -> https://sign.banglyphosate.eu