RE: User PPP přes null-modem kabel

[lists at hosting50.cz]

Chapu to tedy spravne tak, ze na serveru by mel byt ppp spusten napr. Ppp
-dedicated default nebo ppp -ddial default a na klientovi ppp -auto default?

Konfiguraci serveru mam nyní nasledujici:

default:
 set log Phase Chat LCP IPCP CCP tun command
 set device /dev/cuaa1
 set speed 115200
# set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \
#           OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
 set timeout 0
 set lqrperiod 10
 set log Phase LQM
 set ifaddr 172.20.10.1 172.20.10.2 255.255.255.0
 enable lqr
 accept lqr

Set dial jsem vyhodil

Klient ma:

default:
 set log Phase Chat LCP IPCP CCP tun command
 set device /dev/cuaa1
 set speed 115200
 set dial
 set timeout 900
 set lqrperiod 10
# set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp HELLO"
 set ifaddr 172.20.10.2 172.20.10.1 255.255.255.0
 enable lqr
 accept lqr


Zkousel jsem vice moznosti, ale ani jedna nezabrala
Kabel jsem si jisty ze funguje - promeroval jsem rxd txd a gnd, overoval
jsem i cisla portu tak nevim, ještě zkusim jiny pocitac.
Nemuze to by taky OS? na jednom mam 4.8 a na druhem current třeba je tam
nejaky bug.

Tomas Randa

-----Original Message-----
From: users-l-bounces at freebsd.cz [mailto:users-l-bounces at freebsd.cz] On
Behalf Of Dan Lukes
Sent: Tuesday, January 20, 2004 1:55 PM
To: FreeBSD mailing list
Subject: Re: User PPP přes null-modem kabel

lists at hosting50.cz napsal/wrote:
> Takze zkusil jsem vyhodit prikaz login.. A tady je vysledek, evidentne se
to zmenilo:

> tun0: LCP: deflink: SendConfigReq(1) state = Stopped
> tun0: LCP:  ACFCOMP[2]
> tun0: LCP:  PROTOCOMP[2]
> tun0: LCP:  ACCMAP[6] 0x00000000
> tun0: LCP:  MRU[4] 1500
> tun0: LCP:  MAGICNUM[6] 0xf5d059c1
> tun0: LCP:  QUALPROTO[8] proto c025, interval 10000ms
...
> tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent
> tun0: LCP:  ACFCOMP[2]
> tun0: LCP:  PROTOCOMP[2]
> tun0: LCP:  ACCMAP[6] 0x00000000
> tun0: LCP:  MRU[4] 1500
> tun0: LCP:  MAGICNUM[6] 0xf5d059c1
> tun0: LCP:  QUALPROTO[8] proto c025, interval 10000ms

> Z toho moc moudry nejsem... 

	No, PPP se pokusilo zahajit hanshaking s protistranou. Vysila, stale
dokola, request, na ktery nedostava odpoved. Neni ani videt zadne requesty z
druhe strany.

	V tomto okamziku uz bude nutne zacit pozorovat i druhou stranu.
Stejny LOG. Pokud se tam budou objevovat radky "RecvConfigReq" (nebo tak
nejak) pak vime, ze kabel je pruchozi a chyba je v konfiguraci PPP (pripadne
ve vzajemne konfiguraci).

	Pokud se tam nic takoveho objevovat nebude, znamena to, ze seriove
propojeni neni funkcni.

	Trochu se priklanim k te druhe moznosti, protoze kdyby funkcni bylo,
prinejmensim bychom na teto strane meli pozorovat prichod konfiguracnich
requestu z druhe strany - a nic takoveho nepozoruji.

	Jeste jedna moznost je, ze seriak je funkcni, ale protistrana je
nakonfigurovana tak, ze vubec nevi, ze seriak pod ni je aktivni a ona by na
nem mela poslouchat - tim mene odpovidat.

	Vsiml jsem si, na teto strane provozujete PPP v mode "auto". To neni
doporuceno (z manualu plyne, ze vhodne je "dedicated", ja osobne ale spise
doporucuji "ddial") a neni to ani prilis vhodne. V kazdem pripade muze byt
problem, pokud mode "auto" pouzivate na obou stranach.

> A taky nevim proc pise deflink: /dev/cuaa1 doesn't support CD jestli není
pricina tam..

	No, je pravdepodobne, ze zapojeni propojovaciho kabelu je takove, ze
skutecne signal CD neprenasi. Nicmene, ten neni pro komunikaci bezpodminecne
potrebny. PPP jeho nepritomnost zjisti a vyrovna se s tim bez ztraty
funkcnosti. Tahle hlaska tedy pro vas problem patrne nic nezmanea.

						Dan


-- 
Dan Lukes      tel: +420 2 21914205, fax: +420 2 21914206
root  of FIONet,  KolejNET,  webmaster  of www.freebsd.cz
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz


--
FreeBSD mailing list (users-l at freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l