It is currently Sun, 29 Nov 2020 13:07:18 GMT



 
Author Message
 solaris 8 02/02 pppd odd behavior
I recently started using pppd (sun ppp 4.0) on Solaris 8, 02/02.

I got it working without too many problems, but I see two
things wrong that just don't make any sense.

I am using pppd in persist mode (e.g. not in demand) and without
using "idle" in the config file.

The two problems I see are:

1) pppd times out and hangs up the connection automatically after
exactly 3.1 minutes, every time, even without an "idle" command
in the config files, and nothing I put in the config files seems
to be able to stop it from doing this.

2) when pppd attempts to reconnect (after the holdoff time,
if I set that) the re-connect attempt fails because the
terminal line (/dev/cua/b in my case) has been left configured
with two PPP streams modules, spppconv and spppasyn, or something
like that.  The chat script has no chance whatsoever of getting
the modem to dial out.

I can work around the first problem by having a "ping -I 30 xxx" running,
and I worked around the second problem by writing a small program
that does some IOCTL's to look at what streams modules there are
and keeps popping them if their names start with "sppp".

I searched google and sunsolve and see no hint of these problems
described.  
But these problems seem like absolutely cripping type of problems,
and I don't understand how anyone got Sun's ported version of pppd
to do any useful work with them.  Is it just me that sees them?

Franco

--
Franco Barber
f...@febsun.cmhnet.org
(ignore the address in the headers, it's a bogus address).



 Sun, 21 Nov 2004 01:42:41 GMT   
 solaris 8 02/02 pppd odd behavior

Can you post logs and configuration files, please?  Add the "debug"
command to your configuration, and make sure that daemon.debug is
redirected to a file in /etc/syslog.conf.

Is it possible that the peer is initiating this disconnect, rather
than the local pppd?

That would be "spppcomp" (the compression module).

This means that the connection is still up.  It absolutely should
*not* be attempting to reconnect.  Is it possible that you've somehow
launched multiple copies of pppd?

How do you know that those two streams modules are still plumbed
there?  How did you determine that?

Try "pgrep pppd".

That seems to imply that the problem is at the other end of the link.
It's hard to tell without logs, though.

Are there on *what*?

The plumbing looks like this (by default):

        /dev/udp
           |     I_LINK
           +---------------+
                           |
                           ip
                           |
                       /dev/sppp
                           |      I_LINK
                           +---------------+
                                           |
                                        spppcomp
                                           |
                                        spppasyn
                                           |
                                       /dev/cua/b (or other driver)

The lower stream represents the connection to the serial port and
passes PPP packets as M_DATA blocks.  The upper stream is the
connection into the TCP/IP stack, and is a DLPIv2 interface.

Note that, except for DLPIv2 itself, are all private interfaces that
nobody should be using.

I can say that I'm using it quite successfully with none of the
problems you're seeing.  I'd certainly like to know details of the
*exact* problem you're seeing (rather than just a description of it)
so that I can possibly figure out *why* you're seeing it.

--
James Carlson, Solaris Networking         <james.d.carl...@east.sun.com>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677



 Sun, 21 Nov 2004 20:27:24 GMT   
 solaris 8 02/02 pppd odd behavior
In article <l_6L8.14211$Am4.6880...@twister.columbus.rr.com>,
        febb...@hotmail.com (Franco Barber) writes:

I'm using it in "demand" mode and am possibly seeing the 2nd problem:
sometimes my phone line gets strange and the modem drops the connection.
When that happens (as opposed to an idle timeout), pppd seems to not
realize that the connection has been dropped until it gets confused and
ultimately exits (despite "maxfail 0") being unable to re-establish
a connection (maybe because those modules are still there, but I haven't
verified that yet).

--
mailto:rlha...@mindwarp.smart.net  http://www.smart.net/~rlhamil



 Sun, 21 Nov 2004 20:49:59 GMT   
 solaris 8 02/02 pppd odd behavior
In article <l_6L8.14211$Am4.6880...@twister.columbus.rr.com>,
        febb...@hotmail.com (Franco Barber) writes:

--
mailto:rlha...@mindwarp.smart.net  http://www.smart.net/~rlhamil



 Sun, 21 Nov 2004 20:56:00 GMT   
 solaris 8 02/02 pppd odd behavior
rlha...@smart.net (Richard L. Hamilton) writes:

If your modem is not signalling the disconnection to the computer,
pppd won't know that it happens.  Or, if your RS232 cable does not
carry that connect/disconnect signal to the computer, pppd won't
ever find out.

Make completely sure your modem is configured to turn its DCD signal
on when it gets connected to the other modem, and turns DCD off when
that connection is lost.  Most Hayes-compatible modems use &C1 for
this setting.

Also make sure that the init string your pppd config sends to your
modem does not disable the configuration I described above.

  -Greg
--
:::::::::::::  Greg Andrews  :::::  g...@panix.com  :::::::::::::
     I have a map of the United States that's actual size.
                                -- Steven Wright



 Mon, 22 Nov 2004 02:31:41 GMT   
 solaris 8 02/02 pppd odd behavior
OK, I'm back with the information requested.

First, you're right, the timeout is coming from the remote end.
So, never mind the timeout issue.  The other issue does seem to
be a problem, although to see it you have to have the line drop
by some means, either by the other end dropping it, or by using
the modem's "go on hook" button.

So, here's some information about the environment.
Some info like ip addresses, userid, and passwords has been
stripped out.  I replaced the ip addresses with 1.2.3.4 and
1.2.3.5. These are bogus addresses, not the real ones in use.

The modem is an USR Courier and is on /dev/cua/b.
The remote is a netblazer.
There is no chap/pap used, only login/password.
/dev/cua/b is also used bi-directionally for inbound/outbound uucp.
I set pppd's holdoff to 300 just to have time to see what is
happening after the line drops, before pppd retries the connect.

The modem's nvram stored settings:
   ok
   ATI5

   BAUD=115200  PARITY=N  WORDLEN=8  DIAL=TONE

   B0   F1   M1   X7   &A3  &B1  &G0  &H1  &I0  &K1
   &L0  &M4  &N0  &P0  &R2  &S0  &T5  &U0  &X0  &Y1  %N6  #CID=0

   S00=001  S02=255  S03=013  S04=010  S05=008  S06=002  S07=060  S08=002
   S09=006  S10=014  S11=070  S12=050  S13=001  S15=000  S19=000  S21=010
   S22=017  S23=019  S24=150  S25=005  S26=001  S27=000  S28=008  S29=020
   S31=000  S32=009  S33=000  S34=000  S35=000  S36=000  S37=000  S38=000
   S39=000  S40=000  S41=000  S42=126  S43=200  S44=015  S51=000  S53=000
   S54=064  S55=000  S56=000  S57=000  S58=000  S59=000  S60=000  S61=000
   S69=000  S70=000

/etc/ppp/options:
        lock

/etc/ppp/options.cua.b:
        crtscts
        115200
        asyncmap 0xa0000

/etc/ppp/cmhsub:
        connect "/usr/bin/chat -f /etc/ppp/cmhsub-chat -v -s"
        noauth
        defaultroute
        1.2.3.4:1.2.3.5
        debug
        persist
        linkname cmhsub
        logfile /var/adm/log/cmhsub.log
        holdoff 300

/etc/ppp/cmhsub-chat
        SAY     "Chat starting.\n"
        ABORT   BUSY
        ABORT   'NO CARRIER'
        REPORT  CONNECT
        REPORT  enabled
        ECHO OFF
        TIMEOUT 10
        ""      ATZ
        OK-ATZ-OK       "ATS0=0&M4&K1"
        OK      \c
        TIMEOUT 60
        ""      ATDT1615551212
        CONNECT \r\p\r\c
        in:--in:        userid
        word:   password
        enabled \c

/etc/ppp/ip-up:
        This script is setting the netmask on the interface and
        fooling around with resolv.conf, then it stops/starts
        nscd.

/etc/ppp/ip-down:
        Doesn't do anything.

The link is brought up with this command:
        pppd cua/b call cmhsub

Here's the log file entries for the link coming up:

        serial speed set to 115200 bps
        connect option: '/usr/bin/chat -f /etc/ppp/cmhsub-chat -v -s' started (pid 1114)
        Chat starting.
        ^Mabort on (BUSY)
        abort on (NO CARRIER)
        report (CONNECT)
        report (enabled)
        timeout set to 10 seconds
        send (ATZ^M)
        expect (OK)
        ATZ^M^M
        OK
         -- got it

        send (ATS0=0&M4&K1^M)
        expect (OK)
        ^M
        ATS0=0&M4&K1^M^M
        OK
         -- got it

        send ()
        ^Mtimeout set to 60 seconds
        send (ATDT16145551212^M)
        expect (CONNECT)
        ^M
        ATDT16145551212^M^M
        CONNECT
         -- got it

        send (^M\p^M)
        expect (in:)
        chat:  Jun 05 23:09:59 CONNECT 26400/ARQ/V34/LAPM/V42BIS
         26400/ARQ/V34/LAPM/V42BIS^M
        cmhsub login:
         -- got it

        send (userid^M)
        expect (word:)
         userid^M
        Password:
         -- got it

        send (password^M)
        expect (enabled)
         ^M
        ^M
        Packet mode enabled
         -- got it

        send ()
        ^Mchat:  Jun 05 23:10:02 enabled
        Serial connection established.
        serial speed set to 115200 bps
        Using interface sppp0
        Connect: sppp0 <--> /dev/cua/b
        /etc/ppp/pap-secrets is apparently empty
        /etc/ppp/chap-secrets is apparently empty
        sent [LCP ConfReq id=0x39 <asyncmap 0xa0000> <magic 0x9aba937c> <pcomp> <accomp>]
        rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <magic 0x39f1404e> <pcomp> <accomp>]
        sent [LCP ConfAck id=0x0 <asyncmap 0x0> <magic 0x39f1404e> <pcomp> <accomp>]
        rcvd [LCP ConfAck id=0x39 <asyncmap 0xa0000> <magic 0x9aba937c> <pcomp> <accomp>]
        sent [LCP Ident id=0x3a magic=0x9aba937c "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov  8 2001 18:35:15)"]
        sent [IPCP ConfReq id=0x86 <addr 192.188.133.222> <compress VJ 0f 01>]
        sent [CCP ConfReq id=0x3d <deflate 15> <deflate(old#) 15> <bsd v1 15>]
        rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01>]
        sent [IPCP ConfNak id=0x1 <addr 1.2.3.5>]
        rcvd [IPCP ConfRej id=0x86 <addr 1.2.3.4>]
        sent [IPCP ConfReq id=0x87 <addrs 1.2.3.4 1.2.3.5> <compress VJ 0f 01>]
        rcvd [LCP ProtRej id=0x2 80 fd 01 3d 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
        rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01>]
        sent [IPCP ConfAck id=0x3 <compress VJ 0f 01>]
        rcvd [IPCP ConfAck id=0x87 <addrs 1.2.3.4 1.2.3.5> <compress VJ 0f 01>]
        local  IP address 1.2.3.4
        remote IP address 1.2.3.5
        Script /etc/ppp/ip-up started (pid 1116)
        Child process /etc/ppp/ip-up finished (pid 1116), status = 0

While the link is still up:

        There's a lock file in /usr/spool/locks:
                LK.032.020.131073

        stty -a < /dev/cua/b returns an error:
                # stty -a < /dev/cua/b
                stty: : Invalid argument

Then when the line drops, either because the netblazer
drops the line, or because I push the "go on hook" button on the modem,
this shows up in the log:

        Modem hangup
        Script /etc/ppp/ip-down started (pid 1171)
        Connection terminated.
        CCP: Down event in state Starting
        Connect time 3.1 minutes.
        Sent 854 bytes (46 packets), received 8555 bytes (44 packets).
        Child process /etc/ppp/ip-down finished (pid 1171), status = 0

At this point, this is the state of things:

1)      The uucp lock file is gone.

2)      Stty -a shows some weird output:
                # stty -a < /dev/cua/b                    
                speed 9600 baud;
                rows = 0; columns = 0; ypixels = 0; xpixels = 0;
                csdata ?
                eucw ?, scrw ?
                min = 0; time = 0;
                intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>;
                eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>;
                start = <undef>; stop = <undef>; susp = <undef>; dsusp = <undef>;
                rprnt = <undef>; flush = <undef>; werase = <undef>; lnext = <undef>;
                -parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext
                -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc
                -ixon -ixany -ixoff -imaxbel
                -isig -icanon -xcase -echo -echoe -echok -echonl -noflsh
                -tostop -echoctl -echoprt -e{*filter*}-defecho -flusho -pendin -iexten
                -opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel

3)      If you write a program to open /dev/cua/b and do an ioctl(I_LOOK),
        the name of the stream module that you get back is spppcomp.

4)      If you "tip" to the modem, and you type at it,
        you see that the modem's RD and SD lights do not
        light up at all.

After the holdoff period, when pppd retries the connect script,
this is what gets added to the pppd log file:

        serial speed set to 115200 bps
        connect option: '/usr/bin/chat -f /etc/ppp/cmhsub-chat -v -s' started (pid 1186)
        Chat starting.
        abort on (BUSY)
        abort on (NO CARRIER)
        report (CONNECT)
        report (enabled)
        timeout set to 10 seconds
        send (ATZ^M)
        expect (OK)
        alarm
        send (ATZ^M)
        expect (OK)
        alarm
        Failed
        Connect script failed

There was no response to the ATZ from the modem, so it times out.
It sends another ATZ, and there is no response to that either,
so the connect script failed.

After the holdoff period passes, this will repeat again,
apparently forever, until I do a kill on pppd.

After pppd exits, then:

1)      "stty -a" shows normal output:

        # stty -a < /dev/cua/b
        speed 9600 baud;
        rows = 0; columns = 0; ypixels = 0; xpixels = 0;
        csdata ?
        eucw 1:0:0:0, scrw 1:0:0:0
        intr = ^c; quit = ^\; erase = ^?; kill = ^u;
        eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
        start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
        rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
        -parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext
        -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
        ixon -ixany -ixoff imaxbel
        isig icanon -xcase echo echoe echok -echonl -noflsh
        -tostop echoctl -echoprt e{*filter*}-defecho -flusho -pendin iexten
        opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3

2)      If you look at the streams module on /dev/cua/b (using
        a program written to do an ioctl(I_LOOK) you see "ttcompat".

3)      You can tip to the modem and see your characters echoed
        back by the modem in a normal fashion.

So, the way I am working around this, for now, is by
having written a program that keeps doing an ioctl(fd, I_LOOK, buf)
on standard output.   If the name of the streams module begins
with "sppp", the program does an ioctl(fd, I_POP).  Then it
repeats until the I_LOOK returns an error or the streams name
does not begin  with "sppp".  I use this program as the "init"
program in the pppd peers options file.

Franco
--
Franco Barber
feb AT febsun DOT cmhnet DOT org



 Tue, 23 Nov 2004 04:56:47 GMT   
 
   [ 6 post ] 

Similar Threads

1. LILO booting error(L 02 02 02 02 02 - - - - )

2. Deadline Extension: Federated Conference 2002 (DOA'02, ODBASE'02, CoopIS'02)

3. sunblade 1000, solaris 8 (02/02) and recommended patches

4. Solaris 8 (02/02) installation

5. ADSL on Solaris 8 02/02 - Intel

6. Solaris 8 02/02

7. Solaris upgrade 10/00 to 02/02 possible?

8. Solaris 02/02 Companion CD Questions KDE and Gnome

9. Does Solaris 8 02/02 install on P4

10. Install Solaris 8 02/02 stalls


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software