Well, of the three mitigations suggested in the article:

1 - Random NAT port allocation

Seems like the answer is "not by default." According to iptables(8), SNAT defaults to using the pre-translated ports whenever possible, so it's up to the connecting client (victim's TCP stack) to randomly select source ports. There is a "--to-ports" option that lets you limit the usable source ports, but it's not mentioned how the ports are selected in that case.

2 - Reverse Path Validation

I'm not really sure how this helps in the described situation. If the attacker and the victim are on the same wifi access point, then both of their traffic will be sourced from the same network interface, so even strict RFC 3704 validation will pass for spoofed packets from the attacker. But for completeness, you can turn that on by setting a sysctl (rp_filter = 1).

3 - TCP window checking

I _believe_ that the vanilla linux kernel does check this by default, as the mentioned adjustments to OpenWRT seem to be removing a non-standard option to disable the TCP window checking

https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...

In general there are usually rules that prevent cross-forwarding traffic, and thus traffic over wifi is isolated from each client (unless you need to share a home NAS/printer this should remain enabled.)

Most if not all modern routers have this feature, and also the ability to turn off the dumpster-fire that is UPnP and flaky port-trigger mods. Additionally, some add packet marking rules, which is often also used to enforce fair bandwidth sharing. Yet note this can be a nonstandard controversial gray-area.

One could also use a private cert based VPN + Kerberos with firewall client pre-set rules on any un-trusted/open access points.

YMMV, =3

I would have assumed linux conntrack to do more rigorous "tcp window checking" as an assumption, however the article also notes they received a positive response from OpenWRT who implemented a mitigation, so I am curious to see the details of that mitigation.