From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 21:05:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7900F1065673; Sat, 8 Jan 2011 21:05:46 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0168FC17; Sat, 8 Jan 2011 21:05:45 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p08KsWMl018263; Sat, 8 Jan 2011 15:54:32 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sat, 08 Jan 2011 15:54:32 -0500 (EST) Date: Sat, 8 Jan 2011 15:54:32 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bjoern A. Zeeb" In-Reply-To: <20110108185914.D14966@maildrop.int.zabbadoz.net> Message-ID: References: <20110107103837.E14966@maildrop.int.zabbadoz.net> <20110108185914.D14966@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:05:46 -0000 On Sat, 8 Jan 2011, Bjoern A. Zeeb wrote: > On Sat, 8 Jan 2011, Daniel Eischen wrote: > >>>>>> When sending multicast packets to a socket that is _not_ >>>>>> bound to the multicast address, this generates bad UDP >>>>>> checksums. This use to work and was broke sometime between >>>>>> the middle of October and late December as far as I can >>>>>> tell. >>>>> >>>>> My very best guess would be: r215110 >>>> >>>> It doesn't look very harmful, but I'll try backing it out. >>> >>> Backing this out seems to fix it. I'll have to test it >>> more after I get some sleep ;-) >> >> I've attached what may be a proper patch. Please review. >> I'd like to get this fixed in releng_8 too. > > I would remove the comment from the MC good path about the in_pcbladdr() > error but just change the description at the top s,use,prefer, to be > more exact. Agreed. > The other question I am not sure what shoud happen is, in the case > in_pcbladdr() returns a source address but a given one via MC option/ifp > does not find an address (in case outgoing itnerface could be different)? > That was never considered in the past. Yes, I considered that as well. I wasn't sure about that, but the more I think about it, it might make sense to ignore any error from an invalid/nonexistent interface set as an MC option if we are able to find one via in_pcbladdr(). But we'll ignore that for now. Also, are there any restrictions with jail? If we're in a jail and can't find an address, do we really want to allow _any_ address set with an MC option? I've never used jails, but was just wondering if the application could somehow use an interface address that it wasn't allowed to use. > It's probably easiest understood with the slightly modified version > of the patch. > > Otherwise I think it would match both the historic behaviour again > and keep the fix for r215110 (that rev. should be mentioned in the > commit message). > > So apart from the 1 line comment change (ignoring my XXX-BZ completely > for the moment and this fix) this looks good. Ok, I'll commit the patch, and thank you very much for helping me solve this problem :-) -- DE