Skip to content

wifi: Transmission stops and a block-ack "loop" is observed (ns-3-dev)

Hi,

I have a « weird » behaviour in one of my simulation: it looks like data stops reaching the Wifi Mac layer at some point.

The simulation involves another component that's not shareable right now, so unfortunately I can't provide the code, but here are some things about the simulation:

  • The simulation involves two mode using 802.11ac, AdhocWifiMac and IdealWifiManager
  • Routes are set in a static manner
  • Changing the RngRun makes the weird behaviour appear or disappear
  • Node 1 send UDP data to node 0 with a high datarate, as well as Node 0 to Node 1 with a low datarate
  • At some point, Node 0 and Node 1 lose connection with each other (expected given the channel), and then even if the channel gets better, it seems Node 1 cannot send data to Node 0 anymore.

The problem seems the WifiNetDevice does not receive the data from the Socket:

 +39.502236160s 1 Socket:Send(0x564042968760, 0x5640456d5860)
 +39.502236160s 1 Socket:SocketSetDontFragmentTag(0x7ffc160eedd0)
 +39.502236160s 1 Socket:Disable(0x7ffc160eedd0)
 +39.502236160s 1 Socket:GetSerializedSize(0x7ffc160eedd0)
 +39.502236160s 1 Socket:Serialize(0x7ffc160eedd0, 0x7ffc160eeb40)
 +39.502236160s 1 Socket:SocketIpTtlTag(0x7ffc160eea00)                  <- No messages from WifiNetDevice before the NotifyDataSent
 +39.502236160s 1 Socket:NotifyDataSent(0x564042968760, 1024)
 +39.502318080s 1 Socket:Send(0x564042968760, 0x5640456d5860)
 +39.502318080s 1 Socket:SocketSetDontFragmentTag(0x7ffc160eedd0)
 +39.502318080s 1 Socket:Disable(0x7ffc160eedd0)
 +39.502318080s 1 Socket:GetSerializedSize(0x7ffc160eedd0)
 +39.502318080s 1 Socket:Serialize(0x7ffc160eedd0, 0x7ffc160eeb40)
 +39.502318080s 1 Socket:SocketIpTtlTag(0x7ffc160eea00)                  
 +39.502318080s 1 Socket:NotifyDataSent(0x564042968760, 1024)

Looking at the pcap, it seems that before stopping sending data, Node 1 sends 5296 Block Ack Req (see STA-1-0.pcap, below, starting at 3.317895 / packet 43448) which seems a lot, and makes me think of #90 (closed)

Logs:

Any idea what could cause this behaviour?

Thanks,

Rémy

Edited by Rémy Grünblatt