Re: Beim ersten PPP-Verbindungsaufbau zur UMTS-Karte kommen unsinnige Nameserver
Sascha Reiszner schrieb am 15. Jul um 01:32 Uhr:
> Am Mittwoch, den 09.07.2008, 12:17 +0200 schrieb Christian Knoke:
>
> > Ja, die Daten, die ihm fehlen, sind die IP und die korrekten DNS. In einem
> > Fall stehen diese nach 5 Sekunden zur Verfügung (dann gehts schief), im
> > anderen nach 3 (dann klappt es).
> >
> > Bis dahin liefert er falsche DNS. pppd akzeptiert diese, und fordert mittels
> > ConfNAK eine Bestätigung dafür an. Das Modem müsste mit ConfACK bestätigen,
> > tut dies aber nicht (vermutlich weil es weiss dass die Daten falsch sind)
> > und schlägt auch keine IP vor.
> >
> > Dann, nach 3 oder 5 Sekunden (erkennbar an dem rcvd [IPCP ConfReq id=0x0])
> > liegen die Daten vor und das Modem bietet (zum ersten Mal) eine IP an.
> >
> > Das Problem ist, das der pppd (im Falle 5 Sekunden) offenbar die falschen
> > DNS bereits akzeptiert hat und jetzt nur noch nach der IP fragt. Wie gesagt,
> > der Fehler ist IMHO, das der pppd die DNS verwendet, _ohne_das_ die
> > Gegenseite diese mittels ConfACK explizit bestätigt hat.
>
> Dieses Szenario vermute ich auch und hatte heute kurz Zeit den Laptop
> andem ich soetwas eingerichtet habe, zu untersuchen.
> Provider: a1plus.net (Österreich)
> Hardware: Huawei E630
>
> Hier ein Log (nur IPCP) bei dem es geklappt hat:
> (leider mit überlänge wegen der besseren Lesbarkeit)
> ---
> Jul 13 18:57:01 localhost pppd[4481]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Jul 13 18:57:02 localhost pppd[4481]: rcvd [IPCP ConfReq id=0x0]
> Jul 13 18:57:02 localhost pppd[4481]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
> Jul 13 18:57:02 localhost pppd[4481]: rcvd [IPCP ConfNak id=0x1 <addr 89.144.197.66> <ms-dns1 194.48.139.254> <ms-dns3 194.48.124.202>]
> Jul 13 18:57:02 localhost pppd[4481]: sent [IPCP ConfReq id=0x2 <addr 89.144.197.66> <ms-dns1 194.48.139.254> <ms-dns3 194.48.124.202>]
> Jul 13 18:57:02 localhost pppd[4481]: rcvd [IPCP ConfAck id=0x2 <addr 89.144.197.66> <ms-dns1 194.48.139.254> <ms-dns3 194.48.124.202>]
> Jul 13 18:57:03 localhost pppd[4481]: rcvd [IPCP ConfReq id=0x1]
> Jul 13 18:57:03 localhost pppd[4481]: sent [IPCP ConfAck id=0x1]
> ---
> Interessant ist, daß nach dem Zeitpunkt, andem die Karte die Daten hat
> (Zeile 2 = rcvd ConfReq), der pppd nur nach der IP fragt und trotzdem
> DNS dazu bekommt.
Nein, beide ppp-Partner verhalten sich hier korrekt. Der lokale pppd hatte
bereits in Zeile 1 nach den DNS gefragt (mit id=1) und hierauf in Zeile 4
die vollständige Antwort erhalten.
> Hier ein Log wo es fehlschlägt:
*snip*
> Hier das selbe Bild wie bei Marc. Der pppd bekommt 5x die DNS
> vorgeschlagen und akzeptiert diese dann, ohne daß diese Adressen je
> bestätigt wurde.
Ja. In diesem Fall dauerte die IPCP-Phase ja 33 Sekunden! Ich nehm' mal an,
das das auch mal schneller geht, und das das (Mobilfunk-)netzabhängig ist.
Bei GPRS-Einwahl mit Handy kenne ich, das es auch manchmal ausserordentlich
lang dauert oder auch gar nicht geht, ohne ersichtlichen Grund. Das dürfte
bei UMTS ähnlich sein?
> Ein weiterer Workaround den ich leider nicht mehr getestet habe, wäre
> die Option 'usepeerdns' auszukommentieren.
> Dann sollte pppd garnicht nach den DNS fragen.
Das sollte natürlich wunderbar gehen, nur mußt Du dann deinem System die DNS
anderweitig zur Verfügung stellen. Schneller wird die Einwahl dadurch nicht,
Du verhinderst aber, das der (vermutliche) kleine pppd-Fehler durchschlägt.
Setze doch mal probeweise ipcp-max-failure auf eine hohen Wert,
beispielsweise 60. Das sollte vielleicht Einwahldauern bis ca. 60 Sekunden
abfedern.
Gruß
Christian
--
Christian Knoke * * * http://cknoke.de
* * * * * * * * * Ceterum censeo Microsoft esse dividendum.
Reply to: