KielNEt DSL - Probleme
Joerg Freund
hat jemand von Euch AUCH folgende Probs mit Kielnet DSL :
Bei aufender Verbindung (FTPupload) wird die Ltg unterbrochen
(nicht zwangstrennung !!)
Und das so 6 -7 mal in 10 Min
Verschicken von Emails mit Anhang geht nicht
Falls man eine Webserver dahinter hat: extrem langsamer
Datentransport
(so 600Byte/s !)
Eine ANruf bei Kielnet-Admins sowie Neatgear Germany
hat den tTipp gebracht die MTU der Netzwerkkarten von Standard
1500
auf 1492 (DSL Stdt) zu setzten, was aber überhaupt keine
Besserung bringt.
- Die Umsetzung soll doch der Router bzw das Modem machen.....
HArdware:
Router+Modem (integr)
Netgear DG834GB, Firmwareversion V1.04.01
Rechner:
Winxp prof mit rtl8139
Solaris8 x86 mit 3com 10 MBit
Mom fahre ich wieder ISDN, das funzt, aber obiges ist ja kein
Zustand.
....meine Nerven ...... :)
Hat da jemand ähnliche Erfahrungen gemacht ?
--
mfg / best regards
Joerg Freund
http://www.freund-hj.de.vu
Let the SUN always shine through an Open Windows...
Martin Knott
Martin
Joerg Freund
Martin Knott wrote:
> ...es geht nichts über T-online Flat :-)
Identische Technik, letzte Meile auch von der DTAG,
vermittlungsstelle...
:))
mfg jörg
Martin Knott
Also, mein DSL funktioniert seit etlichen Jahren quasi problemlos. *flöt*
Kurt Guenter
>...es geht nichts über T-online Flat :-)
und die beseitigt die KielNet DSL-Problem?
Andreas Maier
rigendwie komisch das den Leuten nicht geholfen wird sondern da nicht was
Produktives raus kommt.
Ich würde an diener Stelle mal zu Kielnet gehen oder da anrufen das Problem
schildern, eventuell ist das Kabelmodem defekt, verwendest du einen Router
sollte man auch den mal austauschen oder weg lassen und es dann nochmals
testen.
Solltest du die Möglichkeit haben einen anderen Computer zum testen zu
nehmen tue es mal.
Es gibt für dieses Problem mehrere Ursachen es kann an einer
Vermittlungsstelle liegen, es kann wie o.g. an deinem Kabelmodem/Router
liegen oder an deinem PC.
Schreib doch mal deine direkten Verlauf von Kabelmodem bis hin zum PC und
die Hardware deines PCs auf.
Vielleicht kann man an hand der Daten dir etwas weiter helfen.
"Martin Knott" <d-...@gmx.net> schrieb im Newsbeitrag
news:opsc1ngn...@new.t-online.de...
Joerg Freund
sorry für die Tippfehler, war nicht beabsichtigt
mfg
Jörg
Bjoern Thomsen
> Schreib doch mal deine direkten Verlauf von Kabelmodem bis hin zum PC und
> die Hardware deines PCs auf.
Was soll das helfen?
Vermtl. hat er im Router den MTU-Wert nicht gesetzt.
Se os,
Björn
PS: Du bist nicht gewillt - trotz mehrmaliger freundlicher Aufforderung
- Dein Tofu-Quoting abzustellen?
Joerg Freund
sorry bin vom "fach",
---------------
das posting sollte eigentlich nur folgendes bringen:
gibt es noch mehr leute die ähnliche probs haben?
gibt es noch mehr leute die überhaupt probs mit
kielnetdsl haben, wenn ja welche
---------------
die mtu sind richtig gesetzt
standart bei uns in .de sind 1492 für atm/dsl,
LAN 1500
die umsetzung sollte auch der router machen,
deswegen war es auch nur ein versuch die mtu
der rechner umzustellen- was aber nicht brachte
ich poste mal die ausführliche mail an KielNet,
die ungefähr 6 std telefonat mit Netgear .de und
KielNet geben ich mal nicht wieder.....
<zitat>
(bei mir, unter anderm:)
Hardware: netgear dg834gb
Solaris8 x86 3com nic
winxp prof rtl8139c nic
(mein bekannter, auch informatiker stud.))
suse linux 7.x rtl8029 (via isdn arcor)
cisco isdn-router
ich hatte nun etwas zeit der sache genauer auf den grund zu
gehen.
meine analyse brachte folgende ergebnisse:
1.: änderung der mtu auf 1492 bei den nic der rechner - keine
besserung
2.: aufruf der routerconfigseite über die dsl-ltg (also quasi
direkt) ist genauso lahm, da ist ausser dem netgear nichts mehr
dazwischen geschaltet
3: analyse von einem bekannten aus:
(verschiedene paketgrößen des icmp-pings, oberhalb einer
bestimmten paket größe geht fast nichts mehr, überschlägig
über weit über 50% verlust- dabei wird aber die MTU nicht
überschritten !!):
(linux, -s = paketgröße)
<zitat>
ping -s1277 82.97.157.101 klappt nicht, aber ping -s1276
82.97.157.101klappt, wenn auch mit Paketverlusten. Ein
ping -s1277 217.70.201.1 (---> 217.70.201.1 stellt die
übergabe zw. kielnet und dem dsl aus meiner sicht her)
klappt ohne Problemer; da gehen auch größere Werte (hab -s1500
getestet).
Zeitweilig gab es auch bei einem schlichten ping 82.97.157.101
massive Paketverluste.
Ein traceroute liefert sowas:
traceroute to 82.97.157.101 (82.97.157.101), 30 hops max, 40 byte
packets
1 halut.solar-empire.de (192.168.242.2) 2 ms 1 ms 1 ms
2 cisco.solar-empire.de (192.168.241.1) 7 ms 7 ms 7 ms
3 * * *
4 hmb-145-253-17-33.arcor-ip.net (145.253.17.33) 36 ms 43 ms
36 ms
5 hmb-145-254-10-45.arcor-ip.net (145.254.10.45) 37 ms 36 ms
37 ms
6 mue-145-254-16-90.arcor-ip.net (145.254.16.90) 51 ms 51 ms
52 ms
7 INXS.MUXS-1-eth000.de.lambdanet.net (194.59.190.51) 51 ms
51 ms 51 ms
8 M-4-eth000-101.de.lambdanet.net (217.71.105.85) 50 ms 49 ms
49 ms
9 S-3-atm010-732.de.lambdanet.net (217.71.105.121) 51 ms 56
ms 50 ms
10 F-4-atm130-733.de.lambdanet.net (217.71.105.5) 52 ms 52 ms
53 ms
11 DUS-2-pos000.de.lambdanet.net (217.71.105.29) 55 ms 54 ms
53 ms
12 HH-4-pos110.de.lambdanet.net (217.71.105.70) 65 ms 64 ms
65 ms
13 KielNet-KI.de.lambdanet.net (217.71.111.82) 65 ms 67 ms 66
ms
14 * * *
15 * * *
^C
Achja, als ich bei mir die MTU auf 1200 gestzt hatte, konnte ich
auf den Webserver zugreifen, aber nur mit großen Latenzzeiten und
laaaangsaaam.
</zitat>
wir haben da noch mehr probiert, was aber letztendlich immer
darauf hinauslief, das irgendwo pakete verloren gehen, die
latenz-
zeiten extrem hoch sind.
4.: wie bereits mitgeteilt habe ich 2 d-link modems durch, welche
mich zu dem netgeargerät brachten, ich glaube ja nun nicht das
alle
defekt waren.
5.: während eines laufenden ftp-download (210 mb) mehrfacher
verbindungszusammenbruch des dsl-carriers, neuconnect.
innerhalb von 10 min bis zu 7 mal
(wenn es lief kamen aber im schnitt 180 kb /s (spitze 225) )
dies gilt nicht nur für ftp-downloads, das grundlose kappen der
ltg.passiert auch so
wenn ich mir das alles so durchdenke, funktioniert die ltg
eigentlich seit beginn nicht richtig. es viel halt eben nicht
weiter
auf, bis eben zu den punkten, das der webserver nicht richtig
ansprechbar gewesen ist (was ich aber zuerst auf patch
und config probs zurückführte - der server ist seit dem 19.08.
durchgepatch, und funktionierte via isdn und im lan einwandfrei),
und der tatsache das sich e-mails mit anhang nicht verschicken
ließen.
weiterhin ist es auch so, das dns-auflösungen im vehältnis lange
brauchen über die dsl-ltg.
ich habe ein firmwareupdate des modemrouters durchgeführt nach
rücksprache mit neatgear GER, es ist gerade eben noch eine beta,
aber schon sehr lange im test.
diese füge ich als anhang bei - allerdings brachte diese, mal
abgesehen von einigen weiteren punkten (dämpfungsanzeige etc)
nichts
wirklich neues, bzw eine verbesserung.
wobei ich aber auch nicht in erfahrung bringen konnte, was an
dieser firmwareversion (v 1.05.00) geändert worden ist.
da ich nun wissen möchte - ich denke sie auch - was mit der ltg
los ist, zumal es ja wohl in selent noch einen kunden mit
ähnlichen, bzw
wohl dem gleichen prob gibt, würde ich es sehr begrüßen wenn sie
sich
mit mir in verbindung setzten könnten.
ist es zum testen der verbindung evtl. möglich einen
entsprechende cisco oder bintec leihweise zur verfügung gestellt
zu bekommen ?
</zitat>
so, das ist der sachstand
mfg
Jörg
- via ISDN-
Christian Ihlow
das kommt mir so halbwegs bekannt vor.
Hatte vor guten 2 Jahren was ähnliches bei meinem T-DSL 768
Bei mir war es so , das die Verbindung teilweise immer langsamer wurde,
auch mal etliche Webseiten nicht auffindbar waren von meinem Anschluss aus.
Das ganze ging soweit bis ich mich im 2-5min Abstand neu anmelden musste.
(Aussage der Telekom damals: Der Fehler müsse bei mir sein, seitens Telekom
wäre alles Ok
Nach knapp 3 Wochen Fehlersuche bei mir, stellte sich bei einem zufälligen
Gespräch mit einem Bekannten heraus das es der Schrank in der
Vermittlungsstelle war und das wir mindestens 10 Leute im Ortsnetz waren mit
dem Problem. Die Hardware war längst neu bestellt als die Hotline noch
meinet das da alles OK is..und ich doch bei mir suchen müsste.... ohne
Worte..)
Versuch doch mal raus zu bekommen wer in der Nähe bei dir noch DSL aus der
gleichen Vermittlungsstelle bekommt und wie dessen Leitung zur Zeit ist.
MfG
Christian
"Joerg Freund" <freu...@gmx.de> schrieb im Newsbeitrag
news:cg5r1i$a4e$1...@ulric.tng.de...
> HAllo,
>
> sorry bin vom "fach",
>
>
Andreas Maier
Muss nicht umbedingt der MTU sein, erklräung spar ich mir, dafür gibt es
google.
Wie ich ja geschrieben habe kann es auch die Vermittlungsstelle sien aber
man sollte sich bevor man das vermutet oder an nimmt auch an sienne PC
wenden und sicher sein das da alles okey ist.
Denn was nützt es wenn bei en dann doch alles okey ist und man selber dann
doch das Problem ist.
Siche rist es immer besser erst einmal zu kielnet zu gehen und zu sagen es
liegt an denen aber muss das sien wenn amn zu ahuse auch erstmal schauen
sollte.
Ich habe nun shcon von meheren anbietern DSL gehabt, Probleme hatte ich
damlas nur bei der Telekom, bei Q-DSL war sogar der Service super, aber das
gehört ja nicht heir rein.
Und das was ich hier sage ist sicherlich kein ToFu.
Aber wenn es elute gibt die meinen es läge am MTU-Wert und schreiben nur
einen Satz finde cih das etwas merkwürdig.
"Bjoern Thomsen" <b....@gmx.de> schrieb im Newsbeitrag
news:cg5oc4$all$04$1...@news.t-online.com...
Heinz-Joachim Spott
> Muss nicht umbedingt der MTU sein, erklräung spar ich mir, dafür gibt
> es google.
> Wie ich ja geschrieben habe kann es auch die Vermittlungsstelle sien
> aber man sollte sich bevor man das vermutet oder an nimmt auch an
> sienne PC wenden und sicher sein das da alles okey ist.
> Denn was nützt es wenn bei en dann doch alles okey ist und man selber
> dann doch das Problem ist.
> Siche rist es immer besser erst einmal zu kielnet zu gehen und zu
> sagen es liegt an denen aber muss das sien wenn amn zu ahuse auch
> erstmal schauen sollte.
> Ich habe nun shcon von meheren anbietern DSL gehabt, Probleme hatte
> ich damlas nur bei der Telekom, bei Q-DSL war sogar der Service
> super, aber das gehört ja nicht heir rein.
> Und das was ich hier sage ist sicherlich kein ToFu.
> Aber wenn es elute gibt die meinen es läge am MTU-Wert und schreiben
> nur einen Satz finde cih das etwas merkwürdig.
ich finde diesen Artikel auch merkwürdig. Sind die Knöppe deiner Tastatur
eigentlich an der richtigen Stelle? Oder ist die Tastatur andersrum?
Was du schreibst ist auf alle Fälle ToFu!
Ahoj
>*))>><
Andreas Maier
was du sagst ja schon lange da du eh von dem Thema null Ahnung hast.
Aber das du überall ruim laberst liegt wohl daran das du nur zu ahuse
hockst? MAch aml was Produktives, soll ich dir ein paar Beispiele nennen
oder es dir zeigen?
"Heinz-Joachim Spott" <ac...@hjspott.de> schrieb im Newsbeitrag
news:2opj7lF...@uni-berlin.de...
Sebastian Gerling
könnte auch an _zu_ vielen Verbindungen gleichzeitig liegen das der Router
damit ein wenig überfordet ist!
Allerdings nur der Fall wenn Filesharing Progs gleichzeit laufen!
MTU ist eine gute Idee - aber musst Du _im_ Router _und_ in Windows ändern!
Tja ansonsten google mal!
Sebastian Gerling
--
PiX-ART.com
Andreas Maier
aber kann imme rnoch ein Problem des DSL_Modems sein falls es keinen Router
gibt.
"Sebastian Gerling" <Seba...@sedoge.com> schrieb im Newsbeitrag
news:2opk2bF...@uni-berlin.de...
Sebastian Gerling
> aber kann imme rnoch ein Problem des DSL_Modems sein falls es keinen
> Router gibt.
Tja ist aber vorhanden ;)
Andreas Maier
seinnews:2opkhhF...@uni-berlin.de...
Joerg Freund
Christian Ihlow wrote:
> Moin,
> das kommt mir so halbwegs bekannt vor.
> Hatte vor guten 2 Jahren was ähnliches bei meinem T-DSL 768
> Bei mir war es so , das die Verbindung teilweise immer
langsamer
-> bei großen Dateien/langen übertragungen ist dieser Effekt
normal
bei DSL (aufgrund der Technik), was aber nicht heißen soll, das
man am
Ende mit 20 Byte/s rumkrebst.
Will sagen messtechnisch spürbar, bei praktischen download sollte
man das eigentlich kaum merken.
Wenn man es doch so stark ist, ist irgendwas im Eimer.
> wurde, auch mal etliche Webseiten nicht auffindbar waren von
snip
ich denke auch das es bei KielN liegt, da ich hier alles gecheckt
habe, was zu checken ist.
> Versuch doch mal raus zu bekommen wer in der Nähe bei dir noch
> DSL aus der gleichen Vermittlungsstelle bekommt und wie dessen
> Leitung zur Zeit ist.
yo, da gibt es jemand in meinem Ort, der kann keine email
mit anhang verschicken - ein teil des Fehlers auch bei mir.
da ich aber mehr mache als der ottonormaluser,
fällt dem kunden das garnicht weiter auf, zumal wenn
er seinen rechner direkt ans modem anschließt,
und keinen router hat.
abgeshen davon hatte ich auch erst die kombie
linux-router - d-link modem: ging garnicht.
und ich habe ahnung UNIX (Solaris) / Linux.
Ich weiß wie man sowas einrichtet, mache
ich ja nun nicht zum ersten mal.
deswegen bin ich nun auf den netgear
umgestiegen (weil es nicht ging), mit dem nebeneffekt,
das die kiste weniger strom brauch....
Das Prob liegt denke ich bei 217.10.201.1,
aus meiner sicht die gegenstelle zum modem.
dort tritt der paketloss auf.
Da die beim Modemrouter angezeigten Datendurchsatzwerte
und die dämpfung nominal sind, die Leitungsstrecke nur
ca. 3 km beträgt, halte ich das für einen Gerätedefekt
entweder beim Einschub in der VmST, oder eben bei
217.70.201.1
mfg
Jörg
Joerg Freund
Sebastian Gerling wrote:
> Neue Firmware für den Router ist drauf?
ja, hatte die v 1.04.00
auf dränegn bei netgear habe ich die v 1.05.00 bekommen,
ist aber noch nicht offiziell freigegeben
> könnte auch an _zu_ vielen Verbindungen gleichzeitig liegen das
> der Router damit ein wenig überfordet ist!
negativ.
> Allerdings nur der Fall wenn Filesharing Progs gleichzeit
laufen!
negativ.
macht aber im test auch keinen unterschied.
abgesehen davon kann man die max. anzahl der gleichzeitigen
udp-verbindungen (p2p) auch einschränken, bzw. unterbinden,
wenn man die ports schließt - das nur am rande
Und da im netgear - mhhhh - ein Linux basierendes OS
läuft, sollte netgear eine kernelvariante gewählt habe,
die den UDP-Patch bereits beinhaltet, war auch nur ein prob bis
kernelversion 2.x (ahhhh weiß ich jetzt nicht mehr genau),
jedenfalls ist die kernelvariante die die suse 8 beinhaltet
bereits daraufhin überarbeitet.
(das letzte habe ich bewußt etwas zu verallgemeinert)
NICHT das es heißt ich hätte gesagt im Netgear läuft ein
suselinux.....
Es läuft dort ein OS das auf Linux basiert.
> MTU ist eine gute Idee - aber musst Du _im_ Router _und_ in
> Windows ändern!
tja, hab ich gemacht - bringt nichts.
vor allem erklärt es nicht, das die Verbindung grundlos
zusammenbricht.
mfg
Jörg
Andreas Maier
würde sagen wenn es das nicht ist, dann kann es wirklich nur die Verbindung
zwischen Kabelmodem und Kielnet ( Vermittlungsstelle) sein.
"Joerg Freund" <freu...@gmx.de> schrieb im Newsbeitrag
news:cg88ef$bet$1...@ulric.tng.de...
Joerg Freund
Andreas Maier wrote:
> Hi,
>
> würde sagen wenn es das nicht ist, dann kann es wirklich nur
die
> Verbindung zwischen Kabelmodem und Kielnet (
Vermittlungsstelle)
> sein.
ISt ja mein reden, aber weiters von Kielnet bekomme ich
erst am Montag, weil da ja ab Fr. 16.00 UHr WE ist.....
naja.
Sonst sind die Admins dort ja freundlich,
wobei ich aber eine der Telefontanten da fast
durchs telefon gezogen hätte, weil sie ich trotz
Namensangabe nicht weiter verbinden wollte.
Michael Roche
Mach doch mal ein Online-Check Deiner Parameter, dann weißt Du
wie du rausgehst.
T-DSL 2000 ist bei mir so z.B. optimal eingestellt.
***********************************************************************
TCP options string = 020405ac0103030201010402
MTU = 1492
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to
1500 for optimal throughput.
MSS = 1452
MSS is optimized for PPPoE DSL broadband. If not, consider raising MTU
to 1500 for maximum throughput.
Default Receive Window (RWIN) = 255552
RWIN Scaling (RFC1323) = 2 bits (scale factor of 4)
Unscaled Receive Window = 63888
RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
511104 (MSS x 44 * scale factor of 8)
127776 (MSS x 44 * scale factor of 2)
63888 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):
Your RcvWindow limits you to: 10222.08 kbps (1277.76 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4088.832 kbps (511.104 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 55 hops
TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000
***********************************************************************
Link:
http://www.speedguide.net/analyzer.php
Gruß
Michael
Sebastian Gerling
Mit Arcor 1500
TCP options string = 020405a001010402
MTU = 1480
MTU is optimized for Windows XP PPoE DSL broadband. If not, consider raising
MTU to 1500 for optimal throughput.
MSS = 1440
MSS is optimized for Windows XP PPPoE DSL broadband. If not, consider
raising MTU to 1500 for maximum throughput.
Default Receive Window (RWIN) = 65535
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 65535
Note: Under Windows 9x, if you have RWIN set to any other value, and the
Analyzer reports 65535 you might need to install the MS Vtcp386 fix.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
506880 (MSS x 44 * scale factor of 8)
253440 (MSS x 44 * scale factor of 4)
126720 (MSS x 44 * scale factor of 2)
63360 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):
Your RcvWindow limits you to: 2621.4 kbps (327.675 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1048.56 kbps (131.07 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 123 hops
Ralf Hasse
> Und das was ich hier sage ist sicherlich kein ToFu.
Kein Grund zur Veranlassung. Bjoern bezog sich nicht auf den Inhalt
Deines Postings, sondern auf den Umstand, daß Du den Vorredner
komplett zitierst und das auch noch unten dranhängst: "Topquote oben,
Fullquote unten" = ToFu. Das ist unschön, weil es den Lesefluß
zerstört.
Mehr dazu hier: http://de.wikipedia.org/wiki/TOFU
Ralf
--
If all else fails, throw up.
Ludwig Boeckel
> Und das was ich hier sage ist sicherlich kein ToFu.
Du velwechserst gerade "Tofu" mit "Quark", und ob das, was Du hier
schreibst, Quark ist, mögen andere kommentieren.
Lieber Andreas, liebe angehende PC-Profis, liebe sonstige junge Hüpfer,
nicht alle, die hier schreiben, tun das nach dem Motto 'egal ob ich die
Tasten treffe, ihr wißt schon, was ich meine'. Und wer Fachmann werden
will (egal auf welchem Gebiet), tut gut daran, die Möglichkeit eigener
Irrtümer und Fehler nie ungeprüft auszuschließen.
Hier wurde Andreas die Absonderung von 'TOFU' vorgeworfen, was durch
die Großbuchstaben als Abkürzung zu erkennen wäre, wenn man nicht durch
eigene Gleichgültigkeit bezügl. Genauigkeit behindert wäre. Diese
Abkürzung hätte Andreas 'ergooglen' können, und wäre er nicht zu
kleinkindhaft trotzig gewesen, einem zusätzlich zur Kritik gegebenen
Link zu folgen, so wäre er auch dort auf die Auflösung gestoßen.
Neben der bereits angegebenen Quelle für Informationen über besser
lesbare Postings, insbesondere zum Zitieren, nämlich
<http://www.afaik.de/usenet/faq/zitieren/>, empfehle ich einen Besuch in
der Newsgruppe de.newusers.infos (und bei weiteren Fragen ist
de.newusers.questions hilfreich).
HTH Ludwig
Rainer Zocholl
>---------------
>das posting sollte eigentlich nur folgendes bringen:
>gibt es noch mehr leute die ähnliche probs haben?
>gibt es noch mehr leute die überhaupt probs mit
>kielnetdsl haben, wenn ja welche
Naja, evtl. haben auch andere so ein Problem und sie interessiert,
wie man den Fehler einkreisen kann?
>die mtu sind richtig gesetzt
>standart bei uns in .de sind 1492 für atm/dsl,
>LAN 1500
>die umsetzung sollte auch der router machen,
Nur dann wenn da ein proxy drauf ist.
Sonst hast Du immer ein volles Paket und
eines mit dem "Rest".
Problematisch ist nicht der reduzierte Durchsatz (ist ja eh nur von Dir weg),
sondern das manche Gegenseiten die Pakete nicht mehr zusammengesetzt
bekommen...(kaputte/paranoide/unwissende Firewall)
>deswegen war es auch nur ein versuch die mtu
>der rechner umzustellen- was aber nicht brachte
>ich poste mal die ausführliche mail an KielNet,
>die ungefähr 6 std telefonat mit Netgear .de und
>KielNet geben ich mal nicht wieder.....
Netgear???
Ich habe einen Kollegen der bei dem Namen auf die Palme steigt...
Netgear hat nämlich zum Teil sehr gute Geräte and auch zum Teil
Sondermüll, weil sie alles zukaufen und nur
und ihr Label drauf drucken und das Handbuch verkorksen:
Im obigen Fall war das Netgear Gerät im orginal ein Zyxel. Zyxel
macht i.A. gute Anleitungen. Firma Netgear meinte aber wohl, die sei
zu lang (Papier ist teuer!) und hat ein paar -wesentliche- Kapitel
einfach weggelassen, auf die sich nachfolgende ständig bezogen.
Als wir das Handbuch vom Zyxel daneben legten, war klar, das
das Problem nicht zwischen Tastatur und Stuhl an diesem Ende sass...
><zitat>
>(bei mir, unter anderm:)
>Hardware:
>netgear dg834gb
Du hast nicht gesagt das Du "funk" machst...!
>Solaris8 x86
>3com nic
>winxp prof
>rtl8139c nic
Argl...realtec... ;-(
>(mein bekannter, auch informatiker stud.))
Soll das jetzt ne Endschuldigung sein? ;-)
>suse linux 7.x
>rtl8029 (via isdn arcor)
Urgs...informatiker und kein Geld für nenen sinnvoll konstrurierten NIC?
Geht's der Branche so schlecht? ;-)
>cisco isdn-router
Hm, wie passt das nu zur rtl8029 zusammen?
Informatiker ebend? ;-)
>ich hatte nun etwas zeit der sache genauer
>auf den grund zu gehen.
>meine analyse brachte folgende ergebnisse:
>1.: änderung der mtu auf 1492 bei den nic der rechner - keine
>besserung
>2.: aufruf der routerconfigseite über die dsl-ltg (also quasi
>direkt) ist genauso lahm, da ist ausser dem netgear nichts mehr
>dazwischen geschaltet
Emm, dann hat das doch nix mehr mit der DSL leitung tun!
>3: analyse von einem bekannten aus:
>(verschiedene paketgrößen des icmp-pings, oberhalb einer
>bestimmten paket größe geht fast nichts mehr, überschlägig
>über weit über 50% verlust- dabei wird aber die MTU nicht
>überschritten !!):
Wohin hat der gepingt?
Den Router LAN, RouterWAn Router des Providers, "jwd."
>(linux, -s = paketgröße)
><zitat>
>ping -s1277 82.97.157.101 klappt nicht,
Welche Fehlermeldung?
FTR: (da nun nicht jeder weiss was 82.97.157.101 ist.
101.157.97.82.in-addr.arpa. 172800 IN PTR dialer-157-101.kielnet.net.
inetnum: 82.97.144.0 - 82.97.159.255
netname: KIELNET-NET
descr: KIELNET-NET
country: DE
admin-c: ML13630-RIPE
tech-c: ML13630-RIPE
tech-c: TNG2-RIPE
status: ASSIGNED PA
notify: guar...@tng.de
route: 82.97.144.0/20
descr: KielNET-Internet IV
origin: AS25295
notify: hostm...@tng.de
mnt-by: TNG-MNT
mnt-lower: TNG-MNT
mnt-routes: TNG-MNT
role: TNG Hostmaster
address: TNG the net generation GmbH
address: Projensdorfer Strasse 324
address: 24106 Kiel
>aber ping -s1276 82.97.157.101 klappt,
>wenn auch mit Paketverlusten.
>Ein ping -s1 277 217.70.201.1 (---> 217.70.201.1 stellt die
>übergabe zw. kielnet und dem dsl aus meiner sicht her)
>klappt ohne Problemer; da gehen auch größere Werte (hab -s1500
>getestet).
>Zeitweilig gab es auch bei einem schlichten ping 82.97.157.101
>massive Paketverluste.
>Ein traceroute liefert sowas:
>traceroute to 82.97.157.101 (82.97.157.101), 30 hops max, 40 byte
>packets
> 1 halut.solar-empire.de (192.168.242.2) 2 ms 1 ms 1 ms
> 2 cisco.solar-empire.de (192.168.241.1) 7 ms 7 ms 7 ms
> 3 * * *
~~~~~ Warum antwortet das Teil nicht?
> 4 hmb-145-253-17-33.arcor-ip.net (145.253.17.33) 36 ms 43 ms 36 ms
> 5 hmb-145-254-10-45.arcor-ip.net (145.254.10.45) 37 ms 36 ms 37 ms
> 6 mue-145-254-16-90.arcor-ip.net (145.254.16.90) 51 ms 51 ms 52 ms
> 7 INXS.MUXS-1-eth000.de.lambdanet.net (194.59.190.51) 51 ms 51 ms 51 ms
> 8 M-4-eth000-101.de.lambdanet.net (217.71.105.85) 50 ms 49 ms 49 ms
> 9 S-3-atm010-732.de.lambdanet.net (217.71.105.121) 51 ms 56 ms 50 ms
>10 F-4-atm130-733.de.lambdanet.net (217.71.105.5) 52 ms 52 ms 53 ms
>11 DUS-2-pos000.de.lambdanet.net (217.71.105.29) 55 ms 54 ms 53 ms
>12 HH-4-pos110.de.lambdanet.net (217.71.105.70) 65 ms 64 ms 65 ms
>13 KielNet-KI.de.lambdanet.net (217.71.111.82) 65 ms 67 ms 66 ms
>14 * * *
>15 * * *
Ja und?
Wenn Du Deinem Router gesagt hast: "Bitte keine Pings beantworten"
ist das doch ganz Ok, resp. eine Nullaussage.
Heute sieht das aber so aus:
KielNet-KI.de.lambdanet.net (217.71.111.82)
traceroute to 217.71.111.82 (217.71.111.82), 30 hops max, 40 byte packets
1 fe0-0r0.ffm1.de.carpe.net (212.96.130.129) 1.344 ms 1.095 ms 1.053 ms
2 w1-0r0.ffm0.de.carpe.net (212.96.129.5) 2.984 ms 4.25 ms 3.157 ms
3 ge-3-1-0-4.fra20.ip.tiscali.net (213.200.64.37) 3.213 ms 3.177 ms 3.056 ms
4 so-0-0-2.fra10.ip.tiscali.net (213.200.81.213) 3.119 ms 3.283 ms 3.184 ms
5 DE-CIX1.F-8-eth130.de.lambdanet.net (80.81.192.74) 3.263 ms 3.263 ms 3.363 ms
6 F-2-eth320-0.de.lambdanet.net (217.71.105.109) 3.533 ms 3.607 ms 3.473 ms
7 H-7-pos000.de.lambdanet.net (217.71.105.93) 10.894 ms 10.946 ms 10.823 ms
8 HH-4-pos010.de.lambdanet.net (217.71.105.34) 16.524 ms 15.131 ms 15.259 ms
9 * * *
10 * * *
Unschön das das Teil nun überhaupt nicht mehr antwortet.
>Achja, als ich bei mir die MTU auf 1200 gestzt hatte, konnte ich
>auf den Webserver zugreifen, aber nur mit großen Latenzzeiten und
>laaaangsaaam.
>wir haben da noch mehr probiert, was aber letztendlich immer
>darauf hinauslief, das irgendwo pakete verloren gehen, die
>latenz-zeiten extrem hoch sind.
Hm...Leitung überlastet?
>4.: wie bereits mitgeteilt habe ich 2 d-link modems durch, welche
>mich zu dem netgeargerät brachten, ich glaube ja nun nicht das
>alle defekt waren.
Das ist wahr.
Allerdings gibt es auf der Webpage von kielnet einen Hinweis, das
nun endlich das Vigor mit den Kielnet leitungen zusammenarbeiten.
>5.: während eines laufenden ftp-download (210 mb) mehrfacher
>verbindungszusammenbruch des dsl-carriers, neuconnect.
>innerhalb von 10 min bis zu 7 mal
>(wenn es lief kamen aber im schnitt 180 kb /s (spitze 225) )
>dies gilt nicht nur für ftp-downloads, das grundlose kappen der
>ltg.passiert auch so
>wenn ich mir das alles so durchdenke, funktioniert die ltg
>eigentlich seit beginn nicht richtig.
Das kann natürlich sein, da ADSL doch recht nah an die physikalischen
Grenzen geht.
>es viel halt eben nicht weiter auf, bis eben zu den punkten,
>das der webserver nicht richtig ansprechbar gewesen ist (was ich
>aber zuerst auf patch
>und config probs zurückführte - der server ist seit dem 19.08.
>durchgepatch, und funktionierte via isdn und im lan einwandfrei),
>und der tatsache das sich e-mails mit anhang nicht verschicken
>ließen.
>weiterhin ist es auch so, das dns-auflösungen im vehältnis lange
>brauchen über die dsl-ltg.
>ist es zum testen der verbindung evtl. möglich einen
>entsprechende cisco oder bintec leihweise zur verfügung gestellt
>zu bekommen ?
>so, das ist der sachstand
Hm, Kielnet soll mal die Leitung ausmssen...
Aber vorher bitte die Realtec-Schrott(*) gegen Intel oder 3com tauschen.
(*)
Wobei Reatltec nicht perse schlecht sein muss, nur leider
korrelieren billige Chips auch mit schlechter Fertigung,
und da der Hersteller eher selten auf den Billig-Karte steht
würde ich sie nicht einbauen.
Bei Interesse suche ich einen Artikel raus in dem rel.
gut beschrieben wird, warum man kein Realtec haben will.
Achso:
Es gab auch mal Karten/Treiber, die ihre MAC vergessen haben...
Joerg Freund
danke für den tip
Michael Roche wrote:
>
>
> Mach doch mal ein Online-Check Deiner Parameter, dann weißt Du
> wie du rausgehst.
>
> T-DSL 2000 ist bei mir so z.B. optimal eingestellt.
>
>
*****************************************************************
******
> TCP options string = 020405ac0103030201010402
snip
Link:
>
> http://www.speedguide.net/analyzer.php
danke für den link
poste dann das ergebnis
mfg
jörg
Joerg Freund
Joerg Freund wrote:
>> Naja, evtl. haben auch andere so ein Problem und sie
>> interessiert,
>> wie man den Fehler einkreisen kann?
>
> gibt einen im ort wie gesagt, der kann auch
> keine email mit anhang
^^^^^^^^^^^^^^^^^^
> via smtp (windows denke ich mit outlook (express) verschicken,
> geht bei mir
> auch nicht. ich weiß aber noch nicht wer das ist um mich
> mal mit ihm zu unterhalten
>
mfg
Jörg
Stephan Hellwig
Andreas Maier schrieb hier:
> @Spott,
>
> was du sagst ja schon lange da du eh von dem Thema null Ahnung hast.
> Aber das du überall ruim laberst liegt wohl daran das du nur zu ahuse
> hockst? MAch aml was Produktives, soll ich dir ein paar Beispiele nennen
> oder es dir zeigen?
Du meinst, er könnte Dir vielleicht deutsche Grammatik und Rechtschreibung
beibringen - und Dir gleichzeitig Dein erbärmliches ToFu abgewöhnen?
Steven
--
"Laß das, ich möchte jetzt deprimiert sein!"
[Sandra Bullock in "Speed 2"]
Stephan Hellwig
Ralf Hasse schrieb hier:
> > Und das was ich hier sage ist sicherlich kein ToFu.
>
> Kein Grund zur Veranlassung. Bjoern bezog sich nicht auf den Inhalt
> Deines Postings, sondern auf den Umstand, daß Du den Vorredner
> komplett zitierst und das auch noch unten dranhängst: "Topquote oben,
> Fullquote unten" = ToFu.
Nicht eher "Text oben, Fullquote unten"? :-)
BTW: Was soll denn eigentlich ein "Topquote" sein?
Ralf Hasse
> Nicht eher "Text oben, Fullquote unten"? :-)
Mist, ich wußte, irgendwer würde es schon merken
:-)
Rainer Zocholl
>HAllo Rainer
>Rainer Zocholl wrote:
>mhh, zyxel baut doch gute geräte
Ja. Aber was nutzt es, wenn die Anleitung unbrauchbar gemacht worden ist?
>> zu lang (Papier ist teuer!) und hat ein paar -wesentliche-
>> Kapitel einfach weggelassen, auf die sich nachfolgende ständig bezogen.
>> Als wir das Handbuch vom Zyxel daneben legten, war klar, das
>> das Problem nicht zwischen Tastatur und Stuhl an diesem Ende
>> sass...
>ohne, wie bekomme ich raus ohne das ding aufzuschrauben, was
>in meinem netgear drin ist ... (überlegt und hat ne idee....)
Naja, das war nur ein Beispiel.
Das Wissen, das Dein Netgear router z.B. Zyxel Hardware ist hilft
evtl. weiter, da Google evtl. bessere Treffer liefert.
Das das Teil, das ich beschrieb, ein Zyxelteil war,
kam durch eine Usenetsuche zum Vorschein.
>>> rtl8139c nic
>>
>> Argl...realtec... ;-(
>>
>die smc ist mir leider durchgegangen
Wie?
>>> 2.: aufruf der routerconfigseite über die dsl-ltg (also quasi
>>> direkt) ist genauso lahm, da ist ausser dem netgear nichts
>mehr
>>> dazwischen geschaltet
>>
>> Emm, dann hat das doch nix mehr mit der DSL leitung tun!
>>
>nach schon, der router hier ist der netgear, integr. modem.
>also bei mir der letzte hop vor internet, von ihm aus der
>der letzte erreichbar bei mir vom i-net aus. bei nat halt eben
>der den man pingen kann normal
>>> 3: analyse von einem bekannten aus:
>>
>>> (verschiedene paketgrößen des icmp-pings, oberhalb einer
>>> bestimmten paket größe geht fast nichts mehr, überschlägig
>>> über weit über 50% verlust- dabei wird aber die MTU nicht
>>> überschritten !!):
>>
>> Wohin hat der gepingt?
>> Den Router LAN, RouterWAn Router des Providers, "jwd."
>>
>meine dsl dialupverb, sprich den netgear
>> FTR: (da nun nicht jeder weiss was 82.97.157.101 ist.
>>
>die dchp vergebene ip meines dsl anschl.,
>also der netgear in diesem moment
>> 101.157.97.82.in-addr.arpa. 172800 IN PTR
>> dialer-157-101.kielnet.net.
>>
>>> (217.71.105.5) 52 ms 52 ms 53 ms 11
>>> DUS-2-pos000.de.lambdanet.net (217.71.105.29) 55 ms 54 ms 53
>>> ms 12 HH-4-pos110.de.lambdanet.net (217.71.105.70) 65 ms 64
>>> ms 65 ms 13 KielNet-KI.de.lambdanet.net (217.71.111.82) 65
>ms
>>> 67 ms 66 ms 14 * * * 15 * * *
>>
>> Wenn Du Deinem Router gesagt hast: "Bitte keine Pings
>> beantworten"
>soll er aber
Und macht er das wirklich?
>> ist das doch ganz Ok, resp. eine Nullaussage.
>>
>> Heute sieht das aber so aus:
>>
>> KielNet-KI.de.lambdanet.net (217.71.111.82)
>>
>> traceroute to 217.71.111.82 (217.71.111.82), 30 hops max, 40
>> DE-CIX1.F-8-eth130.de.lambdanet.net (80.81.192.74) 3.263 ms
>> 3.263 ms 3.363 ms 6 F-2-eth320-0.de.lambdanet.net
>> (217.71.105.109) 3.533 ms 3.607 ms 3.473 ms 7
>> H-7-pos000.de.lambdanet.net (217.71.105.93) 10.894 ms 10.946
>> ms 10.823 ms 8 HH-4-pos010.de.lambdanet.net (217.71.105.34)
>> 16.524 ms 15.131 ms 15.259 ms 9 * * * 10 * * *
>>
>> Unschön das das Teil nun überhaupt nicht mehr antwortet.
>>
>tja eben komplett mit allen daten kriegs ich nicht
Ja, aber nun antwortet ja noch nicht mal mehr der Router vor dir
auf icmp echo requests/unix-traceroutes!
>>> wir haben da noch mehr probiert, was aber letztendlich immer
>>> darauf hinauslief, das irgendwo pakete verloren gehen, die
>>> latenz-zeiten extrem hoch sind.
>>
>> Hm...Leitung überlastet?
>>
>negativ, lief nur ein standard ping von der solariskiste zu
>meinem kumpel,
Nein, nicht deine Leitung, sondern die von Kielnet!
>habe versucht die leitung zu halten
Also eine Bitte:
Wenn Dir weiter geholfen werden soll:
Bitte benutze die Shiftaste an den üblichen Stellen.
Das zu lesen strengt *extrem* an!
>> Das ist wahr.
>> Allerdings gibt es auf der Webpage von kielnet einen Hinweis,
>das
>> nun endlich das Vigor mit den Kielnet leitungen zusammenarbeiten.
>>
>die firma die router etc herstellt wuste ich nicht
>oder wen meinst du?
Nein.
Das Vigor hatte ein Problem mit Kielnet-DSL.
Vielleicht hat Netgear das Problem auch?
Leider steht nicht dabei, welches Problem genau bestand.
>ein managebarer modemrouter mit switch wäre noch
>ne maßnahme.
Wieso?
>aber ich denke eben das die ltg einen weg hat
Also
wenn 3(!) unterschiedliche ADSL-"Modems" nicht gehen,
es "eigentlich" noch nie funktioniert hat,
hat die ADSL Leitung einen an der Marmel.
Das Du alle 3 gleich falsch konfiguriert hast ist allerdings
auch möglich, theoretisch ;-)
>hatte das auch mal kurzfristig mit nem linux router,
>am anfang, und 1 x dlink modem, ging fast garnicht.
>daraufhin einen netgear router ohne modem, an-
>geschlossen an ein ausgetauschtes dlink auch nicht besser
>die 2 dlink haben den geist aufgegeben, total.
>keinen mucks mehr
>daraufhin die dlink zu ich bin doch nicht blöd-markt
>zurückgebracht, mit dem geld und dem netgear zum
>kielnetshop, dort den router gegen den jetzigen gegen
>aufpreis umgetauscht, in der hoffnung das es besser wird.
>auf anraten von den kielnet admins, weil getestet
>in der alten wohnung in kiel hatte ich tdsl mit einem
>linux router (t-modem, t-splitter)
>funzte wie hölle,
Ja. Vorallem sitzt man nicht "wie blöd" vor ner Blackbox!
Ach, eins hab ich noch:
Einmal hatte ich einen ADLS-Router (cisco IIRC) dessen Ethernet-Kabel
war derartig rottig, das es fast denselben effekt hatte wie
bei dir.
Das Kabel war nur ein paar meter lang und sah ganz harmlos aus.
ifconfig zeigte aber reichlich Fehler.
Dabei darf sollten diese ja auf dem Ethernet eher null sein.
Auch das zwischenschalten eines Switches half nicht, nur
ein ordentlich verkabeltes, geschirmtes Cat-5 Kabel zwischen
ADSL-Modem-Router und Linux-(NATTING)-router machte dem Spuk ein ende.
Seltsam ist, das Du Deinen Kiste nicht von aussen anpingen kannst.
Das muss nix mit dem Fehler zu tun haben.
Ich kann mir aber nicht vorstellen, das KielNet Icmp sperrt.
Ganz sicher das die IP stimmt?
Da Du ja noch mit ISDN reinkommst:
Ping dein ADSL doch mal via debug.net an.
>deshalb kann ich die aussage der
>kielnet admins nicht ganz nachvollziehen :
>Linuxrouter machen probleme mit dsl (sinngemäß)
Hae?
Das ist ja wohl eine Dreistigkeit!
Namen geben lassen und Dienstaufsichtbeschwerde schreiben! ;-)
Rainer Zocholl
>On Sun, 22 Aug 2004 20:18:51 +0200, "Joerg Freund" <freu...@gmx.de>
>wrote in kiel.allgemein:
>>> auch nicht. ich weiß aber noch nicht wer das ist um mich
>>> mal mit ihm zu unterhalten
>Mal so ganz kiel.allgemein gefragt, waere der ganze schoene thread
>nicht effektiver in kiel.computer oder kiel.dfue aufgehaengt gewesen?
Ja, eindeutig "dfue". Aber da er schon in kiel.allgemein umfangreich lief...
>Bin zwar kein Infornaliker, aber... :)))
Nunja, es ist aber heilbar.
Joerg Freund
Rainer Zocholl wrote:
> (Joerg Freund) 22.08.04 in /kiel/allgemein:
> Ja. Aber was nutzt es, wenn die Anleitung unbrauchbar gemacht
> worden ist?
da gebe ich Dir ja voll und ganz Recht
snip
>
>
>> ohne, wie bekomme ich raus ohne das ding aufzuschrauben, was
>> in meinem netgear drin ist ... (überlegt und hat ne idee....)
>
> Naja, das war nur ein Beispiel.
> Das Wissen, das Dein Netgear router z.B. Zyxel Hardware ist
hilft
> evtl. weiter, da Google evtl. bessere Treffer liefert.
aha, da werde ich mich mal auf die suche begeben -
meine Idee hat nicht geholfen
>
> Das das Teil, das ich beschrieb, ein Zyxelteil war,
> kam durch eine Usenetsuche zum Vorschein.
DAS werde ich jetzt auch tun
snip
>
>> die smc ist mir leider durchgegangen
>
> Wie?
nunja, wollte eines tages nicht mehr,
ist ein halbes Jahr oder so her, war eh gebraucht.
ich schätze eine Haarriss irgendwo, nach mehr-
maligen Rechnerumbauten. Die passte nicht so richtig
ins Mainboard (mechanisch), war immer
etwas stramm, trotz Kanten vorsichtig abfeilen.....
snip
>>>
>>> Wenn Du Deinem Router gesagt hast: "Bitte keine Pings
>>> beantworten"
>
>> soll er aber
>
> Und macht er das wirklich?
ja, das tut er:
von der toppoint aus:
PING 82.97.148.91 (82.97.148.91) from 195.244.243.2 : 56(84)
bytes of data.
64 bytes from 82.97.148.91: icmp_seq=1 ttl=250 time=59.1 ms
64 bytes from 82.97.148.91: icmp_seq=2 ttl=250 time=71.0 ms
64 bytes from 82.97.148.91: icmp_seq=3 ttl=250 time=59.0 ms
64 bytes from 82.97.148.91: icmp_seq=4 ttl=250 time=59.2 ms
--- 82.97.148.91 ping statistics ---
6 packets transmitted, 4 received, 33% loss, time 5047ms
rtt min/avg/max/mdev = 59.013/62.119/71.021/5.143 ms
Was mir grad auffällt, ohne Last - RJ11-DSL Ltg ist nur
eingesteckt
damit KiNt was zum messen hat, Traffic geht komplett über ISDN -
hielt die Verbindung heute 8 std - OHNE LAST
Bin grad das NetgearLog durchgegangen
Ist da gebastelt worden ?
Mhh, KiNt mietet hier die letzte Meile von der DTAG,
sind die tätlich gewesen/geworden ?
traceroute:
1 sisko (195.244.243.4) 2.185 ms 1.766 ms 2.359 ms
2 brooklyn04-eth1-0.ki.netuse.net (193.98.110.135) 5.597 ms
5.554 ms 5.476 ms
3 magnum01-fet0-0-12.ki.netuse.net (193.98.110.133) 5.265 ms
5.576 ms 5.291 ms
4 magnum03-lob0.f.netuse.net (195.244.255.49) 18.920 ms
18.413 ms 18.945 ms
5 DE-CIX1.F-8-eth130.de.lambdanet.net (80.81.192.74) 27.920 ms
19.153 ms 19.262 ms
6 F-2-eth320-0.de.lambdanet.net (217.71.105.109) 18.681 ms
19.175 ms 32.510 ms
7 H-7-pos000.de.lambdanet.net (217.71.105.93) 19.173 ms
18.964 ms 19.142 ms
8 HH-4-pos010.de.lambdanet.net (217.71.105.34) 19.242 ms
18.695 ms 19.069 ms
9 KielNet-KI.de.lambdanet.net (217.71.111.82) 23.532 ms
22.735 ms 22.567 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
abgebrochen
snip
>>>
>
>> tja eben komplett mit allen daten kriegs ich nicht
>
> Ja, aber nun antwortet ja noch nicht mal mehr der Router vor
dir
> auf icmp echo requests/unix-traceroutes!
auf ping schon wie man oben sehen kann.
ich denke das trace wird bei 217.71.111.82 geschluckt irgendwie,
weiß der Geier
snip
>>> Hm...Leitung überlastet?
>>>
>
>> negativ, lief nur ein standard ping von der solariskiste zu
>> meinem kumpel,
>
> Nein, nicht deine Leitung, sondern die von Kielnet!
die Verbindung von der VmSt aus - die geht doch
meines Wissens zu TNG, da mal nachfragen vielleicht
wissen die ja was...........
aber 217.70.201.1 ist die "Gegenstelle" zum Modem,
da ist/war der Ping-Paketloss extrem hoch, bloß wo
sitzt der genau ?
>
>> habe versucht die leitung zu halten
>
> Also eine Bitte:
> Wenn Dir weiter geholfen werden soll:
> Bitte benutze die Shiftaste an den üblichen Stellen.
> Das zu lesen strengt *extrem* an!
das ist meine antwort auf die rechtsschreibreform -
es im deutschen genauso zu halten wie der englische
sprachraum: alles klein bis auf wenige ausnahmen -
DAS wäre ne Rechtsschreibreform gewesen
:)
Bin manchmal etwas bequem ;)
Ich halte mich ja dran wie man sieht :)
>
>>> Das ist wahr.
>>> Allerdings gibt es auf der Webpage von kielnet einen Hinweis,
>> das
>>> nun endlich das Vigor mit den Kielnet leitungen
>>> zusammenarbeiten.
>>>
>
>> die firma die router etc herstellt wuste ich nicht
>> oder wen meinst du?
>
> Nein.
> Das Vigor hatte ein Problem mit Kielnet-DSL.
> Vielleicht hat Netgear das Problem auch?
> Leider steht nicht dabei, welches Problem genau bestand.
Ach so, da gibt es noch mehr Fabrikte die die Zusammen-
arbeit verweigern.
DEVELO Modemrouter zum Beispiel.
Unter bestimmten Umständen Fritz!Box (Leitungslänge)
Aber deshalb habe ich mir ja auf anraten der Kielnetter
den Netgear gekauft........
>
>> ein managebarer modemrouter mit switch wäre noch
>> ne maßnahme.
>
> Wieso?
Wegen der MTU-Umsetzung.
Sorry, meine managebarer Switch der die MTU
von LAN 1500 auf DSL 1492 umsetzt, BEVOR
es ins DSL geht.
Ist so ein Tip von KielNet Admin.
Allerdings hat es bei allen DSL Anschlüssen die ich bisher
so gemacht habe (alle Modem, Router, NAT mehrere
Rechner) immer ! ohne sowas funktioniert.
>
>> aber ich denke eben das die ltg einen weg hat
>
> Also
> wenn 3(!) unterschiedliche ADSL-"Modems" nicht gehen,
> es "eigentlich" noch nie funktioniert hat,
> hat die ADSL Leitung einen an der Marmel.
>
> Das Du alle 3 gleich falsch konfiguriert hast ist allerdings
> auch möglich, theoretisch ;-)
also bitte :)
Sag ich ja. Aber erklär das mal am Freitag Nachmittag einem
an der Kielnet Störungsannahme bzw den Admins dort.
Aber es ist ja schon Montag......
>
>
>> hatte das auch mal kurzfristig mit nem linux router,
>> am anfang, und 1 x dlink modem, ging fast garnicht.
>> daraufhin einen netgear router ohne modem, an-
>> geschlossen an ein ausgetauschtes dlink auch nicht besser
>
>> die 2 dlink haben den geist aufgegeben, total.
>> keinen mucks mehr
>
>> daraufhin die dlink zu ich bin doch nicht blöd-markt
>> zurückgebracht, mit dem geld und dem netgear zum
>> kielnetshop, dort den router gegen den jetzigen gegen
>> aufpreis umgetauscht, in der hoffnung das es besser wird.
>
>> auf anraten von den kielnet admins, weil getestet
>
>> in der alten wohnung in kiel hatte ich tdsl mit einem
>> linux router (t-modem, t-splitter)
>> funzte wie hölle,
>
> Ja. Vorallem sitzt man nicht "wie blöd" vor ner Blackbox!
Eben ! Dehalb hatte ich mit zu Anfang ja auch nur das
Modem gekauft, weil der Router (Linux) ja da ist.
>
>
> Ach, eins hab ich noch:
> Einmal hatte ich einen ADLS-Router (cisco IIRC) dessen
> Ethernet-Kabel war derartig rottig, das es fast denselben
effekt
> hatte wie
> bei dir.
> Das Kabel war nur ein paar meter lang und sah ganz harmlos aus.
> ifconfig zeigte aber reichlich Fehler.
> Dabei darf sollten diese ja auf dem Ethernet eher null sein.
ethernetseitig ist ja auch alles ok bei mir
> Auch das zwischenschalten eines Switches half nicht, nur
> ein ordentlich verkabeltes, geschirmtes Cat-5 Kabel zwischen
> ADSL-Modem-Router und Linux-(NATTING)-router machte dem Spuk
ein
> ende.
Tja, die LAN Kabel sind ok, der Netgear ist ein Router mit
integr. Modem, also schwerlich zwischen diesen Einheiten
im Gehäuse was zu finden (eher unwahrscheinlich, s.o.)
das Kabel vom Splitter zum Modemeingang (RJ45 -> RJ11)
ist jeweils mit dem Modem Tausch gewechselt worden
noch ein paar Daten:
Dämpfung down/up 38 db 20.5 db
Rauschpegel down/up 14 db 19 db
Messdaten meines Modems
>
>
> Seltsam ist, das Du Deinen Kiste nicht von aussen anpingen
> kannst.
heute ging es- komisch
> Das muss nix mit dem Fehler zu tun haben.
> Ich kann mir aber nicht vorstellen, das KielNet Icmp sperrt.
> Ganz sicher das die IP stimmt?
die stimmte zu dem Zeitpunkt des Testes
> Da Du ja noch mit ISDN reinkommst:
> Ping dein ADSL doch mal via debug.net an.
Ergebnis:
traceroute to 82.97.148.91 (82.97.148.91), 30 hops max, 40 byte
packets
1 fe0-0r0.ffm1.de.carpe.net (212.96.130.129) 1 ms 0.844 ms
0.783 ms
2 w1-0r0.ffm0.de.carpe.net (212.96.129.5) 2.739 ms 2.817 ms
2.697 ms
3 ffm-s2-rou-1071.DE.eurorings.net (134.222.105.205) 2.677 ms
2.66 ms 2.634 ms
4 DE-CIX1.F-8-eth130.de.lambdanet.net (80.81.192.74) 3.042 ms
2.921 ms 2.931 ms
5 F-2-eth320-0.de.lambdanet.net (217.71.105.109) 2.987 ms
3.213 ms 3.057 ms
6 H-7-pos000.de.lambdanet.net (217.71.105.93) 10.623 ms
10.574 ms 10.443 ms
7 HH-4-pos010.de.lambdanet.net (217.71.105.34) 14.824 ms
14.692 ms 14.816 ms
8 KielNet-KI.de.lambdanet.net (217.71.111.82) 18.096 ms
18.637 ms 18.751 ms
es ist wieder bei 217.71.111.82 Schluß, DSL Verbindung steht aber
Ping:
PING 82.97.148.91 (82.97.148.91): 56 data bytes
64 bytes from 82.97.148.91: icmp_seq=0 ttl=246 time=65.0 ms
64 bytes from 82.97.148.91: icmp_seq=1 ttl=246 time=55.7 ms
64 bytes from 82.97.148.91: icmp_seq=2 ttl=246 time=54.2 ms
64 bytes from 82.97.148.91: icmp_seq=3 ttl=246 time=56.5 ms
64 bytes from 82.97.148.91: icmp_seq=4 ttl=246 time=54.7 ms
--- 82.97.148.91 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 54.2/57.2/65.0 ms
Wie gesagt:
Es gibt hier im Ort noch jemand, der auch einen Teil meines Probs
hat. Auch KiNt-DSL, identischer FirewallModemrouter.
>
>
>
>
>> deshalb kann ich die aussage der
>> kielnet admins nicht ganz nachvollziehen :
>> Linuxrouter machen probleme mit dsl (sinngemäß)
>
> Hae?
Ungefähr das habe ich auch gesagt.
> Das ist ja wohl eine Dreistigkeit!
>
> Namen geben lassen und Dienstaufsichtbeschwerde schreiben! ;-)
Namen habe ich, ich will da keinen Anschwärzen,
die sollen ja noch helfen. :)
Ich verlasse mich ja nun auch nicht ausschließlich auf
deren Aussagen.
mfg
Jörg
Joerg Freund
>>
>> http://www.speedguide.net/analyzer.php
>
> danke für den link
>
> poste dann das ergebnis
mom erhalte ich nur nach Wartezeit:
Error retrieving options
Ltg steht
mfg
Jörg
Joerg Freund
Joerg Freund wrote:
snip
> 13 * * *
> 14 * * *
> 15 * * *
> abgebrochen
>
> snip
>
>>>>
>>
>>> tja eben komplett mit allen daten kriegs ich nicht
>>
>> Ja, aber nun antwortet ja noch nicht mal mehr der Router vor
dir
>>
^^^
hat von Dir gelesen anstatt vor
das ist 217.70.201.1
Ping wird ausgeführt für 217.70.201.1 mit 32 Bytes Daten:
Antwort von 217.70.201.1: Bytes=32 Zeit=111ms TTL=119
Antwort von 217.70.201.1: Bytes=32 Zeit=52ms TTL=119
Antwort von 217.70.201.1: Bytes=32 Zeit=1055ms TTL=119
Antwort von 217.70.201.1: Bytes=32 Zeit=667ms TTL=119
Ping-Statistik für 217.70.201.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0%
Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 52ms, Maximum = 1055ms, Mittelwert = 471ms
hatte etwas Last auf der isdn Ltg
>> auf icmp echo requests/unix-traceroutes!
traceroute:
Routenverfolgung zu 217.70.201.1 über maximal 30 Abschnitte
1 <1 ms <1 ms <1 ms fli4l [192.168.241.10]
2 49 ms 30 ms 114 ms telco3.tng.de [213.178.64.17]
3 598 ms 382 ms 732 ms fe0-0-0.kel2.tng.de
[213.178.64.12]
4 477 ms 393 ms 106 ms atm2.fra1.tng.de [213.158.101.91]
5 44 ms 105 ms 39 ms
DE-CIX1.F-8-eth130.de.lambdanet.net [80.81.192.7
4]
6 40 ms 39 ms 40 ms F-2-eth320-0.de.lambdanet.net
[217.71.105.109]
7 731 ms 431 ms 417 ms H-7-pos000.de.lambdanet.net
[217.71.105.93]
8 956 ms 792 ms 240 ms HH-4-pos010.de.lambdanet.net
[217.71.105.34]
9 65 ms 105 ms 80 ms 217.70.201.1
jeweils aus dem tng Netz isdn Dialup
aber wo ist denn die 217.71.111.82 geblieben ?
9 hops, 9 Antworten
217.70.201.1 ist aus meiner Sicht mein 1. host (ip-Adresse)
im Internet von meiner Seite aus, laut Aussage Admin KiNt
wenn ich DSL zu Grund lege
priv. c class - nat (dialup-ip) - 217.70.201.1
sagt Kielnet
Trace von arcor an meinen Router, da tauche die 217.70.201.1
nicht auf
DUS-2-pos000.de.lambdanet.net (217.71.105.29) 55 ms 54 ms 53
>>> ms 12 HH-4-pos110.de.lambdanet.net (217.71.105.70) 65 ms
64
>>> ms 65 ms 13 KielNet-KI.de.lambdanet.net (217.71.111.82) 65
> ms
>>> 67 ms 66 ms 14 * * * 15 * * *
zumindest heute
die 217.710.201.1 sollte dann der 14 oder 15 hop sein oder so ?
aber wieso antwortet er hier nicht, merkwürdig
>
>
> auf ping schon wie man oben sehen kann.
> ich denke das trace wird bei 217.71.111.82 geschluckt
irgendwie,
> weiß der Geier
>
> snip
mfg
Jörg
Joerg Freund
Joerg Freund wrote:
>
> Trace von arcor an meinen Router, da tauche die 217.70.201.1
> nicht auf
>
11 DUS-2-pos000.de.lambdanet.net (217.71.105.29) 55 ms 54 ms 53
12 HH-4-pos110.de.lambdanet.net (217.71.105.70) 65 ms 64 ms 65
ms
13 KielNet-KI.de.lambdanet.net (217.71.111.82) 65 ms 67 ms 66
ms
14 * * *
15 * * *
>
> zumindest heute
nicht von heute, von Tag des TEstes mit meinem Bekannten
Sorry
mfg
Jörg
Bernd Fey
> Hallo Netzgemeinde,
>
> hat jemand von Euch AUCH folgende Probs mit Kielnet DSL :
>...
> Hat da jemand ähnliche Erfahrungen gemacht ?
Bei mir läuft es mit Kielnet einwandfrei, keine Probleme in jeder
Richtung (auch nie gehabt). Up/down Fullspeed, keine
Störungen/Bandbreitenschwankungen/etc.
Joerg Freund
mal ein neuer Zwischenstand:
Die Telekom hat die Leitung in der VSt, und
in dem Kasten an der Strasse gewechselt
(.... "Leitungen getauscht".....)
Bis auf eine Rauschverbesserung im Downstream
hat es nichts gebracht.
Leitung ist von vorne bis hinten
gemessen worden, das ist alles ok.
Kielnet ist etwas ratlos, aber jetzt zumindest
davon überzeugt, das etwas nicht stimmt.
Mal morgen abwarten, da soll sich einer
auf den Port hier Klemmen, und mal
etwas rumtesten.
mfg
Jörg
Bernd Fey
> ...
> Kielnet ist etwas ratlos, aber jetzt zumindest
> davon überzeugt, das etwas nicht stimmt.
Sogar offiziell. :)
"z.Z. gibt es Probleme mit Upload von Dateien, bzw. dem Versand von
E-Mails mit Anhang (> 25kb) im Raum Selent. Wir haben bereits Siemens
zur Problemlösung herangezogen und werden Sie umgehend informieren,
sobald das Problem behoben ist.
Alle anderen Bereiche sind nicht betroffen und funktionieren einwandfrei."
Joerg Freund
erstmal danke an alle, die sich an der Diskussion beteiligt
haben.
Auflösung:
Nachdem ich am Dienstag weitere 2 Std mit KiNt telefoniert habe,
wir noch weitere Dinge getestet haben, schickte KiNt
einen Mitarbeiter los, um in der Vst die Einschübe zu testen.
Herhaus kam folgendes:
(sinngem. E-mail von KiNt)
Alle Einschübe funktionieren nicht,
das Problem ist nicht auf der User-Seite,
sondern ein techn, Prob in der Vst.
Siemens ist informiert,das Prob. wird so schnell
wie möglich behoben.
(E-Mail an mich, 25.08.04 11.00 MESZ)
nun harre ich de Dinge.
mfg
Jörg
Christian Ihlow
Das is ja echt fast so wie bei mir damals.... lach..
> Auflösung:
> Nachdem ich am Dienstag weitere 2 Std mit KiNt telefoniert habe,
> wir noch weitere Dinge getestet haben, schickte KiNt
> einen Mitarbeiter los, um in der Vst die Einschübe zu testen.
Das hat die Telekom bei mir leider damals nich so flott gemacht..
> Herhaus kam folgendes:
> Alle Einschübe funktionieren nicht,
> das Problem ist nicht auf der User-Seite,
> sondern ein techn, Prob in der Vst.
> Siemens ist informiert,das Prob. wird so schnell
> wie möglich behoben.
Das hab ich mir nach den Feherbeschreibungen schon gedacht..
Denn kannste ja bald wieder mit voller kraft durchs NETZ surfen..usw.. :-)
MfG
Christian
Joerg Freund
Christian Ihlow wrote:
> Moin,
> Das is ja echt fast so wie bei mir damals.... lach..
:)
>
>> Auflösung:
>> Nachdem ich am Dienstag weitere 2 Std mit KiNt telefoniert
habe,
>> wir noch weitere Dinge getestet haben, schickte KiNt
>> einen Mitarbeiter los, um in der Vst die Einschübe zu testen.
>
> Das hat die Telekom bei mir leider damals nich so flott
gemacht..
was heißt hier flott, den Ärger hab ich seit dem 1.08.04.........
aber mach das jemanden klar, der davon überzeugt ist,
das alles funzt......
>
>> Herhaus kam folgendes:
>> Alle Einschübe funktionieren nicht,
>> das Problem ist nicht auf der User-Seite,
>> sondern ein techn, Prob in der Vst.
>> Siemens ist informiert,das Prob. wird so schnell
>> wie möglich behoben.
>
> Das hab ich mir nach den Feherbeschreibungen schon gedacht..
naja, ich auch, da der Paketloss eben an einer bestimmten
Stelle auftrat, und nach ca. 16 kb upstream Feierabend
gewesen ist.
Nur hab ich langsam an meinem Wissen gezweifelt,
deshalb Usenet, da ich immer nur gehört habe:
Hier ist alles i.O., liegt am Linuxrouter (deshalb der Netgear),
die MTU und was weiß ich nicht noch alles - aber
steht ja alles im Thread
> Denn kannste ja bald wieder mit voller kraft durchs NETZ
> surfen..usw.. :-)
Hoffe doch bald :)
-------------------
Ich möchte mich nochmal entschuldigen, das es hier in
#kiel.allgemein
gelandet ist.
Ich hatte #kiel.dfue nicht auf der Pfanne....
jetzt schon :)
mfg
Jörg
Bernd Fey
> ...
> , und nach ca. 16 kb upstream Feierabend gewesen ist.
Viiiel mehr ist doch sowieso nicht drin?
~21 kb ist doch das Maximum, oder?
Joerg Freund
Verständnisproblem:
Upstreamgeschw. 192 kbit/s => 24 Kb/s
was ich meinte ist, das nach einer Übertragung von ca. 16 KB
an Daten nix mehr rausgeht.
Dann steht das einfach.
mfg
Jörg
Joerg Freund
KielNet-DSL funzt jetzt in Selent.
Es ist eine falsche Einstellung im DSLAM
gewesen, die den Apparat in der Konfiguration
bei UpstreamTraffic zum Aussteigen gebracht hat.
Siemens hat das zusammen mit
KiNt repariert.
(Aussage Kielnet)
mfg
Jörg