D/L van SSL FTP's gaat steeds langzamer. Tot hij 'stopt'.

[DeMoN]

Een raar probleem,
En het zit mij dwars als exceem.
Elke keer als ik wat wil downloaden,
Lijkt het alsof iemand dit mij heeft verboden.

Welke FTP client of OS ik ook gebruik,
Nooit gaat het downloaden helemaal puik!

---

Tot zover de 5 december verplichtingen...

Ik download met regelmaat wat een een FTP server. Deze server gebruikt Passive FTP over SSL.
Nu heb ik met (denk ik) elke client in mijn netwerk, met welk OS dan ook en met welke FTP client software dan ook het probleem dat af en toe mijn verbindingssnelheid zwaar hard dropped.

Mijn max. d/l zit op de 230 kB/sec gecapped. (Demon DSL Express).

Als ik mijn download van die server start gaat het meestal ffies een minuutje goed en opeens zie ik em gaan van 230 kB/sec, 220 kB/sec, 210kB/sec........etc......10kB/sec.. (en ondertussen haalt ie eigenlijk al helemaal niks meer binnen ).

Wat kan ik over mijn netwerk zeggen?

  PC   PC  PC
   |    |  |
   SWITCH /    (Sweex 100mbit)
      |
      | -- hier zit een muur tussen (plafond, ik zit op zolder met 3 PC's)
      |
   ROUTER - PC (router is een Vigor2600 annex A Firmware: v2.3.6_H)
      | 
   INTERNET

Nog meer weetjes:
• Met FTP servers ZONDER SSL heb ik dit probleem _niet_.
• Ik heb hiervoor een Sweex router gehad en daarmee had ik dit ook. Het lijkt me dus niet aan de router te liggen. Aan de router zit momenteel geen modem, hij bouwt zelf de verbinding op naar Demon Internet. Met die oude Sweex router maakte ik wel gebruik icm het modem. Beide gevallen hebben dus dit probleem.

Heeft iemand een idee wat dit kan veroorzaken?

De FTP server biedt zijn services aan op FTP poort 21.
Ik kan erop komen door voor een Auth TLS connectie als zowel voor een Auth SSL connectie te kiezen in de preferences van bijv. FireFTP.

Ik denk er nu trouwens ineens aan dat ik het nooit met die PC die direct aan de router zit heb geprobeerd. Zou een brakke switch dit kunnen veroorzaken? Dat die switch over zijn nek gaat bij FTP SSL?

Het gekke is, soms haal ik zo een film binnen van 700 MB of zo en de andere keer moet ik heb 5x proberen voordat ie een keer in één keer lekker doorloopt. Als de snelheid af begint te lopen druk ik al meteen op disconnect, want het lijkt erop dat ie sowieso dan niks meer binnen krijgt

Het lijkt er ook een beetje op dat hij meer moeite heeft met allemaal kleine bestandjes (bij.v mp3's) achter elkaar te downloaden dan een grote film. Die films gaan dan ook altijd niet in een keer goed maar een mp3 album binnenhalen is soms echt lang klooien

[silverstorm]

Wat is je MTU? En welke netwerkkaart heb je?

[DeMoN]

silverstorm schreef op maandag 05 december 2005 @ 13:21:
Wat is je MTU? En welke netwerkkaart heb je?

Die MTU en NIC heb ik dus expres niet vermeldt omdat het probleem zich voordoet op meerdere machines met verschillende hard en software.
O.a. Debian linux en Windows XP SP2.

Toch heb ik stiekem wel aan de MTU waardes gedacht, maar dat kan het volgens mij niet echt zijn.

Ik kan op dit moment ff niet checken wat de waardes van mijn werkstation zijn maar die van mijn server (waar ik het ook mee heb en dat is trouwens via de commandline ftp-ssl) wel.

code:

root[~]: ifconfig eth0 |grep -i mtu
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

1500 dus, lijkt me oke?

Wat btw deze nic is:

code:

root[~]: lspci -v |grep -i ethernet
0000:00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 01)

[ Voor 11% gewijzigd door DeMoN op 05-12-2005 13:31 ]

[DeMoN]

Ik zit nu achter de Windows XP SP2 machine die direct op de router zit en heb hier hetzelfde probleem

Wat kan dit nou zijn

[Sendy]

Ik denk dat je je probleem verkeerd beschrijft. De snelheid zal niet lager worden, maar de verbinding zal wel helemaal stilvallen. Het gedrag dat je ziet is verschijnlijk het gevolg van het nemen van een (schuivend) gemiddelde. Omdat er na een bepaalde tijd geen pakketjes meer binnenkomen wordt de gemiddelde snelheid daarna steeds lager.

Kan je dit verifieren? Als je een ethernet scanner gebruikt (ethereal bijvoorbeeld) dan kan je ook meteen zien wie er stopt met pakketjes versturen. heb je dit probleem niet met (grote) HTTP downloads? Probeer eens een groot bestand te versturen met nc ("netcat"), gebeurt er dan hetzelfde?

[DeMoN]

Sendy schreef op maandag 05 december 2005 @ 16:58:
Ik denk dat je je probleem verkeerd beschrijft. De snelheid zal niet lager worden, maar de verbinding zal wel helemaal stilvallen. Het gedrag dat je ziet is verschijnlijk het gevolg van het nemen van een (schuivend) gemiddelde. Omdat er na een bepaalde tijd geen pakketjes meer binnenkomen wordt de gemiddelde snelheid daarna steeds lager.

Ik denk dat je gelijk hebt, want zoals ik in de TS al zei komt er echt helemaal niks meer binnen dus hij blijft idd gewoon uitgaan van dat gemiddelde en zo lijkt het dat hij afneemt.

Kan je dit verifieren? Als je een ethernet scanner gebruikt (ethereal bijvoorbeeld) dan kan je ook meteen zien wie er stopt met pakketjes versturen. heb je dit probleem niet met (grote) HTTP downloads? Probeer eens een groot bestand te versturen met nc ("netcat"), gebeurt er dan hetzelfde?

Met grote HTTP downloads heb ik dit nog niet gehad. Met nc heb ik tot nu toe alleen nog maar kleine files overgebracht van andere servers ( ) maar nog nooit een grote geprobeerd.

Ik zal ethereal er eens op los laten om daadwerkelijk te kijken of de data 100% stil ligt en wat met nc prutsen Bedankt voor de tips iig

Heeft er ondertussen iemand anders nog tips?

[DeMoN]

Ok, ik denk dat ik nu weet waar het door komt, maar hoe het op te lossen?
Ben bang dat niet veel mensen me hiermee kunnen helpen of je moet aardig wat kennis hebben van TCP e.d. op packetniveau.

Maar goed,

Ik dus met Ethereal aan de slag.
- Verbinding met SSL FTP server
- Downloaden van mp3's starten

- ETHEREAL CAPTURE AAN!

Op dat moment zie ik van host A naar host B (ik naar de server) en andersom ACK packets heen en weer gaan met als inhoud encrypte packets

Tot mijn grote verbazing ging het dit keer net zolang goed totdat ik na 5 a 10 minuten (ik had aardig wat mp3's expres aangezet ) besloot om voor de test ander TCP verkeer te gaan veroorzaken!

M.a.w. ik was al die minuten aan het staren naar mijn Ethereal die netjes "on top" op de voorgrond over mijn FireFTP client packets stond te capturen terwijl ik ook in de gaten kon houden dat mijn FTP client netjes stabiel tussen de 220 en 232 kB/sec bleef zitten.

Op het moment dat ik een van de tabs van mijn firefox die gewoon nog openstonden ging reloaden ging het verkeerd. Ik besloot de tab waar IDLE fok.nl open stond even een reload te geven. Op DAT MOMENT zag ik mijn FTP speeds direct droppen zoals in de TS beschreven is.

- ETHEREAL STOP

- packets doorzoeken...

Nu heb ik dus netjes een log van allemaal ACK packets tussen mij en de FTP server (duizenden natuurlijk) tot op het moment dat je er ook WWW tussendoor ziet komen. Niet veel packets later (stuk of 10) volgen daarop opeens TCP packets met errors.

Dit kan gewoon geen toeval zijn.
Het gaat overigens niet direct fout na de www packets.
Eerst komt er de 3-way handshaking met Fok!, die gaat gewoon goed, dan komt er een GET op de / e.d, er worden wat .js files binnengehaald die later natuurlijk weer door firefox geparsed worden en nog wat packets later als er weer wat met Fok! aan communicatie gedaan moet worden komen dus de errors.

Ik heb er even een screenie van gemaakt.
De IP-adressen en de echte data in de packets kan ik jullie helaas niet geven, maar misschien dat iemand deze error sowieso al wat zegt:



Dit met die DUP ACK's gaat zo een tijdje door (100 packets?) en Fok! blijft er trouwens her en der wel gewoon goed doorheen komen, alleen FTP heeft hier dus dusdanig last van dat er niks meer binnen komt, alleen deze shitty packets of zo?

Is er iemand die hier verheldering in kan brengen?

[ThunderNet]

Dingen die ik nu na je verhaal nog afvraag:

andere SSL verbindingen (dus niet ftp) gaan die wel goed?
Kun je aan een log komen op de server?

[The Third Man]

FTP met SSL is eigenlijk ook tussen het wal en het schip in... De data gaat nog steeds buiten de tunnel om dus het is net zo gevoelig als standaard FTP. FTP over SSH (SFTP) is dan ook een veel beter alternatief al ben je wel zo'n 1/3 van je bandbreedte kwijt aan extra overhead. Probeer dat eens?

[DeMoN]

ThunderNet schreef op donderdag 08 december 2005 @ 01:08:
Dingen die ik nu na je verhaal nog afvraag:

andere SSL verbindingen (dus niet ftp) gaan die wel goed?
Kun je aan een log komen op de server?

- Mijn Gmail check ik altijd via https en dat gaat altijd goed
- Ik kan niet aan een log komen, de server staat echt buiten mijn beheer / ik weet waar hij staat / ik weet amper wie hem beheert (ik kan die gast alsnog wel een keertje mailen, misschien dat hij me hier toch aan kan helpen )

Lekkere Kwal schreef op donderdag 08 december 2005 @ 01:41:
FTP met SSL is eigenlijk ook tussen het wal en het schip in... De data gaat nog steeds buiten de tunnel om dus het is net zo gevoelig als standaard FTP. FTP over SSH (SFTP) is dan ook een veel beter alternatief al ben je wel zo'n 1/3 van je bandbreedte kwijt aan extra overhead. Probeer dat eens?

Tsja, dat heb ik idd liever ook, maar ja, die server is nou eenmaal zo ingericht..

[ThunderNet]

Heb je de mogelijkheid om een andere server zo in te richten dat deze ook met FTP-SSL werkt?
op die manier kun je uitvogelen of het aan jou systeem/netwerk ligt.. Of die aan de andere partij

[DeMoN]

ThunderNet schreef op donderdag 08 december 2005 @ 02:08:
Heb je de mogelijkheid om een andere server zo in te richten dat deze ook met FTP-SSL werkt?
op die manier kun je uitvogelen of het aan jou systeem/netwerk ligt.. Of die aan de andere partij

Dat zou ik kunnen doen ja
Ik zal eens kijken hoeveel werk het is en als dat meevalt zet ik er wel even snel eentje op

[DeMoN]

Hmm laat maar, ik ga al niks meer opzetten.

Ik probeer het nu vanaf mijn werk en ook hier heb ik dezelfde problemen.. het ligt dus duidelijk niet aan mij!



Ik ben wel ergens achter nu.

Stel, ik download hoi.mp3 (4 MB)

... downloading ....
...
.....
.......
STOP (bij 2 MB blijft ie bijv. hangen)



Wat ik dan doe ik ff disconnecten, en weer connecten.

Dan kan ik 2 dingen doen:
- Ik gooi die 2MB aan hoi.mp3 van mijn HDD en begin er opnieuw aan.
- Ik resume em.

Nu is het zo dat als ik em opnieuw doe downloaden ik even grote kans heb dat het weer mislukt of lukt en als ik em resume dan staat hij per direct weer stil!!

Ik denk dat dit wel wat zegt, hij kan dus ook niet resumen want op dat moment treedt het probleem per direct op!
Wat zou dit kunnen zijn

[ Voor 68% gewijzigd door DeMoN op 08-12-2005 14:30 ]

[Verwijderd]

is die server niet gewoon brak ingericht? Heb je het al eens geprobeerd met andere SSL FTP servers?

[DeMoN]

Verwijderd schreef op donderdag 08 december 2005 @ 15:22:
is die server niet gewoon brak ingericht? Heb je het al eens geprobeerd met andere SSL FTP servers?

Nee ik kan het ff niet testen met andere SSL FTP servers want er zijn niet zoveel servers die dat draaien. En om dat nou zelf op te gaan zetten duurt me iets te lang

Ik ben trouwens al aan het mailen met de amdin en hij gaat andere FTP server software installeren binnenkort. Hopelijk werkt het dan wel!
Ze draaien nu proftpd en het gaat pureftp worden.

[Verwijderd]

Euh.. /me heeft het zelfde verhaal. maar dan met uploaden. Die kapt er gewoon halfweg mee.

Software : Windows FTP explorer , en WS_ftp .. bij beide krijg ik gewoon een dikke timeout bij bepaalde bestanden zoals index.htm op m'n webserver. Het gaat om een stel templates die ik op een forum wil toevoegen maar halve templates werken niet en m'n forum gaat errors geven.

De oplossing is er nog niet voor gevonden, passive ook al geprobeerd

Wie o Wie?