802.11 HCF bug in checking hasFrameToTransmit(AccessCategory ac) #1031
Description
There are two identical functions, hasFrameToTransmit, in hcf.cc. The one with the input parameter ac doesn't use that input.
The function bool Hcf::hasFrameToTransmit(AccessCategory ac) should retrieve edcaf using:
auto edcaf = edca->getEdcaf(ac);
instead of:
auto edcaf = edca->getChannelOwner();
Otherwise, it leads to a segmentation fault (0x8b) when an internal collision occurs and retryLimitReached is triggered.
Scenario:
When two access categories (e.g., Voice Priority (VO) and Best Effort (BE)) unintentionally conclude contention at the same time, the higher-priority VO queue gains channel ownership. Meanwhile, the lower-priority BE detects the internal collision and calls the handler in hcf::handleInternalCollision().
If the retry limit for that frame has been reached, the function drops the current packet and checks for the next packet in the same queue. This is when hasFrameToTransmit(AccessCategory ac) is called.
Currently, the function retrieves edcaf using edca->getChannelOwner(), which incorrectly returns the queue that has just gained channel access (VO). As a result, instead of checking the BE queue, the function mistakenly returns the status of the VO queue.
Then, requestChannel for BE is called based on the status of the incorrect queue (VO). If the BE queue is empty, this results in a requestChannel call for an empty queue, causing a segmentation fault.