hab einen router/firewall unter suse 7.3 PROBLEMLOS an aon laufen und versuche nunmehr seit stunden das ding an uta zu hängen. benutzername und passwort in /etc/ppp/pap-secrets habe ich geändert, benutzername in /etc/ppp/options auch, kontrolliert ... funzt trotzdem nicht.
der ehemalige benutzername bei uta lautet [email protected]
laut anleitung uta ist daran @utadsl zu hängen
laut anleitung lobenstock daran @provider.at
ich hab also geschrieben: [email protected]@[email protected]
funzt aber so auch nicht.
ist der provider falsch oder sind gegenüber aon noch weitere einstellungen zu ändern.
danke, gruss max.
UTA - ADSL
Forumsregeln
Das Forum fĂĽr den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!
Das Forum fĂĽr den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!
14 Beiträge
• Seite 1 von 1
RE: UTA - ADSL
von max » Sa 02 Mär, 2002 15:04
in pap-secrets steht auch:
cp /etc/ppp/pap-secrets /etc/ppp/chap-secrets
cp /etc/ppp/pap-secrets /etc/ppp/chap-secrets
- max
- Manuel Capellari
RE: UTA - ADSL
von max » Sa 02 Mär, 2002 20:22
<HTML>das meint er dazu:
pppd 2.4.1 started by root, uid 0
Perms of /dev/ttya0 are ok, no 'mesg n' neccesary.
using channel 7
Using interface ppp0
Connect: ppp0 <--> /dev/ttya0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <auth chap MD5> <magic 0xf0ebd263>]
sent [LCP ConfAck id=0x2 <auth chap MD5> <magic 0xf0ebd263>]
sent [LCP EchoReq id=0x0 magic=0x80cb8071]
cbcp_lowerup
want: 2
rcvd [CHAP Challenge id=0x22 <b3aabb948e5686c6bbf82542c96b6863>, name = "WARSCR32"]
sent [CHAP Response id=0x22 <ed228779cc5b69bd9a581ba4b553e519>, name = "[email protected]@[email protected]"]
rcvd [LCP EchoRep id=0x0 magic=0xf0ebd263]
sent [CHAP Response id=0x22 <ed228779cc5b69bd9a581ba4b553e519>, name = "[email protected]@[email protected]"]
Mar 2 15:20:15 linuxrouter last message repeated 6 times
rcvd [CHAP Failure id=0x22 "Authentication failure"]
Remote message: Authentication failure
CHAP authentication failed
cbcp_lowerdown
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
rcvd [LCP TermReq id=0x3]
sent [LCP TermAck id=0x3]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Exit.
kann also offenbar entweder PW oder benutzer nicht lesen (PW natürlich x-mal kontrolliert). obige fehlermeldung bekomme ich NUR wenn @uta.at an die benutzerkennung (siehe oben) angehängt wird - sonst krieg ich gar nix gscheites.
ich vermute, dass uta komprimierte benutzernamen/pw nicht lesen kann, aon aber sehr wohl. sonst wĂĽrde die telekom die anmeldung nicht an uta weiterleiten. es gibt anscheinend zwei variable "noaccomp" bzw. "nopcomp", die dieses verhaltren regeln. die frage ist nur: WO SIND DIE ???</HTML>
pppd 2.4.1 started by root, uid 0
Perms of /dev/ttya0 are ok, no 'mesg n' neccesary.
using channel 7
Using interface ppp0
Connect: ppp0 <--> /dev/ttya0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x80cb8071> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <auth chap MD5> <magic 0xf0ebd263>]
sent [LCP ConfAck id=0x2 <auth chap MD5> <magic 0xf0ebd263>]
sent [LCP EchoReq id=0x0 magic=0x80cb8071]
cbcp_lowerup
want: 2
rcvd [CHAP Challenge id=0x22 <b3aabb948e5686c6bbf82542c96b6863>, name = "WARSCR32"]
sent [CHAP Response id=0x22 <ed228779cc5b69bd9a581ba4b553e519>, name = "[email protected]@[email protected]"]
rcvd [LCP EchoRep id=0x0 magic=0xf0ebd263]
sent [CHAP Response id=0x22 <ed228779cc5b69bd9a581ba4b553e519>, name = "[email protected]@[email protected]"]
Mar 2 15:20:15 linuxrouter last message repeated 6 times
rcvd [CHAP Failure id=0x22 "Authentication failure"]
Remote message: Authentication failure
CHAP authentication failed
cbcp_lowerdown
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
rcvd [LCP TermReq id=0x3]
sent [LCP TermAck id=0x3]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Exit.
kann also offenbar entweder PW oder benutzer nicht lesen (PW natürlich x-mal kontrolliert). obige fehlermeldung bekomme ich NUR wenn @uta.at an die benutzerkennung (siehe oben) angehängt wird - sonst krieg ich gar nix gscheites.
ich vermute, dass uta komprimierte benutzernamen/pw nicht lesen kann, aon aber sehr wohl. sonst wĂĽrde die telekom die anmeldung nicht an uta weiterleiten. es gibt anscheinend zwei variable "noaccomp" bzw. "nopcomp", die dieses verhaltren regeln. die frage ist nur: WO SIND DIE ???</HTML>
- max
RE: UTA - ADSL
von Manuel Capellari » Sa 02 Mär, 2002 20:44
hmmm, das mit dem zweimaligen @uta macht mich stutzig ... AFAIK is das was hinterm AT zeichen ist, fürs routing zuständig, und die daten 2mal zu routen hat nicht wirklich sinn
>es gibt anscheinend zwei variable "noaccomp" bzw. "nopcomp", die dieses verhaltren regeln. die frage ist nur
die kannst bei bedarf in der /etc/ppp/options setzen, wobei ich jedoch bezweifle dass es daran liegt
>es gibt anscheinend zwei variable "noaccomp" bzw. "nopcomp", die dieses verhaltren regeln. die frage ist nur
die kannst bei bedarf in der /etc/ppp/options setzen, wobei ich jedoch bezweifle dass es daran liegt
- Manuel Capellari
RE: UTA - ADSL
von max » Sa 02 Mär, 2002 21:24
= [email protected]@[email protected] =
[email protected]
ist die ehemalige benutzerkennung VOR der umstellung auf adsl
laut uta-begleitschreiben ist an diese kennung @utadsl anzuhängen.
[email protected]@utadsl
ist also - so wurde mir auch von deren hotline bestätigt die neue benutzerkennung.
@uta.at
ist lt. lobenstock fĂĽr das routing von der telekom weiter zu uta notwendig.
aus dem ergibt sich eben [email protected]@[email protected] ... schaut komisch aus, ganz deiner meinung, wenns aber stimmt macht es sehr wohl sinn. die beiden vorderen klammeraffen sind eben nicht als "at" zu inertpretieren sondern als zeichen wie jedes andere auch ....
ich werd jetzt einmal die geschichte mit der komprimierung versuchen und dann mich weiter ärgern
[email protected]
ist die ehemalige benutzerkennung VOR der umstellung auf adsl
laut uta-begleitschreiben ist an diese kennung @utadsl anzuhängen.
[email protected]@utadsl
ist also - so wurde mir auch von deren hotline bestätigt die neue benutzerkennung.
@uta.at
ist lt. lobenstock fĂĽr das routing von der telekom weiter zu uta notwendig.
aus dem ergibt sich eben [email protected]@[email protected] ... schaut komisch aus, ganz deiner meinung, wenns aber stimmt macht es sehr wohl sinn. die beiden vorderen klammeraffen sind eben nicht als "at" zu inertpretieren sondern als zeichen wie jedes andere auch ....
ich werd jetzt einmal die geschichte mit der komprimierung versuchen und dann mich weiter ärgern
- max
RE: UTA - ADSL
von max » Sa 02 Mär, 2002 21:43
... es lag NICHT an noaccomp bzw. nopcomp, zumindest nicht nur daran. der erfolg war durchschlagend - nämlich gar keiner ???
- max
RE: UTA - ADSL
von Manuel Capellari » Sa 02 Mär, 2002 21:46
ich wĂĽrd mal im adsl forum fragen welche form die usernamen bei uta adsl haben, da sollten sich doch leute finden die mit uta surfen
ich kann mir nämlich nicht vorstellen dass die leute im uta NOC deren user absichtlich mit solchen usernamen foltern *g*
ich kann mir nämlich nicht vorstellen dass die leute im uta NOC deren user absichtlich mit solchen usernamen foltern *g*
- Manuel Capellari
RE: UTA - ADSL
von max » So 03 Mär, 2002 17:33
hab die falle gefunden:
anders als bei aon sind in /etc/ppp/options ZWEI zeilen einzutragen:
name [email protected]@[email protected]
user [email protected]@utadsl
der erste eintrag ist fĂĽr die telekom zum weiterleiten
der zweite als benutzernamen fĂĽr die uta.
SO jedenfalls funzt die sache.
anders als bei aon sind in /etc/ppp/options ZWEI zeilen einzutragen:
name [email protected]@[email protected]
user [email protected]@utadsl
der erste eintrag ist fĂĽr die telekom zum weiterleiten
der zweite als benutzernamen fĂĽr die uta.
SO jedenfalls funzt die sache.
- max
RE: UTA - ADSL
von Manuel Capellari » So 03 Mär, 2002 17:45
da stellt sich mir grade die frage, was ein windows user in dem fall macht, ich kann mir nur schwer vorstellen, dass windows automatisch erkennt welcher teil des übergebenen usernamens zur weiterleitung verwendet wird und IMHO gibts auch nicht wirklich eine option wo man das einstellen könnte ...
- Manuel Capellari
RE: UTA - ADSL
von max » So 03 Mär, 2002 19:07
das ist mir im speziellen fall eigentlich WURSCHT - man möge mir verzeihen 
))
))- max
RE: UTA - ADSL
von mad » So 03 Mär, 2002 20:21
schoen dass es jetzt funkt max,
aber zwecks der korrektheit im archiv und so ...
aus der pppd doku ...
: In addition, unless overridden with the
: user option, name will be used as the name to send
: to the peer when authenticating the local system to
: the peer.
sprich, wennst du name und user in ppp.conf
angibst, dann wird nur "user" zum peer geschickt
nicht beides.
mfg,
mad.
aber zwecks der korrektheit im archiv und so ...
aus der pppd doku ...
: In addition, unless overridden with the
: user option, name will be used as the name to send
: to the peer when authenticating the local system to
: the peer.
sprich, wennst du name und user in ppp.conf
angibst, dann wird nur "user" zum peer geschickt
nicht beides.
mfg,
mad.
- mad
RE: UTA - ADSL
von max » Mo 04 Mär, 2002 12:16
GENAU diese stelle gab mir ja den hinweis. ich bekam auf jeden anmeldeversuch "authentication failure" woraus ich den schluss zog, dass bei uta der falsche benutzername ankommt - falsch deshalb, weil beim benutzernamen die providerbezeichnung nicht dabei ist.
der erste versuch, diese klippe zu umschiffen - in /etc/ppp/options als name [email protected] anzugeben in pap-secrets aber OHNE provider brachte nix. offenbar überschreibt die "name"-einstellung die von pap-secrets. erst der eintrag "user" brachte die lösung.
an den telekom-verteiler geht also [email protected] an die uta aber nur die benutzerbezeichnung OHNE @uta.at - damit sind beide glĂĽcklich UND ICH AUCH))
gruss max.
der erste versuch, diese klippe zu umschiffen - in /etc/ppp/options als name [email protected] anzugeben in pap-secrets aber OHNE provider brachte nix. offenbar überschreibt die "name"-einstellung die von pap-secrets. erst der eintrag "user" brachte die lösung.
an den telekom-verteiler geht also [email protected] an die uta aber nur die benutzerbezeichnung OHNE @uta.at - damit sind beide glĂĽcklich UND ICH AUCH
))
gruss max.
- max
14 Beiträge
• Seite 1 von 1
ZurĂĽck zu LINUX & UNIX-DERIVATE
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast