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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to