On Wed, Oct 14, 2026 at 11:25:36PM +0900, Yeonggi Kim wrote: > Hi Amaury, > On Wed, Oct 14, 2026, Amaury Denoyelle wrote: > > I'm not sure about it as this could be regarded as a regression, even if > > I do not see any interest of using QUIC targetting a broadcast address > > currently. Maybe quic_lstnr_may_set_src() should also report false for > > the broadcast range ? I'll ask the opinions of Fred and Willy tomorrow > > on this particular point. > Before you discuss it, I need to correct my previous mail. I wrote > that both broadcast cases fail with EINVAL, but only 255.255.255.255 > does (as do multicast addresses). With a subnet broadcast address as > source (e.g. 192.0.2.255 on a /24), sendmsg() fails with ENETUNREACH, > as for any non-local source address, and on a "transparent" bind > (IP_TRANSPARENT) it even succeeds, so the datagram leaves with the > broadcast address as source. > A subnet broadcast address cannot be recognized from the address > alone, as it depends on the interface prefix. So I see three options. > - Keep the series as is, since listener socket mode already fails the > same way, and document it in the commit message. > - Check the address in quic_lstnr_may_set_src(). This covers > 255.255.255.255 and multicast, but not subnet broadcast. > - Retry once without source address in quic_lstnr_sock_send() on > EINVAL or ENETUNREACH. This covers all of them, except subnet > broadcast on a "transparent" bind. > Any of them is fine with me. Please let me know once you have discussed > it. In the meantime, I will finalize the v2 based on the points we > already agreed on.
Thanks for the complement. I tend to think that solution 2 is the best (exclude broadcast address 255.255.255.255 in quic_lstnr_may_set_src()), but I need confirmation on this. -- Amaury Denoyelle
