Tele2: Absichtlicher Verbindungsabbruch bei Vollast?

[Master One]

Tele2 Complete Max, ATM Verbindung 1a mit Bandbreite 15996/999, Vood manuell als Bridge konfiguriert.

Auf meinem Firewall-Gateway-Rechner, der auch die PPPoE Verbindung verwaltet, läuft Linux mit ausgetüfteltem TrafficShaping, eine Maschine im LAN dient als BT-P2P-Client.

Mit diesem Setup erreicht der BT-P2P-Client unter Vollast eine durchgehende Download-Rate von 1.1 - 1.2 MB/s, mit Spitzen bis 1.7 MB/s.

Nun aber wird andauernd in unterschiedlich kurzen Zeitintervallen (kann von wenigen Minuten, bis etwas unter einer Stunde liegen) vom AccessConcetrator einfach ohne weitere Fehlermeldung die Verbindung gekappt:

Mar 19 10:11:24 mastergate pppd[27868]: rcvd [LCP TermReq id=0x1]
Mar 19 10:11:24 mastergate pppd[27868]: LCP terminated by peer
Mar 19 10:11:24 mastergate pppd[27868]: Connect time 25.4 minutes.
Mar 19 10:11:24 mastergate pppd[27868]: Sent 128156132 bytes, received 1686991990 bytes.
Mar 19 10:11:24 mastergate pppd[27868]: Script /etc/ppp/ip-down started (pid 6342)
Mar 19 10:11:24 mastergate pppd[27868]: sent [LCP TermAck id=0x1]
Mar 19 10:11:24 mastergate pppd[27868]: Script /etc/ppp/ip-down finished (pid 6342), status = 0x0
Mar 19 10:11:27 mastergate pppd[27868]: Connection terminated.
Mar 19 10:11:27 mastergate pppd[27868]: Modem hangup

Im Anschluß ist eine erneute Einwahl zumeist nicht sogleich möglich:

Mar 19 10:11:57 mastergate pppd[27868]: PADS: Service-Name: ''
Mar 19 10:11:57 mastergate pppd[27868]: PPP session is 6737
Mar 19 10:11:57 mastergate pppd[27868]: using channel 176
Mar 19 10:11:57 mastergate pppd[27868]: Using interface ppp0
Mar 19 10:11:57 mastergate pppd[27868]: Connect: ppp0 <--> eth0
Mar 19 10:11:57 mastergate pppd[27868]: sent [LCP ConfReq id=0x1f <mru 1492> <magic 0x6b209e0a>]
Mar 19 10:12:27 mastergate pppd[27868]: LCP: timeout sending Config-Requests
Mar 19 10:12:27 mastergate pppd[27868]: Connection terminated.
Mar 19 10:12:27 mastergate pppd[27868]: Modem hangup

Diese LCP: timeout sending Config-Requests wiederholen sich dann bei erneuten Einwahlversuchen, beim aktuellen Versuch ziemlich genau 10 Minuten lang, bis endlich wieder eine erfolgreiche Einwahl möglich ist. Dann beginnt das Spielchen nach einer unterschiedliche kurzen Online-Zeit wieder von vorne.

Ich sehe da nur zwei mögliche Ursachen:

- Entweder die Karte im Wählamt, an der ich da am AccessConcentrator dranhänge, ist defekt, und rebootet unter Vollast ständig.

- Oder man wird von Tele2 nach bestimmten Zeitintervallen unter Vollast automatisch gekickt, was doch eigentlich gar nicht sein darf!

Was sagen die Experten dazu? Jutta?

P.S. Eine Suche nach LCP TermReq id=0x1 hat keine schlüssigen Ergebnisse gebracht, diese TermReqs (allerdings mit anderen IDs) kommen offenbar normalerweise nur bei fehlerhaftem Verbindungsaufbau vor, was wiederum auf absichtliches Kappen der Verbindung hinweisen könnte. Ein Support-Ticket bei Tele2 läuft schon, und ein Techniker, der sich das mal ansieht, wird mich wohl irgendwann zurückrufen...

[radditz]

oder aber das System denkt, dass du einen Virus Befall hast, der sehr sehr viele Verbindungen aufbaut und die ganze Bandbreite auslastet.

[Master One]

Also daran habe ich ja noch gar nicht gedacht.

Der BT-Client ist transmission-daemon v1.51, und im Config-File scheint es kein Settings für die maximale Anzahl an Verbindungen zu geben, nur max-peers-global (200), peer-limit-global (240) und peer-limit-per-torrent (60).

Ich denke aber nicht, daß es die Anzahl der Verbindungen ist, denn transmission habe ich jetzt schon ein Jahr lang im Einsatz, und es gab damit nie Probleme. Vormals lief mldonkey mit der Einstellung von maximal 1000 gleichzeitigen Verbindungen ebenfalls problemlos.

Sieht eher aus, als ob es an einem Schwellenwert bei der Ãœbertragungsrate liegt, denn solange der BT-Client mit < 1MB/s werkt, scheint es keine Probleme zu geben.

Dann werde ich wohl erstmal mit netstat die Anzahl der Verbindungen checken.

Bislang hat mich von Tele2 noch keiner zurückgerufen (Problem wurde gestern Nachmittag gemeldet).

[Master One]

Well, es kann nicht an der Anzahl an Verbindungen liegen, diese werden durch das Setting "max-peers-global" auf maximal 200 beschränkt, was auch gerade mit Hilfe eines kleinen selbst geschriebenen Skripts, das mir die aktuelle und maximale Anzahl an ESTABLISHED Connections anzeigt, bestätigt wurde.

D.h. auch bei Vollast mit bis zu 1.7 MB/s im Download bleibt hier die Anzahl an gleichzeitigen Verbindungen bei 200, und der Access Concentrator sollte deshalb wohl kaum eine Gegenmaßnahme ergreifen, oder?

[Stefan Hedenig]

Blöde Frage, aber bleibt die Leitung sync?

[Master One]

Ja, ich werde ja eindeutig vom Access Concentrator gekickt, und das hat nichts mit der Leitung bzw. der ATM Verbindung zu tun, denn andernfalls würde es diesen PPPoE Discovery Fehler beim erneuten Versuch, eine Verbindung aufzubauen, geben.

Der verantwortliche Access Concentrator ist übrigens XLFSOLWF01.net.uta.at = 62.218.4.10

[jutta]

> Ja, ich werde ja eindeutig vom Access Concentrator gekickt,

das koennte ein schlichter timeout sein, weil die leitung dicht ist. tritt es auch auf, wenn du dein traffic-shaping so einrichtest, dass der upload *nicht* ausgelastet wird?

[Master One]

Also bei 1.3 MB/s im Download sieht's hier im Traffic Shaper für den Upload in etwa so aus:

class htb 1:1 root rate 880000bit ceil 880000bit burst 1599b/8 mpu 0b overhead 0b cburst 1599b/8 mpu 0b overhead 0b level 7
Sent 30186823 bytes 563484 pkt (dropped 0, overlimits 0 requeues 0)
rate 752424bit 1689pps backlog 0b 0p requeues 0
lended: 122114 borrowed: 0 giants: 0
tokens: -761 ctokens: -761

Sollte also mit einem Gesamt-Upload von 752 kBit/s nicht wirklich dicht sein, auch habe ich die Upload-Bandbreite im Shaper auf 880 kBit/s beschränkt (tc zeigt die "Rate" zwar seltsamerweise in kbit*1000=bit an, ist aber als 880kbit konfiguriert), was als UL-Total (999 kBit/s) * 0.88 eigentlich eine gute Abstimmung sein sollte.

Kann man irgendwie selbst herausfinden, ob der Upload auf der ATM-Strecke zu irgendeinem Zeitpunkt dicht ist?

Oder ist eine Upload-Beschränkung im Shaper von UL-Total * 0.88 etwa doch zu hoch angesetzt?

Ein Timeout halte ich für eher unwahrscheinlich, denn es scheint bis auf den gezeigten Log-Ausschnitt kein weiterer Fehler auf, und wahrscheinlich gibt es für einen LCP TermReq für diesen Fall eine eigene ID (konnte leider keinen Überblick bzw. keine Erklärung zu den TermReq IDs finden).

Der Tele2 Support zieht sich natürlich wieder, sind schon mehr als 24h seit der Problemmeldung (aber immerhin haben sie die kostenpflichtige Technik-Hotline auf eine normale Wiener Nummer umgestellt).

[Stefan Hedenig]

ich würde ihn mit *0.85 ansetzen, ist in der regel genauer...

[Master One]

Inzwischen habe ich mit einem kleinen Skript die Gesamt-Upload-Rate am Traffic Shaper bis zum aktuellen [LCP TermReq id=0x1] mitprotokolliert, und diese lag zum Zeit des Verbindungsabbruchs bei nur 632776 bit/s (mit einer maximale UL-Rate im Beobachtungszeitraum von gerade mal 749544 bit/s), somit fällt die Möglichkeit mit Timeout bzw. Upload dicht auch flach.

NACHTRAG: Jetzt noch mit zusätzlichen multiplen FTP-Uploads (also zusätzlich zum BT-P2P-Traffic) die Upload-Rate auf ziemlich konstante ~ 869000 bit/s hochgejagt (maximale UL-Rate im Beobachtungszeitraum 870488 bit/s), und mehr als 10 Minuten auf diesem Level gehalten, was aber keinen Einfluß auf das geschilderte Problem hatte, d.h. trotz ziemlich konstanter Ausnutzung der UL-Bandbreite über einen längeren Zeitraum kein Verbindungsabbruch. Der Upload kann also nicht der Grund für diese ominösen Verbindungsabbrüche per [LCP TermReq id=0x1] sein.

[n4p]

Blöde Frage, aber bleibt die Leitung sync?

Hatte ein selbiges Problem, und genau das war die Antwort.
Leitungseinbruch durch zu viele Fehler. Je höher der Datendurchsatz umso schneller geschah es.

Lösung sollte bekannt sein.

Mfg

[Master One]

Also die Leitung ist hier definitiv nicht das Problem (keine 100m vom Wählamt entfernt, Telekom Techniker erst vor 2 Wochen wegen einem anderen Problem die Dose ausgetauscht, bei der Gelegenheit auch gleich das Telefonkabel getauscht, Leitung wurde durchgemessen, Werte 1a, kaum CRC Fehler im Status Menü vom Vood). Dennoch, auch für diesen Fall wäre mir die Lösung nicht bekannt (oder meinst Du damit lediglich, den Tele2 Support zu kontaktieren?), wie sieht die denn aus?

[netzwerkbastler]

also [LCP TermReq id=0x1] schickt auch AON bei der 8h Zwangstrennung. Ist ein ganz normales PPP Komando. (LCP Protokoll in PPP)
Bei AON allerdings mit zufälliger ID.

Ich glaube du hast schon recht. Verschwörung oder DSLAM Karte defekt, könnte ein interner Fehler auf der Karte sein die ein Reboot auslöst. (aber 10min Dauer ist auch etwas lang für ein Reboot...)

[ilovebytes]

hi ich tippe auch eher auf einen fehler des dslams - ich habe die gleiche Geschwindigkeit wie du 15999/999 bei Tele2 bin allerdings etwa 1 km vom Wählamt entfernt.

Bei mir stellt es kein Problem dar mit BT die Leitung auch stundenlang am maximum mit 1,6-1,7 Mbit laufen zu lassen - keine Abbrüche.

Allerdings habe ich das Vood in den Keller verbannt - als modem dient ein simples altes speedtouch 546v6 und die einwahl übernimmt ein wrt54gl mit dd-wrt

maximale Verbindungen beim Torrent sind 2000

das ganze läuft nun 1,5 Jahre ohne Ausfälle (zumindest ich habe keine bemerkt)

LG

[Philipp11]

Habe diese Probleme Gott sei Dank auch nicht. DSL Extreme mit 20/1 und kann stundenlang mit maxspeed runterladen ohne Probleme.

dafür aber Routenverfolgung zu tele2.at [212.152.190.190] über maximal 30 Abschnitte:

1 11 ms 11 ms 11 ms XLFSNBVH01.net.uta.at [62.218.4.126]
2 16 ms 16 ms 16 ms 62.218.9.21
3 16 ms 16 ms 16 ms c76wat1-tenGigE-2-1.net.uta.at [212.152.192.165]

4 16 ms 17 ms 16 ms c65s1-r01.ces.uta.at [62.218.15.94]
5 18 ms 16 ms 17 ms 213.90.1.29
6 16 ms 16 ms 16 ms 213.90.1.123
7 17 ms 17 ms 16 ms www.tele2.at [212.152.190.190]

11ms zum Wählamt das 20 Meter entfernt ist