"message too long" when sending broadcasts

Robert Watson rwatson at FreeBSD.org
Sun Nov 20 05:04:12 PST 2005


On Sun, 20 Nov 2005, Michael Voucko wrote:

>
> 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.

Robert N M Watson


More information about the freebsd-stable mailing list