From owner-freebsd-isdn@FreeBSD.ORG Sun Apr 6 13:51:55 2003 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4374837B401 for ; Sun, 6 Apr 2003 13:51:55 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CCFA43F75 for ; Sun, 6 Apr 2003 13:51:54 -0700 (PDT) (envelope-from martin@duskware.de) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 192H7J-0003jj-00 for freebsd-isdn@freebsd.org; Sun, 06 Apr 2003 22:51:53 +0200 Received: from [217.225.28.34] (helo=drowsy.duskware.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 192H7I-0007pa-00 for freebsd-isdn@freebsd.org; Sun, 06 Apr 2003 22:51:52 +0200 Received: by drowsy.duskware.de (Postfix, from userid 205) id 082A933A83; Sun, 6 Apr 2003 22:51:49 +0200 (CEST) Date: Sun, 6 Apr 2003 22:51:49 +0200 From: Martin Husemann To: Markus Dolze Message-ID: <20030406205149.GA7714@drowsy.duskware.de> References: <9383.1049641491@www53.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9383.1049641491@www53.gmx.net> User-Agent: Mutt/1.4.1i cc: freebsd-isdn@freebsd.org Subject: Re: Bugs in isdnmonitor? X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2003 20:51:55 -0000 On Sun, Apr 06, 2003 at 05:04:51PM +0200, Markus Dolze wrote: > 4. > When trying to implement the "dump rights" message i discovered the > following in isdnmonitor/monitor.h: > I4B_MON_DRINI_CODE = 2 > I4B_MON_IDEV_CODE = 2 > Two messages with the same event code? While this is surely suboptimal, the I4B_MON_IDEV_CODE is only used in the initial isdnd <-> client handshake, with both isdnd and monitor client in a special state. That's why it did not bite in the in-tree implementation. If you do "fgrep _CODE monitor.h" you will notice three ocurances of such code overlaps in statefull protocol sections. I don't realy care to much about changes in this area - if you think it should be made unique, that's fine with me. Martin P.S.: amazing how much interest drops once your environment changes - when I first did the monitor stuff I needed it for work - now neither work nor me privately even use ISDN data conections any more. I have to struggle hard to keep a working testbed connection for ocasional tests configured.