Serial line is looped back
Al Longyear
I do not know what message that may have been. The message "serial line is
looped back" comes from the fact that of the ten attempts to negotiate an
LCP exchange with the peer (the system on the other end of the telephone),
all ten attempts resulted in a NAK because the magic number was the same.
This almost always (well, of the over 300+ [no joke] complaints of this
condition, only one was not this) results from the user not starting the
PPP protocol on the peer system before either starting pppd or having the
connect program complete successfully.
(The one and only one instance that was the exception was that someone's
modem went on-hook and he was talking to the modem.)
What happens is that usually you call your ISP. This may be over ISDN or a
POTS line. The modems (if this is a valid term for ISDN, but that is a
different issue) will establish synchronization with those squeals that you
hear. They then go online and raise the carrier.
Ok. So, now you have a modem link.
The next step varies greatly. If your provider is 'properly' configured for
ISDN and PPP then you should just be dumped immediately into the PPP
session and do your identification and authentication via the PPP protocols
for this.
However, many providers are not configured 'properly'. They want you to do
a logon sequence. This involves sending your account name and password via
clear text to the peer system. When the account name is validated, there
may be other prompts for protocol, etc.
Eventually you will get to the point where the provider should start the
PPP protocol. When that happens is the time that you should turn pppd loose
on the connection and let it take over the conversation.
So, what happens when this does not work?
Suppose that your provider has changed the logon sequence so that now, in
addition to your password, he wants to know your zip code or some other
stupid thing. Your script has completed successfully and the pppd process
is trying to negotiate the connection with the peer.
The peer is not running the PPP protocol and the pppd process is talking to
the login processor who is busy echoing the data (they tend to do this) and
following it with "what is this trash? I asked you for your zip code and if
you don't give it to me in the next minute, I'll disconnect." (I am being
silly to make a point. Just stay with me.)
The pppd process sees a LCP configure request frame since it sent one and
that was echoed. The protocol says that you are to exchange LCP configure
request frames and therefore this is a good thing. However, the pppd
process put a 'magic' cookie in the frame. This is called the 'magic
number'. You can see it if you look at the trace. It will be identified as
<magic .....>.
The PPP protocol requires that if you use this magic number that each
system must generate a value and that you are not permitted to receive the
same value as what you sent. This is to prevent the loop condition that you
have because the pppd process is not really talking to another PPP protocol
driver. It is still talking to the login processor which is looping the
data that it is seeing back to what it believes is the 'human'.
The response for pppd is to send a NAK frame and say that the magic value
is invalid. Of course, the NAK is also received back naking the pppd
process' LCP configure request.
Then the process starts over again. The pppd process chooses a new value
and repeats. This is also looped and so it goes and so on and so on and so
on.
After about 10 attempts (this is a configurable option), the pppd process
will say "I've had enough. We have chosen ten different 32 bit numbers and
all ten have been the same between the two computers. You have a loop." In
fact, the odds of two computers choosing the exact same string of ten
thirty-two bit numbers "with replacement" is one in 2 to the 320th power. I
am sorry, but my calculator does not compute a number that high.
The probabilities are so lopsided that there can be only one real answer to
someone who asks this question about the serial line being looped back and
that is "YOU HAVEN'T STARTED THE PPP SOFTWARE ON THE PEER SYSTEM. You may
have thought that you did but you didn't." There are very few statements
which are true these days. That was one of them. Every characters which
PPPD sends out the transmitter is being reflected back into the receiver.
This is called a 'loop.'
You can disable the magic number sequence. There is an option for doing
this. Will this solve the problem? No. It won't. It will only cover it up.
(The only valid reasons for disabling the magic number are if you connect
to a system which totally croaks when it sees the tag or does not follow
the RFCs and sends your own magic number back to you in its configure
request frame. I have yet to find one reference to any system which does
this.)
Now, granted, most ISPs don't ask for a zip code. So, what can be wrong?
Well, almost anything may be wrong. Perhaps you mis-spelled your account
name. Perhaps you mis-spelled your password. Perhaps you are entering the
wrong password. Perhaps there is something on the ISP which is preventing
the normal logon sequence from completing (such as their RADIUS servers
being down). Perhaps you are just too quick in entering the password and
the ISP has flushed the receive buffer but since you sent the password, you
think that all is well. Perhaps you are over your account limit or
something else is preventing your logon. Perhaps you don't have the
authority to run the PPP software on the peer if you are starting it
yourself. Or, perhaps this _specific_ terminal server (most providers have
more quantity than one) does not support PPP.
The list is quite long. It could be any single or any combination of events
which is preventing you from starting the PPP software on the peer system.
The solution is not very objective. You can do it one of two ways. I would
suggest that you do it in both steps, in the order listed.
1. Use minicom, kermit, seyon, telix, qmodem, or whatever terminal emulator
that you like and call the ISP using your account telephone number, your
account name, and your password. Do you see the PPP frame? It is not hard
to spot. It will look like a burst of about forty characters, starting and
ending with a ~, and have several { characters in it. Most of it will
appear as junk, but that seems to be a good 'signature' for the frame.
If you see some other error message or some other trash, then deal with it.
2. If you are using chat or dip, add an expect string to the end. Add
something which you know will never happen. Turn on the logging so that it
will print or log everything that it receives. Do you see the PPP frame?
Don't worry about doing any damage to the peer system. You may just
disconnect or simply wait for the peer to disconnect on you because you did
not answer them. They will, eventually, disconnect.
Now, you should not have to logon to the system with ISDN. You should be
able to just start the PPP protocol if your ISP is smart enough to realize
that the PPP protocols are best left to do the identification that they
want for billing purposes. However, if you still must logon, then just
follow the instructions for doing a POTS style connection. There is no
difference with ISDN other than the lack of a dial tone.
I have stated why the message occurs, where it occurs, when it occurs, and
the procedure for resolving the condition.
Please give, as I shall not, whoever asks this question again a copy of
this response or point them to the PPP HOWTO or the PPP FAQ documents with
my complements.
----------
From: Bill Hogan[SMTP:bho...@bedlam.rahul.net]
Sent: Monday, September 23, 1996 3:56 AM
To: linu...@vger.rutgers.edu
Cc: Bruce Vrieling
Subject: Serial line is looped back
------- start of forwarded message (RFC 934 encapsulation) -------
From: Bruce Vrieling <bvri...@torcon.com>
To: bho...@bedlam.rahul.net
Subject: Serial line is looped back
Date: Mon, 23 Sep 1996 06:29:49 -0400 (EDT)
Hi Bill,
I was hunting around on some of the Linux net archives for information on
a strange error I have been getting with PPPD: "Serial line is looped
back".
When I was running 1.2.13, everything went fine. Then I upgraded to
kernel 2.0, and my ISDN line refuses to connect any more, with this error.
You mentioned in an email to Nuno Serrenho that you had a message from Al
Longyear describing what this was all about, and (hopefully!) a fix.
If you could send that to me, I'd be thankful. :)
...Bruce
------- end -------
Hi, Bruce.
I'm don't have a copy of the message you are talking about, and I
can't recall what I said in it, so I am forwarding your question to the
linux-ppp mailing list.
Best regards,
Bill
Al Longyear
It may be that you are actually occurrence number 2 of the modem echo
problem. What happened to that gentlemen is that for some strange reason,
the modem just went to "NO CARRIER" during the LCP exchange. We never did
find the reason for this. The modem reports showed that the modem had
sensed the loss of the DTR at the local end and that was the reason for the
disconnection.
However, since the modem dropped and the modem was set to echo the
commands, then the modem dutifully echoed the LCP frames and this caused
the problem.
The solution was to program the modem to ignore the DTR signal. Now, while
this is not a recommended solution in the general case, in this specific
case, it did fix the problem since for some strange reason, the modem must
have been seeing a glitch on the DTR signal and disconnecting.
This only showed up when you run the pppd process with the option 'kdebug
31'. This tells pppd to tell the driver to log to the system log all
characters received and sent to the tty driver. It is a long log file, but
if you still have mysterious problems, you may wish to explore this
solution also to get additional information.
I hope that you did not mis-understand me. I do not try to pontificate.
None of this is dogma. Since I am not there, you will have to solve the
problem. I can only give you pointers and a culmination of oh so many
problem reports. However, you will have to act as your own hands and eyes.
I'll help if you need an explanation of the log file, but that is about the
limit.
I am glad that the Bitsurfr Pro can understand the commands. A point of
concern is that the modem is programmed correctly. It should present the
equivalent of a DCD signal to the computer. This is critical in the
computer knowing that the modem link is still active. Many times the modem
must be programmed to do this operation since most modems were derived from
the original DC Hayes 300 "Smartmodem" which came with dip switches set to
ignore the DTR, keep DCD high, etc. Their 2400 modem had the same defaults,
only set in software.
I can only suggest that you ensure that the reset string which your Cisco
sends to the modem forces the modem into the proper mode. Don't just
believe in ATZ or, even worse, AT&F in doing this. Actually send the modem
commands to put the modem into sensing the DTR and reporting DCD.
I would also suggest that you include the equivalent of "ATS2=128" to
ignore the attention code on this modem.
Good luck.
That's about all that I can offer in terms of help with what you have given
me.
p.s. If you do decide to log the raw characters, do NOT post them to this
list. If you must, send them to me by email.
----------
From: Bruce Vrieling[SMTP:bvri...@torcon.com]
Sent: Monday, September 23, 1996 2:23 PM
To: Al Longyear
Cc: linu...@vger.rutgers.edu
Subject: RE: Serial line is looped back
In each case, there was no logon sequence. When I tried dialing in with
Minicom, I see the peer sending me the PPP gibberish. There is no userid
and password; things are done through PAP authentication.
The fact that I am using an ISDN modem doesn't fit into the picture
really; it is a Bitsurfr Pro, and acts like a modem. I can send AT
commands and whatnot, and simply dial their router.
So you see, I'm a little confused. You mention that the vast majority of
the complaints you have received about this issue have to do with PPP not
being started on the peer. This is not the case. And, reflection of my
data back to me does not seem to be done; there is no mistyped Logon:
or Password: string. It looks like I am getting REAL PPP data spat back
at me.
Like you say though, trying the -MN flag does not help. PPPD starts the
connection, but it does not really work, since it is working with the
reflection, and doesn't know it.
I checked the messages file. I get the connect string, and the PPPD
starts. Less than 6 seconds later, it terminates every time. Once it
worked. 4 days later, and many machine reboots, it doesn't. Nothing
changed.
I'm going to visit the unit this evening, and turn on the most verbose
debugging I can find, and see what it says. Any further insight you might
be able to offer would be appreciated.
Bruce Vrieling
Hi Al,
First of all, thanks for the lengthy reply. :)
On Mon, 23 Sep 1996, Al Longyear wrote:
> I do not know what message that may have been. The message "serial line is
> looped back" comes from the fact that of the ten attempts to negotiate an
> LCP exchange with the peer (the system on the other end of the telephone),
> all ten attempts resulted in a NAK because the magic number was the same.
I suspected something like that, without knowing the details. :)
> This almost always (well, of the over 300+ [no joke] complaints of this
> condition, only one was not this) results from the user not starting the
> PPP protocol on the peer system before either starting pppd or having the
> connect program complete successfully.
Had I known Bill would forward my email to the listserv, I would have
stated a few more specifics.
First of all, in both instances I have seen this, the machine at the
other end (the peer) was a CISCO router.
In each case, there was no logon sequence. When I tried dialing in with
Minicom, I see the peer sending me the PPP gibberish. There is no userid
and password; things are done through PAP authentication.
hh
The fact that I am using an ISDN modem doesn't fit into the picture
really; it is a Bitsurfr Pro, and acts like a modem. I can send AT
commands and whatnot, and simply dial their router.
So you see, I'm a little confused. You mention that the vast majority of
the complaints you have received about this issue have to do with PPP not
being started on the peer. This is not the case. And, reflection of my
data back to me does not seem to be done; there is no mistyped Logon:
or Password: string. It looks like I am getting REAL PPP data spat back
at me.
Like you say though, trying the -MN flag does not help. PPPD starts the
connection, but it does not really work, since it is working with the
reflection, and doesn't know it.
I checked the messages file. I get the connect string, and the PPPD
starts. Less than 6 seconds later, it terminates every time. Once it
worked. 4 days later, and many machine reboots, it doesn't. Nothing
changed.
I'm going to visit the unit this evening, and turn on the most verbose
debugging I can find, and see what it says. Any further insight you might
be able to offer would be appreciated.
...Bruce
Gilbert Callaghan
Al, thanks for the discussion on the "serial line is looped back" message.
I would like to comment on a problem I am having which may have a different
answer.
At work, I have created a WAN between our home office and 6 divisional
offices using 28.8 modems, Linux, diald, and pppd on *both* ends. Pppd
is routing IP and IPX. It is working flawlessly - except (you knew this
was coming, right?) the link between Houston and Corpus Christi. It takes
about 2 ot 3 redials before the connection is made. About 50 to 75% of the
time I get the "serial line is ..." message. If I dial in with kermit and
tail the /var/log/messages file it thinks that it connected ok and then
the "link was terminated by peer" or something like that.
I don't think the lines are flakey because I can see the 'chat'
dialog on my local /var/log/messages and it looks clean - all the
way to 'Starting pppd'.
Any comments? Thanks for any insight.
--
Gilbert Callaghan
gil...@pokey.inviso.com
Al Longyear
This is really the same problem. It is just another symptom. You haven't
started the PPP protocol at the time that you told pppd to start.
Until the PPP protocol is started on the peer system there is an excellent
chance that the tty drivers will do the automatic echo of the input.
When the pppd process receives a frame, it will do some checks on the
input. One of them is to look at the magic number. If this is the same, a
NAK frame is immediately sent to the peer.
This sequence can happen fairly quickly and in no time at all you will go
through all ten attempts at sending the LCP configure request frame.
So, for your case, you may wish to consider having the 'caller' system use
the option 'quiet'.
The 'quiet' option says "Don't start the session. Wait for the other guy to
send data first before you attempt to negotiate the PPP protocols." In
effect, the system which calls will simply do the call and then wait for
the other end to send it a PPP frame. Until it receives a frame, no frames
will be sent. No timers will be started. Nothing. It will just sit there
and wait. -- Forever if you don't manually intervene and disconnect the
modem.
Another solution is to configure the 'caller' system to look for the start
of the PPP frame before it declares the connection as being valid. Look for
the ~ character. While you will loose the first frame, you won't be too
'quick' in starting the PPP protocol on the caller side before the callee
has started PPP.
----------
From: Gilbert Callaghan[SMTP:gil...@pokey.inviso.com]
Sent: Monday, September 23, 1996 8:31 PM
To: linu...@vger.rutgers.edu
Subject: Re: line is looped back; thread won't die
Bruce Vrieling
Hi Al,
On Mon, 23 Sep 1996, Al Longyear wrote:
> It may be that you are actually occurrence number 2 of the modem echo
> problem. What happened to that gentlemen is that for some strange reason,
> the modem just went to "NO CARRIER" during the LCP exchange. We never did
> find the reason for this. The modem reports showed that the modem had
> sensed the loss of the DTR at the local end and that was the reason for the
> disconnection.
This was EXACTLY the problem. I added some delays to the CHAT script, and
then watched the messages file (tail -f messages) as I attempted to
connect. The DTE light on the modem would drop right before PPPD would
start. It then would start, sit for 5 seconds, and report the serial line
loopback problem.
Funny thing was, when I used minicom, the line NEVER dropped after the
connect. Only when I used CHAT + PPPD.
My solution? I fiddled with the ATS25 command. I didn't want to leave DTR
off completely, or else hanging up was not easy. This was the only other
DTR command in the book, so I played with it. ATS25=2 made the problem
worse, ATS25=10 solved the problem. The default was 5, and I did not play
with any other values.
> This only showed up when you run the pppd process with the option 'kdebug
> 31'. This tells pppd to tell the driver to log to the system log all
> characters received and sent to the tty driver. It is a long log file, but
> if you still have mysterious problems, you may wish to explore this
> solution also to get additional information.
Didn't get into that. Problem was fixed before it become necessary. :)
> I hope that you did not mis-understand me. I do not try to pontificate.
> None of this is dogma. Since I am not there, you will have to solve the
> problem. I can only give you pointers and a culmination of oh so many
> problem reports. However, you will have to act as your own hands and eyes.
> I'll help if you need an explanation of the log file, but that is about the
> limit.
Sorry if I came across as a little short. I was typing from a terminal
that did not properly understand VT100, through a line that felt like
300 baud, and I was attempting to finish the message as fast as possible
to put an end to my ordeal. :) Your message was very helpful, and hit the
problem right on the nose.
> I would also suggest that you include the equivalent of "ATS2=128" to
> ignore the attention code on this modem.
Hmmm. Then I can't send any more commands to the modem... not sure that
is a good idea. However, I see what you are getting at. Hmmm...
> That's about all that I can offer in terms of help with what you have given
> me.
Problem is fixed, machine is up. :)
Thanks again!
...Bruce