Actually, taking this a bit broader and as someone who has gotten the same questions many times, starting in 2012 with ROS 1 (“This is crap, it doesn’t work, I cannot create a 10 kHz current-control loop distributed over a Windows machine, a Mac and your Linux. Isn’t that what this R-O-S is supposed to do?”), I support this.
In the end, after explaining sufficiently, all engineers are willing to understand there are limits to technology and that things may not work out-of-the-box immediately.
But it does not look good when you have to get all apologetic about a technology stack. Especially not one which is geared towards use in production environments (ROS 2 == ROS-for-Products).
And, more often than not, there is no one around with sufficient in-depth knowledge to explain why something isn’t working, and how to change it such that it will work. Finding a configuration which can improve the out-of-the-box experience on a set of use-cases which are common would be tremendously valuable.
As in real-life, first impressions count.
If a single configuration isn’t feasible, perhaps a set of profiles could be introduced? “Switch to the wifi/lossy-network profile if you’re not using a cabled network”.
But that’s all assuming wifi actually needs special configuration, and it 's not something else which is affecting user experiences here.
Are you referring to ros2/rmw_fastrtps#315 among others? That wasn’t specifically blamed on the router I believe. It was more a combination of factors (but the router was among those). I believe the FastRTPS documentation was extended with some more info on use over wifi as a result of diagnosing those issues: Typical Use-Cases: Fast-RTPS over WIFI. I could imagine other vendors have similar documentation.