From owner-freebsd-current Wed Nov 19 22:47:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14378 for current-outgoing; Wed, 19 Nov 1997 22:47:19 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA14369 for ; Wed, 19 Nov 1997 22:47:14 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA02270 for current@FreeBSD.ORG; Thu, 20 Nov 1997 07:47:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id MAA26992; Wed, 19 Nov 1997 12:33:45 +0100 (MET) Message-ID: <19971119123345.BQ56455@uriah.heep.sax.de> Date: Wed, 19 Nov 1997 12:33:45 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: ppp and ascend router problems References: <199711131806.NAA02823@mailman.iuinc.com> <199711132339.XAA21225@awfulhak.demon.co.uk> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199711132339.XAA21225@awfulhak.demon.co.uk>; from Brian Somers on Nov 13, 1997 23:39:27 +0000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian Somers wrote: > The peer is behaving differently. If this is the same peer, I'd be > surprised. The funny thing here is that we manage to squeeze two > CONFIG REQs out before the peer sends anything. The peer doesn't REQ > for four seconds. That could be a busy radius server on the other end. > I'd examine this with whoever controls (and hopefully understands) > the peer. Basically, if we send a REJ, the peer *must not* REQ the > things that we REJ. We are entitled to drop the connection > immediately if this happens because the peer is violating the ppp > protocol. When debugging FreeBSD's sppp layer, i've in the end sent a large bug report to Ascend, complaining about various protocol violations (the most serious was that they allowed IPCP negotiation before completing authentication phase, and then dropped the successfully authenticated connection, for the only apparent reason that non-AUTH traffic happened before). I've got a quick response, even from a developer, but have yet to hear anything againg from them... -- 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. ;-)