Post B6i9YEvC0X27Ee5p3Y by mildsunrise@tech.lgbt
 (DIR) More posts by mildsunrise@tech.lgbt
 (DIR) Post #B6i9YEvC0X27Ee5p3Y by mildsunrise@tech.lgbt
       1 likes, 0 repeats
       
       wireguard (the kernel module, at the very least) does not apply backpressure to its interfaces. it will immediately dequeue packets as they arrive, and will never stop the queue, instead it seems to drop oldest packets in its internal queue. this means it is useless to set, say, a fair queueing qdisc on a wg interface :(
       
 (DIR) Post #B6iQw1jIP9ZeUZSNN2 by mildsunrise@tech.lgbt
       1 likes, 0 repeats
       
       someday this will affect me and maybe I'll write a patch to apply the backpressure... seems like a relatively small changethat and a boolean nlattr for preserving fwmarks on packets
       
 (DIR) Post #B6iR2F0dwZD7PrXAMS by mildsunrise@tech.lgbt
       1 likes, 0 repeats
       
       I'd even go as far as to claim this is a bug, as it goes against the expectations from any netdev driver
       
 (DIR) Post #B6iSjN9XdrD54xpJ9k by manawyrm@chaos.social
       1 likes, 0 repeats
       
       @mildsunrise that's one of the main issues that plague almost all VPN protocols and ruins the user experience for normal users :/
       
 (DIR) Post #B6iWeKn3OlzG7VA3Vo by mildsunrise@tech.lgbt
       1 likes, 0 repeats
       
       @manawyrm huh, really? i thought linux would propagate backpressure from the TUN/TAP interface, meaning if you don't read fast enough from it, the queue would eventually be stopped. is that not the case?
       
 (DIR) Post #B6iXLctZxXzaiyrAJc by manawyrm@chaos.social
       1 likes, 0 repeats
       
       @mildsunrise tun/tap also has various other problems as far as I can tell, but the worst problem is probably the missing byte queue limits. They tell the kernel how much packets/bytes a network driver has already successfully consumed so it can properly control the flow of data, not just when it's already too late and packet loss has occured.