Es könnte sein, das ich das "überlesen" habe, dann bitte ich um entschuldiung..
Aber was für ein FTP-Client verwendest du denn?
Aber was für ein FTP-Client verwendest du denn?
@trendchiller: FTP oder FTPES ?
Es gibt zwar in RFC 793 die Vorgabe, dass eine beendete TCP Verbindung für eine gewisse Zeit (ca. 2-4 Minuten) im Status TIME-WAIT verbleiben soll, allerdings würde dies nur zu einem "exhausted port"-Problem führen und nach dieser kurzen Zeit wieder funktionieren; Du sprichst jedoch davon, dass Du den FTP-Session-Timeout abwarten musst, um weiter zu kommen; das passt irgendwie also nicht.
Da wohl nicht so viele Leute zu diesen speziellen FTP-Servern mit diesen Einschränkungen Zugriff haben, zäume das Pferd doch einmal von der anderen Seite auf und versuche dieses Phänomen mit einem anderen FTP-Server im Internet ohne diese Einschränkungen zu reproduzieren. Sollte die Nachstellung damit nicht gelingen, sehe ich das Problem dann eher auf der Provider-Seite dieser speziellen FTP-Server oder einer ganz speziellen Problematik durch die Kombination FB und diesen FTP-Servern. Ein Kontakt zu AVM sollte dann evtl. hilfreicher sein.
Es gibt zwar in RFC 793 die Vorgabe, dass eine beendete TCP Verbindung für eine gewisse Zeit (ca. 2-4 Minuten) im Status TIME-WAIT verbleiben soll, allerdings würde dies nur zu einem "exhausted port"-Problem führen und nach dieser kurzen Zeit wieder funktionieren; Du sprichst jedoch davon, dass Du den FTP-Session-Timeout abwarten musst, um weiter zu kommen; das passt irgendwie also nicht.
Da wohl nicht so viele Leute zu diesen speziellen FTP-Servern mit diesen Einschränkungen Zugriff haben, zäume das Pferd doch einmal von der anderen Seite auf und versuche dieses Phänomen mit einem anderen FTP-Server im Internet ohne diese Einschränkungen zu reproduzieren. Sollte die Nachstellung damit nicht gelingen, sehe ich das Problem dann eher auf der Provider-Seite dieser speziellen FTP-Server oder einer ganz speziellen Problematik durch die Kombination FB und diesen FTP-Servern. Ein Kontakt zu AVM sollte dann evtl. hilfreicher sein.
nucleardirk
Aktives Mitglied
- Mitglied seit
- 12 Okt 2004
- Beiträge
- 1,493
- Punkte für Reaktionen
- 0
- Punkte
- 36
Nutze ich auch - ich konnte bisher Deine Probleme aber nicht nachvollziehen. Gegenstelle ist ein Synology-NAS, ein Rechner im Buero mit filezilla server sowie ein ftp der Uni und der meiner Website bei All-Incl.
Es scheint mit in der Tat auch auf die Gegenstelle anzukommen.
Elsi29
Aktives Mitglied
- Mitglied seit
- 24 Dez 2008
- Beiträge
- 2,866
- Punkte für Reaktionen
- 13
- Punkte
- 38
Die Rauschunterdrückung beim herkömmlichen T-Com Analoganschluss ist GROTTIG SCHLECHT!!!! Bei einigen Gesprächen verstehe ich meinen Gesrpächspartner teilweise gar nicht mehr.
Ich habe jetzt erst einmal ankommende Anrufe auf meine Sipgate Nr. umgeleitet (ist kostenlos) damit ich zumindest ankommende Gespräche einwandfrei führen kann.
Ich habe jetzt erst einmal ankommende Anrufe auf meine Sipgate Nr. umgeleitet (ist kostenlos) damit ich zumindest ankommende Gespräche einwandfrei führen kann.
@Elsi29
leider ein bekannter Fehler. Bitte an AVM melden, damit die das noch mal überarbeiten.
Bis dahin:
leider ein bekannter Fehler. Bitte an AVM melden, damit die das noch mal überarbeiten.
Bis dahin:
s'KATERchen schreibt:
Rauschunterdrückung deaktiviert: #614*1*#91**
Rauschunterdrückung aktivieren: #614*0*#91**
In den Beschreibungen zu den Telefoncodes steht es überall andersrum:
Rauschunterdrückung am Analoganschluss einschalten: #614*1*#91**
Rauschunterdrückung am Analoganschluss ausschalten: #614*0*#91**
Was stimmt denn nun? :noidea:
Joe
Rauschunterdrückung deaktiviert: #614*1*#91**
Rauschunterdrückung aktivieren: #614*0*#91**
In den Beschreibungen zu den Telefoncodes steht es überall andersrum:
Rauschunterdrückung am Analoganschluss einschalten: #614*1*#91**
Rauschunterdrückung am Analoganschluss ausschalten: #614*0*#91**
Was stimmt denn nun? :noidea:
Joe
Ich glaube Du hast recht, das es andern herum sein muss. Ich habe es aber so aus einer AVM-Mail kopiert. Probiere es doch einfach mal aus. 
nucleardirk
Aktives Mitglied
- Mitglied seit
- 12 Okt 2004
- Beiträge
- 1,493
- Punkte für Reaktionen
- 0
- Punkte
- 36
Mh, das is ziemlich regelmäßig - alle 12 Stunden 15 Minuten bzw. alle 735 Minuten oder 44.100 Sekunden. Irgendwie glaub ich nicht an nen Zufalls-Reconnect.
Das ist ja auch kein Reconnect, sondern der ganz normale DHCP-Refresh am Kabelanschluss. Die Adressen sind ja auch immer die gleichen .zzz.yy.xxx. Wobei es keinen Sinn macht, DNS-Server und Gateway zu verschleiern.
[Edit Novize: Überflüssiges Fullquote des Beitrag #408 gelöscht - siehe Foren-Regeln]
Stimmt schon so. Mit 1 wird deaktiviert und mit 0 aktiviert.
Ich hatte es auch erst andersherum gemacht, weil ich dachte das war ein Fehler, aber da bestand das Problem immer noch. Warum das AVM diesmal anders macht kann ich auch nicht sagen. Aber das deaktivieren wirkt wirklich Wunder. Die Qualität ist wieder wie mit der alten Firmware.
Stimmt schon so. Mit 1 wird deaktiviert und mit 0 aktiviert.
Ich hatte es auch erst andersherum gemacht, weil ich dachte das war ein Fehler, aber da bestand das Problem immer noch. Warum das AVM diesmal anders macht kann ich auch nicht sagen. Aber das deaktivieren wirkt wirklich Wunder. Die Qualität ist wieder wie mit der alten Firmware.
nucleardirk
Aktives Mitglied
- Mitglied seit
- 12 Okt 2004
- Beiträge
- 1,493
- Punkte für Reaktionen
- 0
- Punkte
- 36
Mich wundert nur dass dieser Reconnect bisher nie im Log dokumentiert wurde. Also auf gut deutsch - Ich brauch mir da keine Gedanken zu machen, ja?
Normales FTP.
Scheint nur an meiner FB so zu sein :-(
Anderer Anschluss, gleicher Server alles ok.
FTP intern auch ok.
Über die FB scheinbar problematisch.
Ich schaue weiter...
so...
eigenen FTP-Server über VPN erreicht, Transfer gestartet und nach 3 Minuten trat auch dort der Fehler auf...
Zuletzt bearbeitet:
Hat unimedia derweil dann an dem DHCP gearbeitet?
Ich hab mal nen Kollegen gehabt der hatte nur 1 PC, und wollte keinen Router haben.
D.h. Modem (Motorola) -> PC.
Alle 15 Minuten, manchmal sogar alle 1 Stunde flog er vom netz.
Ich habe damals einen IRC Server betrieben, und als IRC-Serverowner sah ich diese fliegereien, und
da war es so, das je nach laune des dhcp servers von unity mal eine Neue IP kam, oder die "Alte" weiter verwendet wurde.
Mit einem Router (damald der D-Link DIR 52x) konnte das Problem behoben werden.
Im Modemlog des Motorola konnte man sehen, dass das Modem durch den DHCP eine ACK gemeldet bekam
wonach wenn ich das System richtig verstehe der DHCP Server in Kurzen Zeitintervalen prüft, ob das Gerät (Kabelmodem)
noch mit dem Netz verbunden ist. Das Modem bzw. das Angeschlossene Gerät muss bei dieser ACK Frage die antwort
geben, dass das Gerät noch da ist, und die IP weiter behalten werden kann.
Bleibt die Antwort aus, dann versucht der DHCP Server in noch kürzen Zeitabständen eine weitere Anfrage.
Passiert nach dem 2 und 3ten male immer noch nichts, kommt es dann irgendwann zu einem Time-Out, und die Verbindung wird
"Zwangsweise" unterbrochen, und Neu hergestellt, wobei dann der ganze Prozess von vorne beginnt.
Soweit ich es selbst noch aus eigenerfahrung weiss, Fragt der DHCP Server nach 35 Minuten Onlinezeit auf 1 Stunde gesehen ab.
Kommt keine antwort, kommt in der 45 Min. die neuerliche anfrage. Beim nächsten mal bei der 55 Minute.
Passiert bis hierhin immernoch nichts, kommt kurz vor der 60 min. eine nochmalige Anfrage, die dann ab der 60 Min. bei misserfolg
zum Time-Out der gesamten Leitung führt, bis das Spielchen wieder von vorne los ging.
Ob und was sich JETZT geändert hat, dazu kann ich nichts mehr sagen, da ich aufgrund verschiedener Probleme mit Unitymedia hatte
nicht sagen kann, weil ich seit 2012/12 kein Kunde mehr dort bin, und dabei sah meine Config damals so aus:
Motorola Modem -> D-Link Dir 52X -> PC's und Später kam dann die 7390 als "LAN1" Betrieb an das Modem zum laufen.
Damals habe ich ein Leistungsprofil mit 64.000 gehabt, die auch immer voll anlagen.
Da aber neuerdings bei Unitymedia mit IPV6 gearbeitet wird, und das ganze zu einem Kioskinternet geworden ist, und unitymedia
schon damals keine Lösung mir anbieten konnte, ausser wie es jetzt neuerdings gehandhabt wird, einen "Buisnesvertrag" abzuschließen
der dann insgesamt noch Teurer kommt, als ein "Telekom" anschluss, habe ich von meinem Sonderkündiungsrecht gebrauch gemacht
und bin seit Anfang diesem Jahres bei der Telekom.
Ich war von 2005 - 2012/12 "Kunde" bei denen, und habe die "Anfänge" miterlebt, wo es noch ISH (Ehmen. KabelNRW) sich nannte, mit sage und schreibe 2 Mbit/s.
Gegenüber der Telekom war das damals Traumhaft, weil man dabei richtig gesehen hat, wie die Bits und Bytes nur so geflogen sind.
Auch das Surfverhalten (Geschwindigkeit) ist recht klasse gewesen.
Nur wie es jetzt im mom wegen diesem IPv6 gehandhabt wird, macht das überhauptgarkeinen Spass.
Ich bin gespannt wie das erst noch werden soll, wenn die Zeit mit ipv4 dann entgültig vorbei sein wird.
Ich hab mal nen Kollegen gehabt der hatte nur 1 PC, und wollte keinen Router haben.
D.h. Modem (Motorola) -> PC.
Alle 15 Minuten, manchmal sogar alle 1 Stunde flog er vom netz.
Ich habe damals einen IRC Server betrieben, und als IRC-Serverowner sah ich diese fliegereien, und
da war es so, das je nach laune des dhcp servers von unity mal eine Neue IP kam, oder die "Alte" weiter verwendet wurde.
Mit einem Router (damald der D-Link DIR 52x) konnte das Problem behoben werden.
Im Modemlog des Motorola konnte man sehen, dass das Modem durch den DHCP eine ACK gemeldet bekam
wonach wenn ich das System richtig verstehe der DHCP Server in Kurzen Zeitintervalen prüft, ob das Gerät (Kabelmodem)
noch mit dem Netz verbunden ist. Das Modem bzw. das Angeschlossene Gerät muss bei dieser ACK Frage die antwort
geben, dass das Gerät noch da ist, und die IP weiter behalten werden kann.
Bleibt die Antwort aus, dann versucht der DHCP Server in noch kürzen Zeitabständen eine weitere Anfrage.
Passiert nach dem 2 und 3ten male immer noch nichts, kommt es dann irgendwann zu einem Time-Out, und die Verbindung wird
"Zwangsweise" unterbrochen, und Neu hergestellt, wobei dann der ganze Prozess von vorne beginnt.
Soweit ich es selbst noch aus eigenerfahrung weiss, Fragt der DHCP Server nach 35 Minuten Onlinezeit auf 1 Stunde gesehen ab.
Kommt keine antwort, kommt in der 45 Min. die neuerliche anfrage. Beim nächsten mal bei der 55 Minute.
Passiert bis hierhin immernoch nichts, kommt kurz vor der 60 min. eine nochmalige Anfrage, die dann ab der 60 Min. bei misserfolg
zum Time-Out der gesamten Leitung führt, bis das Spielchen wieder von vorne los ging.
Ob und was sich JETZT geändert hat, dazu kann ich nichts mehr sagen, da ich aufgrund verschiedener Probleme mit Unitymedia hatte
nicht sagen kann, weil ich seit 2012/12 kein Kunde mehr dort bin, und dabei sah meine Config damals so aus:
Motorola Modem -> D-Link Dir 52X -> PC's und Später kam dann die 7390 als "LAN1" Betrieb an das Modem zum laufen.
Damals habe ich ein Leistungsprofil mit 64.000 gehabt, die auch immer voll anlagen.
Da aber neuerdings bei Unitymedia mit IPV6 gearbeitet wird, und das ganze zu einem Kioskinternet geworden ist, und unitymedia
schon damals keine Lösung mir anbieten konnte, ausser wie es jetzt neuerdings gehandhabt wird, einen "Buisnesvertrag" abzuschließen
der dann insgesamt noch Teurer kommt, als ein "Telekom" anschluss, habe ich von meinem Sonderkündiungsrecht gebrauch gemacht
und bin seit Anfang diesem Jahres bei der Telekom.
Ich war von 2005 - 2012/12 "Kunde" bei denen, und habe die "Anfänge" miterlebt, wo es noch ISH (Ehmen. KabelNRW) sich nannte, mit sage und schreibe 2 Mbit/s.
Gegenüber der Telekom war das damals Traumhaft, weil man dabei richtig gesehen hat, wie die Bits und Bytes nur so geflogen sind.
Auch das Surfverhalten (Geschwindigkeit) ist recht klasse gewesen.
Nur wie es jetzt im mom wegen diesem IPv6 gehandhabt wird, macht das überhauptgarkeinen Spass.
Ich bin gespannt wie das erst noch werden soll, wenn die Zeit mit ipv4 dann entgültig vorbei sein wird.
Zuletzt bearbeitet:
qwertz.asdfgh
IPPF-Promi
- Mitglied seit
- 18 Feb 2011
- Beiträge
- 4,467
- Punkte für Reaktionen
- 65
- Punkte
- 48
Anscheinend tritt diese DHCP- bzw. Internetverbindungs-Erneuerung nur in "7390 über LAN1 an (Kabel-) Modem"-Szenarien auf und da, je nach Anbieter oder Einwahlmodem, in unterschiedlichen Intervallen.
Eventuell gab es dieses Problem schon länger, wurde nur bisher nie in den Logs geführt.
Habt Ihr Zugriff auf die Einstellungen oder Firmware des jeweiligen Modems, d.h. kann der Anwender da Änderungen vornehmen?
Falls ja, prüft doch mal, ob es dort Lease-Time-Einstellungen gibt oder die vorhandene Firmware veraltet ist.
Falls nicht, Meldung an den jeweiligen ISP, mit Fehlerbild-Beschreibung und ggfs. Log-Ausschnitten.
Eventuell gab es dieses Problem schon länger, wurde nur bisher nie in den Logs geführt.
Habt Ihr Zugriff auf die Einstellungen oder Firmware des jeweiligen Modems, d.h. kann der Anwender da Änderungen vornehmen?
Falls ja, prüft doch mal, ob es dort Lease-Time-Einstellungen gibt oder die vorhandene Firmware veraltet ist.
Falls nicht, Meldung an den jeweiligen ISP, mit Fehlerbild-Beschreibung und ggfs. Log-Ausschnitten.
Neueste Beiträge
-
FRITZ!Box 4060 - Labor 7.90 - Sammelthema- Letzte: Bugs Bunny
-
[Gelöst] 7490 mit anderen IP-Adressen (als 192.168.178.1) recovern- Letzte: BenGurion_
-
[Sammlung] Aktuelle Konditionen für Vertragsverlängerung
- Letzte: Martin
-
FRITZ!Box 7590 / FRITZ!OS 8.00 vom 31.10.2024
- Letzte: joto
-
Fritz!DECT 302 regelt nicht mehr- Letzte: Jstessi
-
Analoges Wählgerät einer Alarmanlage an VoIP betreiben ...
- Letzte: Multireed