Alice Fun Speed (VDSL) ab 02.09.10 verfügbar

[stevve33]

besteht das upload problem bei der 1:1 Übernahme der Daten nun auch auf der 7390 ?

 

[nobox]

http://www.speedtest.net/result/982358809.png

 

[dfroe]

Das Upload-Problem besteht übrigens auch dann, wenn ich in der Alice-Box die ppp-Verbindung via ar7.cfg deaktiviere, und mich per PPPoE Passthrough mit der dahinter liegenden 7570 ins Internet einwähle. Das Upload-Problem in der FritzBox müsste demnach noch tiefer als in der PPP-Schicht liegen. Seltsame Sache.

Die Aussage, dass eine 1:1-Kopie der Konfigurationsdateien funktioniert, klingt jedoch sehr interessant. Ich frage mich nur, warum deine VoIP-Verbindung nicht wegen des anderen User-Agent Strings abgelehnt wird.

Ich hatte bisher nur die vermeintlich relevanten Abschnitte der Konfig-Dateien übertragen. Heute Abend werde ich es dann auch mal mit einer 1:1 Kopie versuchen.

 

[geriom]

Hi,
wegen dem Upload Problem: Habe die 7570 auch nur als Modem vor einer 7170. Normales Portforwarding von einem FTP Server bringt bei mir auch nur 470kB/s. Durch einen VPN Tunnel schafft die selbe Anordnung 970kB/s. Irgendwie scheinen die verpackten Pakete von der Limitierung ausgenommen zu werden.

 

[Novize]

Das glaube ich nicht.
Entweder werden alle Datenpakete limitiert/ausgebremst oder keines. VPN-Pakete zu priorisieren halte ich für ein Gerücht.
Versuche Dich einmal an diesem Thema: Howto: Geschwindigkeitsprobleme ins Internet

 

[dfroe]

Das einzige, was ich mir noch vorstellen könnte, wäre dass die Priorisierung, Limitierung (oder was auch immer es sein sollte) nur auf TCP Verbindungen zutrifft. VPN wird in der Regel ja eher über UDP getunnelt.

 

[geriom]

Es ist aber so.
Die Tests führe ich mit einem Linux-Server auf der gegenüberliegenden Seite durch. Die Werte entnehme ich dem MidnightCommander.
1. Verbindung über lokale Adresse == 970kB/s
2. Verbindung über Dyndns direkt == 470kB/s

Tests habe ich jetzt mehrfach wiederholt.

P.S. Werde morgen oder übermogen mal den VPN Tunnel über TCP aufbauen.

 

[nobox]

Die Aussage, dass eine 1:1-Kopie der Konfigurationsdateien funktioniert, klingt jedoch sehr interessant. Ich frage mich nur, warum deine VoIP-Verbindung nicht wegen des anderen User-Agent Strings abgelehnt wird.

Wo setzt man denn den User-Agent String ? Achso, schriebst Du ja oben schon, gar nicht.

Kurz rekapituliert: Deine Versuche mit dem UAS waren aber über die originale Internetverbindung und nicht über die 2. PVC ? Vielleicht interessiert der UAS bei Nutzung der 2.PVC nicht ?

 

[dfroe]

Wo setzt man denn den User-Agent String?

Das ist das Problem: Gar nirgends. Der 'voipd' generiert den User-Agent String irgendwie dynamisch. Meine Vermutung ist, dass vorallem die Umgebungsvariable $CONFIG_PRODUKT_NAME in den User-Agent String mit einfließt. Ich werde eine Manipulation dieser Variable heute Abend testen.

Kurz rekapituliert: Deine Versuche mit dem UAS waren aber über die originale Internetverbindung und nicht über die 2. PVC?

Das ist korrekt. Weil ich die 2. PVC nicht zum Laufen gebracht habe (durch Kopieren der entsprechenden Abschnitte in der ar7.cfg). Ich werde es heute Abend aber wie gesagt mit einer 1:1 Kopie der ar7.cfg testen. Das sollte mit der 2. PVC dann schon irgendwie hinzukriegen sein.

Den User-Agent String hatte ich zu meinen Testzwecken mit Hilfe eines Asterisks geändert.

 

[nobox]

Einen schönen Versuch fände ich auch, in einer 2ten per passthrough angebundenen box die 2. PVC als erste zu registrieren.

 

[dfroe]

Einen schönen Versuch fände ich auch, in einer 2ten per passthrough angebundenen box die 2. PVC als erste zu registrieren.

Das wäre auch eine Idee. Allerdings müssten die beiden PVCs ja mit unterschiedlichen VLANs nach außen gehen. Eine für die reguläre 1. PVC und die andere für die 2. VoIP PVC.
In der Alice-Box (DSL-Modem) kann ich aber nur eine VLAN-Config angeben, die auf PPPoE-Passthrough Verbindungen angewendet wird.
Demnach würde dieses Vorhaben wahrscheinlich nicht funktionieren.

Mein Endziel bleibt nach wie vor eine Box (mein Freetz-W920V/7570) - und keine Kaskade aus insgesamt drei FritzBox-Abkömmlingen.

 

[nobox]

Mein Endziel bleibt nach wie vor eine Box (mein Freetz-W920V/7570) - und keine Kaskade aus insgesamt drei FritzBox-Abkömmlingen.

Jaja, schon klar - dient ja auch nur der Informationssammlung.

Und da fänd ichs schon lustig: Internet samt entsprechendem VLAN über die 7570HN, voip über 2.PVC über die Box dahinter - d.h. alice hardware nutzen und trotzdem alle Fritz-möglichkeiten für das VOIP - das wäre eine Konstellation, die die noch nichtmal verbieten können

 

[dfroe]

Hallo,
wie angekündigt hier nun mein Zwischenstand für heute: Es tut nicht.
Ich habe mehrere Stunden alles mögliche probiert, mit Wireshark die Paketmitschnitte sämtlicher PVCs während des SIP-Aufbaus analysiert, es sieht alles ganz gut aus, aber ich bekomme einfach keine Registrierung über meine FritzBox hin. Auch wenn ich ausschließlich die VoIP-PVC mit deren Zugangsdaten und VLAN-Einstellungen als einzige und primäre PVC einrichte, klappt es auch nicht. Es werden brav die Register-Anfragen meiner FritzBox an die private 10er IP-Adresse des Hansenet SIP-Server geschickt, es kommt aber nie ein Antwortpaket zurück. Wenn ich absichtlich falsche Zugangsdaten verwende, bekomme ich prompt einen 401, d.h. grundsätzlich funktioniert die Kommunikation schon. Aber auf meine korrekten SIP Registrierungsanfragen reagiert der Hansenet-Server einfach nicht. Ich habe jedes einzelne Frame auch auf VLAN-Tagging untersucht, es ist alles absolut korrekt gesetzt.

Ich stehe somit wirklich kurz davor, die Sache aufzugeben. Also die Telefonie. Der normale Internetzugang direkt auf der FritzBox eingerichtet läuft wie eine eins. Womöglich wird's dann wohl oder übel doch wieder ein externer SIP-Account für die ausgehende Festnetztelefonie werden, auch wenn's eigentlich vollkommen unnötig ist. Aber die Telefonverbindung analog von der Alice-Box durchzuschleifen funktioniert leider nur äußerst unzuverlässig.

Es wundert mich nur sehr, dass auch eine exakte 1:1 Übertragung der gesamten export-Datei (also mit allen cfg-Dateien) nicht wie gewünscht auf meiner FritzBox funktioniert hat. Es kommen beide PVCs zustande, die Internetleitung ist auch einwandfrei, aber die Telefonie will einfach nicht funktionieren.

Interessant wäre vielleicht für mich ein vergleichbarer Mitschnitt der VoIP-Registrierung der Alice-Box. Damit könnte ich ja Frame für Frame die beiden Szenarien vergleichen, und schauen wo es eventuell noch Unterschiede gibt. Nur leider gibt es die Seite http://<IP>/html/capture.html auf der Alice-Box nicht, so dass ich im Moment nicht wüsste, wie ich einen solchen Paketmitschnitt der originalen Alice-Box bewerkstelligen könnte.

 

[dfroe]

Und weil's so Spaß macht gleich noch ein Nachtrag von mir: Es funktioniert doch.

Im Endeffekt war der Fehler ganz banal, so einfach das man eigentlich gleich hätte drauf kommen können. Trotzdem habe ich es erst heute am Tag 3 per Zufall bemerkt.

Mein Problem bestand darin, dass ich als Zielplattform nicht nur irgendeine einfache FritzBox genommen habe, sondern einen bereits sehr stark personalisierten SpeedPort W920V mit einem Freetz-Image. Das Freetz-Image war auch gar nicht das Problem. Das Problem war ein Quagga OSPF-Daemon, der munter auf dem Freetz gelaufen ist, und der von meinem lokalen Heimnetzwerk eine 10.0.0.0/8 Route empfangen hat, welche natürlich auch ganz brav in die aktive Routingtabelle eingebaut wurde. Dummerweise nutzt ausgerechnet Hansenet in deren VoIP-Backbone auch das gesamte 10er Netz für die PPP-Einwahl, Gateways, DNS-Server, NTP-Server, SIP-Server und RTP-Server. In Richtung 'dsl'-Interface auf der FritzBox ist aber nur eine Defaultroute 0.0.0.0/0 vorhanden. Die ganzen VoIP-Pakete wurden also nie ins Internet geschickt, sondern immer brav in mein Heimnetzwerk. Kein Wunder, dass es da immer zu einem Timeout gekommen ist.

Jedenfalls habe ich durch meine intensiven Experimente auch einige Eigenheiten der Hansenet-Anschlüsse kennengelernt.
So ist zum Betrieb der VoIP-Telefonie die 2. PVC unbedingt zwingend notwendig. Es funktioniert nämlich nur, wenn der ganze VoIP-Traffic für Hansenet komplett in deren privaten 10er IP-Netz abgewickelt wird.
Hansenet verwendet verschiedene Hostnamen, z.B. registrarXX.sip.alice-dsl.de für die SIP-Anmweldung, oder auch time.sip.alice-dsl.de als NTP-Server. Diese ganzen Hostnamen lassen sich auch aus dem öffentlichen Internet heraus per DNS auflösen. Man erhält eine öffentliche IP-Adresse des Servers, und man findet dort auch tatsächlich einen SIP-Server vor. Es ist jedoch nicht möglich, darüber ein Telefonat zu führen. Die Verbindung wird mit der Fehlermeldung Forbidden einfach abgelehnt.

Der Witz am 2. PVC ist, dass man bei der Einwahl mit den speziellen Zugangsdaten für den VoIP-PVC IP-Adressen aus einem 10er Adresspool geliefert bekommt. Nicht nur die eigene "WAN"-IP und das PPP-Gateway, sondern auch z.B. die DNS-Server sind spezielle Adressen aus dem 10er Block. Frägt man nun einen Hostnamen wie z.B. registrarXX.sip.alice-dsl.de oder time.sip.alice-dsl.de von genau diesem 10er Nameserver ab, so erhält man - oh Wunder - auf einmal eine ganz andere IP-Adresse zurück. Nämlich auch wieder eine aus dem 10er Netz. Und wenn man sich gegen genau diesen 10er SIP-Server nun registriert, funktioniert die Anmeldung ohne Probleme. Auch sämtliche Telefonate werden anstandslos akzeptiert, auch der gesamte RTP-Traffic fließt innerhalb dieses 10er Netzes. Hansenet hat hier also wirklich ein komplett dediziertes privates IP-Netz für die IP-Telefonie. Wichtig ist daher, dass man das Netz 10.0.0.0/8 nicht auch noch direkt am LAN-Port der FritzBox hängen hat.

Als nächsten Schritt fand ich es ganz interessiert, woher die FritzBox eigentlich weiß, welche Daten sie über den 1. oder 2. PVC zu senden hat. Ich hätte mir gedacht, dass dies einfach mittels verschiedener IP-Routen geregelt ist, die auf verschiedene Interfaces zeigen. Also ein Interface für den 1. PVC und ein weiteres für den 2. VoIP-PVC. Genau so ist es aber nicht. Es gibt in der Routing-Tabelle der Box nur eine einzige Defaultroute, die auf das Interface mit dem Namen 'dsl' zeigt. Es fließen also erst einmal die Daten für alle PVCs in dieses dsl-Interface hinein. Spannend wird es nun, was sich genau hinter diesem 'dsl'-Interface befindet. Das muss irgendeine proprietäre Einrichtung von AVM sein. Dort wird nun aber der ganze Internetverkehr auf die verschiedenen PVCs aufgeteilt. Und zwar anhand des in der ar7.cfg definierten Kriteriums 'tcclassroutes'. Dieses ist innerhalb der Konfiguration für den VoIP-PVC definiert und beinhaltet Schlüsselwörter von Datenklassen, die über diese PVC geleitet werden sollen. Unter anderem eben 'sip', 'sipdns', 'rtp', 'ntp' und 'ntpdns'. Was genau unter diesen Schlüsselwörtern zu verstehen ist, habe ich jedoch nicht herausgefunden. Es hat jedenfalls nichts mit irgendwelchen QoS-Klassen zu tun. Auch ist z.B. 'sip' nicht einfach nur dadurch definiert, dass der UDP-Zielport 5060 ist. Es muss vielmehr irgendeine interne Kennzeichnung sein, so nach dem Motto "SIP-Pakete die vom voipd-Daemon stammen". Denn SIP-Pakete meines Asterisk-Servers, die auch an Zielport 5060 gerichtet sind, werden nicht über den 2. PVC geroutet.

Ganz schön spannend, was da hinter den Kulissen so alles vorgeht. An die so auf meinem SpeedPort eingerichtet Alice-VoIP Verbindung lässt sich mit Hilfe eines "IP-Telefons" dann übrigens auch ganz einfach und so wie ich das wollte ein Asterisk anklemmen, jetzt wo es endlich funktioniert.

Wie sich der User-Agent String des FritzBox-internen 'voipd' anpassen lässt, habe ich übrigens in diesem Thread hier ergänzt:
SIP User-Agent der FritzBox personalisieren

IP-Telefone lassen sich übrigens aber auch auf der originalen Hansenet-Box ankoppeln. Das kastrierte Webinterface gibt es zwar nicht her, die Hard- und Software aber sehr wohl. Es funktioniert wunderbar, die aus der Alice-Box exportierte Konfiguration (mit entschlüsselten Passwörtern) in einer FritzBox 7570 einzuspielen, dort dann über deren Webinterface die gewünschten SIP-Clients anzulegen, die Konfiguration wieder zu exportieren, und anschließend auf der Alice-Box wieder zu importieren. Es reicht hierbei nicht, nur die voip.cfg zu übertragen. Wichtige Einstellungen, wie z.B. die Zuordnung, welches Telefon welche Rufnummer benutzt, stehen in einigen der anderen Binärdateien. Es funktioniert übrigens anstelle der 7570 auch eine ältere 7270 um so die Konfigurationsdatei etwas aufzuwerten. Wer also einfach nur anstelle eines analogen Telefons ein IP-Telefon an die Alice-Box hängen möchte, kann dies auf diesem Umweg tun. Denn eigentlich kann es Hansenet doch auch recht egal sein, was für ein Telefon ich nun konkret an meinem Anschluss in Betrieb habe. Wichtig ist natürlich, dass ich nur eine einzige Leitung habe, das ist klar. Aber dass man grundsätzlich alle Endgeräte außer einem analogen Telefon ausschließt, halte ich irgendwie für eine ziemlich übertriebene Einschränkung.

Dann kann ich mich jetzt ja entspannt zurücklehnen, und meinen neuen VDSL-Anschluss genießen. Mit netto 9 Mbps Upload, und einer Telefonleitung inklusive Festnetzflatrate.

http://www.speedtest.net/result/984382779.png

 

[stevve33]

Danke an Dfroe bei mir funktioniert nun auch alles .... Speedport W920@AVM .76 Firmware

 

[dfroe]

Ich habe heute nochmal mit der Technik-Abteilung der Alice-Hotline telefoniert, in der Hoffnung, einen Mitarbeiter zu erwischen, mit dem man fachkundig über das Upload-Problem der originalen Alice-Boxen reden könnte. Hat leider nicht geklappt.

Seine Aussage war, dass er sehen kann, dass das Modem 10 Mbps freigibt; womit er wohl die Datenrate gemeint hat, mit der sich das DSL-Modem synchronisiert hat. Dass nun mit meiner Alice-Box wie auch bei allen anderen Nutzern im Upload nur ca. 4 Mbps möglich sind, dazu hat er nur gemeint, dass muss ein Problem mit dem PC sein. Die Box gibt 10 Mbps frei, somit hat Hansenet das erfüllt, was vertraglich zugesichert ist, alles weitere ab der Box zum PC sei meine Sache. Toll. Dass der Upload mit einem anderen Modem schneller läuft, hat ihn nicht wirklich interessiert (nur Support für das mitgelieferte DSL-Modem).

Mein zweiter Ansatz war dann, ihn irgendwie kulanterweise darum zu bitten, die DSLAM-Datenrate etwas zu erhöhen, so wie auch damals mein ADSL2+-Profil wegen ausreichender Leitungsreservern etwas höher gesetzt wurde. Darauf nur die pauschale Antwort, dass er das nicht kann. Er würde es ja wollen, aber selbst wenn er es könnte, und er würde die Datenrate erhöhen, so wäre diese "übertaktet" (wortwörtlich), und das wäre dann wie wenn man einen PC übertaktet, sprich die Leitung würde immer wieder ausfallen. Mit meiner Antwort, dass dies nicht stimmen würde, weil die Leitung bei mir (DSLAM nur wenige Meter entfernt) bei der aktuellen Synchronisation immer noch einen SNR von rund 30 dB aufweist, konnte er irgendwie gar nichts anfangen. Natürlich weiß ich, dass ich keinerlei Anspruch darauf habe, und es ausschließlich Kulanz seitens Hansenet wäre, mir bei meiner Leitung einen höheren DSL-Sync. zu gewähren als vertraglich vereinbart. Aber damals bei ADSL ging's ja schließlich auch - und wenn man den Screenshots glauben schenken darf, gibt es durchaus auch Hansenet-User mit einem VDSL-Sync >50 Mbps. Nunja, Schade, dann wird's wohl bei den 10 Mbps bleiben. Immerhin kommen mit dem Speedport wenigstens die in vollem Umfang auch an.

Für die Nutzer der originalen Hansenet-FritzBox scheint es derzeit aber keine guten Aussichten zu geben, dass das Upload-Problem seitens Hansenet behoben werden würde. Zumindest solange die Antwort gilt "das Modem synct mit 10 Mbps, daher alles in Ordnung".

 

[mikrogigant]

Für die Nutzer der originalen Hansenet-FritzBox scheint es derzeit aber keine guten Aussichten zu geben, dass das Upload-Problem seitens Hansenet behoben werden würde. Zumindest solange die Antwort gilt "das Modem synct mit 10 Mbps, daher alles in Ordnung".

Sobald über das Problem in den einschlägigen Medien berichtet wird, dürfte sich auch Hansenet in Bewegung setzen. Über das Verbindungsproblem, das nach einem nach Update bei Infineon-DSLAMs auftrat, wurde auf teltarif.de und Co. ja auch schon berichtet.

Allerdings dürfte das Upload-Problem wohl nur für die wenigsten tatsächlich störend sein. Viele werden es gar nicht bemerken, und von denen, die es bemerken, sind sicher nicht wenige in der Lage, Fremdhardware Alice-tauglich zu machen und diese einzusetzen. Damit erledigt sich das Upload-Problem von selbst.

Grüßle

Der Mikrogigant

 

[dfroe]

Vermutliche sind die Kunden, die tatsächlich 10 Mbps Upstream haben wollen, den ISPs sowieso ein Dorn im Auge - weil diese Kunden den Upstream auch nutzen werden (ich z.B. für Online-Backups und VPN).
Ein krasses Beispiel hierfür ist z.B. KabelBW, wo ich selbst bei 100 Mbps Downstream lediglich 2,5 Mbps Upstream erhalte, um so effektiv "PowerUser" abzuschrecken.

Es ist natürlich äußerst geschickt von Hansenet, das Modem mit 10 Mbps synchronisieren zu lassen, um so dann behaupten zu können, der gesamte Upstream würde vorhanden sein.
Zumal ich auch gar nicht nachvollziehen kann, wo diese Bandbreitenbeschränkung überhaupt sitzt. Es muss etwas im Modem sein, da es mit Fremdgeräten ja funktioniert. Ein klassischer Traffic Shaper im Linux-Kernel ist es allerdings auch nicht. Dieser ist auch auf der Alice-Box auf den synchronisierten Upstream eingestellt.
Dann bleibt wohl wirklich nur der Rat, eigene Hardware einzusetzen, wenn man seinen Hansenet VDSL-Anschluss mit vollem Upstream nutzen möchte.

 

[stevve33]

Da bist du ja an den richtigen geraten , das ist einer der Gründe warum ich vermeide die Hotline anzurufen.

Wobei bei dem geplanten Stellenabbau wird die Motivation sicherlich nicht besser ...

 

[geriom]

Hi,
dann kann ich ja glücklich sein, dass bei mir der Upload funktioniert. Habe gestern Abend noch einmal den Speedtest von Alice probiert und es wird 9,16Mbit/s angezeigt. Der DSLAM ist von Broadcom.
Irgend etwas muss bei mir anders sein. Ein Bekannter von mir hat von vielleicht ungüstigen MTU zwischen den Geräten gesprochen???
Bislang hat auch noch niemand anders VDSL in Kombination von 7570 als Modem und 7170 als Router probiert oder?