From owner-freebsd-stable@FreeBSD.ORG Mon Nov 21 12:14:26 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 827E216A41F for ; Mon, 21 Nov 2005 12:14:26 +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 C4E5F43D46 for ; Mon, 21 Nov 2005 12:14:25 +0000 (GMT) (envelope-from voucko@gmx.li) Received: (qmail invoked by alias); 21 Nov 2005 12:14:23 -0000 Received: from p54B0794F.dip.t-dialin.net (EHLO [192.168.0.2]) [84.176.121.79] by mail.gmx.net (mp036) with SMTP; 21 Nov 2005 13:14:23 +0100 X-Authenticated: #10517968 Message-ID: <4381BA1E.3050005@gmx.li> Date: Mon, 21 Nov 2005 13:14:22 +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> <437FCEAB.80000@gmx.li> <20051120130304.T8182@fledge.watson.org> In-Reply-To: <20051120130304.T8182@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 21 Nov 2005 12:14:26 -0000 >> 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? > > It would also be quite easy to make this configurable -- the code in > ip_output is fairly straight forward: > > /* > * Look for broadcast address and > * verify user is allowed to send > * such a packet. > */ > if (isbroadcast) { > if ((ifp->if_flags & IFF_BROADCAST) == 0) { > error = EADDRNOTAVAIL; > goto bad; > } > if ((flags & IP_ALLOWBROADCAST) == 0) { > error = EACCES; > goto bad; > } > /* don't allow broadcast messages to be fragmented */ > if (ip->ip_len > ifp->if_mtu) { > error = EMSGSIZE; > goto bad; > } > if (flags & IP_SENDONES) > ip->ip_dst.s_addr = INADDR_BROADCAST; > m->m_flags |= M_BCAST; > } else { > m->m_flags &= ~M_BCAST; > } > > We could add a global option, or maybe just an IP socket option. I had quite a hard time to find this peace of information which makes me think that there aren't too many other application suffering from the inability to fragment?! But if there will be setsockopt option for this feature, I'm happy to test it with heartbeat. Michael