WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2018-Feb-08 09:43:27

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Some questions about usage methods of the 802.11 Reference Design

Hi,

I met some problems when I used the 802.11 Reference Design.

When I generate the .elf file for wlan_mac_high_ap in Xilinx Software Development Kit, I don't konw how to set up the contents of the parts of the pop-up dialog box after I clicked the Generate Linker Script. When I set up the default setting, there will be some mistakes as follows:
1.region `mb_high_ilmb_bram_cntlr_0_mb_high_dlmb_bram_cntlr_0' overflowed by 150696 bytes   
2.undefined reference to `__wlan_exp_eth_buffers_section_end'   
3.undefined reference to `__wlan_exp_eth_buffers_section_start'
4.wlan_mac_high_ap.elf section `.text' will not fit in region
`mb_high_ilmb_bram_cntlr_0_mb_high_dlmb_bram_cntlr_0'   

I hope you can tell me how to set up the contents of the parts of the pop-up dialog box after clicking the Generate Linker Script when generating the .elf file for wlan_mac_high_ap in Xilinx Software Development Kit. What's more, I hope that you can give me a more detailed steps when using the 802.11 Reference Design.

Thank you.
Dong chen

Offline

 

#2 2018-Feb-08 12:46:26

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Some questions about usage methods of the 802.11 Reference Design

You cannot use the SDK's "Generate Linker Script" tool with the 802.11 Ref Design. The 802.11 code requires linker script options that are not supported by the SDK "Generate" tool.

The 802.11 Ref Design SDK workspace includes known-good linker scripts for CPU High and CPU Low. The SDK application projects are already configured to use these scripts. Refer to the Using the Design: SDK page in the user guide for details on re-creating the SDK workspace from the reference design archive. You can use the SDK workspace and modify the code without changing the linker scripts.

Offline

 

#3 2018-Feb-19 08:56:34

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

In the 802.11 Reference Design, I don't know what the wlan_mac_low_nomac project is used for. 

What's more, if I want to realize a simple communication between a WARP v3 hardware and a computer, can I use the .elf file which uses the IBSS application in CPU High and DCF MAC in CPU Low? I hope that you can give some advice to help me to relize the goals.

Thank you very much.
Dong chen

Offline

 

#4 2018-Feb-19 09:28:31

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

dongchen wrote:

I don't know what the wlan_mac_low_nomac project is used for.

NOMAC, as its name implies, implements no medium access control. It's therefore not directly useful for any over-the-air interactions on a medium that is shared with other devices. Here are the primary uses:

1) NOMAC serves as a platform for PHY measurements like PER. Typically these experiments are highly controlled and are not over-the-air. The DCF is not needed and only serves the muddle the results of the experiment. For example, the transmitter and receiver characterization pages contain results that were gathered using the NOMAC low-level application.

2) NOMAC serves as a foundation for novel MACs that do not adhere to the 802.11 standard. If you want to built something that is totally different than the DCF, then it's likely easier to start with NOMAC and build up as opposed to starting with the DCF and tear down before building up. For example, the frequency-division duplexing, frequency-hopping, and token passing MACs are all examples of medium access strategies that are not based on DCF behaviors. All of them were built on top of NOMAC.

3) NOMAC serves as a simple example of how to interact with the PHY. The DCF is a complicated design. Most users start off by looking at how transmissions and receptions work in NOMAC before studying the DCF.

dongchen wrote:

What's more, if I want to realize a simple communication between a WARP v3 hardware and a computer, can I use the .elf file which uses the IBSS application in CPU High and DCF MAC in CPU Low? I hope that you can give some advice to help me to relize the goals.

Either the IBSS or AP high-level projects should work for this application. After the node boots up, your computer can join either the MANGO-AP or MANGO-IBSS (ad-hoc) networks and communicate with a device plugged into the Ethernet side of the WARP node. See the user guides for the AP and the IBSS projects.

Offline

 

#5 2018-Mar-05 06:51:01

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

I couldn't understand the content of the programs very well in the 802.11 reference design. Could you provide me with some learning meterials or program flow charts to help me understand these programs in the 802.11 reference design?

Thank you very much!
Dong Chen

Offline

 

#6 2018-Mar-05 08:23:33

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Some questions about usage methods of the 802.11 Reference Design

The best resources are the user guide and source code; we're happy to answer any specific questions that aren't covered by these.

Offline

 

#7 2018-Mar-21 22:08:24

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

I want to know if the 802.11 Reference Design is only implemented to enable the WARP V3 board to connect to a Wifi network or also can enable the WARP V3 board to send and receive data with a specific computer. The wlan_mac_ibss.c file under the src package in the wlan_mac_high_ibss package of the 802.11 Reference Design has a section of the code as follows:


// If you want this station to try to associate to a known IBSS at boot, type
// the string here. Otherwise, let it be an empty string.

static char default_ssid[SSID_LEN_MAX + 1] = "MANGO-IBSS";


Does that mean that I just need to replace the "MANGO-IBSS" with the SSID of a network if I want to connect the WARP V3 board to a Wifi network?

What's more, I want to know where the code is to enable the WARP V3 send or receive data with a specific computer.

Thank you very much!
Dong Chen

Offline

 

#8 2018-Mar-22 09:54:55

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

dongchen wrote:

I want to know if the 802.11 Reference Design is only implemented to enable the WARP V3 board to connect to a Wifi network or also can enable the WARP V3 board to send and receive data with a specific computer.

The 802.11 Reference Design has three top-level projects:

1) An AP that hosts a network that other devices can join. These devices can be other WARP v3 boards running the STA design or commercial Wi-Fi devices like smartphones/laptops.

2) A STA that can join an AP. This AP can be another WARP v3 board running the AP design or a commercial access point.

3) An IBSS that hosts or joins an ad hoc network with other devices.

dongchen wrote:

The wlan_mac_ibss.c file under the src package in the wlan_mac_high_ibss package of the 802.11 Reference Design has a section of the code as follows:

Code:

// If you want this station to try to associate to a known IBSS at boot, type
// the string here. Otherwise, let it be an empty string.

static char default_ssid[SSID_LEN_MAX + 1] = "MANGO-IBSS";

Does that mean that I just need to replace the "MANGO-IBSS" with the SSID of a network if I want to connect the WARP V3 board to a Wifi network?

If the Wifi network is an ad hoc network, yes. Otherwise, it sounds like the STA design might be a better fit. The STA has a similar line of code that will perform an active scan and join the SSID "MANGO-AP" if it sees it. You can change that SSID to the network you want it to join. Note: this network must have security disabled for the STA to successfully join it.


dongchen wrote:

What's more, I want to know where the code is to enable the WARP V3 send or receive data with a specific computer.

The 802.11 Reference Design implements a standard Ethernet portal. The wireless device it sends a packet to is based on the destination MAC address of the Ethernet frame it receives. The design can also transmit locally generated payloads using the local traffic generator (LTG) subsystem.

Offline

 

#9 2018-Mar-22 22:43:26

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

After I download the STA program to the WARP V3 board and the WARP V3 board has been connected to a Wifi network,  what should I do if I want to send data to a personal computer which has been also connected to this network?

Thank you very much!
Dong Chen

Offline

 

#10 2018-Mar-23 12:28:11

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

The STA implements an ethernet portal. If you plug it directly into a PC's Ethernet port, that PC will be able to send any IP traffic to the rest of the network. Note: STAs don't send traffic directly to other STAs on the same wireless network. It will get routed through the AP.

Offline

 

#11 2018-Apr-08 23:19:58

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

As you said above, a STA can join a commercial access point. If I downloaded the STA program to the WARP V3 board and  the WARP V3 board was connected to a Wifi network, I want to know if the warp v3 board can send and receive data through the way of wireless communication with a specific computer which was also connected to the same network which the warp v3 board was connected to. In the other words, can the warp v3 board with STA program downloaded in be used as a node like the computer to communicate in a wireless way with other computers which be conneted to the same network? If it is ok, I hope that you can tell me where the code is to implement the wireless communication of data between the warp 3 board and the computer or provide me some learning materials to explain this process.

Thank you very much!
Dong Chen

Offline

 

#12 2018-Apr-09 10:19:30

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

dongchen wrote:

I want to know if the warp v3 board can send and receive data through the way of wireless communication with a specific computer which was also connected to the same network which the warp v3 board was connected to. In the other words, can the warp v3 board with STA program downloaded in be used as a node like the computer to communicate in a wireless way with other computers which be conneted to the same network?

Clients that are associated with an AP don't communicate directly with one another. They communicate via the AP in two hops. This behavior is implemented. The behavior you are describing is better suited for an IBSS network (aka an "ad hoc" network). This always works with commercial devices -- you have to "create a network" on whatever commercial device you are using.

All projects implement a standard Ethernet portal, so you can communicate with other devices on the network without changing any C code. Specifically:

1. If you plug a laptop into W3's ETH A port and let the STA design associate with a commercial AP, a DHCP server upstream of the AP should give your laptop an IP address. If you attempt to pink the IP address of another wireless client on the AP, that communication will hop through the AP and not communicate directly from W3 to the other client.

2. If you have a similar setup but use the IBSS project, you'll probably need to self-assign IP addresses to your network. Once you do that, you should be able to ping the IP address of other members of the IBSS and that communication will occur directly without hopping through a central node.

Offline

 

#13 2018-Apr-10 05:16:02

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

What you mentioned before is that I need to plug a laptop into W3's ETH A port. I want to know whether I can implement the communication between a computer and a warp v3 board without a laptop plugged into it, that is, can a single warp v3 board send or receive date with another computer if the single warp v3 board and the computer are connected to the same network. In other words, what I want to implement is that a single warp v3 board sends data to a computer through the radio interface A and B.

What's more, I want to know where is the code to realize the data sending from the warp v3 board to other devices in the 802.11 Reference Design and how I should modify the code of the 802.11 Reference Design if I want to implement it. I hope that you can give me some advice. 

Than you very much!
Dong Chen

Last edited by dongchen (2018-Apr-10 07:01:33)

Offline

 

#14 2018-Apr-10 09:29:25

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Some questions about usage methods of the 802.11 Reference Design

I'm sorry, but I don't understand what you're trying to build. Can you describe (in detail) what network topology you need - How many WARP v3 nodes? How many Wi-Fi clients? How many wired clients? What nodes are connected wirelessly and/or wired?

Offline

 

#15 2018-Apr-10 23:27:45

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

What I want to implement is a experiment, the Man-in-the-middle Attack in Wireless Network. That is, I want use the warp v3 board as a attacker to interfere with the communication between the other two devices.

We consider a simple wireless ad-hoc network in which two parties (for example they are two computer) communicate with each other through a wireless connection (for example, using 802.11 wireless connection). Assume that the two computers have already went through the handshake phase and have a wireless link available between them. Now one of the computers named as Alice want to send a message to another computer named as Bob. In the MITM  attack scenario, the attacker intercepts the legitimate message and sends fake message. By the end of the scenario, Alice and Bob end up with sharing a message with the attacker.

In theory there is a possible ways to do this: message collision. More concretely, the attacker jams Alice’s message, causing a collision at Bob’s receiver, which is very ordinary on a busy wireless network. The collision prevents Bob decoding Alice’s message. The attacker can now send his own message to Bob, with the help of a directional antenna so that Alice does not notice it.

Now let’s consider the 802.11 Wi-Fi protocol. In the Wi-Fi protocol, each successful transmission is followed by an acknowledgment message. The above attack strategy then will not work since Alice will know something is going wrong if the message jammed and it receives no acknowledgment of the reception of its message from Bob. Accordingly, the attacker will modify his strategy: it will not only jam the transmission, but also will jam or forge the acknowledgment when necessary. The whole process is illustrated in the following:
1.Alice sends a message M.
2.Attacker jams M.
3.Attacker forges Ack and sends it to Alice.
4.Attacker forges M1 and sends it to Bob.
5.Bob sends Ack.
6.Attacker jams Ack.

These are all the experimental processes I want to achieve. In the experiment, there are two Wi-Fi clients (they might be two laptops) and a warp v3 board(as an attacker). All these devices communicate with each other in wireless way. So firstly, I just want to realize the wireless communication between a laptop and a warp v3 board. The network topology is an ad-hod network.

The IBSS project in the 802.11 Reference design can joins an ad-hoc network. But I don’t know how to modify the code of the IBSS project to realize that a warp v3 board send a specific custom message to a laptop which is connected with the warp v3 board in an ad-hoc topology. I can’t even find where the code is to implement sending data from the warp v3 board to the laptop in the 802.11 Reference design. I hope that you can tell me where the code is to send data and how I should modify the code to realize sending specific custom message from a warp v3 board to another device in an ad-hoc topology.

Thank you very much!
Dong Chen

Last edited by dongchen (2018-Apr-11 08:50:20)

Offline

 

#16 2018-Apr-11 10:25:53

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

Sounds like an interesting project. The 802.11 Reference Design is definitely a good fit for it. Here are some high-level thoughts in on where in the design you might make modifications to realize the design you described:

* Jamming an ongoing reception should take place in CPU_LOW. Specifically, the frame_receive() function of wlan_mac_dcf.c gets called while a reception is ongoing. Initiating a new transmission in this context will effectively jam the reception for other nearby devices.

* Forging an ACK also belongs in the DCF. The frame reception code starting here speculatively creates an ACK for transmission and only sends it if the reception was FCS good and addressed to the node running that code. You'll want to change that behavior to send an ACK for packets whose receiver address match other known devices on the network.

* Forging M1 is probably best suited for implementation in CPU_HIGH. In the IBSS code, there are two places where data packets get enqueued for transmission. ethernet_receive() sticks an 802.11 header on an already-existing payload that came from the Ethernet processing in the framework. This probably isn't super useful for mimicking how to create your own totally custom payloads. Instead, you should look into the Local Traffic Generation (LTG) framework. Specifically, the ltg_event() function gets called periodically to enqueue a new packet whose payload is created in that context. You could probably do something similar for the construction of M1.

Offline

 

#17 2018-Apr-13 09:45:26

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

I have the following questions.

1.The frame_receive() function of wlan_mac_dcf.c seems to determine how to transmit data and which data will be transmitted according to the different kinds of information received. Do I understand it right?

2.You said before that initiating a new transmission in this context will effectively jam the reception for other nearby devices. Sorry, I can’t understand what you mean. Do you mean that jamming the reception for other nearby devices can be realized through transmitting data to a destination node no matter what data I receive? Can you explain it to me in detail? Which part of the program should I initiate a new transmission?

3.I don’t know how to initiate a new transmission. Can you tell me how to do it in detail?

4.Can you provide me with a description document of all functions in the wlan_mac_low_dcf project and the wlan_mac_high_ibss project or tell me where I can find it? Because I want to know which functions I can to call if I want to realize a specific content (for example transmitting data) and it's hard and exhausting to read the code line by line. I would be much more grateful if you could provide me with flowcharts of these functions.

Thank you very much!
Dong Chen

Last edited by dongchen (2018-Apr-13 09:53:13)

Offline

 

#18 2018-Apr-13 10:24:30

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

dongchen wrote:

1.The frame_receive() function of wlan_mac_dcf.c seems to determine how to transmit data and which data will be transmitted according to the different kinds of information received. Do I understand it right?

It's looking at the incoming data to see if it needs to send a CTS (if what was received is a RTS to the node) or an ACK (if what was received was a DATA frame to the node). It's made a little more complicated by the fact that it sets up those transmissions early in the case of short received packets. For longer packets, there is enough time during the reception to do other stuff before having to set up the transmission to hit the SIFS requirement.


dongchen wrote:

2.You said before that initiating a new transmission in this context will effectively jam the reception for other nearby devices. Sorry, I can’t understand what you mean. Do you mean that jamming the reception for other nearby devices can be realized through transmitting data to a destination node no matter what data I receive? Can you explain it to me in detail? Which part of the program should I initiate a new transmission?

I was giving a high-level suggestion. When you have a device that is in frame_receive() dealing with an ongoing waveform that's still on the air you have an opportunity that begin transmitting something while that reception is still happening. Any neighboring devices will receive the superposition of the original reception and your new transmissions -- this will likely cause a collision. I'm not able to tell you the specifics of how to accomplish this. You'll need to study the code carefully. I believe it will only be C code changes and you don't need to touch the hardware design.

dongchen wrote:

3.I don’t know how to initiate a new transmission. Can you tell me how to do it in detail?

It's all there in the C code. You need to study it in detail. As we've said before, frame_receive() initiates CTS and ACK transmissions. In the same file, frame_transmit_general() sends DATA packets. Start from poll_tx_pkt_buf_list(). That function looks to see if there are any transmissions ready to be sent that were passed down from CPU_HIGH. If there are, it begins a transmission. You'll need to follow the code flow as it jumps from the DCF to the low framework files.

dongchen wrote:

4.Can you provide me with a description document of all functions in the wlan_mac_low_dcf project and the wlan_mac_high_ibss project or tell me where I can find it? Because I want to know which functions I can to call if I want to realize a specific content (for example transmitting data) and it's hard and exhausting to read the code line by line. I would be much more grateful if you could provide me with flowcharts of these functions.

Such documentation does not exist. The comments directly in the C code are the best way for understanding what its doing. The design is complex and it will take time to understand it all.

Offline

 

#19 2018-Apr-15 09:35:47

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

I want to know what the three files (wlan_exp_node_ibss file, wlan_mac_ibss_uart_menu file and wlan_mac_ibss file) are used to realize respectively in the 802.11 reference design.

Thank you!
Dong Chen

Offline

 

#20 2018-Apr-15 10:29:03

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Some questions about usage methods of the 802.11 Reference Design

wlan_exp_node_ibss.c implements functions for the wlan_exp framework which are specific to the IBSS application. Other wlan_exp functions which are not specific to IBSS  are implemented in wlan_exp_node.c.

wlan_mac_ibss_uart_menu.c implements the UART menu (interactive console available via the CPU High UART) for the IBSS application.

wlan_mac_ibss.c is the top-level source file for the IBSS application in CPU High. This file implements all the IBSS-specific MAC behaviors.

Offline

 

#21 2018-Apr-16 09:10:09

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

I have the following questions:

1.By reading the code, I found that the handle_tx_pkt_buf_ready function is used for saving the packet buffer index into one of two global dl_list structs (gl_tx_pkt_buf_ready_list_general or gl_tx_pkt_buf_ready_list_dtim_mcast) based upon the pkt_buf_group_t in the tx_frame_info_t for that packet buffer when a ready message for a Tx packet buffer is sent from CPU_HIGH. So I think if the warp v3 board want to send message, this function needs to be called in the code of the CPU_HIGH so as to let the board know what message is ready to transmitted. But I am puzzled as to that I can find where this function is called in the code of CPU_HIGH. Can you tell me where the handle_tx_pkt_buf_ready function is called?

2.As we all know, if a node wants to send data to another node, it needs to know the physical address of another node. By reading the code, I think the frame _transmit_general function is used for transmitting data to another node. But I can’t find where this function inputs the physical address of the other node which receives the message from the node?

Thank you very much!
Dong Chen

Offline

 

#22 2018-Apr-16 09:29:49

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Some questions about usage methods of the 802.11 Reference Design

1) Those variables and functions are only used in CPU Low. CPU High cannot use these. These functions are part of the handshake between CPU High and Low for new Tx packets. Refer to the user guide for more details on this handshake.

2) Tx packets are created in CPU High, including the full MAC header with the MAC address fields. Packets are enqueued after creation then, sometime later, de-queued and passed to CPU Low for transmission.

Offline

 

#23 2018-Apr-19 10:44:34

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

The Itg_event() function needs to be provided with two parameters:u32 id( Unique ID of the previously created LTG) and callback_arg(Callback argument provided at LTG creation time; interpretation depends on LTG type). As you said previously, Tx packets are created in CPU High, including the full MAC header with the MAC address fields. Does the callback_arg parameter contain the MAC address of the packet to be sent? If so, the function is not be provided with the two parameters when it is called in the main() function in wlan_mac_ibss.c file. So how does the CPU High provide the MAC address to the Itg_event() function or where is the code to realize this?

Thank you very much!
Dong Chen

Last edited by dongchen (2018-Apr-19 10:48:19)

Offline

 

#24 2018-Apr-20 05:13:18

dongchen
Member
Registered: 2018-Feb-06
Posts: 24

Re: Some questions about usage methods of the 802.11 Reference Design

Hi,

As you said before, Tx packets are created in CPU High, including the full MAC header with the MAC address fields. I want to know where is the code to get the Mac address and where is the code to put the Mac address to the Mac header.

Thank you very much!
Dong Chen

Offline

 

#25 2018-Apr-23 10:10:28

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Some questions about usage methods of the 802.11 Reference Design

First, please don't create duplicate threads.

dongchen wrote:

The Itg_event() function needs to be provided with two parameters:u32 id( Unique ID of the previously created LTG) and callback_arg(Callback argument provided at LTG creation time; interpretation depends on LTG type). As you said previously, Tx packets are created in CPU High, including the full MAC header with the MAC address fields. Does the callback_arg parameter contain the MAC address of the packet to be sent? If so, the function is not be provided with the two parameters when it is called in the main() function in wlan_mac_ibss.c file. So how does the CPU High provide the MAC address to the Itg_event() function or where is the code to realize this?

The address is in the callback_arg. The callback_arg has to be cast as a specific type describing the payload of the LTG. The most common type is "ltg_pyld_fixed", which is used for constant-bit-rate traffic sources that produce a payload of identical length for each packet. this line pulls the destination address from the callback_arg.

The MAC address makes its way into the callback_arg when the LTG is originally set up. Typically, user will employ wlan_exp in Python on a host PC to configure and start an LTG on the node. See the n.ltg_configure wlan_exp command. But this isn't a strict requirement. It's not documented well, but you can configure an LTG directly from C using the ltg_sched_create() and ltg_sched_start() functions. That's how wlan_exp works -- it calls those functions when processing the CMDID_LTG_CONFIG command from the Python host.

For the sparsely commented ltg_sched_create function,

- The first argument, type, should be "LTG_SCHED_TYPE_PERIODIC" if you want the traffic schedule to periodic.
- Assuming type LTG_SCHED_TYPE_PERIODIC, the "params" should be a pointer to a ltg_sched_periodic_params struct that you create and fill in with whatever parameters you want. Note: a "duration_count" of "LTG_DURATION_FOREVER" will make it so the LTG does not automatically stop generating frames after a certain number has been met.
- The third argument should be a pointer to a ltg_pyld_fixed struct that you fill out. That's the argument that eventually gets passed to the ltg_event function when the scheduler calls it. This is the struct that contains the destination address. For an IBSS project, any arbitrary address here will result in an enqueued frame whose receiver address matches the provided address.

dongchen wrote:

As you said before, Tx packets are created in CPU High, including the full MAC header with the MAC address fields. I want to know where is the code to get the Mac address and where is the code to put the Mac address to the Mac header.

Look how addr_da is actually used in ltg_event. It's passed off to wlan_mac_high_setup_tx_header to be filled into the "tx_header_common" variable. This variable is then used in the construction of the LTG payload with the following call to wlan_create_ltg_frame(). The result is a complete ready-to-be-transmitted 802.11 frame sitting in the Tx queue in DRAM. Once dequeued, the whole thing gets copied into a Tx packet buffer and passed off to CPU_LOW.

From your other thread:

dongchen wrote:

Official website about the 802.11 reference design shows that the ltg_event() function in the wlan_mac_ibss.c file gets called periodically to enqueue a new packet whose payload is created in that context. And the code comments about the handle_tx_pkt_buf_ready() function in wlan_mac_dcf.c file says that it saves the packet buffer index into one of two global dl_list_structs based upon the pkt_buf_group_t in the tx_frame_info_t for that packet buffer when a message for a Tx packet buffer is sent from CPU_HIGH. My understanding of this is that the ltg_event() function will periodically and constantly generate packets and once a new packet is generated, the packet buffer index of the packet will be saved into one of two global dl_list structs by the handle_tx_pkt_buf_ready() function. Do I understand it right?

Only indirectly. ltg_event() periodically enqueues packets into DRAM that cannot be accessed by CPU_LOW. poll_tx_queues() then empties the queue whenever there is available occupancy in the Tx packet buffers that are shared between CPU_HIGH, CPU_LOW, and the TX PHY core. When that context copies a payload from DRAM into a Tx packet buffer it sends an IPC message to CPU_LOW to inform the processor it has done so. It's on receipt of this IPC message that CPU_LOW populates the global dl_lists that you mentioned.


dongchen wrote:

If what I understand is right, whether can I use the the frame_transmit_general() function in wlan_mac_dcf.c file to send the packet generated as describe above at any time?

You probably don't want to violate the round-trip between CPU_HIGH and CPU_LOW. Every dequeued packet should lead to a single call of frame_transmit_general(). Generally speaking, you want to use CPU_HIGH to create the packets you want to send and not try to do it directly in CPU_LOW (there are exceptions to this rule of thumb: CPU_LOW generates packets like periodic beacons and control responses. But these are corner cases that need to be carefully studied if you want to do something similar).

Offline

 

Board footer