Thu May 02, 2024 11:36 am
Even though L4 data is unacknowledged type (UDP), WiFi layer (L2 in particular) still requires some bi-directional communication (ACKs of wireless frames for example) when data is sent to unicast destination address. Which means that jamming transmitting side effectively blocks it from transmitting data (beyond from a few frames being retransmitted many times).
What might help: sending your stream to broadcast IP address ... By design[*], those frames would be then sent out without transmitting station expecting any feedback, so jamming transmitter wouldn't prevent it from sending data. However, this means that data would be sent out at lowest possible datarate (by default that's around 1.1Mbps). Depending on stream requirements, you'd have to set basic rates property (slightly) higher than required by stream.
I wrote "might help", transmitter still might not try to transmit data, WiFi drvices (stations and APs alike) are supposed to wait for "free air" in order to avoid collisions (multiple stations/APs transmitting concurrently on same frequency channel effectively cancel each other because receiver can not filter "unwanted noise") ... when one device is jammed on purpose this mechanism is not wanted but AFAIK you can't disable it.
[*] In ROS there's setting multicast helper which (if set to full) converts broadcasts/multicasts into unicasts for each connected station. This then allows a few nice things: data can be sent out at highest possible rate (depending on individual station link state), data can be buffered (to wait for station to wake up from sleep states) ... at the cost of multiplying amount of data necessary to transmit (each connected station gets its own copy).
In your particular case this is exactly the opposite from what you'd like to see as it means unicast transmission with expectation to get acks ... And in case of PtP the data multiplication doesn't happen anyway.