You are not logged in.
Hi,
I'm using 2 WARP 802.11 reference design, I want to use 1 WARP as a slave which transmit packets from Wire interface (ETH_A) only, broadcast, no reception so that it does not auto response (transmission must be disabled except for broadcast packets from ETH_A). So I modify 2 lines in wlan_mac_dcf.c as following, but it cannot transmit broadcast packets from ETH_A
if(board_mode == 0) wlan_mac_low_poll_frame_rx(); //line 204. board_mode = 0: master, 1: slave
and
if(board_mode == 1) return; //line 530 disable beacon transmission. board_mode = 0: master, 1: slave
Can you please explain a bit about the Wired-wireless transmission path? And can you please explain to me why WARP cannot transmit ETH_A broadcast packets after the above modification?
Thanks a lot
Offline
I think it's the second code chunk that broke things. By default, multicast transmissions are buffered and sent after beacon transmissions. If you prematurely exit the beacon transmission function, you wind up breaking that functionality.
If you don't want to transmit any beacons as your slave node, it's better to disable them in the high-level MAC. This shuts off beaconing entirely and makes sure to not buffer any multicast packets. You can do this by calling the AP's configure_bss() function with "BSS_FIELD_MASK_BEACON_INTERVAL" as the update_mask argument and "BEACON_INTERVAL_NO_BEACON_TX" as the interval specified in bss_config->beacon_interval.
Offline
Hi, I tried your solution (use original mac_low - change mac_high only), it can disable the beacon transmission, but it cannot transmit packets from ETH_A
bss_config_t bss_config; bss_config.beacon_interval = BEACON_INTERVAL_NO_BEACON_TX; beam_config_bss_callback(&bss_config, BSS_FIELD_MASK_BEACON_INTERVAL);
Can you tell me the data flow in Tx path (from ETH_A to Wireless)? Does it wait for any special beacon?
I tried to trace the causes but it's quite confusing.
Thank you
Last edited by vutran (2018-Aug-14 01:20:19)
Offline
Hi, I tried your solution (use original mac_low - change mac_high only), it can disable the beacon transmission, but it cannot transmit packets from ETH_A
You'll have to provide more detail - how do you conclude the node is not transmitting multicast packets received on ETH A? When multicast buffering is bypassed (which is the case when beacon Tx is disabled) the AP design will immediately enqueue and transmit multicast packets received on the bridged Ethernet interface. Are you using the AP application in CPU High? Is your node configured to create a wireless network at boot (DIP switches all down)?
Offline
I used "configure_bss(...);" (through a callback) to disable beacon in mac_high_ap.
bss_config_t bss_config; bss_config.beacon_interval = BEACON_INTERVAL_NO_BEACON_TX; beam_config_bss_callback(&bss_config, BSS_FIELD_MASK_BEACON_INTERVAL);
My test setup is the following:
(1) Use python code on a server connected to ETH_A to send 1000000 1000-byte broadcast packets (haven't called the "configure_bss(...);" yet). The TX LED is almost always on during the transmission. So I can confirm the broadcast packets are transmitted
(2) Call the "configure_bss(...);", and use the python code to send packets as mention in (1). The TX LED is just blinking weakly (as same as it is before transmission), so I conclude that the broadcast packets are not transmitted (may be response packets only), so I do (3)
(3) I comment out "wlan_mac_low_poll_frame_rx();" in mac_low_dcf to disable any response packet, then compile. Do (2) again, TX LED is always OFF. So I conclude that both beacon and broadcast packets are not transmitted
Last edited by vutran (2018-Aug-14 10:56:30)
Offline
I found that this line in "wlan_mac_ap.c" causes the problem. When the AP beacon_tx_mode is set to NO_BEACON_TX, the packets are ignored.
if(gl_dtim_mcast_buffer_enable && gl_cpu_low_supports_dtim_mcast && (gl_beacon_txrx_config.beacon_tx_mode != NO_BEACON_TX)) { //Line 801
...I'm wondering if the condition "beacon_tx_mode != NO_BEACON_TX" is important? Can I remove it?
Last edited by vutran (2018-Aug-15 08:10:49)
Offline
That line comes from the poll_tx_queues() function to handle dequeueing the DTIM multicast packet buffer group. If DTIM multicast buffering is disabled, that group isn't used so you don't need to dequeue anything from it. In that case, all packets whether they are unicast or multicast use the "PKT_BUF_GROUP_GENERAL" group.
What makes you believe that line is in error?
Offline
Because when I set the beacon_tx_mode = NO_BEACON_TX (using the configure_bss()), the above "if" block is always false, so the multicast packets are never processed.
I have tried to remove the "&& (gl_beacon_txrx_config.beacon_tx_mode != NO_BEACON_TX)" and it can transmit broadcast packets now. But I'm wondering if removing that condition causes any side effect?
I feel like it is a bug in your code, is it correct?
Offline
I see, thanks for pointing out this behavior. I can see the bug now. In addition to actually disabling beacon transmissions, NO_BEACON_TX was intended to behave as if "gl_dtim_mcast_buffer_enable" was set to zero. That is, multicast packets should use the "PKT_BUF_GROUP_GENERAL" group processing just like unicast packets. However, I missed a case which caused multicast packets to be neither dequeued as PKT_BUF_GROUP_GENERAL nor PKT_BUF_GROUP_DTIM_MCAST when NO_BEACON_TX was set an "gl_dtim_mcast_buffer_enable" was set to one.
I believe the behavior can be fixed by changing line 730 to the following:
if( gl_dtim_mcast_buffer_enable && gl_cpu_low_supports_dtim_mcast && (gl_beacon_txrx_config.beacon_tx_mode != NO_BEACON_TX)) {However, I haven't tested that change. Once I do, I'll reply to this thread and make sure it gets incorporated into the next release.
I think your code change (removing "&& (gl_beacon_txrx_config.beacon_tx_mode != NO_BEACON_TX)") will also give you the behavior you want without any adverse side effects, but it relies on the fact that the DCF will properly ignore the pkt_buf_group of any new to-be-transmitted packets when you've set the beacon_tx_mode to NO_BEACON_TX. It isn't the "right" way to fix it -- it's relying on some sanity checking in the low-level MAC.
Offline
Can you also explain why you don't want DTIM MCAST and tx_beacon_mode == NO_BEACON_TX at the same time? In the wlan_mac_dcf.c (line 258), you move all DTIM MCAST packets to general queue if x_beacon_mode == NO_BEACON_TX (and the transmit function automatically transmits a beacon).
Is there any side effect if I transmit MCAST packets without beacon?
Last edited by vutran (2018-Aug-24 08:45:40)
Offline
Can you also explain why you don't want DTIM MCAST and tx_beacon_mode == NO_BEACON_TX at the same time?
DTIM Multicast Buffering is a standard behavior for 802.11 APs when any associated station enters power savings mode. When a STA is dozing it will not receive any packets. The standard specifies that a dozing STA should wake up at specified beacon intervals (the "DTIM Interval") to receive the latest beacon from the AP. In this situation the AP buffers all multicast transmissions until immediately after the beacon so that all stations (including the ones that just woke up) will receive the multicast traffic. Thus, if the AP does not transmit beacons (a behavior not allowed by the 802.11 spec but is supported by our design), DTIM Multicast Buffering is meaningless. If you disable AP beacon transmissions, the AP must transmit multicast packets just like any other traffic.
Offline