Conference turris::digital_unix

8999.0. "Weird problem with PPP" by SMURF::PETERT (rigidly defined areas of doubt and uncertainty) Fri Feb 28 1997 11:20

    I'm not quite sure how to describe this other than PPP seems to be
    behaving somewhat finicky.  Sometimes it works, and sometimes it
    doesn't.  Here's what's going on:
    
    I'm dialed in from home, connected through ppp right now.  Home
    system is a Sandpiper, running V4.0, ssb (rev. 386).  I've been 
    running ppp ever since we got the 28.8 modems in ZK3.  But for a 
    while now, it only seems to work correctly if I dial into a 
    specific number, and get connected to a specific, ah, node? port?
    closet?  The only one that seems to work, after negotiating password
    and entering my user name, shows up in the prompt as
    
    ZK12C7>
    
    I think that's right, or very close, the C7 is what I look for.
    If I get in through some other line C6, C8, etc, things don't
    seem to work.  And today C7 isn't working right either.  But 
    it's partly working.  I can get into the VMS system, SMURF,
    I can run netscape, and can access some but not all pages.
    But I can't reach quarry, my home and mail system, or my
    officie systems.  At least not totally.  
    
    Here's where things get real screwy.  If I just try an rlogin,
    I don't see much, but if I try telneting to one of these systems,
    I actually connect, get prompted for login and password, and
    usually get a message, 
    
    Last login: Fri Feb 28 08:18:33 from usr406.zko.dec.c
    
    and then I'm stuck.  But now netstat -i shows my input errors
    climbing...
    
    petert@dippikill 51> netstat -i
    Name  Mtu   Network     Address               Ipkts Ierrs    Opkts
    Oerrs  Coll
    ln0*  1500  <Link>      08:00:2b:39:b4:5c         0     0        0    
    0     0
    sl0*  296   <Link>                                0     0        0    
    0     0
    lo0   1536  <Link>                             1155     0     1155    
    0     0
    lo0   1536  loop        localhost              1155     0     1155    
    0     0
    ppp0  1500  <Link>                             5846    92     6821    
    0     0
    ppp0  1500  16          usr406.zko.dec.com     5846    92     6821    
    0     0
    
    I had the idea it might be my something in my .login or .cshrc
    files, but I wouldn't think those get invoked when I try to 
    get in through ftp or access my own homepage through
    netscape.
    
    One thing that might be related, but then again might not, 
    is that if my connection drops at some point, and I dial back
    in, I can only make things work if I get the same line and
    C7 port/closet/whatever.  It appears I get set a particular
    user number, such as usr406.zko.dec.com above, and if I
    get in through a different line, it never gets assigned a 
    new usr number, which I imagine is an ip address, and I have
    to reboot in order to get back to square one.
    
    Has anyone seen anything like this, or have any ideas?
    Right now I'm logged into my Unix systems, but that's only
    because I'm first logged into the VMS system, and then I 
    can telnet to the Unix systems through that.  It's a wee
    bit baffling and restrictive.  
    
    Thanks,
    PeterT
     

    Have you tried to reduce the MRU at your end?

I'll give it a shot.  But I'm pretty sure it's at the low recommended level
right now, 256 or 296.  I've tried turning on debugging, tracking input
packets and such, but I haven't figured a way to tell what's in the
error packets that are causing the ierrs.  Although, now looking at what
I originally wrote, if I read things right, the MTU is 1500 for ppp0.
So maybe I've messed things up somewhere in the /etc/ppp/options file.

PeterT

Well, tried messing with the MRU value, but as I suspected it was already
at the recommended low.

However, I seem to have found a solution.  If I try logging in to the 
Unix systems this gets stuck.Next I login to the VMS machine, and then login over
to the Unix system.  There I can see myself logged in (if inactive) and using
the -M option to who, I can tell where it thinks I'm coming in from.

This matched what ip address I had been assigned, checking the log info
and netstat -i.

Just for the heck of it, I tried pinging my home machine from the
VMS->Unix login, and lo and behold, my stuck login finally came up,
and everything worked fine after that.

So, was this some routing congestion on the Unix side, or some other
such thing?

PeterT

After working with this for a while I believe I've been able to reach the
conclusion that the PPP support in the terminal servers has a bug.  You
should make sure that the mru option is 508 or lower.  You can turn on
debugging and watch pppd negotiate this with the terminal server.

If were talking about the same problem then you should notice:

	o Without changing the MRU, if you try to talk to a Digital UNIX
	  system >= V3.2G then the link will appear to hang.
	o pppd may start logging "FCS errors"
	o If you try to talk to an Ultrix system or to Digital UNIX <V3.2G
	  then this should work (i.e. not hang.)

The terminal server is doing something goofy when the MRU is >508 and
the machine you're trying to talk to is attempting to do "path MTU
discovery".


	-- Farrell


[Posted by WWW Notes gateway]

    This is what I have in my /etc/ppp/options file
    I have logged on right now using the ZK3 ppp server and V4.0B systems
    at both ends.
    
    asyncmap 200a0000       # XOFF, XON, and ^] (the default telnet escape)
    escape 7e,7f,fe,ff,93   # 7-bit and 8-bit variants of rlogin escapes
                            # 0x93 is XOFF or-ed with top bit (0x80)
    mru 1064                        # IP header plus 256 more octets
    
    crtscts                 # Use hardware flow control
    
    defaultroute            # Adds a default route to the system routing
    tables
    

Well, I thank you for all your help, and I'll take Farrell's advice into 
account, but I don't seem to be having much of a problem anymore.  
So why would it clear up with a ping?

PeterT

I have no idea why this would clear up by using ping.

FYI, we ship a default options file that has a bunch of escapes in it.  But
in our environment we don't need them.  So in Vikas' options file he could
get rid of the "escape" line entirely and set the asyncmap to 0 (pppd is
paranoid and will force it to all-ones unless overridden.)  This will
help your throughput.


	-- Farrell

[Posted by WWW Notes gateway]