Re: Probleme mit Kernel-PPP nach Update 2.2.6 -> 2.2.7

As Udo Erdelhoff wrote:

> ich nutze hier 2.2-stable, die Updates kriege ich über via CTM (über die
> Mailingliste ctm-src-2_2. Seit dem heutigen Update von delta 760 (post
> 2.2.6-RELEASE) auf 824 (post 2.2.7-RELEASE) will das Kernel-PPP nicht mehr.
> Nicht mal mehr der ping zur Gegenstelle funktioniert.

Was das mit dem Kernelupgrade zu tun hat, ist mir nicht klar. Den
Rest kann ich mal versuchen zu interpretieren.

> Aug 8 20:17:59 nathan pppd[286]: pppd 2.3.5 started by operator, uid 0
> Aug 8 20:17:59 nathan pppd[286]: Using interface ppp0
> Aug 8 20:18:00 nathan pppd[286]: Connect: ppp0 <--> /dev/cuaa3
> Aug 8 20:18:00 nathan pppd[286]: sent [LCP ConfReq id=0x1 <magic 0xa235fa37> <pcomp> <accomp>]
> Aug 8 20:18:00 nathan pppd[286]: rcvd [LCP ConfRej id=0x1 <pcomp> <accomp>]

Hmm, Deine Seite wünscht protocol field compression sowie address
field und control field compression, bekommt dies aber von der
Gegenseite abgelehnt.

> Aug 8 20:18:00 nathan pppd[286]: sent [LCP ConfReq id=0x2 <magic 0xa235fa37>]

Deine Seite stimmt dem zu.

> Aug 8 20:18:00 nathan pppd[286]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xf2b1504f>]
> Aug 8 20:18:00 nathan pppd[286]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xf2b1504f>]

Die Gegenseite wünscht PFC/ACFC nicht (das merken wir uns jetzt mal
für später), sie wünscht ein Rücksetzen der asyncmap auf leer (das
solltest Du Dir auch wünschen btw., um sinnlose Escapereien zu sparen)
und sie wünscht PAP authentication, dem Du allem zustimmst.

> Aug 8 20:18:00 nathan pppd[286]: rcvd [LCP ConfAck id=0x2 <magic 0xa235fa37>]
> Aug 8 20:18:00 nathan pppd[286]: sent [PAP AuthReq id=0x1 user="<username>" password="<passwort>"]
> Aug 8 20:18:00 nathan pppd[286]: rcvd [PAP AuthAck id=0x1 "Login Succeeded"]
> Aug 8 20:18:00 nathan pppd[286]: Remote message: Login Succeeded
> Aug 8 20:18:00 nathan pppd[286]: sent [IPCP ConfReq id=0x1 <addr 141.39.224.154> <compress VJ 0f 01>]
> Aug 8 20:18:00 nathan pppd[286]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 00> <addr 141.39.224.46>]
> Aug 8 20:18:00 nathan pppd[286]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 00> <addr 141.39.224.46>]
> Aug 8 20:18:00 nathan pppd[286]: rcvd [IPCP ConfAck id=0x1 <addr 141.39.224.154> <compress VJ 0f 01>]
> Aug 8 20:18:00 nathan pppd[286]: local IP address 141.39.224.154
> Aug 8 20:18:00 nathan pppd[286]: remote IP address 141.39.224.46

Alle Verhandlungen funktionieren problemlos.

> Beim start des pppd:
> ppp0: no compressor for [15 3 29], 3
> ppp0: no compressor for [1a 4 8], 4
> ppp0: no compressor for [18 4 8], 4

Kann ich nicht deuten. Möglicherweise CCP-Ablehnungen. Vielleicht
auch Hinweise auf Fehler in der VJ-Headercompression.

> Bei einem ping 141.39.224.46 (die Gegenstelle halt) kommt dann:
> ppp0: missing UI (0x3), got 0x21

Das und ...

> Beim Abbau der Verbindung:
> ppp0: missing UI (0x3), got 0xc0

...das sind wesentliche Informationen. Die Gegenseite sendet ganz
offenbar Pakete, die protocol-field compressed und/oder address/
control field compressed sind, obwohl sie dies nie verhandelt hat
(s. o.). Deine Seite erwartet diese Kompressionen nicht, sondern
wünscht sich, daß als nächstes das (informationslose) Oktett ``UI''
(unnumbered information, 0x3) kommt. Interessant ist, daß entweder
die Gegenseite keine address field compression benutzt hat oder aber
Deine Seite dies durchgehen lassen hat (vor der 0x3 müßte eine
ebenfalls informationslose 0xff, für ``all stations'' als HDLC-
Zieladresse stehen). Statt des UI kommt sofort die PPP protocol
number, diese übrigens ebenfalls ,,komprimiert'', d. h. die führende
Null des Protokolls 0x0021 (IP network data) ist weggelassen worden.
Das Protokoll 0xc023 (LCP) beginnt nicht mit einer Null, folglich kann
es nie komprimiert werden, daher beklagt er sich beim Emfang des
LCP-Pakets der Gegenseite (terminate acknowledge vermutlich) über 0xc0
statt 0x21. Die Gegenseite scheint übrigens all Deine Pakete korrekt
zu empfangen; sonst hätte sie ja keinen Grund, im Sekundenrhytmus
IP-Pakete zu senden (und das LCP terminate request hat sie offensicht-
lich auch empfangen).

Ich würde die Gegenseite als defekt deklarieren. Was läuft denn dort?

Die einzige Erklärung, was das mit Deinem Upgrade zu tun hat, die ich
mir vorstellen kann ist, daß Dein PPP das fehlende UI früher
durchgehen lassen hat und diese ,,Kompressions''modi (sie sparen
jeweils höchstens ein Oktett pro Frame) mittels impliziter Heuristik
erkannt hat auch ohne daß sie verhandelt worden sind. Das kann man
als ,,lazy implementation'' durchgehen lassen, auch wenn es nicht ganz
exakt nach dem Buchstaben des Geset^H^H^H^H^HRFCs ist.

-- 
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)