Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!solaris.cc.vt.edu!news.mathworks.com!fu-berlin.de!cs.tu-berlin.de!uni-erlangen.de!news.tu-chemnitz.de!irz401!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: PPP on FreeBSD v2.1.0 Date: 10 Jun 1996 18:29:30 GMT Organization: Private BSD site, Dresden Lines: 40 Message-ID: <4phpia$4n0@uriah.heep.sax.de> References: <4p56p5$8js@azure.acsu.buffalo.edu> <31B9F12B.7909@idt.liberty.com> <Pine.NEB.3.93.960609234137.1774C-100000@tomqnx.tomqnx.com> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Tom Torrance at home <tom@tomqnx.com> wrote: > I had similar problems with ppp as well using tun0 to communicate with a > Shiva LAN Rover. Inspecting /var/log/ppp.log, I saw that it was > complaining about an unknown protocol. The unknown protocol should not be the problem. It should be silently disabled, and as long as the protocol wasn't a substantial one (like IPCP -- the IP control protocol), it should continue. However, iijppp has a bug where it falls flat on the face when pred1 compression is not disabled, but the remote peer doesn't speak pred1 CCP. Both peers still negotiate CCP, but cannot agree on a common compression protocol to use. Alas, iijppp still continues to send pred1-compressed data packets later, in the assumption that the existance of a working CCP alone would justify this. :-/ This got very obvious after upgrading a FreeBSD PPP server to FreeBSD post-2.1, where the pppd does also speak CCP (but only knows about BSD compression). The net effect was the same as you described, and since i was unable to find the bug in iijppp i picked the lazy route and hacked pppd to shutdown the CCP layer if no agreement on the compression protocol could be negotiated. (CCP is of no use in this case anyway.) This did at least insure that iijppp and pppd could communicate together without special tweaks, but iijppp remains to be the buggy one. In short, since _you_ can decide to manually disable pred1 compression on your side, _this_ should do the trick for you. (Btw., the apparent effect of the above bug is that you can initially send about one or two ping packets across the wire, before everything starts to stall.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)