WICED WiFi Driver stalls after several seconds, buffer allocation error

[Anonymous]

Hi all,

I've two problems.

I've implementing some code between LwIP and WWD. My code contains one thread with queue (I use own queue implementation).

I found point of integration of my code between LwIP and WWD. To receive data from LwIP I've used own function instead of wiced_network_send_ethernet_data() function and in my code I call wiced_network_send_ethernet_data() function to send data to WWD. I receive data from WWD in function host_network_process_raw_packet().

So, my code receives data from WWD, then does some modification in own thread and then sends it to LwIP.

Also I've enabled monitor mode and changed in function wiced_wifi_prepare_join parameter for ioctl WLC_SET_INFRA to zero to enable Ad-Hoc mode.

First my problem is about function wiced_network_send_ethernet_data().

If I allocate own packet by function host_buffer_get and function wiced_network_send_ethernet_data() often fails inside itself in piece code:

/* Add link space at front of packet */

    result = host_buffer_add_remove_at_front( &buffer, (int32_t) -WICED_LINK_OVERHEAD_BELOW_ETHERNET_FRAME );

    if ( result != WICED_SUCCESS )

    {

So, it means that function host_buffer_add_remove_at_front can't allocate additional space before buffer.

I found 2 workarounds here. First is to allocate new temp buffer by malloc, then copy current to buffer to it, and then create new buffer by function host_buffer_get with enough space.

Second workaround is to allocate huge buffer in my code and there use function host_buffer_add_remove_at_front to decrease size. It allows to allocate additional spaces later in function wiced_network_send_ethernet_data().

But it looks strage, what do you think?

My second problem is in WWD driver. When all this stuf is working (LwIP <-> My code <-> WWD driver + monitor mode + ad-hoc), WWD driver stalls after several seconds. So I'm able to send several packets between modules but after several second they don't want to send or receive any packets.

I see in debugger that wiced_thread_func (in file wwd_thread.c), where WWD shall send/receive packets, stalls in getting semaphore:

result = host_rtos_get_semaphore( &wiced_transceive_semaphore, (uint32_t) WICED_THREAD_POLL_TIMEOUT, WICED_FALSE );

Do anybody know what I did wrong in the code that could lead to this behaviour?

P.S.

My boards: SSB-WM-N01

SDK version: 2.4.1

[GregG_16]

The header also mentions buffer allocation error. But explanation does not say anything about it. So, in case this error is seen, there is a possibility that the buffers are not freed properly. In case some packets are being consumed by "My code" module, it needs to free the buffer by calling host_buffer_release().

About the second problem of wiced_thread_func stalling in getting semaphore.

This is the expected behavior of wiced_thread_func() thread. It waits on this semaphore (wiced_transceive_semaphore), and gets woken up when a packet is to be received or when a packet needs to be sent.

The problem of link space at the front of the packet inside wiced_network_send_ethernet_data()

For this problem your solution

“Second workaround is to allocate huge buffer in my code and there use function host_buffer_add_remove_at_front to decrease size. It allows to allocate additional spaces later in function wiced_network_send_ethernet_data()”

Is good. You allocate buffer which has enough space for WICED_LINK_OVERHEAD_BELOW_ETHERNET_FRAME, and then reserve this space using host_buffer_add_remove_at_front().

This is the correct behavior, functions like wiced_packet_create_tcp(), the system reserves the space for TCP/IP and link headers at the head of the buffer. This is done to ensure that no copy is required to add TCP/IP and link headers to the packet.

dshenoy thanks for the help.

[Anonymous]

Hi gangi,

The header also mentions buffer allocation error. But explanation does not say anything about it. So, in case this error is seen, there is a possibility that the buffers are not freed properly. In case some packets are being consumed by "My code" module, it needs to free the buffer by calling host_buffer_release().

I don't need to call host_buffer_free() because it does in WWD driver thread or in LwIP stack.

About the second problem of wiced_thread_func stalling in getting semaphore.

This is the expected behavior of wiced_thread_func() thread. It waits on this semaphore (wiced_transceive_semaphore), and gets woken up when a packet is to be received or when a packet needs to be sent.

In a WiFi sniffer I see packets intended to my board, but there is no reaction from WWD (no packets from WWD). At the same time, I send packets to WWD, but it also doesn't send them to wireless medium (no packet in the sniffer). It is what I mentioned:

WWD driver stalls after several seconds. So I'm able to send several packets between modules but after several second they don't want to send or receive any packets.

So, I agreed with new allocation, but I still have a problem with WWD.

[Anonymous]

Hi Pavel,

Can you explain what outcome you are trying to achieve?

Your description looks like you are modifying things in the wrong place causing you the troubles you are seeing.

[Anonymous]

Hi nikvh,

I have some code that I want to integrate between LwIP and WWD. And I want to receive management and data frames from WWD and WWD shall work in ad-hoc mode.

I have done that integration as I see it and now I want to get it working.

But I see that WWD malfunctions.

I have enabled monitor mode, because described WWD API that allows to receive beacons doesn't work.

I have changed infrastructure mode with ad-hoc mode by ioctl.

[GregG_16]

Hello,

If you are attempting to use 'monitor mode' to simulate the 'ad hoc' function, unfortunately this will not work.

[Anonymous]

gangi,

I'm not trying to "simulate ad-hoc over monitor mode". It is independent features.

I'm trying to use ad-hoc mode and run monitor mode, because I need beacons frames that I can't retrieve by default WICED API.