User PPP přes null-modem kabel

[Dan Lukes]

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