inet-framework
An error in large scale simulation-IEEE80211, ackedFrame is not yet transmitted
Omnet 5.5.1 inet-4.1.1-ce69d088d OS: MacOs Component: inet::ieee80211::Dcf, node.wireless.AccessPoint.wlan[0].mac.dcf Summary: The access point received the WlanAck from one host in the mac layer, but then the error of ackedFrame = is not yet transmitted -- in module (inet::ieee80211::Dcf) is thrown. This error only occurs when I run a large scale simulation (1000 hosts to associate with an accesspoint). Small scale simulations run normally and successfully.
Steps to Reproduce:
.ned file: import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator; import inet.node.inet.WirelessHost; import inet.node.wireless.AccessPoint; import inet.physicallayer.ieee80211.packetlevel.Ieee80211ScalarRadioMedium;
configurator: Ipv4NetworkConfigurator radioMedium: Ieee80211ScalarRadioMedium host[numHosts]: WirelessHost ap: AccessPoint
.ini file: numHosts=1000 **.mgmt.frameCapacity = 10 **.wlan[].mac.retryLimit = 7 **.bandName = "5 GHz (20 MHz)” **.opMode = “ac" **.wlan[].radio.antenna.numAntennas = 8 **.bitrate = 693.3Mbps **.wlan[].radio.transmitter.power = 100mW **.wlan[].radio.transmitter.headerBitLength = 100b **.carrierFrequency = 5GHz **.wlan[].radio.receiver.sensitivity = -85dBm **.wlan[].radio.receiver.snirThreshold = 4dB
Nothing needs to do. Just let the 1000 hosts associate with the accesspoint.
Actual Results: Error log: ** Event #95208892 t=5.753734560263 Lan80211acFinal.ap.wlan[0].mac (Ieee80211Mac, id=138053) on WlanAck (inet::Packet, id=437184744) INFO (Rx)Lan80211acFinal.ap.wlan[0].mac.rx: Lan80211acFinal.ap.wlan[0].mac.rx: Received frame from PHY: (inet::Packet)WlanAck (14 bytes) [[inet::physicallayer::Ieee80211HtPhyHeader, length = 50 b | inet::ieee80211::Ieee80211AckFrame, length = 10 B | inet::ieee80211::Ieee80211MacTrailer, length = 4 B]] <!> ackedFrame = is not yet transmitted -- in module (inet::ieee80211::Dcf) Lan80211acFinal.ap.wlan[0].mac.dcf (id=138058), at t=5.753734560263s, event #95208892
Expected Results: Lan80211acFinal.ap.wlan[0].mac.dcf: Frame sequence finished
My speculation: Related codes: inet/linklayer/ieee80211/mac/originator/AckHandler.cc Function: AckHandler::processReceivedAck Such a status is set when--
ackStatuses.find(id)== ackStatuses.end() where id = SequenceControlField(ackedFrame->getSequenceNumber(), ackedFrame->getFragmentNumber()); ackStatuses is a map <id, statues>
To sum up, the ACK frame is received from PHY by mac.rx, but when dcf tried to handle it, it can not be found in the map (ackStatuses)
I also checked the packets dropped, it seems not the reason here as so many drops were handled correctly.
Additional Information: Note that at first I met such a problem when I have a more complex setting with TCP applications, internet cloud and wired network. With my analysis, I simplified the simulation, and the error is still here with the simple network described above. I replaced the error throw statement with EV-WARN as Levy's suggestion and the expected info of "Frame Sequence Finished" was given then. (Really thanks for Levy's help)
I tried to reproduce this but I could not with the provided information. Could you please add the exact contents of the NED and INI files?
I downloaded your zip file and run the BugReport config under INET 4.1.1 and latest master branch on Ubuntu linux. Both run without problems way beyond the simulation time where the error happened for you.
Could you please minimize the network and configuration files? Please also check that the bug is still triggered in the latest INET master branch. There were quite a few changes in 802.11 ACK handling. Note that you will have to migrate the INI file (e.g. carrierFrequency renamed to centerFrequency, headerBitLength renamed to headerLength)
I tried really hard to reproduce this problem with the current master branch but I failed to do so. Unless you provide some more details how to reproduce it, I will close this bug.
ohhh, sorry for my late reply, I was very busy with my course work these days. You can close it, I will also check with your suggestion later. Thanks for your time so much!
On Fri, 15 Nov 2019 at 07:37, Levente Mészáros [email protected] wrote:
I tried really hard to reproduce this problem with the current master branch but I failed to do so. Unless you provide some more details how to reproduce it, I will close this bug.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/inet-framework/inet/issues/467?email_source=notifications&email_token=ANPG5CTBODPIXLSXVYB5M4LQT2647A5CNFSM4JAJAZTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEFZR5Q#issuecomment-554408182, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPG5CXTJZKQKNO63L4JVM3QT2647ANCNFSM4JAJAZTA .
Hi, we encountered the same problem in preparation of our class. It seems like the problem only exists on macOS.
For our project, we got this error on version 5.6 and 5.6.1 of OMNeT++ with INET 4.2. We tried compiling with clang and gcc, but always got the same result.
However, I just tried to reproduce the bug using the simulation model that the author provided, but I was unsuccessful. Our simulation model also contains only a few wireless hosts, so I don't think it directly depends on the number of hosts.
@levy We are happy to share our project with you to test this issue further, but as it is the solution to one of our course tasks, we do not want to publish it here. Should we sent it to you via e-mail?
Best regards, dstolpmann
Could you please check if the problem still persist with the latest master branch?
We found out that enabling IEEE 802.11e by adding the following lines to the ini file circumvents this error:
**.wlan[*].classifier.typename = "ExampleQosClassifier"
**.mac.hcf.edca.edcaf[].pendingQueue.maxQueueSize = -1
**.mac.qosStation = true
By looking at the code, all traffic in our simulation model should be classified as "Best Effort" traffic, so there is no prioritization going on.
Hi @levy,
I have just checked if the bug still persists with the current INET master version and it does. I think this issue should be reopened.
Best regards, dstolpmann
Hi @levy,
We have figured out how to reproduce this problem:
It only happens when libc++ is used as standard library (as on Mac OS) and not libstdc++. We have verified this by linking omnet/INET against libc++ on linux and are able to reproduce the problem.
We also have a hypothesis why this happens:
The error is tracked down to the AckHandler class where the ack status for some frames seems to be lost. This happens, because inside the AckHandler, the ack status is stored inside a map<SequenceControlField, Status> and as the SequenceControlField has a modulo arithmetic (e.g. 0 < 2047 < 4094 < 0) it clashes with the way how the std:map is organized internally. As we understand, the std:map is implemented as a binary search tree, which is rebalanced when elements are added or removed. When a specific element is queried from the map, only one side of the tree is traversed. While this is not a problem when only a small range of sequence number is in the tree, once the full range of sequence numbers is added, an item might have been added to the left side of the tree, but after rebalancing is expected to be on the right (And therefore when we call map::find, it is not found).
As the modulo arithmetic of sequence numbers is not important in the AckHandler, we have prepared a pull request, which serializes the sequence numbers so that they don't cause problems within the map here. This change is tested against the example project @dstolpmann sent you last year.
I hope our insights are helpful :) Best, Konrad
