You are not logged in.
warp_user wrote:
There is data in sta_two_node_two_flow_capture.hdf5 but nothing in ap_two_node_two_flow_capture.hdf5.
Can you clarify what you mean by "data" in this context? Is the content of the STA's log file RX_OFDM events from the AP? Or RX_EVENTS from someone else? Or Tx Events? Does the AP's log have no entries at all, or only Tx entries to the STA?
If the AP -> STA flow is working but the STA -> AP flow is not, I think that's consistent with the token passing message being lost or not sent for some reason. If neither flow seems to be working, then it may be something else.
There isn't too much else I can say without knowing more. Try printing to UART whenever NOMAC is sending a token request (e.g. sometime after the call to wlan_create_token_offer_frame()). Does that print periodically like you expect at the node acting as the AP? If so, then move on to the STA side and print when you are processing the request and generating the reply. That can help narrow down where the problem is coming from. Be sure to lower the rightmost dip switch in the User I/O section of WARP v3 to output the CPU_LOW UART over the micro-USB connection.
Offline
Answering to your question there is no data at all in the ‘ap_two_node_two_flow_capture.hdf5’.
Then I have followed a suggestion in the following link,
http://warpproject.org/forums/viewtopic … 10#p14710; and modified the parameter in MAC_HW_LASTBYTE_TOKEN(9) to 9 bytes.
This is in figure (1).
This generates data for both AP and STA once characterized with WARPnet (using the steps specified in https://warpproject.org/trac/wiki/802.1 … terization).
I have used 'log_capture_two_node_two_flow.py' in WARPnet framework.
Then I have used 'log_process_summary.py' to read those hdf5 files.
The output recognizes data at 12Mbps instead of 18Mbps as used in the python script, as specified in figure (2) – AP data - and figure (3) – STA data.
Furthermore I have used Wireshark monitor mode to sniff packets during the operation and manage to filter similar to token_offer and token_request being generated. These correspond to the frames 442 to 445 in the figure (4). But this change is from Authentication to Data only and could not find any instance for change of direction in data transfer.
Please note that, MangoCom_03:96 is the AP and MangoCom_03:06 is the STA.
Thanks in advance for any insight and guidance on the above issues.
Figure (1)
http://wikisend.com/download/342818/f1.png
Figure (2)
http://wikisend.com/download/150306/f2.png
Figure (3)
http://wikisend.com/download/363180/f3.png
Figure (4)
http://wikisend.com/download/732486/f4.png
Offline
First, I have a couple of general debugging suggestions. wlan_exp is really good for two things:
A) Characterizing a known working design
B) Debugging large-scale protocol problems. For example, suppose a node that seems to get access to the medium unfairly in an unexpected way. wlan_exp can help track down the OTA packet interactions that led to that behavior.
wlan_exp is less well-suited for debugging fundamental protocol issues like the ones you are seeing. It's simple, but a really powerful debugging strategy is simply adding xil_printf() calls at various parts of the code to make sure they are executing and in the order your are expecting. Using UART to debug like this is useless when you are trying to measure anything timing sensitive (like throughput) since it takes a long time to print relative to wireless behaviors. But it's great for making sure that code is executing like you expect.
Here are a couple of more concrete suggestions on places to look:
1. Before even starting any traffic flow, make sure the token handshake is working properly. If you aren't seeing the reservation reliably alternate between the AP to the STA, there is no point in going any further until you figure out why. You'll want to add some prints to NOMAC. To view UART prints from CPU_LOW, be sure to lower the right-most switch on the user IO DIP switch
1a) Print "Create Token Offer" at the end of wlan_create_token_offer_frame().
1b) Print "Create Token Response" at the end of wlan_create_token_response_frame().
1c) Print "Received Token Offer" in frame_receive() here:
if(unicast_to_me && (rx_header->frame_control_1 == MAC_FRAME_CTRL1_SUBTYPE_TOKEN_OFFER)){ ... mpdu_info->state = wlan_mac_dcf_hw_rx_finish(); if(mpdu_info->state == RX_MPDU_STATE_FCS_GOOD){ xil_printf("Received Token Offer\n"); ...
1d) Print "Received Token Response" in frame_receive() here:
} else if(unicast_to_me && (rx_header->frame_control_1 == MAC_FRAME_CTRL1_SUBTYPE_TOKEN_RESPONSE)) { ... mpdu_info->state = wlan_mac_dcf_hw_rx_finish(); if(mpdu_info->state == RX_MPDU_STATE_FCS_GOOD){ xil_printf("Received Token Response\n"); ...
With those changes you should see the AP print:
... Create Token Offer Received Token Response Create Token Offer Received Token Response ...
The STA should print
... Received Token Offer Create Token Response Received Token Offer Create Token Response ...
2. Figure 4 you posted is very suspicious. It looks like the AP (MangoCom_03:96) is hemorrhaging authentication messages. It's important to figure out why this is happening. First, verify this is happening even without the involvement of your wlan_exp script by printing a message like "Enqueued an Authentication Response" on line 1382 of wlan_mac_ap.c. Does that print repeatedly? If it does, that mean the STA, for some reason, is sending its authentication request repeatedly so you can track that down by adding similar prints in the wlan_mac_sta.c code.
Offline
I have updated NoMAC design accordingly (for release 1.5.2) as suggested in Token MAC tutorial. Once the updated design is compiled successfully hardware boards are programmed using SD cards.
For the case of release 1.5.2, in STA design the hex display shows '--' instead of '0' at the start (http://warpproject.org/forums/viewtopic.php?id=3121).
To fix this issue I have changed the original line 'sta_update_hex_display(0xFF)' to 'sta_update_hex_display(0x00)' in function 'main()' of 'wlan_mac_sta.c'
I want to first test this design in WARPnet environment.
I have started with 'blink_nodes_leds.py' and this fails to identify the STA node (AP identification is successful). This problem is very similar to the issues in http://warpproject.org/forums/viewtopic.php?id=3063.
I am using WARP V3 with Release v1.5.2, ISE 14.4 in a Ubuntu environment.
Awaiting for a favourable response soon,
Many thanks
Offline
For the case of release 1.5.2, in STA design the hex display shows '--' instead of '0' at the start
This is the intended behavior when the node is configured to boot with a null BSS and will not attempt to join the default BSS. This mode is selected via the DIP switch - refer to the user guide for details. When you're running experiments with wlan_exp we recommend using the "null BSS" mode at all nodes and explicitly configuring the desired BSS state at all nodes via Python.
I have started with 'blink_nodes_leds.py' and this fails to identify the STA node (AP identification is successful).
The blink_node_leds example uses a broadcast packet to execute the "identify" command at all nodes on the local network. If one of your nodes does not respond to this command, it means it is not receiving the broadcast packet. Check that the node has booted successfully (check the UART output) and that its ETH B interface is connected via 1Gb Ethernet to the local network switch.
Offline
I have modified the ‘nomac’ model in version 1.5.2 towards a token MAC implementation as suggested in the tutorial and encounter issues once debugged for the behavior of token MAC. From my understanding it seems the problem occurs in the ‘frame_receive’ function. When frame_receive() is called via the main function the receive packet buffer is not called accordingly.
As there are several changes and modifications added upgrading from version 1.3 to version 1.5.2 in most cases I had to study the codes carefully when upgrading token MAC for version 1.5.2.
In addition I have named token mac structure as 'schmac' with the intention of keeping 'nomac' project for benchmarking the extended models in the future. I would appreciate if you can have a look at the attached model in resolving this issue. In addition to the zip file including the extended model there is also an accompanying document highlighting the changes and modifications.
EDK project is uploaded in http://wikisend.com/download/789806/sch … _debug.zip and the document is in http://wikisend.com/download/555426/schmac_model.zip
Thanks in advance and awaiting a favourable reply soon
Last edited by warp_user (2016-Sep-28 05:37:15)
Offline
I would like to use the TOKEN MAC in an application similar to wireless/wired bridge set up as in http://warpproject.org/trac/wiki/OFDMRe … ns/Bridge. I am currently testing the performance using WARPnet framework and would like your help in understanding the steps in replacing the LTGs (in WARPnet framework) with a real application similar (to VLC or any other streaming).
I am using the TOKEN MAC design provided for version 1.3 (with plans to test in v 1.5 in future).
Would appreciate your assistance in resolving this issue. Many thanks.
Offline
The 802.11 Ref Design implements wired-wireless bridging between the WARP v3 node's ETH A interface and the wireless interface. This bridge operates in parallel with the LTG framework. LTG traffic will only be generated if enabled explicitly via Python or C code. The bridge will generate traffic any time Ethernet packets arrive at ETH A.
One common setup is to connect the AP's ETH A interface to an Ethernet network with internet access and a DHCP server (i.e. the "LAN" side of a home router), and connect the STA's ETH A interface to a PC's Ethernet interface. The PC will then use the 802.11 Ref Design link for its internet connection. You can then stream whatever traffic you want between the STA PC and a PC on the AP's Ethernet network (iperf, VLC, etc).
Offline
Many thanks for the reply, it is really helpful.
Could you please point me to the part of the 802.11 Ref Design which handle the association of AP and the STA? I need to use the Token MAC design for a streaming application with with association of STA and AP at the boot instead of using WARPnet framework.
Thanks in advance
Offline
In the v1.5 code all BSS state is configured in the configure_bss() function. The AP creates its BSS via configure_bss(). The STA uses its scan-and-join state machine to find the AP's BSS, then executes the association handshake, then updates its own BSS state via configure_bss().
In v1.3 the basic processes are the same just less centralized. The STA uses the same scan-and-join state machine to discover the AP's BSS and executes the association handshake. This process is implemented in wlan_mac_sta_join_fsm.c.
You can skip the scan-and-join process if you know the AP and STA MAC addresses ahead of time. You could modify the AP C code to add the STA to its association table, and modify the STA to boot up in the associated state. We don't have example code for this - I would recommend following the code path for the wlan_exp "node_ap.add_association(node_sta)" call.
Offline
I have followed the suggested approach as in wlan_exp “node_ap.add_association(node_sta)” and managed to test successfully for the for the NoMAC bridge application (version 1.3).
But when I tried to run the Ethernet - wireless bridging application for Token MAC the machine connected to the STA cannot associate with the AP.
Once debugged using UART output it can be seen that token offers and responses are passed between AP and the STA successfully.
Are there any additional measures needed to consider in Token MAC to bridge Ethernet packets to Wireless design?
The following are the codes added to the AP and STA (just before the last while in main function) to bypass the scan and join process.
Thanks in advance