AW: ISDN, es weigert sich beharrlich

Tue Nov 9 13:10:21 CET 1999

On Tue, Nov 09, 1999 at 09:12:34AM +0100, Andre Landwehr wrote:
> On Mon, Nov 08, 1999 at 07:59:43PM +0100, Frank Matthiess wrote:
> > E021F -> E 02 1F
> > 1F - Normal, unspecified
> >      Hat ganz normal abgebaut, soll heißen aufegelegt!
> > 
> 
> da fällt mir grade ein: sowas in der Art hat mein Rechner neulich auch
> ausgespuckt, als ich versucht habe meine laufende Konfiguration von 2.2.12 auf
> 2.2.13 upzudaten. Offenbar gibts mit dem aktuellen Kernel Schwierigkeiten was
> ISDN angeht. Er hat auch irgendwie die Authentifizierung nicht hinbekommen und
> die Gegenseite hat aufgelegt.

Authentifizierung findet aber NICHT im kernel statt - Das wird
nur ein Symptom der fehler gewesen sein d.h. wahrscheinlich sind im kernel
low-level pakete verloren gegangen ....

Bevor authentifizierung stattfindet wird normalerweise LCP
(Link Control Protocol) gesprochen was erst die Art der Authentifizierung
aushandelt (PAP, CHAP, MSCHAP etc). Danach findet erst die authentisierung
statt. Wenn LCP erfolgreich verhandelt worden ist logged die kiste im Syslog
"LCP up".

Nochmal fuer alle die die zusammenhaenge nicht verstehen hier ein
kommentierter Verbindungsaufbau ... So sollte das aussehen und wenn
jetzt VOR irgendeiner LCP zeile eine ISDN fehlermeldung kommt
dann ist das KEINE Authentisierungsproblematik - Das sollte damit
jedem klar werden ....

Nov  7 14:30:11 bounce kernel: ippp, open, slot: 0, minor: 0, state: 0000 
Nov  7 14:30:11 bounce kernel: ippp_ccp: allocating reset data structure 
Nov  7 14:30:11 bounce ipppd[32653]: Connect[0]: /dev/ippp0, fd: 8
Nov  7 14:30:12 bounce kernel: ippp0: dialing 1 06151310800... 
                                              ^ ^^^^^^^^^^^

Ersteres die NUMMER des Einwahlversuches und das zweit
ist die Rufnummer ..

Nov  7 14:30:14 bounce kernel: isdn_net: ippp0 connected 
Nov  7 14:30:14 bounce kernel: isdn_net: chargetime of ippp0 now 276240550 
Nov  7 14:30:14 bounce ipppd[32653]: Local number: , Remote number:
			06151310800, Type: outgoing

Nov  7 14:30:14 bounce ipppd[32653]: PHASE_WAIT -> PHASE_ESTABLISHED,
			ifunit: 0, linkunit: 0, fd: 8

Bis hier hin war ISDN dialing .... Jetzt startet der pppd ...

Nov  7 14:30:14 bounce ipppd[32653]: sent [0][LCP ConfReq id=0x1 <mru
			1500> <magic 0x5836580f>]

Unsere seite will eine MRU setzen (Maximum Receive Unit)

Nov  7 14:30:15 bounce ipppd[32653]: rcvd [0][LCP ConfReq id=0x1 <mru
			1514> <auth pap> <magic 0xc9e4255b> <pcomp> <accomp>]

Die gegenstelle will "auth pap" d.h. Authentisierung mit PAP und
pcomp und acccomp ...

Nov  7 14:30:15 bounce ipppd[32653]: sent [0][LCP ConfRej id=0x1 <pcomp>
			<accomp>]

Wir lehnen pcomp und accomp ab ...

Nov  7 14:30:15 bounce ipppd[32653]: rcvd [0][LCP ConfReq id=0x2 <mru
			1514> <auth pap> <magic 0xc9e4255b>]

Die gegenstelle schickt einen berichtigten config request OHNE pcomp
und accomp NUR authentication pap  und MRU ...

Nov  7 14:30:15 bounce ipppd[32653]: sent [0][LCP ConfAck id=0x2 <mru
		1514> <auth pap> <magic 0xc9e4255b>]

Wir ACKen den request - Damit sind alle GEGENSTELLENbedingungen akzeptiert

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][LCP ConfReq id=0x1 <mru
		1500> <magic 0x5836580f>]

Wir senden erneut UNSEREN config request nach MRU ...

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][LCP ConfAck id=0x1 <mru
		1500> <magic 0x5836580f>]

Dieser Request wird geACKt und damit sind beide seiten LCP maessig configuriert.

Nov  7 14:30:17 bounce ipppd[32653]: lcp layer is UP

Die meldung - "lcp layer is UP"

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][PAP AuthReq id=0x1
		user="aolip" password not logged for security reasons! Use
		'+pwlog' option to enable full logging.]

Authentication Request ....

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][PAP AuthAck id=0x1msg=""]

Authentication ACK ...

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][IPCP ConfReq id=0x1 <addr
			0.0.0.0>]

Wir fragen nach eine IP Addresse ...

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][IPCP ConfReq id=0x3
			<compress VJ 0f 00> <addr 192.168.0.1>]

Die gegenstelle gibt sich als 192.168.0.1 aus und will VJ Header Compression.

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][IPCP ConfRej id=0x3
			<compress VJ 0f 00>]

Wir lehnen VJ Compression ab ...

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][IPCP ConfNak id=0x1 <addr
			213.20.232.176>]

Wir bekommen auf die anfrage nach "0.0.0.0" ein NAK und eine neue IP Addresse

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][IPCP ConfReq id=0x2 <addr
			213.20.232.176>]

Wir schicken einen erneuten request nach der oben angegebenen IP Addresse

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][IPCP ConfReq id=0x4 <addr
			192.168.0.1>]

Erneute anfrage der gegenstelle nach 192.168.0.1 diesmal OHNE VJ Header
compression 

Nov  7 14:30:17 bounce ipppd[32653]: sent [0][IPCP ConfAck id=0x4 <addr
			195.71.237.37>]

Wir bestaetigen diese config ...

Nov  7 14:30:17 bounce ipppd[32653]: rcvd [0][IPCP ConfAck id=0x2 <addr
			213.20.232.176>]

Und bekommen ein ACK auf unseren Request ...

Nov  7 14:30:17 bounce ipppd[32653]: local  IP address 213.20.232.176
Nov  7 14:30:17 bounce ipppd[32653]: remote IP address 195.71.237.37

IP Addressen sind ausgehandelt - Das routing steht ...

Nov  7 14:30:40 bounce ipppd[32653]: Connection terminated.
Nov  7 14:30:40 bounce ipppd[32653]: taking down PHASE_DEAD link 0, linkunit: 0
Nov  7 14:30:40 bounce ipppd[32653]: sent [0][LCP TermReq id=0x2 6c 69 6e 6b 20 63 6c 6f 73 65 64]

Ein TermReq wird geschickt und so schnell aufgelegt das kein ACK
mehr zurueckkommt ...

Nov  7 14:30:40 bounce ipppd[32653]: LCP is down

Flo
-- 
Florian Lohoff		flo at rfc822.org		      	+49-5241-470566
  ...  The failure can be random; however, when it does occur, it is
  catastrophic and is repeatable  ...             Cisco Field Notice