연결이 작동하지 않는데는 많은 이유가 있을 수 있다 - chat가 올바로 완료되지 않았을 수도 있고, 회선이 엉네트워크일 수도 있고, 등등. 따라서 지적된 것에 따라 syslog를 점검한다.
PPP 지원을 커널에 컴파일해 넣었는데도 pppd를 실행시키려고 하면 커널에서 ppp를 지원하지 않는다고 하는 것이 제일 흔한 문제 중 하나다! 이런 일이 일어나는 데는 많은 이유가 있다.
앞서 ppp를 지원하도록 커널을 재컴파일했지만 새 커널로 부팅하지
않을 수도 있다. 이것은 /etc/lilo.conf를 고치지 않고 lilo를
다시 실행시켰을 때 이런 경우가 생긴다.
커널에 대한 점검은 uname -a라고 명령하면 얻어낼 수 있는데,
아래와 같은 줄이 나타날 것이다.
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
여기에는 커널의 버젼과 커널이 컴파일된 날짜가 있다. - 이것을 보면 어떻게 된 것인지 잘 알 수 있다.
ppp지원을 모듈로 컴파일했는데, 모듈을 make, install하지 않았다면, 이런
오류가 나타난다. kernel-HOWTO와 README 파일을
/usr/src/linux디렉토리애서 찾아 읽어본다.!
모듈과 관련된 다른 가능성은 자동적으로 모듈이 장전되리라고 생각했는데
kerneld(실행 중에 자동장전 및 장전해제를 해준다)를 실행시키지
않은 경우이다. kerneld mini-HOWTO를 읽어서 kerneld의 설정에 대해
알아본다.
반드시 ppp-2.2는 커널 버젼 2.0.x와 써야 한다. ppp-2.2를 커널 버젼 1.2.x와 함께 쓸 수 있기는 하지만(커널 수정을 할 경우), 그렇지 않다면 ppp-2.1.2를 써야 한다.
pppd를 루트 사용자로서 쓰고 있는 것이 아닐 경우에도(pppd가 루트 사용자용이 아닐 경우) 이런 출력을 받게 된다.
여기에는 많은 이유가 있다.(comp.os.linux를 한번 본다)
가장 일반적인 실수는 스크립트 어딘가에 입력을 잘못한 경우다. 이런
경우에는 리눅스 PC와 서버 사이에 이루어진 chat 대화 내용을
syslog(/var/log/messages) 안에서 확인해 볼 수밖에 없으며,
각 행별로 이를 만들어 가야 한다. 이를 점검하기 위하여
수동으로 ppp 서버에 전화해 볼 필요가 있다.
실제 프롬프트의 내용을 매우 조심스럽게 점검해 볼 필요가 있다 - 그리고 인간은 입력해 넣은 것 대신 자기가 생각한 데로 읽는 경향이 있다는 점을 염두에 두자!
여기에도 많은 이유가 있을 수 있다 - 직렬 회선 귀환 등등이며,
여러가지 것 중 하나(혹은 몇개)가 이유가 될 수 있다.
이 경우 무엇이 문제인지 알려면, pppd 자체에 관한 아래 몇가지 장면에 대해 감을 잡고 있어야 한다.
pppd가 시작할 때 원격 기계에 LCP(연결 제어 프로토콜:Link control protocol)패킷을 보내게 된다. 이때 유효한 응답을 받으면 IPCP(IP 제어 프로토콜:IP control protocol) 패킷을 쓰는 다음 단계로 가며 이 통신이 완료되었을 때에만 PPP연결을 시작할 수 있는 실제적인 ip 배치 작업이 시작된다.
lcp 패킷을 보낼 때 원격에서 작동 중인 ppp 서버가 없다면, 로긴 과정에서 원격 쪽에 반영되어 있을 것이다. 이 패킷은 8비트를 사용하므로, 8번째 비트가 빠진 것으로 반영된다(ASCII는 7비트라는 점을 기억할 것). PPP는 이것을 보고 불평한다.
이러한 반영이 일어날 수 있는 데는 몇가지 이유가 있다.
chat 스크립트가 완료되면, pppd는 내쪽 PC에서 시작한다. 하지만, 서버에서 로긴 과정을 완료하지 않았다면(서버에서 PPP를 시작하도록 요구한 명령을 보내지 않은 경우도 포함해서) , PPP는 시작하지 않는다.
따라서, lcp 패킷은 되돌아오지 않고 이런 오류를 당하게 된다.
조심스럽게 점검해보고 (필요하다면) chat 스크립트를 고쳐야 한다.(앞을 보라)
어떤 PPP 서버에서는 자기 쪽에서 ppp를 시작하기 전에 로긴 과정이 끝난 다음 특정 명령을 주거나 실행키를 누르도록 요구한다.
chat 스크립트를 점검한다 (앞을 보라).
수동으로 로긴한 다음 PPP를 시작하기 위해 실행키도 보내야 한다면, chat 스크립트의 맨 밑에다 빈 기다림/보내기 쌍을 추가하기만 하면 된다(보내기 자리에 빈 문자열을 넣어주면 실제로는 실행키 값을 보낸다).
이때는 잔머리를 좀 굴려야 한다!
기본값으로 리눅스 pppd는 최대 10개의 lcp 설정 요구를 보내도록 컴파일 되어 있다. 만약 서버가 시작하는데 좀 느리다면, 상대방 PPP 가 이를 받을 준비가 다 되기 전에 이 10번의 요구를 다 보낼 수 있다.
그러면 내 기계에서는, pppd가 돌아온 10개를 볼 것이고(8비트가 짤린) 끝내게 된다.
이를 해결하는데 두가지 방법이 있다:-
ppp 선택사항에다 lcp-max-configure 30를 덧붙인다. 이때 늘린
값만큼 pppd는 lcp 설정 패킷을 보낸 다음에 끝낸다.정말로 서버가
느리다고 치면, 이것보다도 값을 더 늘려야 한다.
좀더 잔머리를 굴리는 방법이 있는데 앞에서 이미 보았듯이 PPP 서버에 수동으로 로긴할 때 PPP가 시작하면서 처음에 보내는 쓰레기 값처럼 보이는 것 맨 앞에 나타나는 기호가 (~)이다.
이 지식을 이용해서 chat 스크립트의 맨 뒤에다 ~를 기다렸다가 아무 것도
보내지 않는 기다림/보내기쌍을 추가할 수 있다.
\~ ''
주의: ~이 쉘에서 특별한 의미를 갖고 있으므로, 탈출문자여야 한다(그래서 탈출문자 역슬래쉬가 붙어있다).
pppd가 기본값 라우트를 설정하지 않는다면, (비교적 정확한데) 기존의 기본값 라우트를 지우거나/대체하지 않기 때문이다.
이런 오류가 생기는 보통의 경우는 몇몇 배포본이 이더넷 카드를 특정한 네트워크라우트로 설정하지 않고 기본값 라우트로 설정하기 때문이다.
Linux NAG와 Net2/3 HOWTO를 읽어보면 이더넷 카드를 올바로 설정하는 것과 이와 관련된 라우트에 대해 정보를 얻을 수 있다.
다른 경우는 랜이 자체적으로 게이트웨이/라우터를 이미 쓰고 있고 내 라우팅 테이블이 이 기본값 라우트를 이미 가리키도록 설정되어 있는 경우다.
이 마지막 상황을 고치려면 IP 네트워크에 대한 약간의 지식이 필요하며 이것은 이 하우투의 범위를 벗어난다. 전문가의 조언을 받기를 바란다(뉴스그룹 안에서 로컬적으로 물어볼 수 있는 있는 누군가에게 )
이것 말고도 ppp를 정확하게 연결하고 실행하는 데 실패할 만한 이유는 많다.
PPP FAQ(실제 문답식으로 되어 있다)를 보자. 이것은 상당히 대화식인 문서이며, 해답이 있다! 내 자신의 (슬픈) 경험에 비추어 본다면, 문제가 거기에 없다면, 문제는 ppp의 오류 때문이 아니다! 내 경우 적당한 커널 모듈로 판을 올리지 않은 ELF 커널을 쓰고 있었던 것이다. 나는 겨우 이틀(거기에다 하루밤 거진다)을 완벽한 PPP 서버가 뭐가 잘못됐는지 알아내기 위해 썼을 뿐이지만!