From owner-freebsd-current@FreeBSD.ORG Wed Jan 15 11:34:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86C79687; Wed, 15 Jan 2014 11:34:36 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E28A189A; Wed, 15 Jan 2014 11:34:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0FBYUKe032160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jan 2014 15:34:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0FBYU44032159; Wed, 15 Jan 2014 15:34:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Jan 2014 15:34:30 +0400 From: Gleb Smirnoff To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Subject: Re: Regression on 10-RC5 with a multicast routing daemon Message-ID: <20140115113430.GK26504@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , andre@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 15 Jan 2014 11:34:36 -0000 Olivier, On Tue, Jan 14, 2014 at 05:51:53PM +0100, Olivier Cochard-Labbé wrote: O> I'm trying to port a PIM sparse-mode daemon ( O> https://github.com/troglobit/pimd/) and I've meet a problem: O> This daemon compile and run fine on FreeBSD 9.2 but on 10-RC5 this daemon O> can't understand received multicast packets (received from other PIM O> neighbors) and display this kind of error message in debug mode "warning - O> Received packet from 10.0.12.2 shorter (28 bytes) than hdr+data length O> (20+28)". O> How to troubleshoot this problem ? O> O> My current work of this port can be tested with theses commands: O> O> cd /usr/ports O> fetch -o ports.pimd.shar " O> https://sourceforge.net/p/bsdrp/code/HEAD/tree/trunk/BSDRP/patches/ports.pimd.shar?format=raw O> " O> sh ./ports.pimd.shar O> cd net/pimd O> make install TL;DR version: you need not subtract iphdrlen in 10.0. Code in igmp.c:accept_igmp() should be smth like: iphdrlen = ip->ip_hl << 2; #ifdef RAW_INPUT_IS_RAW /* Linux */ ipdatalen = ntohs(ip->ip_len) - iphdrlen; #else #if __FreeBSD_version >= 1000000 ipdatalen = ip->ip_len - iphdrlen; #else ipdatalen = ip->ip_len; #endif #endif You can also look into quagga sources, file ospfd/ospf_packet.c, for more examples of workarounds for this API mess. Long story is the following. Historical behaviour of BSD raw sockets were the following: * packet is modified - packets' ip_len and ip_off are converted to host byte order - packets' ip_len is reduced by the actual size of IP header This is an artefact from the fact that the kernel stack modified every packet at the very beginning of its processing, and worked with it in this form. It just didn't bother to convert it before passing to raw socket, so raw socket wasn't truly _raw_. This is actually a bug. Later, most non-BSD operating systems defined the following API for raw sockets: * packet is passed unmodified btw, I find this much better behavior. Later, right before 9.0-RELEASE, in r226105 (merged to stable/9 as r226299) Andre has changed behaviour to: * packet is modified - packets' ip_len and ip_off are converted to host byte order This appeared a huge disaster to a number of ports, thus it was backed out in r227423 in stable/9. However this remained in head. We decided that all ports should be fixed during two years up to 10.0-RELEASE. Later on, there is a trend for BSD systems to convert their IP stacks to stop modifying byte order internally in kernel. But the compatibility for the raw sockets remained. This is what I did in FreeBSD in r241913 and in r241923. Right now, looking behind, it seems to me that we should have convert raw sockets to be truly raw, like in Linux, right in the 10-release cycle. The API mess should be reduced. According to comments in quagga, DragonFly has the following behavior: * packet is modified - packets' ip_len is reduced by the actual size of IP header Damn, what a mess. I'd like to go towards absolutely unmodified packets for the 11-release cycle. -- Totus tuus, Glebius.