PPP pro pripojeni MS
Dan Lukes
dan at obluda.cz
Wed Sep 1 17:24:20 CEST 2004
On Wed, 1 Sep 2004, Josef Jursa wrote:
>>> snazim se nakonfigurovat PPP na FreeBSD 4.10 pro pripojovani MS stanic
>>> pres modem. Nechteji se domluvit:
>>> tun0: CCP: MPPE: Not usable without CHAP81 .
>>>
>>> enable chap80 chap81 chap pap
>>> v ppp.conf nepomaha. Nevite nekdo co s tim?
>>
>> Detailni LOG PPP hanshakingu (na strane FreeBSD staci) by nebyl ?
> Je to dost velke, do konference se to nepropasirovalo.
Nevadi, relevatni cast z toho vyberu.
> Tady je:
> Sep 1 14:18:14 MyPC ppp[11402]: tun0:
> Command: default: enable chap80 chap81 chap pap
> Sep 1 14:18:14 MyPC ppp[11402]: tun0:
> Warning: enable chap80: Ambiguous command
Syntakticke chyby v konfiguraku by opravit neskodilo - i kdyz na nas
problem tahle syntakticka chyba vliv nema.
> 14:18:16 MyPC ppp[11402]: tun0: LCP: deflink: LayerStart
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: deflink: SendConfigReq(1)
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: ACFCOMP[2]
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: PROTOCOMP[2]
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: ACCMAP[6] 0x00000000
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: MRU[4] 1500
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: MAGICNUM[6] 0xb5fce038
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05)
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: deflink: RecvConfigAck(1)
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: ACFCOMP[2]
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: PROTOCOMP[2]
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: ACCMAP[6] 0x00000000
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: MRU[4] 1500
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: MAGICNUM[6] 0xb5fce038
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05)
> Sep 1 14:18:16 MyPC ppp[11402]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd
Receno lidsky - klient protistrane nabidnul, ze on se ji
autentizuje pomoci CHAP (protoze je to jeden z mnoha autentizacnich
mechanismu, ktery umi ). A protoze protistrana (server, zrejme Windows XP)
tento mechanismus take umi, byla jeho nabidka prijata. Tim je dohodnuto,
ze klient pri svoji autentizaci pouzije CHAP.
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: deflink: RecvConfigReq(3)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: ACCMAP[6] 0x00000000
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: MAGICNUM[6] 0x6ee73ca0
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: PROTOCOMP[2]
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: ACFCOMP[2]
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: deflink: SendConfigAck(3)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: ACCMAP[6] 0x00000000
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: MAGICNUM[6] 0x6ee73ca0
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: PROTOCOMP[2]
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: ACFCOMP[2]
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: deflink: LayerUp Sep
Jen pro uplnost, take druha polovian hanshakingu. Server se
klientovi autentizovat nebude a klient je s tim srozumen.
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: Phase: bundle: Authenticate
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: Phase: deflink: his = none, mine = CHAP 0x05
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: Phase: Chap Output: CHALLENGE
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: Phase: Chap Input: RESPONSE (16 bytes from jjppp)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: Phase: Chap Output: SUCCESS
A jak je videt, autentizace se (dohodnutou metodou) take podarila.
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: CCP: MPPE: Not usable without CHAP81
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: CCP: deflink: SendConfigReq(1)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: CCP: DEFLATE[4] win 15
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: CCP: PRED1[2]
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: deflink: RecvProtocolRej(7)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: LCP: deflink: --
> Protocol 0x80fd (Compression Control Protocol) was rejected!
Klient poznamenava, ze pokud autentizace nebyla provedena pomoci
CHAP81 (coz nebyla), nelze pouzit MPPE. PRoto nabizi jen DEFLATE a PRED1.
Server, ktery neni ochoten na zadnou z techto dvou moznosti pristoupit,
odmita kompresi jako takovou.
A v teto chvili uz nic nebrani dohode o IP spojeni (i kdyz
nekomprimovanem):
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: deflink: RecvConfigReq(8)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: COMPPROTO[6] 16 VJ slots
> with slot compression
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 10.0.0.2
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: deflink: SendConfigAck(8)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: COMPPROTO[6] 16 VJ slots
> with slot compression
Tahle polovina probehla celkem hladce. Horsi je to s druhou
polovinou:
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: deflink: SendConfigReq(1)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 0.0.0.0
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: COMPPROTO[6] 16 VJ slots
> with slot compression
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: deflink: RecvConfigRej(1)
> Sep 1 14:18:17 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 0.0.0.0
...
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: deflink: SendConfigReq(5)
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 0.0.0.0
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: COMPPROTO[6] 16 VJ slots
> with slot compression
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: deflink: RecvConfigRej(5)
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 0.0.0.0
Klient opakovane trva na tom, ze pouzije adresu 0.0.0.0 a server mu
opakovane rika, ze to tedy nepujde.
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: deflink: SendConfigReq(6)
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: IPADDR[6] 0.0.0.0
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: COMPPROTO[6] 16 VJ slots
> with slot compression
Po sestem pokusu o opakovani dochazi serveru trpelivost:
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: deflink: RecvTerminateReq(9)
> Sep 1 14:18:18 MyPC ppp[11402]: tun0: IPCP: deflink: SendTerminateAck(9)
Tim pokus o spojeni konci.
Je zrejme, ze problemy jsou dva - MPPE o kterem byl dotaz. Tam to
vidim jako jasne - je potreba prestat naprosto zbytecne konfigurovat klienta
tak, ze muze (libovolne) pouzit jakykolvi autentizacni protokol, ktery si
zamane. Kdyz chci, aby pouzil CHAP81, reknu, ze ma pouzit CHAP81 a nerikam s
tim soucasne CHAP, PAP a dalsi. Troufam si verit, ze tohle bude pro reseni
problemu stacit.
A pak je tu jeste zretelny druhy problem, ktery soucasti otazky
nebyl - klient se se svym serverem neni schopen a ochoten dohodnout na tom,
jakou bude mit adresu. Tady je to s odhadem, kde je chyba, slozitejsi -
osobne bych to tipoval na chybnou konfiguraci serveru, ktery pro tohoto
klienta uz nema zadnou IP adresu, kterou by smel pouzit a kterou by mu tedy
k pouziti nabidnul.
Dan
More information about the Users-l
mailing list