From owner-freebsd-net@FreeBSD.ORG Wed Apr 20 21:27:13 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69D4416A4CE; Wed, 20 Apr 2005 21:27:13 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 039D943D1F; Wed, 20 Apr 2005 21:27:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3KLRBms035007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2005 14:27:12 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4266C9D7.1010906@errno.com> Date: Wed, 20 Apr 2005 14:29:59 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20050419064747.GC734@cell.sick.ru> <4264D430.D39B81D0@freebsd.org> <20050419120324.GA5862@cell.sick.ru> <4264F4BC.4F3B57AE@freebsd.org> <20050419121141.GB5862@cell.sick.ru> <4264F7D4.F5A9775F@freebsd.org> <42652357.8020604@errno.com> <20050419171406.GA378@cell.sick.ru> In-Reply-To: <20050419171406.GA378@cell.sick.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Andre Oppermann cc: net@freebsd.org Subject: Re: if_link_state_change() patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 21:27:13 -0000 Gleb Smirnoff wrote: > On Tue, Apr 19, 2005 at 08:27:19AM -0700, Sam Leffler wrote: > S> >change message will report either all state changes or those where at > S> >the time of reporting the state changed relative to the last report. > S> >The same assumption is true for the OpenIGPd we are working on at the > S> >moment. > S> > S> It is possible with the change to defer the messages to have multiple > S> changes coalesced. If an app is written to assume it receives notice of > S> every change and it uses this to track internal state then it can get > S> confused. The issue was whether or not to communicate any coalescing to > S> applications so they can recognize that it's happened. In lieu of doing > S> that I asked for a console printf so we could see if it ever happened in > S> practice. > > Yes, all the time we are speaking about a theoretical issue. Let's see > whether it can happen or not. I decided to go ahead with this change. > > S> >From an (routing) application point of view only effective state changes > S> >are interesting and only those should be provided. > S> > > S> > S> If an inteface does down, moves network, then comes back up and you only > S> get the up event then you will likely do the wrong thing unless you have > S> some other way of identifying what happened. I'm not convinced (yet) > S> this cannot happen so am being cautious. > > In this case you will receive additional messages, not only RTM_IFINFO. > Move network will also generate RTM_NEWADDR and RTM_DELADDR > Only if someone sets the address which won't be true in the case I'm thinking of: dhclient handling a wireless nic that re-associates with a different ap. But since the dhclient I'm thinking of isn't in the tree yet I'll look at the problem myself. Sam