Speedport an MPD - Eine traurige Geschichte
Der Wechsel einer PPPoX-Plattform bringt vor allem dort Probleme, wo Alt- und Fremdgeräte im Einsatz sind. Besonders unangenehm sind die Speedports der Telekom. Mit Verzicht und Sorgfalt geht es trotzdem.
Als neues LNS soll MPD auf FreeBSD zum Einsatz kommen. Mit den vorgegebenen Fritzboxen tut alles wunderbar. In der Praxis kommen aber verschiedene Kunden nicht mehr vernünftig online.
Speedport W 700V
Das Gerät kann sich meist nicht anmelden. Alle zig Versuche gelingt es trotzdem und dann funktioniert die Anbindung stabil. Was ist da los?
Im LCP Debugging findet sich ein ganz normaler Vorgang:
- Die Vorschläge werden verhandelt, abgelehnt, umformuliert und neu verhandelt.
- Alle Umformulierungen finden Stück für Stück statt. Es wird nur soviel geändert, wie unbedingt nötig.
- Nach drei Verhandlungsrunden sendet der Speedport eine Termination Request. Er legt auf.
- In den seltenen Fällen, in denen es klappt, gelingt die Verständigung in der vierten Runde.
- In diesen Fällen antwortet der Speedport nicht in Runde drei auf die Vorschläge. Stattdessen überspringt er diese Runde.
Der Speedport hat offenbar ein internes Limit auf drei Verhandlungsrunden (nach den ersten Runden mit dem LAC). Gelingt es ihm nicht binnen dieser drei Runden eine PPP Verbindung auszuhandeln, legt er auf. Fritzboxen machen dagegen bis zu zehn Durchläufe.
Die Erklärung liegt darin, daß Paketverluste auf der DSL Leitung dazu führen können, daß der dritte Vorschlag gar nicht beim Speedport ankommt. Dann verarbeitet er den Vorschlag der vierte Runde als dritten Vorschlag.
Daraus ergibt sich als Lösung, die "richtigen"(TM) Vorschläge gleich zu Anfang auszugeben. Es genügt in diesem Fall, die Authentisierungsprotokolle auf PAP einzuschränken. Der MPD schlägt dieses Authentisierungsprotokoll normalerweise als letztes vor, weil es den niedrigsten Sicherheitsgrad auf der Leitung bietet. Der Speedport macht aber nur PAP und durch die notwendigen Extrarunden kommt die Verbindung dann gar nicht mehr zustande.
create link template ... l2tp set link no chap-md5 chap chap-msv1 chap-msv2 eap set link enable pap set link deny pap
Natürlich gibt es da ein neues Problem: Alle Kunden, die bisher ausschließlich CHAP machten, können nun gar nicht mehr arbeiten. Dafür gibt es zwei Ansätze:
- Wenn der Carrier seinem LAC beibringt, die Anschlußkennung zu übertragen, kann der MPD den Stand der letzten fehlgeschlagenen Anmeldung vermerken. Beim nächsten Anmeldeversuch (von diesem Anschluß) beginnt er dann an der Abbruchstelle erneut. Dieses Verfahren ist selbstjustierend und kann eine weite Bandbreite von Parametern aushandeln.
- Wenn der Carrier seinem LAC beibringt, die schon vorab ausgehandelten Parameter zu übertragen, kann der MPD auf diesen Stand aufsetzen und direkt mit den schon ausgehandelten Einstellungen weiter machen.
Beide Varianten wurden von mir schon testweise implementiert, jedoch ist die Versorgung mit den Parametern noch nicht produktiv.
Speedport W 723V Typ A
Das Gerät kann sich sauber anmelden. Es funktioniert allerdings keine eingehende Datenübertragung. Die Daten erreichen den Speedport offenkundig nicht.
Beim Sniffen findet man die ganz normale Kommunikation. Es gehen DNS Anfragen aus, es kommen Antworten zurück. Es gehen HTTP Anfragen aus, es kommen Antworten zurück. Aber es gibt nie mehr als das initiale Paket des Verbindungsaufbaus. Und das wird immer wiederholt. Als ob Paketverlust auftritt.
Im LCP Debugging sieht auch alles gut aus. Jedoch kommt nach einer Weile eine ungewöhnliche Meldung:
LCP: protocol 0x2145 was rejected
Auch hier ist die Erklärung so einfach wie überraschend:
- Beide Seiten handeln PROTOCOMP aus.
- Diese Kompression gestattet es, die normalerweise 16-bit langen Protokollfelder als ein Oktet zu übertragen, wenn diese dort hinein passen.
- IPv4 Payload hat die Protokollkennung 0x0021, was wegen PROTOCOMP als 0x21 kodiert wird.
- Der Speedport liest das Protokoll trotz gegenteiliger Aushandlung immer als zwei Oktets ein.
- Er beschwert sich über das unbekannte Protokoll "0x2145", also das Protokoll 0x21 und das erste Byte des Payloads 0x45.
- Der Speedport verwirft die Nutzdaten von IPv4 Paketen.
Die Lösung besteht darin, dieses Protokoll nicht mehr auszuhandeln.
create link template ... l2tp set link no protocomp
Und schon geht's wieder. Trotzdem ist es unschön, auf wünschenswerte Protokolleigenschaften zu verzichten, nur weil ein verschwindend kleiner Anteil an Endgeräten solche katatrophalen Fehler macht.
Auch hier bietet sich an, individuell auf die Kundengeräte einzugehen. Da aber die PROTOCOMP Aushandlung noch vor dem Login erfolgt, geht es auch nur wieder mit Hilfe des Carriers.
- Wenn der Carrier seinem LAC beibringt, die Anschlußkennung oder den Nutzernamen zu übertragen, kann der MPD diesem Anschluß beim nächsten Einwahlversuch PROTOCOMP verbieten.
Für eine Implementation des Verhaltens sind die o.g. Testimplementationen anpaßbar.