From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 01:17:35 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6171116A41F for ; Sun, 20 Nov 2005 01:17:35 +0000 (GMT) (envelope-from voucko@gmx.li) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A387D43D45 for ; Sun, 20 Nov 2005 01:17:34 +0000 (GMT) (envelope-from voucko@gmx.li) Received: (qmail invoked by alias); 20 Nov 2005 01:17:32 -0000 Received: from p54B044EE.dip.t-dialin.net (EHLO [192.168.0.2]) [84.176.68.238] by mail.gmx.net (mp012) with SMTP; 20 Nov 2005 02:17:32 +0100 X-Authenticated: #10517968 Message-ID: <437FCEAB.80000@gmx.li> Date: Sun, 20 Nov 2005 02:17:31 +0100 From: Michael Voucko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <437B1466.8030202@gmx.li> <20051119165212.O88861@carver.gumbysoft.com> In-Reply-To: <20051119165212.O88861@carver.gumbysoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: Re: "message too long" when sending broadcasts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2005 01:17:35 -0000 >>I'm trying to install the latest version of heartbeat (linux-ha), which >>unfortunately is not available from the ports tree yet. >>Setup is two boxes running (5.4-STABLE FreeBSD from Oct 17 2005) both connected >>to a hub with lnc NICs on a private 10.0.0.0/24 subnet (actually its only a >>'simulated hub' provided by VMWare if this matters). >> >>After some initial struggles configuration, build and installations works as >>expected - but now the most basic parts of this application won't work anymore. >>When trying to use UDP broadcast messages for the heartbeat it would error out >>with "Message too long" for packets larger than 1472 bytes, in other words as >>soon as fragmentation of the package would be necessary (MTU is 1500). >> >>I received a code snippet from the heartbeat developers to isolate the problem >>(create sender and receiver socket, send broadcast packets of a certain size). >>To rule out VMware as the basic problem I tried real boxes but the problem >>persists. >> >>Is there any size restriction for UDP broadcast messages? >>Is there anything which prevents UDP broadcast from being fragmented? >> >>I searched RFCs, man pages for socket, setsockopt, ioctl, sendto and other >>places but did not find anything that could explain the behaviour (which seems >>to be no problem on other OS). >> >>Any pointers, comments? > > >>From sendmsg(2): > > The address of the target is given by to with tolen specifying its size. > The length of the message is given by len. If the message is too long to > pass atomically through the underlying protocol, the error EMSGSIZE is > returned, and the message is not transmitted. > > I remember debugging some funky behavior regarding fragmenting packets and > UDPv6 some time ago. I don't remember if a fix was committed or not. In the meantime I found the explaination. Taken from W. Richard Stevens Unix Network Programming - Vol 1 - 3rd Edition: The Sockets Networking API 20.4 dg_cli Function Using Broadcasting .. IP Fragmentation and Broadcasts Berkeley-derived kernels do not allow a broadcast datagram to be fragmented. If the size of an IP datagram that is being sent to a broadcast address exceeds the outgoing interface MTU, EMSGSIZE is returned (pp. 233–234 of TCPv2). This is a policy decision that has existed since 4.2BSD. There is nothing that prevents a kernel from fragmenting a broadcast datagram, but the feeling is that broadcasting puts enough load on the network as it is, so there is no need to multiply this load by the number of fragments. .... AIX, FreeBSD, and MacOS implement this limitation. Linux, Solaris, and HP-UX fragment datagrams sent to a broadcast address. Maybe it's worth adding this information somewhere to make it easier to find? Michael