From owner-freebsd-net Fri Feb 1 9:51:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from chmls06.mediaone.net (chmls06.ne.ipsvc.net [24.147.1.144]) by hub.freebsd.org (Postfix) with ESMTP id 212E637B402 for ; Fri, 1 Feb 2002 09:51:28 -0800 (PST) Received: from baloo.ne.mediaone.net (panariti.ne.mediaone.net [66.30.120.53]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id g11HqXr08368 for ; Fri, 1 Feb 2002 12:52:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by baloo.ne.mediaone.net (8.11.6/8.11.6) with ESMTP id g11HpYY64613 for ; Fri, 1 Feb 2002 12:51:34 -0500 (EST) (envelope-from panariti@mediaone.net) Date: Fri, 01 Feb 2002 12:51:34 -0500 (EST) Message-Id: <20020201.125134.730570091.panariti@mediaone.net> To: freebsd-net@freebsd.org Subject: 4.5R and explicit broadcast routes From: "David A. Panariti" X-Attribution: davep X-Mailer: Mew version 2.2rc1 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, 4.5R has a new behavior that is breaking an old (and essential) application of mine. When the app tries to make a TCP connection to 255.255.255.255, (as shown by strace: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(3, {sin_family=AF_INET, sin_port=htons(6666), sin_addr=inet_addr("255.255.255.255")}}, 16) = -1 EACCES (Permission denied) ) something in the new net code is adding an explicit route for broadcast, e.g.: 192.168.123.255 ff:ff:ff:ff:ff:ff UHLWb 0 8 dc0 In 4.4, no explicit route for broadcast ever got added, and the app could connect, presumably due to never finding the broadcast route. At this point, I'm not 100% sure this is THE problem, but it certainly is A problem. Unfortunately, all I have is a binary for the app, so I can't figure out what they are doing. I don't even know if making a TCP connection to 255.255.255.255 is legal. Does anyone know where this explicit broadcast route is being added, and why? Is there a knob to turn it off? Since this is the only app I care about that uses its port, I could add special case code to *NOT* add this route when I see a connection to this port to addr 255.255.255.255. Would the lack of this route cause then cause other failures, too? Some more details: During connect, the broadcast route is found and the app then errors out inside ip_output() since the flags passed to that routine mask out all bits except SO_DONTROUTE. During connect, tcp_usr_connect() calls tcp_output() which eventually calls ip_output(): error = ip_output(m, tp->t_inpcb->inp_options, &tp->t_inpcb->inp_route, (so->so_options & SO_DONTROUTE), 0); Inside ip_output(): if (ro->ro_rt->rt_flags & RTF_HOST) isbroadcast = (ro->ro_rt->rt_flags & RTF_BROADCAST); ... if (isbroadcast) { .... if ((flags & IP_ALLOWBROADCAST) == 0) { error = EACCES; goto bad; } } Even if the socket did allow broadcasts, that bit would have been masked in the call to ip_output(). This error is set and the connect fails. thanks, davep -- The surest protection against temptation is cowardice. -- Mark Twain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message