On Sun, May 06, 2001 at 04:09:46PM +0200, Martin Hahn ( web.de ) wrote:

Hallo Karsten.

Ich habe auf Deinen Rat hin die Einstellungen des IO-Ports durchgetestet mit der Karte. Vier Möglichkeiten habe ich ja immerhin: 0x200 (das war in der letzten Mail), 0x240, 0x300 und 0x340. Die letzten beiden haben immerhin etwas mehr 'log' generiert als 0x200, den habe ich hier mal dargestellt:

Ja das sieht jetzt richtig gut aus, die beiden Enden kommunizieren nicht mehr nur einseitig. Damit ist auch klar das irgendwas in den 0x200/0x240 bzw. dessen shadow Addressen einen Konflikt verursacht (shadow Addressen sind die wo hoehere Adressbits gesetzt sind, also zb 0x600, 0xa00 ....) ...

May 6 15:43:42 marvin ipppd[220]: sent [0][LCP ConfRej id=0x1 < 00 04 00 00> <auth chap md5> ] ... May 6 15:43:42 marvin ipppd[220]: sent [0][LCP ConfRej id=0x2 <auth pap>] ...

Das liest sich im Momemt so für mich, als seien sich die beiden Partner nicht so richtig darüber einig, welche Art Authentifizierung sie zuließen. Immerhin endet die Verbindung schon um ein Vielfaches schneller als vorher und es gibt keinen Timeout mehr. Wenn ich mich recht erinnere, habe ich mit -pap und -chap die Authentifizierung ausge- schaltet, da ich ja kein Server bin.

Nein da bist Du etwas zu weit gegangen, damit schaltest Du auch PAP/CHAP fuer den Client aus. Du darfst nur nicht +pap/+chap in den Optionen haben, das verlangt dann von der anderen Seite sich zu authentifizieren. -pap/-chap ist nur dafuer da gezielt eines der beiden auszuschalten.

Weißt Du, was es jetzt noch sein könnte? Ist es jetzt nur noch das dumme Login, woran es scheitert? Immerhin, das wäre schon der Silberstreifen am Horizont 8-)

Also -pap -chap raus und es sollte gehen (nicht vergessen neu zu starten). -- Karsten Keil SuSE Labs ISDN development