inode xdsl: routing problem nach ppp aufbau

Das Forum fĂĽr den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!
Forumsregeln
Das Forum fĂĽr den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!

RE: routing problem - wieder korrektur

Beitragvon Morkeleb » Mo 10 Feb, 2003 16:42

Nach weiteren gesprächen und testen mit Roland entfernten wir fehler in meinen instruktionen.
Nun mache ich es so:

route -n
route del default gw <destination ip von eth0>
ifconfig eth0
route add >broadcast ip von eth0< gw >eigene ip adresse von eth0<
route add 10.0.0.138 gw >eigene ip adresse von eth0<

hier wird angenommen daĂź eth0 die netzwerkverbindung zum inode modem darstellt.

Erfahrungen von xDSL@home 256/128
In Hardware verwendet das modem trotzdem 768kbit transferrate (kann das aber nicht "beweisen", upload geschwindigkeit unbekannt) die dann aber auf schlechte weise per software auf 25-32 kb/s heruntergeregelt werden. Dies vermutlich verursacht eine sehr instabile verbindung (variable schlechte (subjektive) response zeiten, sehr variable und ungenĂĽgende transferraten die vorallem im upload sehr schwach sind.
Des weiteren fällt dieses problem bei windows viel weniger ins gewicht als bei linux, vermutlich weil die netzwerk implementierung recht verschieden ist intern (das sollte sich aber nicht bemerkbar machen). Unter linux sind so die transfer raten noch viel schlechter, meist unter 10kb/s.
Unter umständen kann es aber auch an einem unzureichenden ausbau des verbindungsknotens bei mir liegen. Jedenfalls deckt es sich aber mit den Erfahrungen von Robert (http://www.ADSL.at/forum/read.php?f=3&i=30049&t=29823).

Ich hoffe daß dies bei einem upgrate auf 768/256 wegfällt.
Hier muĂź ich Inode also klar kritisieren, es ist da aber wohl nichts zu machen.

Morkeleb
Morkeleb
 

RE: routing problem - wieder korrektur

Beitragvon Werner » Mo 10 Feb, 2003 18:58

<HTML>Das Problem ist leider schon ziemlich alt (es wächst bereits ein Bart) aber die Lösung stimmt und das was auf der INode Homepage steht leider nicht. Die Lösungen (es waren ja 2) die hier gepostet wurden dürften alle hinkommen ich hab nur den route -n und dann die defaultroute löschen trick benutzt und fahr damit eigentlich seit 2 monaten ganz gut.

Ich denke es wird Zeit dass ich meine Scripte endlich fertigstell und dann ins Netz stelle, ich schau dass ich das heut noch erledig dann sollte das ganze automatisiert sein wenn pptp ordentlich installiert ist.
Mich freuts nur nicht da eine eigene Homepage aufzumachen kann ich die Scripte irgendwem schicken der sie dann einfach online stellt?

Zur INode speed, der download sollte nicht so lahm sein, ich hab hier einen 768/128 Anschluss der noch nicht auf 256 geuppt wurde, ich erreich seitdem der Bone in Linz endlich aufgebohrt wurde, trotzde relativ komplexen IPTable IPStack pro Verbindung um die 40-50KByte/sec. maximal etwa 75 derzeit, was durch den schlechten upload (trotz 128 etwa 9KByte/sec anstatt 16) erklärt werden kann. Ich denke also nicht dass das mit den 10Kbyte/sec bei einer 256/128er Leitung normal ist, normal war das bei mir eigentlich nur bis vor 3-4 Tagen als der Bone von Linz nach Wien endlich die versprochene Erweiterung erhalten hat, seitdem gehts wieder wie geschmiert. Auch die Ping Zeiten sind ganz ok und ich denke nicht dass die Softwaredrosselung er Modems das Problem ist, die Modems sind so oder so gedrosselt wenn man weiss was bei ADSL möglich ist.

ping www.heise.de
PING www.heise.de (193.99.144.71): 56 octets data
64 octets from 193.99.144.71: icmp_seq=0 ttl=249 time=62.1 ms
64 octets from 193.99.144.71: icmp_seq=1 ttl=249 time=62.8 ms
64 octets from 193.99.144.71: icmp_seq=2 ttl=249 time=63.3 ms
64 octets from 193.99.144.71: icmp_seq=3 ttl=249 time=57.7 ms
64 octets from 193.99.144.71: icmp_seq=4 ttl=249 time=57.7 ms
64 octets from 193.99.144.71: icmp_seq=5 ttl=249 time=57.3 ms
64 octets from 193.99.144.71: icmp_seq=6 ttl=249 time=62.4 ms

ping www.inode.at
PING www.inode.at (195.58.160.3): 56 octets data
64 octets from 195.58.160.3: icmp_seq=0 ttl=253 time=50.3 ms
64 octets from 195.58.160.3: icmp_seq=1 ttl=253 time=57.2 ms
64 octets from 195.58.160.3: icmp_seq=2 ttl=253 time=43.7 ms
64 octets from 195.58.160.3: icmp_seq=3 ttl=253 time=48.4 ms
64 octets from 195.58.160.3: icmp_seq=4 ttl=253 time=44.1 ms

hierzu muss man sagen dass mein relativ aufwendiger iptables stack doch einiges kostet


ping www.gentoo.org
PING www.gentoo.org (216.110.80.169): 56 octets data
64 octets from 216.110.80.169: icmp_seq=0 ttl=44 time=209.9 ms
64 octets from 216.110.80.169: icmp_seq=1 ttl=44 time=194.4 ms
64 octets from 216.110.80.169: icmp_seq=2 ttl=44 time=236.3 ms
64 octets from 216.110.80.169: icmp_seq=3 ttl=44 time=200.3 ms
64 octets from 216.110.80.169: icmp_seq=4 ttl=44 time=224.0 ms
64 octets from 216.110.80.169: icmp_seq=5 ttl=44 time=200.2 ms
64 octets from 216.110.80.169: icmp_seq=6 ttl=44 time=221.7 ms


Also auch von den Ping Zeiten her relativ konstante Werte, mit einem gelegentlichen Schluckauf.

Auch noch ein transfer ergebnis von einem niederländischen ftp server:

wget ftp://ftp.snt.utwente.nl/pub/os/linux/g ... 20.tar.bz2
--18:49:40-- ftp://ftp.snt.utwente.nl/pub/os/linux/g ... 20.tar.bz2
=> `portage-20030120.tar.bz2'
Resolving ftp.snt.utwente.nl... done.
Connecting to ftp.snt.utwente.nl[130.89.175.1]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/os/linux/gentoo/snapshots ... done.
==> PORT ... done. ==> RETR portage-20030120.tar.bz2 ... done.
Length: 7,192,496 (unauthoritative)

100%[====================================>] 7,192,496 28.54K/s ETA 00:00

18:53:48 (28.54 KB/s) - `portage-20030120.tar.bz2' saved [7192496]

Ist relativ lahm verglichen zu dem was ich seit dem backbone update sonst meist bekomme (ich krebse pro Berbindung im regelfall um die 40-50kbyte/sec rum und maxe bei 72-75 aus derzeit) es ist aber derzeit hochlastzeit wegen dem frĂĽhen Abend und ich weiss nicht inwieweit der ftp server der in Holland steht grad dicht ist (online updates diverser Distros).

Aber ich geb zu solche speed hab ich erst seit ein paar Tagen, davor gings mir genauso wie dem Vorposter.
</HTML>
Werner
 

RE: routing problem - wieder korrektur

Beitragvon Penderiko » Mo 10 Feb, 2003 23:12

Jo danke, so funkts. spitzenanleitung Morkeleb !!

solltest dich bei der inode support hotline bewerben ;)
roland, auch dir ein grosses DANKE!!!

cya
Penderiko

ps: von dem ping bin ich auch mächtig enttäuscht. aber kein wunder, ich hab bis zu meinem zyxel modem schon einen ping von 30ms.

den selben ping hatte ich bei chello, allerdings zu meinen favorite cs-servers :((
das ist echt hart - ich hoffe das bessert sich noch
Penderiko
 

RE: routing problem - wieder korrektur

Beitragvon Walter » Di 11 Feb, 2003 11:30

Hallo allerseits!
Ich verfolge nun seit einigen Tagen aufmerksam diese Unterhaltung.
Versuche seit Wochen eine xDSL inode Verbindung mit suse 8.1 hinzubekommen. Ich bedanke mich fĂĽr die heiĂźen Tipps.
Wäre noch sehr dankbar für einen Link mit einem funktionierenden pptp-Client.
cya
Walter
Walter
 

RE: routing problem - wieder korrektur

Beitragvon Roland » Di 11 Feb, 2003 11:39

Hallo

Als pptp Client kannst du den neuesten von http://pptpclient.sourceforge.net/ herunterladen. Version 1.1.0 ist im Moment der aktuellste. Die Microsoft Chap Erweiterungen brauchst du nicht.

Roland
Roland
 

RE: routing problem - wieder korrektur

Beitragvon Werner » Fr 14 Feb, 2003 00:07

Das mit dem Script auf einen Server legen hat sich erübrigt ich hab einen Trick gefunden wie man nichtmal den defaultroute merken muss, damit ist mein script mit regular expressions und default server merken hinfällig.
Folgene Befehlssequenz sollte gehen:

#!/bin/sh
route del default #loeschen der default route

#folgendes Kommando stellt die Verbindung zum Einwahlserver her
route add -host 10.0.0.138 eth0
#nun das installierte PPtP anstarten
pptp-command start

oder kurz als eingabe kommandosequenz:

route del default
route add -host 10.0.0.138 eth0
pptp-command start

ist viel kĂĽrzer und relativ angenehm. Viel Spass :-)
Werner
 

RE: routing problem - wieder korrektur

Beitragvon Walter » Mo 17 Feb, 2003 18:00

Hallo Werner!

Die kommandosequenz klappt bei mir immer noch nicht.
Ich schicke dir mal meine ifconfig ausgabe und die rout tabelle.
Die verbindung geht bei mir über eth1. Ich denke da sind einträge zuviel. Aber welche?
GruĂź Walter

walterspc:/home/walter # ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:A0:CC:60:C4:7C
inet Adresse:192.168.0.1 Bcast:192.168.0.255 Maske:255.255.255.0
inet6 Adresse: fe80::2a0:ccff:fe60:c47c/10 GĂĽltigkeitsbereich:Verbindu
ng
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:0 (0.0 b) TX bytes:288 (288.0 b)
Interrupt:9 Basisadresse:0xe800

eth1 Protokoll:Ethernet Hardware Adresse 00:40:F4:34:91:C2
inet Adresse:172.16.254.205 Bcast:172.16.254.255 Maske:255.255.255.0
inet6 Adresse: fe80::240:f4ff:fe34:91c2/10 GĂĽltigkeitsbereich:Verbindu ng
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1604 errors:0 dropped:0 overruns:0 frame:0
TX packets:1383 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:243080 (237.3 Kb) TX bytes:104554 (102.1 Kb)
Interrupt:5 Basisadresse:0x8800

lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 GĂĽltigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:210 errors:0 dropped:0 overruns:0 frame:0
TX packets:210 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:13620 (13.3 Kb) TX bytes:13620 (13.3 Kb)

walterspc:/home/walter # pptp-command start
All routes added.
Tunnel my-first is active on ppp0. IP Address: 62.99.150.214
Installed /etc/resolv.conf.pptp as /etc/resolv.conf
walterspc:/home/walter # ifconfig ppp0
ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:62.99.150.214 P-z-P:62.99.171.14 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1000 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:282 (282.0 b) TX bytes:52 (52.0 b)

walterspc:/home/walter # route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
62.99.171.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
172.16.254.255 172.16.254.205 255.255.255.255 UGH 0 0 0 eth1
10.0.0.138 172.16.254.205 255.255.255.255 UGH 0 0 0 eth1
10.0.0.138 172.16.254.1 255.255.255.255 UGH 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.16.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 172.16.254.1 0.0.0.0 UG 0 0 0 eth1
walterspc:/home/walter #
Walter
 

RE: routing problem - wieder korrektur

Beitragvon Werner » Di 18 Feb, 2003 19:24

Ja, das Problem ist eth1, denke ich, ich kanns jetzt nicht verifizieren, aber ich denk du musst

route del default eth1
route add -host 10.0.0.138 eth1
pptp-command start

sollte gehen

Probiers einfach mal, kann nicht viel schiefgehen
Werner
 

Vorherige

ZurĂĽck zu LINUX & UNIX-DERIVATE

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 34 Gäste