Date: Sun, 20 Nov 2005 02:17:31 +0100 From: Michael Voucko <voucko@gmx.li> To: freebsd-stable@freebsd.org Subject: Re: "message too long" when sending broadcasts Message-ID: <437FCEAB.80000@gmx.li> In-Reply-To: <20051119165212.O88861@carver.gumbysoft.com> References: <437B1466.8030202@gmx.li> <20051119165212.O88861@carver.gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437FCEAB.80000>