fedora+xdsl@home connection freeze

[nertx]

hi!

ich hab die einwahl mit linux (fedora 1) hinbekommen allerdings nicht mit der anleitung von inode - is nämlich nicht komplett! falls also jemand einen tipp braucht....

aber ich hab ein anderes problem: wenn ich grössere datenmengen downloade dann "friert" die verbindung ein! kann dann nur die verbindung trennen und wieder starten! kennt jemand das problem bzw. eine lösung dafür?

danke für alle tips!

gruss,
nertx

[M@rio]

Aus at.inode:

es gibt in der tat ein problem mit dem üblichen linux pptp client, und
zwar versucht dieser viel zu hartnäckig, "sprünge" in den GRE sequence
numbers auszugleichen. diese sprünge entstehen vor allem bei voller oder
übervoller auslastung der dsl-leitung, da es dann nicht vermieden werden
kann, daß mal ein paar pakete verlorengehen. da sich bei inode xdsl@ der
GRE-tunnel (pptp-tunnel) über die dsl-leitung erstreckt, während beim
telekom adsl der tunnel nur im lokalen lan besteht, kann dieses problem
beim xdsl@ auftreten während es beim telekom adsl nicht auftritt[1]. ein
gepatchter pptp client kann hier unter umständen abhilfe schaffen[2].

lg
richard

[1] das rfc gibt an, daß die sequence numbers nur für "congestion
control" (in verbindung mit den ack-paketen) und "packet reordering"
verwendet werden, keinesfalls aber um den tunnel zu einem "reliable
transport" zu machen, da von keinem der peers verlorengegangene pakete
neu gesendet werden (retransmissions). deswegen halte ich das aktuelle
verhalten des pptp clients (aggressives verwerfen von paketen) für einen
bug. außerdem fungiert GRE als einkapselung für IP, was per definition
ein "unreliable" protokoll ist, deswegen macht es wenig sinn, im
kapselungsprotkoll hier einen level an "reliability" zu erzeugen. aus
diesem grund gibt es in anderen kapselungsprotokollen (z.b. pppoe, l2tp)
keine ähnlichen mechanismen.

[2] ein inoffizieller "quick & dirty" (aber funktionierender) patch
könnte so aussehen: (vorsicht whitespace)

------------8<------------8<------------
--- pptp_gre.c.ori 2004-01-08 12:03:08.000000000 +0100
+++ pptp_gre.c 2004-01-05 10:39:13.000000000 +0100
@@ -366,13 +366,14 @@
return 0;
}
/* check for expected sequence number */
- if ( first || (seq == seq_recv + 1)) { /* wrap-around safe */
+ /* if ( first || (seq == seq_recv + 1)) { */ /* wrap-around safe */
if ( log_level >= 2 )
log("accepting packet %d", seq);
stats.rx_accepted++;
first = 0;
seq_recv = seq;
return callback(cl, buffer + ip_len + headersize, payload_len);
+#if 0
/* out of order, check if the number is too low and discard
thepacket.
* (handle sequence number wrap-around, and try to do it right) */
} else if ( seq < seq_recv + 1 || WRAPPED(seq_recv, seq) ) {
@@ -395,6 +396,7 @@
seq, seq_recv + 1);
stats.rx_overwin++;
}
+#endif
return 0;
}

------------>8------------>8------------

--
Richard Fuchs | Software Development
Fon. 059 999 2000 | Inode GmbH, Büro Graz
Fax. 059 999 6699 | Business Center, Schmiedlstraße 1, 8042 Graz
www.inode.at | Raserei verbindet uns.

[nertx]

danke schonmal!

wenn mir jetzt noch jemand sagen könnte wie ich diesen patch anwende wäre ich wünschlos glücklich

hat jemand einen tip für mich?

thx,
nertx

[nertx]

ok patchen hat geklappt danke!

aber das machts nicht besser - im gegenteil jetzt tritt der "freeze" schon nach wenigen minuten auf...

jemand noch eine idee??

danke,
gruss nertx

[M@rio]

jemand noch eine idee??

Ja selbiger von oben in der selben Newsgroup. Vielleicht solltest du deine Fragen direkt dort (at.inode) stellen.

(replying to self)

Richard Fuchs wrote:

> [2] ein inoffizieller "quick & dirty" (aber funktionierender) patch

aus gegebenem anlass, hier eine upgedatete version des patchs. der
vorige hatte das problem, daß sich die verbindung u.u. trotzdem noch
instabil verhalten hat.

lg
richard
--
Richard Fuchs | Software Development
Fon. 059 999 2000 | Inode GmbH, Büro Graz
Fax. 059 999 6699 | Business Center, Schmiedlstraße 1, 8042 Graz
www.inode.at | Raserei verbindet uns.



--------------------------------------------------------------------------------


--- pptp_gre.c.ori 2004-03-31 13:27:53.000000000 +0200
+++ pptp_gre.c 2004-03-31 13:27:40.000000000 +0200
@@ -342,9 +342,9 @@
u_int32_t ack = (PPTP_GRE_IS_S(ntoh8(header->flags)))?
header->ack:header->seq; /* ack in different place if S = 0 */
ack = ntoh32( ack);
- if (ack > ack_recv) ack_recv = ack;
+ /* if (ack > ack_recv) */ ack_recv = ack;
/* also handle sequence number wrap-around */
- if (WRAPPED(ack,ack_recv)) ack_recv = ack;
+ /* if (WRAPPED(ack,ack_recv)) ack_recv = ack; */
if (ack_recv == stats.pt.seq) {
int rtt = time_now_usecs() - stats.pt.time;
stats.rtt = (stats.rtt + rtt) / 2;
@@ -366,13 +366,14 @@
return 0;
}
/* check for expected sequence number */
- if ( first || (seq == seq_recv + 1)) { /* wrap-around safe */
+ /* if ( first || (seq == seq_recv + 1)) { */ /* wrap-around safe */
if ( log_level >= 2 )
log("accepting packet %d", seq);
stats.rx_accepted++;
first = 0;
seq_recv = seq;
return callback(cl, buffer + ip_len + headersize, payload_len);
+#if 0
/* out of order, check if the number is too low and discard thepacket.
* (handle sequence number wrap-around, and try to do it right) */
} else if ( seq < seq_recv + 1 || WRAPPED(seq_recv, seq) ) {
@@ -395,6 +396,7 @@
seq, seq_recv + 1);
stats.rx_overwin++;
}
+#endif
return 0;
}

[severnaya]

Unter Linux und Breitbandverbindungen ist das Beste sich einen Router zu kaufen.

[lordpeng]

>Unter Linux und Breitbandverbindungen ist das Beste sich einen Router zu kaufen

nur wenn mans ned anders gebacken kriegt ...

just my 2 cents