Re: [LINUX:7138] ppp baglantisi kurulamiyor

---------

New Message Reply About this list Date view Thread view Subject view Author view

Subject: Re: [LINUX:7138] ppp baglantisi kurulamiyor
From: IOerror (IOerror@tfz.net)
Date: Sun 27 Jun 1999 - 00:32:51 EET DST


Fuat Aktoprakligil wrote:
>
> Iyi gunler;
> Yakinlarda Redhat 6.0 kurdum fakat ppp baglantisi kuramiyorum.
> log lari tail ledigimde baglanti kesilirken asagidaki satirlari elde
> ediyorum.
> ---------------------
> Serial Connection established
> using interface ppp0
> connect ppp0 ?--? /dev/modem
> LCP:timeout sending config-requests
> connection terminated
> connect time 0.6 minutes
> receive serial link is not 8-bit clean
> Problem: all had bit 7 set to 0
> exit
> ----------------------------

PPP-Howto'yu karıştırırken şu satırlara rastladım ve sanırım işinize
yarar.

                                                        -- IOerror

18.3 The syslog says ?serial line is not 8 bit clean...?

There are variations on this too - such as serial line looped back etc.,
and the cause can be one (or a sequence)
of a number of things.

To understand what is going on here, it is necessary to grasp a bit of
what is going on behind the scenes in pppd
itself.

When pppd starts up, it sends LCP (link control protocol) packets to the
remote machine. If it receives a valid
response it then goes on to the next stage (using IPCP - IP control
protocol packets) and only when this
negotiation completes is the actual IP layer started so that you can use
the PPP link.

If there is no ppp server operating at the remote end when your PC sends
lcp packets, these get reflected by the
login process at the far end. As these packets use 8 bits, reflecting
them strips the 8th bit (remember, ASCII is a 7
bit code). PPP sees this and complains accordingly.

There are several reasons this reflection can occur.

You are not correctly logging into the server

When your chat script completes, pppd starts on your PC. However, if you
have not completed the log in process
to the server (including sending any command required to start PPP on
the server), PPP will not start.

So, the lcp packets are reflected and you receive this error.

You need to carefully check and correct (if necessary) your chat script
(see above).

You are not starting PPP on the server

Some PPP servers require you to enter a command and/or a RETURN after
completing the log in process
before the remote end starts ppp.

Check your chat script (see above).

If you log in manually and find you need to send a RETURN after this to
start PPP, simply add a blank
expect/send pair to the end of your chat script (an empty send string
actually sends a RETURN).

The remote PPP process is slow to start

This one is a bit tricksy!

By default, your Linux pppd is compiled to send a maximum of 10 lcp
configuration requests. If the server is a
bit slow to start up, all 10 such requests can be sent before the remote
PPP is ready to receive them.

On your machine, pppd sees all 10 requests reflected back (with the 8th
bit stripped) and exits.

There are two ways round this:-

Add lcp-max-configure 30 to your ppp options. This increases the maximum
number of lcp configure packets
pppd sends before giving up. For really slow server, you may need even
more than this.

Alternatively, you can get a bit tricksy in return. You may have noticed
that when you logged in by hand to the
PPP server and PPP started there, the first character of the ppp garbage
that appears was always the tilde
character (~).

Using this knowledge we can add a new expect/send pair to the end of the
chat script which expects a tilde and
sends nothing. This would look like:-

\~ ''

Note: as the tilde character has a special meaning in the shell, it must
be escaped (and hence the leading
backslash).
 
 Listeden cikmak icin:
          unsub linux
 mesajini listeci@bilkent.edu.tr'a gonderiniz.
   Lutfen Listeci icin MIME / HTML / Turkce Aksan kullanmayin.
  Liste arsivinin adresi: http://listweb.bilkent.edu.tr/


New Message Reply About this list Date view Thread view Subject view Author view

---------

Bu arsiv hypermail 2b25 tarafindan uretilmistir.