|
Bugzilla – Full Text Bug Listing |
| Summary: | Simulation crashes on AP's receiving of an Assoc. Response | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Jan <janjessewitsch> |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P5 | ||
| Version: | ns-3.26 | ||
| Hardware: | All | ||
| OS: | All | ||
This is not a bug, it is just a unimplemented feature that you are apparently busy on. The purpose of this tracker is to spot and fix issues in our code, not in your own implementation. I will reject this bug. If you need help for your implementation, please refer to our forum. |
The issue arises from the implementation of "Hotspotting", a concept of switching the WiFi state (STA to AP, or visa versa) of (mobile) nodes to connect and exchange data opportunistically. Node A (station) that has just sent an association request to Node B (AP/hotspot), decides to become an AP/hotspot for other nodes (e.g. because Node B was busy and the association response is delayed). Node B replies with an association response that is received by Node A and causes the simulation to crash. That is because (in ApWifiMac::Receive) the case of an association response is not considered. The received WifiMacHeader is: - a Management header, - addressed to this node, but - neither an association request, - nor a disassociation. Hence, RegularWifiMac::Receive is called. In this method arises the NS_FATAL_ERROR ("Don't know how to handle frame (type=" << hdr->GetType ()); (where hdr->GetType() is WIFI_MAC_MGT_ASSOCIATION_RESPONSE). To continue my project I chose a workaround. I modified ApWifiMac::Receive so that association responses are dropped: // below if (hdr->IsDisassociation ()){...} else if (hdr->IsAssocResp()) { NotifyRxDrop (packet); return; } Although an access point usually not receives association responses, it should remain functional if this happens.