home *** CD-ROM | disk | FTP | other *** search
/ Peanuts NeXT Software Archives / Peanuts-1.iso / CDROM / FAQs / PPP / part4 < prev    next >
Encoding:
Internet Message Format  |  1996-10-09  |  12.2 KB
  1. Path: informatik.tu-muenchen.de!fu-berlin.de!zrz.TU-Berlin.DE!stern.fokus.gmd.de!nntp.gmd.de!news.ruhr-uni-bochum.de!news.rhrz.uni-bonn.de!ignatios
  2. From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
  3. Newsgroups: comp.protocols.ppp,news.answers,comp.answers
  4. Subject: comp.protocols.ppp part4 of 8 of frequently wanted information
  5. Supersedes: <ppp-faq/part4_843589201@cs.uni-bonn.de>
  6. Followup-To: poster
  7. Date: 8 Oct 1996 19:18:23 GMT
  8. Organization: computer science department, university of Bonn, Germany
  9. Lines: 249
  10. Approved: news-answers-request@MIT.Edu
  11. Expires: 5 Nov 1996 19:20:02 GMT
  12. Message-ID: <ppp-faq/part4_844802402@cs.uni-bonn.de>
  13. NNTP-Posting-Host: theory.cs.uni-bonn.de
  14. Summary: This document contains information about the Internet Point-to-Point
  15.     Protocol, including a bibliography, a list of public domain and
  16.     commercial software and hardware implementations, a section on
  17.     configuration hints and a list of frequently asked questions and
  18.     answers on them.
  19.     It should be read by anybody interested in connecting to Internet
  20.     via serial lines, and by anybody wanting to post to
  21.     comp.protocols.ppp (before he/she does it!)
  22. Xref: informatik.tu-muenchen.de comp.protocols.ppp:17757 news.answers:83696 comp.answers:21553
  23.  
  24. Archive-name: ppp-faq/part4
  25. Version: $Revision: 3.14 $
  26. Last-modified: $Date: 1996/09/16 18:10:03 $
  27. URL: http://cs.uni-bonn.de/ppp/part4.html
  28.  
  29.                                                   PPP questions and answers
  30.                     4. MISC. PPP QUESTIONS WITH ANSWERS
  31.                                      
  32.        Does somebody have a patent on PPP?
  33.       
  34.        Is it possible to use PPP as link layer in ISDN?
  35.       
  36.        My ppp does infinite configuration negotiation. What's wrong?
  37.       
  38.        My ppp gets strange configure rejects. What's wrong?
  39.       
  40.        What is Asychronous HDLC?
  41.       
  42.        DP package: What is
  43.       str_restore: couldn't push module ldterm
  44.       
  45. 4.1 Does somebody have a patent on PPP?
  46.  
  47.  
  48. From: emv@msen.com (Edward Vielmetti)
  49. Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.protocols.ppp
  50. Subject: Re: Public domain PPP for SCO 2.0??
  51. Date: 8 Dec 1992 06:04:52 GMT
  52.  
  53.    [Somebody] wrote:
  54.    
  55.    Doesn't matter.  I just read (in another newsgroup) that DEC has a
  56.    patent on PPP, and is asking $5000 for a license.  That means no public
  57.    domain PPP, and a rapidly increasing reluctance to support it from OEMs.
  58.     Stick with SLIP until something better comes along.  This is *not*
  59.    true.
  60.    
  61.    DEC has a patent application outstanding for the negotiation of a 48 bit
  62.    checksum which might be used in one of the option negotiation phases.
  63.    It is not an essential part of PPP; many implementations currently do
  64.    not use this little tiny algorithm in the way they work, and they work
  65.    just fine.
  66.    
  67.    There is no indication that the 48 bit FCS will be accepted or
  68.    standardized on by the IETF - from my reading of the  mailing lists
  69.    traffic that is unlikely at this point.
  70.    
  71.    There are free PPPs and there will continue to be free PPPs.  You will
  72.    also more likely buy PPPs as part of hardware you buy.
  73.    
  74. 4.2 Is it possible to use PPP as link layer in ISDN?
  75.  
  76.    [Somebody] wrote: Is it possible to use PPP as link layer in ISDN?  If
  77.    yes, what about signalling? Do you need to combine PPP with the I.451
  78.    for basic call control? PPP over ISDN is described by RFC 1618. It
  79.    promotes PPP in bit-sync or in octet-sync HDLC over ISDN B-channels, or
  80.    PPP in X25 / PPP in Frame Relay over ISDN D-channel.
  81.    
  82. 4.3 My ppp does infinite configuration negotiation.
  83. What's wrong?
  84.  
  85.   4.3.1 [CABLE PROBLEM]
  86.   
  87.    Each other month somebody posts a question which essentially is the one
  88.    above. It could, of course, be some very strange set of configurations
  89.    options which get the ppp to never terminate the negotiation process
  90.    (typical situations listed in further down). One other possibility was
  91.    seen many times on the derivatives of public ppp for suns, namely
  92.    pppd-1.01beta and dp-2.x.
  93.    
  94.    Detailed symptoms (from a posting on the net, I saw similar logfiles
  95.    some  months ago):
  96.    
  97.  
  98.   Typical debugging log output:
  99.  
  100.   Dec 18 16:11:01 pppd[1694]: Starting ppp daemon version 1.0beta patchleve
  101. l 1
  102.   Dec 18 16:11:01 pppd[1694]: warning... not a process group leader
  103.   Dec 18 16:11:01 pppd[1694]: pgrpid = 1694
  104.   Dec 18 16:11:01 pppd[1694]: popped stream module : ttcompat
  105.   Dec 18 16:11:01 pppd[1694]: popped stream module : ldterm
  106.   Dec 18 16:11:01 pppd[1694]: Using unit ppp0
  107.   Dec 18 16:11:01 pppd[1694]: hostname = Riga
  108.   Dec 18 16:11:01 pppd[1694]: connect: ppp0 /dev/ttya
  109.   Dec 18 16:11:01 pppd[1694]: fsm_sconfreq(c021): Sent id 1.
  110.   Dec 18 16:11:01 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  111.   Dec 18 16:11:01 pppd[1694]: Setting itimer for 3 seconds.
  112.   Dec 18 16:11:04 pppd[1694]: Alarm
  113.   Dec 18 16:11:04 pppd[1694]: fsm_sconfreq(c021): Sent id 2.
  114.   Dec 18 16:11:04 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  115.   Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
  116.   Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
  117.   Dec 18 16:11:07 pppd[1694]: Alarm
  118.   Dec 18 16:11:07 pppd[1694]: fsm_sconfreq(c021): Sent id 3.
  119.   Dec 18 16:11:07 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  120.   Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
  121.   Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
  122.  
  123.   ... [lots of repetitious logging deleted] ...
  124.  
  125.   Dec 18 17:02:24 pppd[1694]: Alarm
  126.   Dec 18 17:02:24 pppd[1694]: fsm_sconfreq(c021): Sent id 254.
  127.   Dec 18 17:02:24 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
  128.   Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
  129.   Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
  130.   Dec 18 17:02:26 pppd[1694]: Hangup
  131.   Dec 18 17:02:26 pppd[1694]: Untimeout 6194:16b38.
  132.   Dec 18 17:02:26 pppd[1694]: Setting itimer for 0 seconds.
  133.   Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ldterm
  134.   Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ttcompat
  135.   Dec 18 17:02:26 pppd[1694]: fcntl(F_SETFL, fdflags): Bad file number
  136.  
  137.    The above final is caused by sending a SIGHUP to the pppd process
  138.    (however three successive SIGKILL's seem to be necessary to really   get
  139.    rid of it).
  140.    
  141.      The warning "not a process group leader" appears to be the   innocent
  142.    result of a subtle coding bug, with no later effects,   but I haven't
  143.    tried fixing it (variable "pid" uninitialized).
  144.    
  145.      During all this, there seems to be no activity on the serial line, as
  146.     evident from an Interfaker(tm) breakout patch box.  I was desperate
  147.    enough to lower the speed to 50 bps in order to verify this.
  148.    
  149.      At the same time, "netstat -i" does show increasing figures for the
  150.    ppp0 interface in the "Opkts" column, but in no other column.
  151.    
  152.    Solution: in all cases I could solve, it was a case of missing modem
  153.    control lines in the cables, leading to 'cts' floating to 'false'. The
  154.    LCP FSM happily sent configuration requests (they went to the serial
  155.    line driver buffer (and not out)), waited for an answer, got none, timed
  156.    out, and retried. After lots more of retries, especially on a big
  157.    machine, the send buffer finally does overflow, and ppp stops with an
  158.    error message.
  159.    
  160.    You just have to connect 2,3,4,5,6,7,8 and 20 to the modem to repair it,
  161.    or to wire a reasonably complete null-modem cable. No, there is no
  162.    software hack, except when you patch the sources yourself. And that
  163.    would be a bad idea in my opinion. Even a small Sparcstation SLC can
  164.    overload any modem on a serial line, and you would get lots of
  165.    unnecessary packet drops because of that.
  166.    
  167.                                                                        i.s.
  168.                                                                            
  169.   4.3.2 [ADDRESS CONFIGURATION ERROR]
  170.   
  171.    Each other month somebody posts a question which essentially is the one
  172.    above. It could, of course, be some very strange set of configurations
  173.    options which get the ppp to never terminate the negotiation process,
  174.    but this seems unlikely. This does happen under dp-2.3 [and probably
  175.    others, i.s.] when both sides of the link have differing opinions as to
  176.    what the 2 IP addresses should be.  If the remote-address offered from
  177.    the remote side doesn't match the locally configured version then dp-2.3
  178.    will send back an REJ packet.  The remote side will then resend the
  179.    original address again and the loop will continue.
  180.    
  181.    To see if this is the case check the log for address REJ's.  Then decode
  182.    the two hex addresses and print it out in the normal dot notation.  This
  183.    is the IP address pair of what dp-2.x expected and what it got.  Now
  184.    either reconfigure dp-2.x to expect this address or change the address
  185.    that the other side is sending.
  186.    
  187.                                     Wolfgang Rupprecht <wolfgang@wsrcc.com>
  188.                                                                            
  189. 4.4 What is Asychronous HDLC?
  190.  
  191.    It's HDLC with a character-by-character encapsulation, rather than a
  192.    bit-by-bit encapsulation. The details are discussed in the RFC1331,
  193.    appendix A. Basically, the flag character, the escape character and
  194.    (possibly) control characters are escaped by prepending the escape
  195.    character and XORing them with 0x20, while sync hdlc transparently
  196.    inserts '0' bits after sequences of 5 '1' bits to be sure to never
  197.    transmit the flag character in the frame.
  198.    
  199.    A short description of the part of ISO 3309:1991 that describes async
  200.    (ISO calls it start/stop mode) HDLC is available with anonymous ftp from
  201.    ftp.uni-erlangen.de in pub/doc/ISO/english/async-HDLC.
  202.    
  203.    
  204.    
  205. 4.5 My ppp gets strange configure rejects. What's wrong?
  206.  
  207.    Every few days, s.b. posts a similar question, which melts down to the
  208.    above, when you look at it.
  209.    
  210.    The symptoms are, e.g.:
  211.    
  212.  
  213. Feb  6 09:04:08 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject
  214.  for protocol 29801!
  215. Feb  6 09:04:09 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject
  216.  for protocol 67!
  217. Feb  6 09:04:09 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject
  218.  for protocol 15405!
  219. Feb  6 09:04:11 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject
  220.  for protocol 15405!
  221. ....
  222.  
  223.    Pre-ppp-2.1 implementations (I think); this includes dp-2.x and probably
  224.    early dp-3.x'es are too stupid to detect the old (RFC1172) vs. new  (RFC
  225.    1332 and later) format of VJ compression, although it differs in the
  226.    length and the length is explicit in each option. They tend to be off by
  227.    2 bytes after seeing such an option, and doing horrible things to
  228.    logfiles, like the cited ones.
  229.    
  230.    dp-2.x users should use DP_ARGS=vjmode,draft for talking to nearly
  231.    everything, or switch to ppp-2.1.2 if they don't need autodialup in the
  232.    next few months.
  233.    
  234.    The faulty side is the other one.
  235.    
  236. 4.6 DP package>  When the link goes down,
  237. I get "str_restore: couldn't push module xxx"... What's wrong?
  238.  
  239.    On DP-anything (at least) on SunOS 4.x, when the link goes down, you
  240.    often get these messages:
  241.    
  242.  
  243. Aug 42 01:02:03 machine ppp[181]: str_restore: couldn't push module ldterm:
  244.  No such device or address
  245. Aug 42 01:02:03 machine ppp[181]: str_restore: couldn't push module ttcompa
  246. t: No such device or address
  247.  
  248.    I guess this is pretty normal. The tty line in question was configured
  249.    to create the hangup condition on loss of carrier. The hangup condition
  250.    made the OS disconnect the tty device from the program, send the program
  251.    a SIGHUP signal, and reinitialize the tty line as a normal tty (thats
  252.    what ldterm and ttcompat are for). DP gets the SIGHUP, tries to clean up
  253.    itself (popping its own stream modules and pushing the ones it found
  254.    there when it started) and can't do it any longer.
  255.    
  256.    Maybe dp could detect the condition and not complain, or not try to
  257.    clean up itself; but there might be a misjudgement of the situation,
  258.    leaving the tty without the streams modules, or with dp's own... this
  259.    would be a disaster: you could never again use them from innocent
  260.    programs like getty, login, or kermit.
  261.    
  262.    The way it is now, if it can restore the tty to a sane state, it will;
  263.    if it can't, at least it tried.
  264.    
  265.                                                                        i.s.
  266.                                                                            
  267.    
  268. -- 
  269. -- 
  270. --
  271. Unsolicited junk e-mail will be proofread at US$50.- per page. By sending
  272. such e-mail to my address, you accept these terms.
  273.