From owner-svn-src-head@freebsd.org Sat Aug 20 16:36:59 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D560BC0C12; Sat, 20 Aug 2016 16:36:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6363F125C; Sat, 20 Aug 2016 16:36:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-it0-x232.google.com with SMTP id x131so54577905ite.0; Sat, 20 Aug 2016 09:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6DGdjVJFCS/p3RRXAlo3iTeQlDzxVyFU9q4i8aqPXbg=; b=qmHRrSu39Dv6tcNhmQEvaQbZPeoJejO1LC9jJiLgH/3Zbs5XvVgutEQqTMEW3p78aO Io4Acw/L4UM7k7sYRw4p21j5sOilPOkGtcZw9KuAR0HOhFfX5L0R5h3nOpm1geF4Pg12 JbpR15u4tHYNqteNghQSMzGIl8oCxRtdGlz6G76eAkkcJ5oJYNj9K19DVlZByZDNQ4Ba zqRSS3XBS95/wggiztvJ8vin4w6/sJ7Uz6YsEVE/Gl4ZpkHIdHZ6sbPl8FyLiLJ2KuKE kDe+/7az6pPcU3WimB6d59wEQmhOZBUXnnSF1l+diD7TIjg8Xf71do7W5QMFjuuz4B9J PQFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6DGdjVJFCS/p3RRXAlo3iTeQlDzxVyFU9q4i8aqPXbg=; b=ZXUWTU4CTaFApzawzd79fkQJLDmj9uuFLCfbIiYQ3Rft1tOrOAFzBJ7ZekyYV/uebY Ii3loJSPJiC7mjbGemGtQn7B71kap77WjuDWduO+z0nV2CeskZRWl7af6Xs9sH96WRIv O/h2hj2NyZ/awHpU1SK2afJs004x5TzFKev/Rs7voCKDaNM0LmoHJE+FgSgBaSS9JG+u JsWOWiSDOkVOt8+OE05yZdP6L22qNbs7RfRyVIH+mDOOGjvJ+l6mvxr25UUX0erR4olU VlMb10l4x+0yXQNdPwD91GLfyaBNKYkjbxFBHv8VTS3DPZhlhfd4M0LF1u3izNISl01j 38kg== X-Gm-Message-State: AEkoouvvnhA3D+fO+YXGpu63yoktS+8b0EpyNUekJeTLerYQdGSiVfWfN2khM+NYF7F395i+Pzr1wosFs50rXQ== X-Received: by 10.36.149.5 with SMTP id m5mr12870457itd.20.1471711018603; Sat, 20 Aug 2016 09:36:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.200.71 with HTTP; Sat, 20 Aug 2016 09:36:58 -0700 (PDT) In-Reply-To: <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> From: Ryan Stone Date: Sat, 20 Aug 2016 12:36:58 -0400 Message-ID: Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Bruce Simpson Cc: Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 16:36:59 -0000 + adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking. Unfortunately, reverting r304436 would mean that every UDP packet would incur the overhead of an additional rlock/runlock call, which is what I've been trying to avoid. I don't see a particularly good path forward. - The if_addr_lock would appear to be an excellent candidate to be converted into an rmlock, but unfortunately we made the mistake of exposing the lock through the ifnet KPI. Fixing that would require rototilling every single Ethernet/WiFi/etc driver in the tree. - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. - mbuf flags are far too precious to allocate a new one for such a narrow use-case On Sat, Aug 20, 2016 at 11:42 AM, Bruce Simpson wrote: > On 20/08/16 16:27, Ryan Stone wrote: > >> Can you send a broadcast packet through an L3 tunnel? I thought that a >> L2 tunnel was required. >> > > Yes. This is perfectly legal and necessary for forwarding of IPv4 > broadcasts to work. (it is Internet Protocol after all, not > Infernal-ethernet-extension Protocol. ;-)) > > The change is in UDP input so it will not affect routers. But if a FreeBSD > system were at the end of a link layer, and was the final recipient of the > IPv4 broadcast packet, then if that link layer is not Ethernet, all bets > are off. > > That situation could occur very easily where FreeBSD is hanging off the > end of a PPPoE link: e.g. consumer DSL, microwave, etc. > > The underlying link layer for the tunnel might be Ethernet, but it will be > demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not normally > distinguish between unicast, broadcast, multicast. > > Broadcast destined for the host on its PPP address would be transported > inside the tunnel, encapsulated as a normal unicast Ethernet packet. > > But this mbuf flag is not guaranteed to be set in all situations; >> e.g. where the link layer does not have the concept of broadcast >> being distinct from other kinds of network traffic. PPP and ATM are >> the most obvious examples. >> >> >> We don't support ATM, but PPP is a good example. I hadn't thought of >> that. Hm, ip_input() already has to check for a broadcast IP. What it >> set M_BCAST on the mbuf at that time? >> > > ATM is one of those things everyone kind of has to support by default in > some way because of the ITU ADSL specs. It is literally written into > G.992.x. > > Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted on > the UK all by themselves, though, and we wish it would just go away. > > Whilst your suggestion may work, it may be dangerous, as you are then > stepping on the meaning of the flags. Some of them are intended to be used > for one layer to signal another. > > M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received > this as a broadcast / I intended for link layer to send this as a > broadcast". M_PROTOFLAGS is normally used to clear flags with different > meaning in different protocol layers. > > M_MCAST also has similar status. On my PhD, I wrote code which uses a > private Ethernet link between FreeBSD routers for load distribution; it > distributes unicast traffic using IPv6 multicast. > > It uses multicast both as convenience, and as a way to 'channelise' > traffic if the Ethernet link supports it, using multicast groups. (Modern > shared memory switches can slice L2 multicast traffic like this quite > efficiently. So one slice of unicast traffic could be switched across > locations purely at L2. However, the distribution of actual IPv6 multicast > was out of scope.) > > The routers have to very carefully clear M_MCAST on egress, to ensure > normal L2 next-hop resolution for IPv6 destinations. > >