On Thu, Oct 15, 2026 at 02:23:05PM +0200, Amaury Denoyelle wrote: > On Wed, Oct 14, 2026 at 04:36:01PM +0200, Amaury Denoyelle wrote: > > 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. > > Okay so after internal discussions here, the best solution is simply to > ignore the problem with address 255.255.255.255. Retry/VN/Stateless > Reset emission will fail in this case, but it's doubtful there is any > value for QUIC clients using multicast anyway.
Yep, anyway this address is not special, any odd address can be a broadcast IPv4 address depending on the network it belongs to, same for even addresses that are thet network's base addresses, and that's not even counting multicast addresses. The point here is that it makes no sense by definition to try to operate connection-oriented protocols (that QUIC is) with broadcast/multicast where by definition multiple nodes could receive the traffic and try to start processing in parallel. Willy
