linux user group brescia

> > Feb 18 18:02:24 localhost pppd[1236]: Using interface ppp0
> > Feb 18 18:02:24 localhost pppd[1236]: Connect: ppp0 <--> /dev/ttyS0
> > Feb 18 18:02:26 localhost pppd[1236]: local  IP address 192.168.100.1
> > Feb 18 18:02:26 localhost pppd[1236]: remote IP address 195.223.123.2
> > Feb 18 18:02:26 localhost pppd[1236]: IPCP terminated by peer
> > Feb 18 18:02:26 localhost pppd[1236]: Unsupported protocol (0xc029)
[...]
> > Feb 18 18:02:27 localhost pppd[1236]: LCP terminated by peer

Riecco il logfile incriminato:
 la negoziazione dell'indirizzo va a buon fine...
 ...ma qualchecosa si blocca...

IPCP e' un protocollo standard: Internet Protocol Control Protocol
  definito dalla RFC 1332... eccone la descrizione:

   The IP Control Protocol (IPCP) is responsible for configuring,
   enabling, and disabling the IP protocol modules on both ends of the
   point-to-point link.  

[Per cui si tratta di una cosa DIVERSA rispetto l'LCP che determina i 
 parametri FISICI della linea, tipo sequenze di escape, timeouts, etc.]

Praticamente IPCP determina:
 1) gli indirizzi IP, locali e remoti;
 2) il protocollo di compressione da usare.

La fase 1 pare andare a buon fine, in quanto apparentemente vengono
 assegnati gli IP voluti alla macchina... la fase 2 parrebbe essere 
 quella problematica.
La RFC 1700, quella che indica i numeri assegnati per i vari servizi di
 TCP/IP riporta per il 0xc029:

   c029            CallBack Control Protocol (CBCP)

[e questo e' a proposito, in quanto rientra nella sezione PPP Data Link
 Layer]
 Il problema e' che questa negoziazione non dovrebbe avvenire in IPCP ma
  in LCP... strano... 
 

 Prova a incrementare il livello di debug del pppd [con un
  debug
  kdebug 7
 in /etc/ppp/options ] 
 e/o  ad aggiungere un 
  ipcp-accept-local 
 nel medesimo file.
   
P.S.
 Il callback dovrebbe essere supportato a livello di demone... non so se pero'
  viene gestito a livello di kernel... questo potrebbe spiegare lo strano
  messaggio di errore...

Ciao,
 lg