View Full Version : FTP Mysterium V7R1
Zerberus77
29-09-13, 19:40
Hallo Tarasik,
ich glaube nicht, dass das PTF hier hilft, aber schaden tut's auch nicht.
@Wolfgang,
bei der IBM melden bringt sicher auch nix, da das Problem am FTP Server ist und der ja eine Windows Kiste ist.
Ich würde mal Testhalber einen FTP Server im Netz installieren und mit diesem so einen Filetransfer nachstellen. Du wirst sehen, alles funktioniert ohne Probleme.
MFG Zerberus
wolfgang.w
30-09-13, 07:44
@Tarasik
Ja, dieses PTF habe ich auch schon gesehen, ist jedoch für meinen Fall nicht relevant, da es sich beim APAR um einen ganz anderen Sachverhalt handelt.
... da das Problem am FTP Server ist und der ja eine Windows Kiste ist.Das ist meiner Meinung nach nicht ganz korrekt weil
- mit dem alten 520'er V5R3 System funktioniert es (testeshalber immer noch) einwandfrei
- vom neuen System aus bei einem anderen Kunden ebenfalls Bestellungen per FTP abgeholt werden und da das genau gleiche Problem auch auftritt (ist natürlich auch eine Windows Kiste).
Somit kann, zumindest aus meiner Sicht, behauptet werden, dass es nicht an den FTP-Servern liegen kann.
Hallo,
auf eine Aparbeschreibung würde ich mich nicht verlassen, dieses Ptf ersetzt einige andere Ptfs aus dem FTP Bereich.
Ich würde es trotzdem installieren.
Hallo,
vermutlich liegt es an Deinem Script, denn da ein Sprung von R530 nach R710 gemacht wurde, beachtete man nicht die Änderung mit R540.
Hier aus dem Memo von R540:
FTP reply code changed
For V5R4, the FTP server was changed to return a reply code of 226
instead of 250 when a successful data transfer has been completed. This
made the FTP server compliant with RFC 959, which states that if the
data transfer connection is closed after a successful data transfer, the
reply code should be 226. If you have FTP scripts that are expecting the
250 reply code, you should change the scripts to expect a 226 reply code
for a successful data transfer.
wolfgang.w
30-09-13, 14:13
Da ich auf der i5 im Script ja lediglich den Anwender "simuliere" beinhaltet so ein Script ja nur ein paar Zeilen.
Script:
login passwort
SENDEPSV 0
SENDEPRT 0
cd get
namefmt 1
lcd /idoc
mget *
close
Da wird ja vom Script her nichts erwartet oder so. Das macht ja alles der FTP-Client. Oder meintest du etwas anderes?
Abgesehen davon handelt das erwähnte Memo ja vom FTP Server auf der i5 und nicht vom FTP Client.
Betreffend den PTFs werde ich sicherlich noch die allerneuesten einspielen - wie bereits gesagt wurde, schaden kann's ja nicht!
Zerberus77
30-09-13, 19:14
Hallo Wolfgang,
da du noch die 'alte' Maschine hast, kannst du ja ganz schnell testen, ob es ein Problem am Client oder Server ist.
Erstelle dir auf der 'alten' Maschine einen Ordner und stell 10 - 20 'kleine' Files 5 - 10 kB groß rein.
Nun ändere dein Script, das es sich die Files von der 'alten' Maschine holt.
Tritt da das Phänomen auch auf?
MFG Zerberus
wolfgang.w
01-10-13, 08:26
Hallo Zerberus
Auf so eine Idee wäre ich gar nicht gekommen da ich davon ausging, dass von IBM auf IBM kein Problem sein dürfte!
Um möglichst die gleichen Bedingungen zu schaffen habe ich auf einer externen 800'er Maschine mit V5R2 (10 jähriges Entwicklersystem, welches mit FTP noch nie Probleme hatte) dieselben .xml Datein raufkopiert. Insgesamt 25 Stück. Das Script entsprechend abgeändert, so dass die Daten von diesem System geladen werden sollen. ES TRITT GENAU DER GLEICHE FEHLER AUF!
Er macht zwar weiter und schafft schlussendlich 24 Dateien zu laden, aber er benötigt extrem Zeit (dieses Phänomen habe ich schon vorher im normalen Job beobachtet). Für jede Datei gehen da locker 10Sek. drauf obwohl die so klein sind und es sich um eine 150Mbit Leitung handelt. Normalerweise müsste der ganze Job in 2 bis 3 Sekunden durch sein. Er hat über 4,5 Minuten benötigt.
Was mich bereits an frühren Logs verwundert hat ist, dass nach dem Auftreten des 500'er Fehlers die Portanweisungen auf das System selbst zeigen. Bei der ersten Datei steht im Log
227 Entering Passive Mode (xx,x,xxx,xx,144,214)
Bei der 2. Datei ebenfalls
227 Entering Passive Mode (xx,x,xxx,xx,144,214)
Dann kommt der Fehler
500 Bad passive command from server
Es kann keine aktive Datenverbindung zum Server hergestellt werden.
Ursachencode 1.
Verwendung von PASV ist für diese Server-Sitzung inaktiviert.
Ab jetzt wird für jede Datei einen Portbefehl abgesetzt welcher auf die Maschine selbst zeigt
PORT 192,168,1,9,151,167
Das macht für mich nun wirklich keinen Sinn.
Obwohl dies so ist, hat der wenigsten 24 Dateien geladen. Mit Sicherheit nur weil es sich um ein AS/400 handelt und nicht um einen Windowsserver!
500 Bad passive command from server
Es kann keine aktive Datenverbindung zum Server hergestellt werden.
Ursachencode 1.
Verwendung von PASV ist für diese Server-Sitzung inaktiviert.
Ab jetzt wird für jede Datei einen Portbefehl abgesetzt welcher auf die Maschine selbst zeigt
PORT 192,168,1,9,151,167
Das macht für mich nun wirklich keinen Sinn.
Obwohl dies so ist, hat der wenigsten 24 Dateien geladen. Mit Sicherheit nur weil es sich um ein AS/400 handelt und nicht um einen Windowsserver!Doch das macht sehr viel Sinn.
Er schreibt ja, dass ein "Bad passive command from server" empfangen worden ist und er deshalb auf active FTP umschaltet ("Verwendung von PASV ist für diese Server-Sitzung inaktiviert.").
Und die PORT Befehle sind active FTP data-connections und bei active FTP wird ein TCP Port beim Client eröffnet.
Dies ist ja der Unterschied zwischen Active FTP (FTP Client fungiert beim Data Transfer als Server) und Passive FTP (FTP Server ist immer Server).
Bei Deinem Windows FTP Server wird ebenfalls auf active FTP umgeschalten, nur wird dies wahrscheinlich von einer Firewall nicht erlaubt und daher funktioniert es dort nicht.
Wenn das Problem auch mit einem AS400 FTP Server nachgestellt werden kann würde ich ein Problem bei IBM melden. Denn dann liegt wohl doch ein Fehler im FTP Client vor.
wolfgang.w
01-10-13, 09:06
@EFueloep
Mit "es macht für mich keinen Sinn" habe ich nicht den Port Befehl an und für sich gemeint, sondern dass der Port Befehl auf die systemeigene IP-Adresse zeigt! Das macht ja wirklich keinen Sinn!
Wie oben beschrieben macht es bei ActiveFTP doch Sinn die eigene Adresse zu verwenden, da ja eben der Client nun die Daten vom Server selber abholen will.
Aber da solltest du nun wirklich einen IBM-Fehler melden.