From owner-cvs-all@FreeBSD.ORG Thu Jan 26 20:13:41 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4FDD16A420; Thu, 26 Jan 2006 20:13:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7077143D45; Thu, 26 Jan 2006 20:13:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 12:13:40 -0800 Message-ID: <43D92D73.40409@elischer.org> Date: Thu, 26 Jan 2006 12:13:39 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <200601261306.k0QD6o4P070834@repoman.freebsd.org> <43D927B4.9040602@elischer.org> <20060126195806.GC83922@FreeBSD.org> In-Reply-To: <20060126195806.GC83922@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph ng_pppoe.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 20:13:41 -0000 Gleb Smirnoff wrote: >On Thu, Jan 26, 2006 at 11:49:08AM -0800, Julian Elischer wrote: >J> try not to change the behaviour of the LMI and PPPoE modules too much. >J> the modules as they were, were certified by MCI as being complient with >J> their >J> PPPoE requirements. >J> Some of the required behaviours were odd to me becasue they were not >J> specified by the spec. >J> (e.g. this behaviour) > >Ok. Should I hide the new behavior under a sysctl, turned off by >default? It isn't destructive however. Is there any available test >to verify whether any check is broken with new code > It should be controllable, but you can enabe it by defalult.. I no longer have the specs etc. and have lost contact with the MCI guy. (though he was a freebsd user which was cool) >? > >The other change I'm planning to do is the following - if the >original PADI had empty Service-Name, and we are servicing a >specific Service-Name, then return remove empty one from PADO, >returning only our specific Service-Name. > >J> An interesting story.. >J> >J> I went to Dallas where their test lab was, with a laptop and the test >J> box (actually 2 of them) >J> (A whistle Interjet) and all the sources. When, in the first morning, >J> they gave me a list of >J> tests for which they wanted changes, (i.e. it failed,) I made the >J> changes over the >J> lunch hour on my laptop, and comiled up a new kernel and asked them to >J> retest in the afternoon. They were amazed as they had never seen >J> turnarund in less that 3 months >J> (mainly from big companies). >J> >J> Needless to say, it passed with Flying colours in the second try, but >J> according to the paperwork >J> it passed with flying colours on the first try (from their perspective). >J> Something else they >J> had never seen. :-) > >I did the draft of this change at the D-Link office, too, while their >guy was testing different gear against current FreeBSD. :) > > >