FTP Mysterium V7R1

[wolfgang.w]

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]

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]

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!

[EFueloep]

 
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]

@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!

[Fuerchau]

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.

[Anton Gombkötö]

Gute Erklärung: http://slacksite.com/other/ftp.html#passive

Hier steht es viel kürzer, aber dafür in Deutsch: File Transfer Protocol

Noch kürzer: Das macht unglaublich viel Sinn, neben "PORT" die Adresse des Servers zu sehen. Denn es ist der SERVER, der hier dem Client mitteilt, zu welcher Adresse und zu welchem Port er sich verbinden soll. (wie schon auf der ersten Seite dieses threads erklärt.)
Und das ist aller Wahrscheinlichkeit nach eben derselbe Server.
(Wahrscheinlich hat man darum die IP-Adresse beim Extended passive auch wieder rausgeworfen. )

[BenderD]

[Zerberus77]

Hallo Wolfgang,

jetzt weiß ich wieder, was ich heute machen wollte. *gg*

Werd mir das morgen mal auf unserem System ansehen. PTFGRP sind halbwegs aktuell?

MFG Zerberus

[Zerberus77]

Hallo Wolfgang,

mit extern, meinst du da ausserhalb eures Netzwerkes?
Wenn ja, hast du auch eine Maschine im selben Netzwerk?
Wenn ja, bitte mit der mal testen.

MFG Zerberus

[wolfgang.w]

Hallo Zerberus

So, bin erst jetzt dazu gekommen den internen Test noch durchzuführen. Ich habe also meine 25 .xml Dateien auf das alte System kopiert und das Script umgeschrieben damit die Daten von dort abgeholt werden.

KEINE FEHLERMELDUNGEN - KEINE PROBLEME!

Leider kann ich dieses Ergebnis jetzt nicht deuten. Was bedeutet das jetzt? Liegt es wirklich nur am Durchsatz von intern/extern? An der Firewall kann es nicht liegen, da beide Systeme nebeneinanderstehen und in die gleichen Kanäle greifen (Switch, Hausverkablung, Firewall). Das neue System hat die gleiche IP-Adresse und den gleichen Namen wie zuvor das alte System hatte. Das alte System wurde entsprechend umnummeriert und umbenannt. Sogar der physische Standort wurde ausgetauscht, wie man das eben so macht mit einem neuen System.

Fazit:
- intern läuft problemlos
- extern erzeugt Fehler (mittlerweile 2x WinServer und 1x AS/400 getestet )

[Zerberus77]

Hallo Wolfgang,

also, folgendes wäre der nächste Schritt:

*) TRCCNN auf der iSeries
*) TRCCNN oder WireShark Trace auf dem FTP Server. Ich würde die externe iSeries bevorzugen *gg*

Intern würd ich beim TRCCNN die IP Adresse des FTP Servers in das Feld 'Ferne Adresse' eintragen und bei der extern iSeries würd ich nicht filtern (ausser du kannst die interne iSeries wirklich identifizieren). IP Adresse der internen iSeries wird nicht gehen, da ich davon ausgehe, dass die Adresse genated wird.

Die neuen Träce würd ich mir dann wieder ansehen.

P.S.: Nach meiner Erfahrung, tippe ich auf die FireWall. Mich würde es nicht wundern, wenn die Fehlermeldung gar nicht vom FTP Server, sondern von der FireWall kommt. Klingt komisch, kann aber durchaus sein. Interessant wäre, mal die Logs der FireWall zu durchforsten, ob sich da irgendwelche Hinweise finden.

P.P.S.: Wenn im 'alten' System wirklich eine 100Mbit Karte verwendet wurde und jetzt mit 1Gbit gearbeitet wird, wäre es einen Versuch wert, entweder in der LIND und auf dem Switch die Geschwindigkeit auf 100/*FULL fest einzutragen. Alternativ könntest du eine andere Karte/ ein anderes Port an der Netzwerkkarte verwenden und via Routingeintrag dieses andere Port für den FTP (für Testzwecke) verwenden.

Habt ihr eine eigene Netzwerkkarte, oder Verwendet ihr den HEA?

MFG Zerberus