UMTS mit T-Mobile über Non-Default APN geht nicht

[gkpop]

Hallo,

ich bekomme den 1751 nicht dazu per UMTS mit einem alternativen APN zusammenzuarbeiten. Ich nutze eine T-Mobile Karte und bei Nutzung des Default APN "internet.t-mobile" läuft alles wie erwartet. Ich habe jedoch noch einen (wichtigen) Account bei einem anderen Anbieter welcher mit T-Mobile zusammenarbeitet und dazu muss man einen anderen APN eintragen ("celox.sa.t-moble").

Auf meinem Handy ist das kein Problem - einfach APN wechseln und den entsprechenden passenden Login-Account nehmen. Auf dem 1751 funzt nur der Default T-Mobile APN. Jemand eine Idee woran das liegt? Ansonsten muss ich das Gerät wohl zurückgeben.

Gruss,
Gerald

P.S.: Mein Account auf dem APN "celox.sa.t-mobile" hat ein "@" Zeichen im Usernamen, ich hoffe doch, dass der 1751 damit keine Probleme hat.

[froeschi62]

Hi,

Probiere mit deiner T-Mobile Karte einfach ohne Usernamen und Passwort den APN "internet.t-d1.de" einzutragen. Sollte das funktionieren liegt es nicht generell an der APN Wechselmöglichkeit sondern eher am Account.

Gruß
Dietmar

[gkpop]

Danke für den Hinweis. Habe nun noch etwas herumprobiert. Wenn ich "internet.t-d1.de" als APN nehme klappt es auch, egal welche Benutzerdaten ich eingebe.

Nur wenn ich "celox.sa.t-moble" als APN eintrage geht es nicht, aber hier muss ich auch zwangsläufig einen bestimmten Benutzerlogin nehmen. Ich gehe nun davon aus, dass bei der Übermittlung des Usernamens irgendwas schief geht - evtl. hat es nun doch mit dem "@" im Loginnamen zu tun.

Hat evtl. jemand schon Erfahrungen damit gemacht?

Gruß
Gerald

[froeschi62]

Hi,

versuche mal statt "@" "at" einzugeben. Mit diesem Zeichen hat der LC wohl Probleme.
Eigentlich müsste es trotzdem gehen denn hier siehst Du welche Zeichen grundsätzlich erlaubt sind (PPP Verbindung). Allerdings gilt das für die direkte PPP Verbindung.
Hast Du eventuell Umlaute drin?


Possible Entries for columns in PPP:
[1][Peer] : 16 chars from: ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()
-,/:;<=>?[\]^_.0123456789
[2][Authent.] : none (0), CHAP (8), PAP (4)
[3][Key] : 32 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'(
*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[4][Time] : 2 chars from: 1234567890
[5][Try] : 2 chars from: 1234567890
[7][Conf] : 3 chars from: 1234567890
[8][Fail] : 3 chars from: 1234567890
[9][Term] : 3 chars from: 1234567890
[6][Username] : 64 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'(
*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[10][Rights] : none (0), IP (1), IP+NBT (3)

Viele Grüße
Dietmar

[gkpop]

Moin & Danke schonmal bisher .

Ich brauche das "@" im Usernamen da dieses für den Celox-APN ein wichtiges Trennungszeichen ist (->Realm). Von daher bringt der Austausch durch "at" leider nix. Ansonsten habe ich keine besonderen Zeichen/Umlaute im Usernamen, er sieht generell so aus: xxxxx-xxxx@xxxx
(wobei alle "x" kleine Buchstaben bzw. Ziffern sind)

Anhand Deiner Liste müsste der Username also im Prinzip ok sein. Woher hast Du die Daten - ist das ein RFC oder kommt das von Lancom? Wenn der LC wirklich kein "@" mag ist das schlecht ;-(.

Gruß
Gerald

[froeschi62]

Hi,

das kommt vom Lancom. Du gehst per Telnet einfach in das PPP Verzeichnis und gibst "set ?" ein.

Gruß
Dietmar

[gkpop]

Ah, ok. Dieses Commmandline-Interface vom LC ist mir noch nicht so geheuer.

Ich hatte mir jetzt mal mit "trace + ppp" die PPP-Verhandlung angezeigen lassen, aber da zeigt er leider auch nix was mich weiterbringt. Der LC versucht nur laufend (mit welchen Usernamen auch immer) sich zu connecten und bricht dann nach X Versuchen immer wieder ab. Unschön.

Gruß
Gerald

PS: ein richtiger Packet-Dump von der PPP-Verhandlung wäre nicht schlecht, aber ob das mit dem LC geht?

[froeschi62]

Hi,

doch, eigentlich müste Dir das PPP Trace eine Verhandlung mit dem falschen Usernamen/Passwort anzeigen. Hast Du richtig geschaut? Suche mal im Trace nach "bad username or password".
Prinzipiell müsste es definitiv gehen. Der Lancom kann Deine erforderlichen Zeichen verarbeiten.

Gruß
Dietmar

[gkpop]

Jep, stimmt. Es ist nicht anscheinend doch nicht der Username. Es gibt ein Loop/Ping-Pong in der IPCP Verhandlung:

...
[PPP] 1900/01/01 00:12:23,680

Received IPCP frame from peer T-MOBILE (channel 19)
Evaluate configure-nak with ID 35 and size 16
Peer NAKs primary DNS address 10.11.12.13, accepted
Peer NAKs secondary DNS address 10.11.12.14, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-MOBILE
Inserting IP address 0.0.0.0
Inserting primary DNS address 10.11.12.13
Inserting secondary DNS address 10.11.12.14
Sending IPCP configure-request with ID 36 and length 22 to peer T-MOBILE (channel 19)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 1900/01/01 00:12:24,690

Received IPCP frame from peer T-MOBILE (channel 19)
Evaluate configure-nak with ID 36 and size 16
Peer NAKs primary DNS address 10.11.12.13, accepted
Peer NAKs secondary DNS address 10.11.12.14, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-MOBILE
Inserting IP address 0.0.0.0
Inserting primary DNS address 10.11.12.13
Inserting secondary DNS address 10.11.12.14
Sending IPCP configure-request with ID 37 and length 22 to peer T-MOBILE (channel 19)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 1900/01/01 00:12:25,690

Received IPCP frame from peer T-MOBILE (channel 19)
Evaluate configure-nak with ID 37 and size 16
Peer NAKs primary DNS address 10.11.12.13, accepted
Peer NAKs secondary DNS address 10.11.12.14, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-MOBILE
Inserting IP address 0.0.0.0
Inserting primary DNS address 10.11.12.13
Inserting secondary DNS address 10.11.12.14
Sending IPCP configure-request with ID 38 and length 22 to peer T-MOBILE (channel 19)
Starting IPCP restart timer with 3000 milliseconds

...

So geht das laufend weiter. Hm, mal weitersuchen.

[froeschi62]

Hi,

also irgendwas stimmt mit Deinem APN Namen nicht. Er bekommt auch keine IP zugeteilt. Ich habe aus Spaß diesen APN über Google gesucht. Der taucht im ganzen Internet nicht auf.
Teste deinen Account mal mit dem APN "ca.t-mobile".

Gruß
Dietmar

[gkpop]

Der APN ist schon der Richtige - ich benutze ihn auf meinem Handy und auf meinem Laptop unter Ubuntu, da läuft das ohne Probleme. Ich hab hier einen eigenen RADIUS Server und einen LNS der die PPP Verbindung terminiert.

Ich dachte dass der Request gar nicht zu mir reinkommt und habe mich deshalb auf das APN/Usernameproblem beschränkt, aber nun sehe ich, dass der LC doch eine Verbindung initial aufbauen kann - Username/Passwort kommen also hier rein und werden angenommen. Danach scheint aber was im weiteren IPCP zu klemmen, IP-Adresse und DNS Server von meinem LNS kommen beim LC nicht mehr an.

Unter Ubuntu bekomme ich im ersten IPCP Step auch erstmal per PPP immer die DNS-Server "10.11.12.13/10.11.12.14" und erst danach im 2ten Anlauf die 'richtigen' DNS-Server und die IP zugewiesen. Auf dem LC sieht es anders aus. Mal sehen was ich aus meinem LNS noch per Debug rausholen kann.


Gruß
Gerald

[froeschi62]

Hi,

ok, dann bist Du wenigstens schon einen kleinen Schritt weitergekommen. Dann klinke ich mich hier aus. Aber halte uns bitte auf dem Laufenden.

Viele Grüße
Dietmar

[gkpop]

Moin,

ok, dann hier mal ein weiteres Ergebnis. Nachdem ich das ganze Setup nun mit einem Cisco-UMTS System getestet habe liegt es wahrscheinlich an der Authentifizierung - mit PAP geht es mit CHAP nicht.

Bei der Cisco kann ich explizit ein "refuse CHAP / use PAP" konfigurieren, bei dem LC habe ich so eine Option noch nicht gefunden. Die einzige CHAP/PAP Auswahlmöglichkeit im LC-Userinterface ist anscheinend nur für die Authentifizierung der *Gegenseite* zuständig, aber die authentifiziert sich ja nicht am LC sondern umgekehrt.

Ich glaube ich bin irgendwo in der LC Doku über "Scriptuploads" oder etwas ähnliches gestolpert, evtl. kann man darüber ja noch ein paar mehr Optionen beeinflussen. Schaunmermal.


Gruß,
Gerald

[froeschi62]

Hi,

ich sage da nur als Stichwort Kommunikation/Protokolle/PPP-Liste:
Auswahl
"Die Gegenstelle mit PAP überprüfen"
"Die Gegenstelle mit CHAP überprüfen"

Das kannst Du hiermit im LC ebenfalls konfigurieren.

Gruß
Dietmar

[gkpop]

Jo, die Auswahl kannte ich . Das meinte ich mit '... ist anscheinend nur für die Authentifizierung der *Gegenseite* zuständig ...'.
Wenn ich diese Option auf CHAP oder PAP setze will der LC, dass sich unser Einwahlserver *bei ihm* authentifiziert und das ist nicht gewollt. Der LC soll sich ja beim Einwahlserver authentifizieren.