FTP Mysterium V7R1

[Fuerchau]

Firewalls dürfen keine Meldungen erzeugen sondern blocken nur.
Käme eine Meldung wüsste man ja, dass die Adresse/der Port existiert um weitere Angriffe zu initiieren.
Das ist wie bei den Mails, die eine 1-Punkt-Bilddatei enthalten um beim Download des Bildes die Gültigkeit zu verifizieren.

Aber zum Thema:
Ich würde da eine Fehlermeldung an IBM abgeben, da es ja mit dem vorherigen Release reibungslos funktioniert.
Eine Firewall kann man da ausschließen.

[wolfgang.w]

Hallo Zerberus

Besten Dank für Deine Antwort.

Es wird der HEA verwendet (Typ #576F 'PCIe2 1GbE Adapter 4Port'). Interessanterweise steht in der WRKLIND Beschreibung der Ethernet Leitungsbeschreibung 100M/*FULL als aktuelle Übertragungsgeschwindigkeit. Wahrscheinlich ist das verwendete Kabel noch ein Kat5 (kann's nicht überprüfen, ich bin nicht vor Ort). In der ursprünglichen Konfig. steht bei Übertragungsgeschwindigkeit *AUTO drin.

Den TRACE werde ich dir senden sobald ich ihn gemacht habe. Könnte allerdings eins/zwei Tage dauern.

Die Firewall wird nicht von mir betreut. Ich werde das mal in die Wege leiten, dass das Log gespeichert wird.

[wolfgang.w]

@Fuerchau

Ich würde da eine Fehlermeldung an IBM abgeben

Wie und wo würdest du das machen?

[Fuerchau]

Da ich kein IBM-Kunde bin, kann ich das leider nicht sagen.

[Zerberus77]

Hallo Fuerchau,

FireWalls sind durchaus in der Lage Meldungen zu schicken. Vielleicht fungiert die ja auch als FTP Proxy.

@Wolfgang,

ist das System ein Standalone System oder wird es von einer HMC gemanaged?
Wenn HMC managed, dann LIND Parameter *AUTO/*AUTO und via HMC den HEA so konfigurieren wie am angestecketen Switch Port.
Wenn Standalone, dann LIND wie Switch Port konfigurieren.

MFG Zerberus

[EFueloep]

Einen SW Call kann über folgenden Link eröffnet werden (IBM ID required):

IBM Service Request - Service requests & PMRs

Bezüglich Firewalls:

Die FW könnte sehr wohl an diesem Problem schuld sein.
Speziell bei FTP macht die FW weit mehr als man glaubt. Eine FW liest den Inhalt der FTP Control Session mit. Der FTP Client teilt dem Server mit er will eine Passive FTP Data Connection (SENDPASV). Der FTP Server antwortet mit der Port Information auf welchem Port er für eine FTP Data Connection ready ist. Die FW öffnet dynamisch dieses Port für outgoing traffic und läßt die Connection from FTP-Client zu diesem Port des FTP-Servers zu.

In diesem Fall könnte es sein, dass die FW mit dem Port vom FTP-Server nicht "einverstanden" ist oder sonst irgendein Problem damit hat. Daher könnte die Meldung "500 bad passive command from server" durchaus von der FW kommen.
Ich würde dies nicht sofort ausschließen.

[wolfgang.w]

@EFueloep¨
Danke für SW Call Adresse!

Ich verstehe deine Erklärung soweit. Aber ich schliesse die Firewall eigentlich aus dem Grunde aus weil die FTP Transfers auf das alte System problemlos funktioniert haben und nur die Transfers auf das neue System (welches sich im gleichen Netz befindet) Probleme macht.

Es kann ja nicht sein, dass die FW beim einen System alles durchlässt und beim anderen nicht. Sofern irgendwas geblockt würde, dann müsste es sowieso beim alten System blocken, da das neue System mittlerweile die IP-Adresse des alten Systems hat. Das alte System hingegen hat zwangläufig eine andere bekommen. Trotzdem werde ich mir mal die Logs organisieren (ev. müssen diese ja zuerst aktiviert werden).

@Zerberus
Das System hat eine LAN-Konsole (Operations Console). Die LIND Parameter sind *AUTO/*AUTO. Den Switch Port muss ich noch prüfen lassen (wie gesagt, ich bin nicht vor Ort).

[Zerberus77]

Hallo Wolfgang,

ah, jetzt versteh ich, konfiguriert ist *AUTO/*AUTO, aber aktuell ist 100M/*FULL.
Hmm, ich würde die FireWall nicht ausschließen, wenn die Kommunikation jetzt schneller geht als vorher - die FireWall aber nicht nachkommt, die MAC Adresse hat sich geändert,...
Ich denke aber nicht, dass etwas geblockt wird, ich glaub eher es ist ein Problem mit der Geschwindigkeit.

Wie gesagt, interessant wäre jetzt mal der Trace beider Seiten. Vielleicht wäre es sogar möglich diese Traces von der 'alten' und der 'neuen' iSeries zu machen, da hät ich dann einen direkten Vergleich.
Bei dem Trace werden QSYSPRT Spoolfiles erstellt, die reichen. Die QPCSMPRT brauch ich nicht.

MFG Zerberus