WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#26 2018-Apr-24 10:49:40

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

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

Hi,

Firstly, I apologize to you for creating duplicate threads. I am eager to know the answer to my questions. So I do this as a last resort.

Secondly, I am very grateful to you for giving me detailed explanations every time. This is a great help to me.

Lastly, I still have some questions and I hope that you can help me. These problems are as follows.

I have read the functions you listed for me in detail. I want to use the ltg_sched_create() function to set a LTG up. Can I call this function in main() function of wlan_mac_ibss.c file to realize it? If this can be done. Did I need to configure the parameters(type, params, callback_arg, cleanup_callback) required by this function by myself? In the wlan_mac_ibss.c file, there is one line code into which users can input a default ssid to associate the board to a known IBSS at boot. Is this line of code related to the parameters required by ltg_sched_create() function? These parameters relate to the very low level of wireless communication. I think it is difficult to configure them by myself.

Thank you very much!
dongchen

Last edited by dongchen (2018-Apr-25 09:11:32)

Offline

 

#27 2018-Apr-25 10:21:00

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 have read the functions you listed for me in detail. I want to use the ltg_sched_create() function to set a LTG up. Can I call this function in main() function of wlan_mac_ibss.c file to realize it? If this can be done. Did I need to configure the parameters(type, params, callback_arg, cleanup_callback) required by this function by myself?

That's right, you'll need to create the arguments and then provide pointers to them when calling that function. This isn't too hard, but upon reflection this part of the design is pretty poorly commented. It's no excuse, but the reason for that is that most users don't interact with these functions directly and instead invoke LTGs from wlan_exp in a Python host computer. I've created a ticket to fix that in a future release. In the meantime, here is some example code that should help:

Code:

ltg_sched_periodic_params  my_ltg_schedule;
ltg_pyld_fixed             my_ltg_pyld;
u32                        my_ltg_id;

//1) Fill in schedule details
// a) The LTG schedule deals in units of FAST_TIMER_DUR_US, which is 64 usec in the reference design.
//    So, an interval of 31 would enqueue a packet every (31*64 = 1984 usec). Change this to whatever you
//    want. A value of 0 will effectively backlog the enqueue operation so the design transmits a packet
//    as quickly as possible.
my_ltg_schedule.interval_count = 31;
// b) The LTG can automatically stop after a certain number of intervals. Or we can have it run forever once we
// 	  start it by setting to LTG_DURATION_FOREVER
my_ltg_schedule.duration_count = LTG_DURATION_FOREVER;

//2) Fill in the payload details
// a) If we want every enqueued packet to be the same length, used the LTG_PYLD_TYPE_FIXED type
my_ltg_pyld.hdr.type = LTG_PYLD_TYPE_FIXED
// b) Set the MAC address of where you want the packets to go. For example, if
//    we want the receiver address to be 00-01-02-03-04-05, then do the following:
my_ltg_pyld.addr_da[0] = 0x00;
my_ltg_pyld.addr_da[1] = 0x01;
my_ltg_pyld.addr_da[2] = 0x02;
my_ltg_pyld.addr_da[3] = 0x03;
my_ltg_pyld.addr_da[4] = 0x04;
my_ltg_pyld.addr_da[4] = 0x05;
// c) Set the length of the packet. Note: this value does not include the MAC header and FCS bytes.
//	  A value of 1000 will realize a 1028 byte frame from the perspective of the PHY.
my_ltg_pyld.length = 1000;

// 3) Configure the LTG using the above parameters
//    Note: the LTG has the ability to call a user-provided function after an LTG is destroyed. This is useful
//	  if any dynamically allocated memory needs to be freed. For this use, we statically allocated the above
//	  structs so we don't need to provide a callback. A value of NULL tells the framework to not bother calling
//    anything after an LTG is destroyed.
my_ltg_id = ltg_sched_create(LTG_SCHED_TYPE_PERIODIC, &my_ltg_schedule, &my_ltg_pyld, NULL);

// 4) Finally, we can start the LTG
ltg_sched_start(my_ltg_id);

If you stick that chunk of code into this highlighted line, your IBSS project should begin transmitting a data frame to 00-01-02-03-04-05 approximately ever 2ms.

dongchen wrote:

In the wlan_mac_ibss.c file, there is one line code into which users can input a default ssid to associate the board to a known IBSS at boot. Is this line of code related to the parameters required by ltg_sched_create() function? These parameters relate to the very low level of wireless communication. I think it is difficult to configure them by myself.

Not really. The SSID is used by the IBSS at boot to scan for and "join" other ad hoc IBSS nodes with the same string. Once they all agree on the same BSS parameters like the BSSID, then LTGs can be exchanged between them. The outgoing LTG frames have three addresses: a transmitter address (the address of the node transmitting), a receiver address (the address of the node receiving... specified in the above code block), and the BSSID (the address agreed upon during the SSID scan and join at boot).

Offline

 

#28 2018-Apr-27 09:59:54

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

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

Hi,

Thank you for the help you have been to me all the time. I still have some questions which are not very clear and I would like to ask you.

1.I want to know what the type of the packet is created by the ltg_event() function. Is it a data frame, a control frame or a beacon frame? I think it is a data frame. As we all know, Data frames are made up of the following parts: Frame Control, Duration ID, Address1, Address2, Address3, Sequence Control, Address4, Frame Body(the part we usually really want to send), FCS. But I can’t find where the code is to set the Frame Body for the packet. I can just find the code to set other parts(for example MAC header and so on). And I do not remember that we had set the Frame Body in our previous discussion. In the ltg_event() function, there are several lines of code which I think is related to the Frame Body:

// Checkout 1 element from the queue;
curr_tx_queue_element = queue_checkout();
// Create LTG packet
curr_tx_queue_buffer= ((tx_queue_buffer_t*)(curr_tx_queue_element->data));

But the queue_checkout() function is just to remove and return a entry from the free pool. Does the free pool has many frame bodys which have already be written? I hope that you can explain it to me.

2.If I write the program according to the code you last said to me to make the warp v3 board send data to a computer, can I use Wireshark on the computer to capture these data? And how do I determine that the data captured by Wireshark is from the warp v3. Under ordinary circumstances, users can analyze where the packets captured by Wireshark come from through the source address or content of the packet. But I don’t know the IP address of the warp v3(that is, from the computer's perspective, the address which the packet came from) or the content of the packet we send. 

Thank you very much!
dongchen

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

Offline

 

#29 2018-Apr-30 08:31:15

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.I want to know what the type of the packet is created by the ltg_event() function. Is it a data frame, a control frame or a beacon frame? I think it is a data frame. As we all know, Data frames are made up of the following parts: Frame Control, Duration ID, Address1, Address2, Address3, Sequence Control, Address4, Frame Body(the part we usually really want to send), FCS. But I can’t find where the code is to set the Frame Body for the packet. I can just find the code to set other parts(for example MAC header and so on). And I do not remember that we had set the Frame Body in our previous discussion.

Couple of things:

1. It's a data frame. The ltg_event() calls wlan_create_ltg_frame(), which wraps a call to the generic wlan_create_data_frame() function and tacks on some extra LTG-specific payload after.

2. Most packets don't have the "Address4" field you described. All of our data transmissions have 3 addresses (even fewer for control messages). I haven't studied or implemented it, but I think the Address4 field is used for WDS bridging.

3. With the exception of the custom LTG-specific LLC header in the first bytes of the payload, we don't write a payload to the packet. For LTGs, it's all junk data for measuring MAC and PHY performance. The payload of our transmissions is just whatever happens to be sitting in DRAM when that packet is created. The payload gets thrown away at the other end anyway. For Ethernet receptions (where the payload actually matters), the underlying data is filled in by the Ethernet DMA.

dongchen wrote:

In the ltg_event() function, there are several lines of code which I think is related to the Frame Body:

// Checkout 1 element from the queue;
curr_tx_queue_element = queue_checkout();
// Create LTG packet
curr_tx_queue_buffer= ((tx_queue_buffer_t*)(curr_tx_queue_element->data));

But the queue_checkout() function is just to remove and return a entry from the free pool. Does the free pool has many frame bodys which have already be written? I hope that you can explain it to me.

"curr_tx_queue_buffer" is just an address into DRAM someplace given to the code by the Tx queue framework. wlan_create_ltg_frame() fills that address with the entire contents of the frame that will be transmitted (including header and metadata). As I said above, the actual payload or "Frame Body" is never explicitly set since it's not actually needed. The only thing the receiver needs to know is whether the data was successfully decoded. The contents of the data is irrelevant for LTG tests.

dongchen wrote:

2.If I write the program according to the code you last said to me to make the warp v3 board send data to a computer, can I use Wireshark on the computer to capture these data? And how do I determine that the data captured by Wireshark is from the warp v3. Under ordinary circumstances, users can analyze where the packets captured by Wireshark come from through the source address or content of the packet. But I don’t know the IP address of the warp v3(that is, from the computer's perspective, the address which the packet came from) or the content of the packet we send.

Yes, it should all be viewable on Wireshark.  You aren't looking for IP addresses -- that's a layer higher. There is no IP address for an LTG transmission. Instead, you'll need to filter my transmitter MAC address. You'll need to capture in "Monitor Mode" to see the MAC addresses in the 802.11 headers. With this you can see which packets are coming from your WARPv3 node.

Offline

 

#30 2018-May-03 04:20:43

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

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

Dear chunter,

I have modified the code of the 802.11 reference design according to what you told me before and then used the warp v3 board to send data to a computer. But I still can't capture the data sent from the board using Wireshark installed in the computer. If the warp v3 board sends data to a computer through the methods what we discussed before, does the board need to connected with the computer in ad-hoc mode? If the computer and the board doesn't connected to any wire or wireless networks, can the board directly send data to the computer? Can I replace the "MANGO-IBSS" with the SSID of an ad-hoc network in following code to make the board connect to the ad-hoc?(The following code is in the wlan_mac_ibss.c file.)

// 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";


What's more, can you tell me how to know the MAC addresses of the data sent by my warp v3 board(that is, the MAC address of my warp v3 board) in the 802.11 headers so as to I can filter it in Wireshark.

Thank you very much!

Last edited by dongchen (2018-May-03 09:19:41)

Offline

 

#31 2018-May-03 09:21:24

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

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

What's more, can you tell me how to know the MAC addresses of the data sent by my warp v3 board(that is, the MAC address of my warp v3 board) in the 802.11 headers so as to I can filter it in Wireshark.

Every WARP v3 node is assigned two MAC addresses from Mango's address allocation (40:D8:55:04:2x:yz). These addresses are printed on a label on the back of the board. The 802.11 Ref Design uses address A for the wireless MAC address and address B for the wlan_exp interface (ETH B).

The 802.11 Ref Design also prints its wireless MAC address to the CPU High UART on boot.

Offline

 

#32 2018-May-04 07:48:15

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

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

Hi,

Apart from sticking the chunk of the code which you tell me before into the wlan.mac.ibss file, does the warp v3 board need to connected to the same network with a computer if it want to send data to the computer?
If I want to connect the warp v3 board in a ad-hoc network created by a computer, how can I do to input the password of the network to the board?

Thank you very much!

Offline

 

#33 2018-May-04 08:32:17

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

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

If I want to connect the warp v3 board in a ad-hoc network created by a computer, how can I do to input the password of the network to the board?

The current 802.11 Reference Design for WARP v3 (v1.7.6) only supports open (unsecured) networks. You can either:
-Create the ad-hoc network on your PC with no wireless security, then join that network with the WARP v3 IBSS node
or
-Boot the WARP v3 IBSS node first, then join its network from your PC

Offline

 

#34 2018-May-05 08:59:36

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

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

Hi,

Does the warp v3 board need to be connected to the same ad-hoc network with the computer in advance if the warp v3 board wants to send data to the computer?

Thank you very much!

Offline

 

#35 2018-May-05 10:10:08

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

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

Does the warp v3 board need to be connected to the same ad-hoc network with the computer in advance if the warp v3 board wants to send data to the computer?

Yes - 802.11 IBSS nodes must be members of the same ad-hoc wireless network (i.e. share the same SSID and BSSID) before they can exchange data packets.

Offline

 

#36 2018-May-15 09:01:45

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

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

Hi,

Just as what you mentioned before, the warp v3 board must be members of the same ad-hoc wireless network as the computer before they can exchange data packets. I tried to generated a ad-hoc network using the Win7 operating system installed on my computer but the board couldn’t connect to it. Can you recommend me a way to generate ad-hoc network which the board can connect to successfully and tell me how to generate it step by step?

Thank you very much!
dongchen

Offline

 

#37 2018-May-15 14:30:05

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

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

I'm not sure what the actual mechanics of ad hoc networks are on Windows. I don't use any Windows machines that are wireless. However, it might be useful to first create the IBSS on WARP and then have your computer join that network. I suspect it will show up in the list of networks just like typical APs but with some designator to let you know its another device on an ad hoc network. Going that direction might prevent your computer from using MCS and PHY modes that are not supported by the design.

Offline

 

#38 2018-May-15 21:45:11

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

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

Hi,

As we discussed before, the board need to be used as an attacker in the Man-in-the-middle Attack experiment. The board must be concealed so it may be not appropriate to let the computer join the network created by the WARP. Can you recommend me a way to create a ad-hoc network even if it is not in the Win7 operating system.

Thank you very much!
dongchen

Offline

 

#39 2018-Aug-22 01:45:51

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

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

Hi,

The wlan_mac_dcf.c file of the 802.11 Reference Design shows that the n_slot provided to wlan_mac_tx_crtl_A is only a suggestion and there will not be a backoff if the medium has been idle for a DIFS. I want to know where the code is to detected whether the medium has been idle for a DIFS.

Thank you very much!
dongchen

Offline

 

#40 2018-Aug-22 09:04:59

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

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

That behavior is implemented in hardware via the Tx A controller state machine in the wlan_mac_hw core. We made this design decision to minimize the chance of a race condition. If this logic was implemented in software, the latency between checking medium state and initiating a transmission would be large enough that the medium state could change.

Offline

 

#41 2018-Aug-23 00:51:21

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

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

Hi,

How can I modify the code to realize that the board transmits packet immediately without waiting for a DIFS idle medium?

Thank you very much!
dongchen

Offline

 

#42 2018-Aug-23 09:58:19

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

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

These lines of code are where the DCF code tells the underlying hardware what a DIFS should be. The DIFS vs. TxDIFS is a little confusing. TxDIFS is backdated from DIFS by analog Tx latencies. It's when the Tx needs to start such that the first sample out of the radio occurs on the DIFS boundary. You can lower those registers. I'm actually not totally sure what happens if set them to 0. I assume it would work.

Also, if you need to more broadly disable carrier sensing, you can do what NOMAC does and call:

Code:

REG_SET_BITS(WLAN_MAC_REG_CONTROL, (WLAN_MAC_CTRL_MASK_CCA_IGNORE_PHY_CS | WLAN_MAC_CTRL_MASK_CCA_IGNORE_NAV));

That will make it so the "BUSY" signal is not influenced by physical carrier sensing or the NAV.

Offline

 

Board footer