Ik heb een stuk software voor een meteo station (Cumulus) dat 24/7 draait en bestanden upload naar een server. Dat ging - al heel lang - tot 6 april 6u40 goed maar sindsdien krijg ik de melding tijdens het overdrachtsproces :
(Authentication failed because the remote party has closed the transport stream.)
Gesproken met de hosting service en die verwijst duidelijk naar Ziggo ivm de afhandeling van het FTP protocol in combinatie met firewall. Het maken van de verbinding gaat prima maar het uploaden zelf gaat fout.
WinSCP geeft geen probleem.
Aan mijn kant is niets veranderd, de fail was spontaan na een herstart van de software na backup (dus een herinitialisatie) terwijl er er verder niets veranderd was (instellingen of zo).
Wie heeft een suggestie?
Jij bent de IT-hulplijn in je straat, de verlichting werkt thuis op commando en je groet de pakketbezorger met de slimme deurbel. Herkenbaar? Dan zijn de Community events echt iets voor jou! Doe mee en sluit je aan.
Goede avond @Hans_R,
Maar via andere netwerken kunt u dus wel een transfer succesvol afronden?
Zo ja, zou u dan het volgende willen testen, neem voor elke stap rustig de tijd en herstart voor de zekerheid zowel het modem als de PC na elke test poging.
Test 1:
Zou u de volgende opties onder Firewall instellingen van het modem willen uitschakelen "Block fragmented IP packets" & "Flood detection"
Test 2:
Zou u de firewall op het modem geheel willen uitschakelen.
Test 3:
Zou u binnen het modem de betreffende server/pc een vast ip willen geven en in DMZ modus willen plaatsen.
(UPNP & port forwarding eventueel uitschakelen)
MVG
Dag @Jonathan-458 ,
Test 1 en Test 2 heb ik al uitgevoerd en lossen het probleem niet op. Op dit moment staat de firewall ingesteld als in de afbeelding:
Test 3 begrijp ik niet helemaal. De ftp server ligt buiten mijn bereik en wordt door de domeinnaam aangesproken. Ik heb geen invloed op het IP-adres van de bestemming (ftp server op meteo-wagenborgen.nl) en het plaatsen in de DMZ van de externe server lijkt me niet relevant. De PC heb ik het adres gefixeerd en in de DMZ geplaatst. Ik hef dat graag ASAP weer op.
Port forwarding wordt gebruikt door Synology en moet aan staan anders kan ik niet meer bij mijn NAS en dat kan echt niet.
Voor de duidelijkheid: tussen mijn PC en de ftp-server gaat het goed met FTPS al verbreekt de verbinding soms onverklaarbaar. Op de PC gebruik ik WinSCP. Maar het probleem waar ik op doel - en ik ben daar blijkbaar niet duidelijk in geweest - ligt tussen een RPi (aan de binnenkant) en de ftp server (aan de buitenkant). De PC en de RPi gaan via hetzelfde modem en hetzelfde protocol en de RPi weigerde ineens te verzenden (die deed het dus al heel lang). Als ik het protocol wijzig op de RPi (naar FTP of SFTP) dan heb ik geen probleem. Het is alleen FTPS en het ging van het ene moment op het andere waarbij op mijn systeem noch op het systeem van de server (volgens de hoster) iets veranderde.
Vandaar mijn claim/vermoeden dat het aan het transport ligt, b.v. een routing die veranderd is op de transport poort van de passive verbinding.
Merk op, dat alles altijd - drie jaar al - heeft gefunctioneerd in de huidige configuratie (ik heb dus alleen net de DMZ aangepast). Merk ook op, dat de verbinding tussen de RPi en het modem verder perfect verloopt.
Mvg, HansR
Overigens wil ik, als je veel verder wilt met het afbreken van de netwerk protectie, dat toch ook niet meer verder publiek communiceren. Daar moeten we echt dan iets anders op verzinnen.
Mvg. HansR
Dag@Jonathan-458 ,
Ik hoor niets meer van je. Betekent dit dat we uit de opties zijn of dat je de RPi ziet als niet meetellend?
Mvg, HansR
Goede middag @Hans_R,
Excuses, notificatie gemist.
Met test 3 bedoel ik de client computer welke het probleem ervaart.
Okey, dus uiteindelijk werkt het op de PC wel maar zijn er soms random disconnects zonder een verklaarbare of duidelijke response van zowel de client als de server? (niet gewoon inactivity timer disconnect)
Als er iets met transport Ziggo sided of Server sided zou het in mijn beleving binnen uw netwerk geheel niet moeten werken.
Het probleem is dus dat de RPi geen verbinding meer opzet via FTPS, welk programma gebruikt u? Dit is niet opgetreden na een library/OS/Programma update?
U maakt geen gebruik van een firewall op de RPi?
MVG
RPi bedoelt u RaspberryPi mee?
Dag @Jonathan-458 ,
Inderdaad de Raspberry Pi (met Linux Raspbian, meest recente versie, Mono als .NET).
Het probleem is dus dat de RPi geen verbinding meer opzet via FTPS, welk programma gebruikt u? Dit is niet opgetreden na een library/OS/Programma update?
Overigens wordt er wel een verbinding opgezet maar met de datapoort gaat het ergens fout.
Het gaat om software voor een Meteo station: CumulusMX en eigen software. Beiden gebruiken FluentFTP als FTP library, een tool uit de NuGet toolbox van Visual Studio 2019.
(En dan wordt het lastig waarschijnlijk)
Mvg.HansR
Hi @Hans_R,
Dat wordt inderdaad even wat lastiger, custom setup.
Maar infeite is FluentFTP overall gelijk, de basis config zou niet veel moeten verschillen, denk ik.
Zou u deze kunnen delen. (svp server, certificaat & login details verwijderen.)
MVG
Hi @Jonathan-458 ,
Wat zou je precies gedeeld willen hebben? De FTP code voor connect en upload neem ik aan? Dat is geen probleem hoor, maar ik wil wel zo min mogelijk opsturen.
Ik denk dat je link (en van daaruit verder lezend) mij inderdaad brengen - waar ik al eerder was geweest - bij de oorzaak: It seems to be due to a lack of TLS session resumption support in FluenFTP.
En dan is de vraag, wat is dat precies en hoe ga ik daar mee om?
Moet ik per access een nieuwe verbinding maken en het bestand overbrengen?
Mvg. HansR
Goeiemorgen @Jonathan-458 ,
Ik heb nog even doorgelezen op dit punt en ik denk dat die session resumption inderdaad het probleem is. Als je alsnog mijn inet code wil zien laat het even weten. Ik heb in de tussentijd mijn hoster gevraagd om de instelling van mijn FTP server te wijzigen. Als ik daarvan wat terug hoor en heb getest kom ik hier terug.
mvg. HansR
Goede morgen @Hans_R,
Is goed, mocht dit het toch niet zijn dan graag het FTP config gedeelte delen zonder cert, login of server gegevens.
Het vergt helaas een aanpassing server-sided omdat Fluent FTP alleen FTPS ondersteund i.c.m. TLS in Explicit modus.
MVG
OK, Ik hou je op de hoogte.
Hi @Jonathan-458 ,
Ik zou je op de hoogte houden dus nog even een update.
Ik heb een poging ondernomen om een lijn te ontdekken in de mogelijkheden maar ben daarvan afgestapt: het is te complex. Ik heb de volgende oplossingen gekozen:
Voor mij zijn met bovenstaande maatregelen de problemen opgelost.
Als er een gebruiker is met een hosting-provider die met geen van de oplossingen om kan gaan, dan ben ik er wel klaar mee. En FTP(S) is wat mij betreft tot nader orde down the drain. Er lijkt geen standaardisatie van poort en handshake meer te zijn - mijn hoster heeft b.v. voor FTPS gewoon poort 21 ipv 990 - en verschillende servers lijken andere dialecten te praten. Gaat lekker zo.
Bedankt voor het meedenken in elk geval.
Met vriendelijke groet,
HansR
Hi @Hans_R,
Mooi dat u nu een alternative methode heeft gevonden. maar blijf het toch raar vinden dat van de een op de andere dag ineens niet meer werkte.
Explicit FTPS wordt standaard op port 21 geconfigureerd en daar zou FluentFTP dus mee moeten kunnen communiceren, echter staan bij FluentFTP issues meerdere melding dat dit niet geheel naar behoren werkt nog open. Dus misschien in de toekomst.
U zou op de GitHub pagina ook een issue kunnen openen en hopelijk wordt het dan uiteindelijk gefixt.
MVG
Vul de belangrijkste trefwoorden in en vind het topic die past bij je vraag. Onze community zit boordevol kennis.
Start je eigen topic en krijg hulp van anderen. Op de community helpen ervaren klanten je graag op weg.