Hi! Have a very specific task. I have two Metal 52 ac. Connected in bridge mode. Let’s call them A and B. Mikrotik A sends UDP streaming video to B.
My question is - is it possible for A to broadcast UDP packets and them receive by B, without established connection ? Reason is that A can be jammed, so it is not able to receive packets from B and support connection. But A is far away and can listen without issues.
UDP is state-less L4 protocol … meaning that UDP connections are not really established, there is no connection handshake. Instead one side starts to transmit packets and the other side may (or may not) transmit packets in the opposite direction. Whether traffic is bidirectional or not entirely depends on application. BTW, multicast streams are always UDP exactly for this reason: multiple receivers share same data stream and in a “connected mode” this wouldn’t be possible.
So technically it’s definitely possible to do what you described. But it depends on application if side A can start streaming without side B ever asking for the stream. In scenarios about IPTV where channels are multicast, side B (receiver) uses IGMP to “ask” for some particular stream. You have to check if in your case there’s also some mechanizm to start the stream.
In my case receiver (mikrotik “B”) doesn’t ask anything. UDP streaming works constantly without issues. But once Mikrotik “A” is jammed - no streaming is received on “B”. My knowledge of mikrotik is very poor. Maybe I need to enable multicast ? Or my connection type is wrong - right now it’s bridge (B router) and station-bridge (A router)
What in particular does mean “Mikrotik A is jammed”?
By Wi-Fi jammer. So, it’s can’t hear anything from router “B”. Only send.
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.
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
I don’t think this will help in this case without changing the sender connection; per OP comments, the traffic generator, Station A, is station bridge so is an 802.11 wireless client. All traffic ToDS (i.e. from client to AP) is treated as unicast at 802.11 layer, so even if it is group addressed for final destination (either multicast or broadcast), an 802.11 ACK is still required from the DS (access point) to the client.
Thank you for the ideas. I can change bridge mode to something else if this can help