cancel
Showing results for 
Search instead for 
Did you mean: 

Wi-Fi Combo

Anonymous
Not applicable

Hi,

I'm having this strange issue. I'm running my board on dual mode. I've opened a few tcp ports. One port is connected to my MQTT broker and another TCP port is working as server in softAP mode(for OTA code update). Everything works fine till the time I'm not using the softAP. communication with my broker works perfectly.

As soon as I connect my cellphone to softAP, I dont see any communication happening with broker. I'm analyzing this data on my computer using wireshark and I don't see any traffic being generated by my board.

Looks like TCP is getting confused on something for where to send data. Has anyone else faced similar problem??

I'm using freeRTOS with LwIP. For MQTT, I'm using Paho library. Wiced 3.1.2 sdk

0 Likes
33 Replies
SeyhanA_31
Employee

Hi,

I have loaded console application to the BCM943362WCD4 evb and setup to run STA and iperf server.

Connected a client and started the iperf test. While iperf is running, I can connect the to BCM943362WCD4 using iPhone and my PC. There is no issue detected. Perhaps this test do not replicate what you are doing.

It is possible for MCU to reply to a message later then usual while another client is connecting to the STA but connection should not be dropped.

If possible, perhaps you can share your code with us demonstrating the failure.

Seyhan

0 Likes
Anonymous
Not applicable

This sounds very similar to the problem I'm seeing. 

See my post here:

TCP client socket stops transmitting when AP interface connects

Did you ever get it resolved?  I'm using 2.4.1, but the description is almost identical.

0 Likes
SeyhanA_31
Employee

Hi,

Setuped a BCM943362WCD4 as STA and connected a client to it then started the ping. When the second client connects to the same STA, one or two pings are not answered by the STA. Perhaps this shows the delay in response while second client connects to the STA, where this delay causes previously established connection to drop.

We are looking at this issue. Once a solution is available patch will be posted.

Seyhan

0 Likes
Anonymous
Not applicable

As I described in my post, everything works as expected when the TCP client on the STA interface connects to a server on the local network.  The TCP socket functions normally before and after a second connection from a browser is made to the HTTP server running on the AP interface.

However, when the TCP client on the STA interface connects to a server on the internet, the socket becomes unresponsive once a second connection is made to the HTTP server running on the AP interface.

I don't know if that detail is unique to my situation or if shatruddha sees the same thing.

0 Likes
Anonymous
Not applicable

Hey

I'm sorry, I've been busy lately. I've had exactly same situation as you described. In my case I was connecting to MQTT Broker. but after a connection is made with http server on AP interface, previous connection with MQTT was getting disturbed.

I could not find any solution, so for the moment I've dropped the idea of using softAP for the moment.

0 Likes
Anonymous
Not applicable

We hit the same issue, just wondering if you already have the fix for this issue?

Test with snip.apsta:

associate wiced soft AP and connect to http://192.168.0.1 then ping

always timeout.

Network ready IP: 192.168.0.1

Joining : phoenix

Successfully joined : phoenix

Obtaining IP address via DHCP

Network ready IP: 192.168.0.103

Pinging 192.168.0.1 every 1000ms with a 900ms timeout.

Ping Reply : 7 ms

Ping Reply : 4 ms

Ping Reply : 2 ms

Ping Reply : 2 ms

Ping Reply : 0 ms

Ping Reply : 2 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 1 ms

Ping Reply : 3 ms

Ping Reply : 2 ms

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout

Ping timeout


I also trace this issue in my own code and found the reason the device fails to connect via STA interface is:

wiced_tcp_connect returns timeout (It's because netconn_connect() returns lwip_error (-3)).


0 Likes
Anonymous
Not applicable

I haven't found a work around of my own.  I'm still waiting on Broadcom.  Please share any other details you discover.  Fixing this doesn't appear to be a high priority for Broadcom.

0 Likes
JaeyoungY_71
Employee

Hi folks,

We've looked into the problem and were able to identify the error with NetX / NetX_Duo. We create separate NetX stack instances for each interface(STA / AP / P2P), and should have separate ARP caches as well. However in the previous code (3.1.2 and before) it was sharing the same ARP cache between all the interfaces. This was causing corruption in communication. We have tested the below solution out and can confirm this solves the problem for NetX and NetX_Duo. It will be fixed in the next SDK release, in the meanwhile you can apply the changes by the following.

You can change the code in the following locations

    - /WICED/network/NetX/WICED/wiced_network.c

    - /WICED/network/NetX_Duo/WICED/wiced_network.c

/******************************************************

*                Static Variables

******************************************************/

/* Network objects */

++ADD THE FOLLOWING++

static char  wifi_sta_arp_cache[ARP_CACHE_SIZE];

static char  wifi_ap_arp_cache[ARP_CACHE_SIZE];

static char  wifi_p2p_arp_cache[ARP_CACHE_SIZE];

#define WIFI_STA_ARP_CACHE    wifi_sta_arp_cache

#define WIFI_AP_ARP_CACHE    wifi_ap_arp_cache

#define WIFI_P2P_ARP_CACHE    wifi_p2p_arp_cache

static char    wiced_ip_stack[3]    [IP_STACK_SIZE];

--COMMENT OUT BELOW--

//static char    wiced_arp_cache      [ARP_CACHE_SIZE];

In the function wiced_ip_up()

/* Enable ARP */

--COMMENT OUT BELOW--

//if ( nx_arp_enable( &IP_HANDLE(interface), (void *) wiced_arp_cache, ARP_CACHE_SIZE ) != NX_SUCCESS )

++ADD THE FOLLOWING++

if ( nx_arp_enable( &IP_HANDLE(interface), (void *) ARP_FOR_IF( interface ), ARP_CACHE_SIZE ) != NX_SUCCESS )

Unfortunately we could not duplicate this problem on LwIP. We will continue to look into this and will keep you posted on any findings. Thank you for your patience.

Thanks,

Jaeyoung

0 Likes
Anonymous
Not applicable

Hi Jaeyoung,

Did you try apsta snip with LwIP build?

Here is my observation:

1) don't change any code in apps/snip/apsta/apsta.c

   The console shows the ping *always* timeout.

2) modify the code to bring up AP interface before STA interface.

   I can get ping reply after boot.

   But if my PC associate the "WICED Soft AP" and then either wait for a while or just connect to http://192.168.0.1

   Then I can observe ping *always* timeout.

Can you reproduce it?

0 Likes
Anonymous
Not applicable

hi jaeyoung,

In apsta mode.

I think the problem is not able to make new connection on STA interface if

WICED SoftAP is associated. The error is: wiced_tcp_connect result=2

So you can run a tcp/http client  on STA interface to see this issue.

If you are running a server on the device, it can still accept new connections.

Hope this helps to make you reproduce and trace this issue.

0 Likes
JaeyoungY_71
Employee

Hi Sam,

I've tried it out with the snip.apsta app again (LwIP with SDK 3.1.2 on BCM43362WCD4 board). The string of pings are all coming back even when the AP is set up and I connect to the WICED Soft AP and open the 192.168.0.1 page. This was the same even after I changed the sequence to bringing up the Soft AP first and then connect with the STA mode. Here are my results.

Are you saying that you cannot connect with STA mode once the AP is setup? It should not affect the bringup of STA mode at all. Which board are you using?

Thanks,

Jaeyoung

apsta.PNG

0 Likes
Anonymous
Not applicable

Hi Jaeyoung,

Can you ping 168.95.1.1 instead of 192.168.0.1?

The problem is:

Before associate wiced soft AP, ping 168.95.1.1 ok.

After associate wiced soft AP, ping 168.95.1.1 always timeout.

Below is the required change for this test:

-static wiced_ip_address_t  ping_target_ip;

+static wiced_ip_address_t  ping_target_ip = { WICED_IPV4, { .v4 = (uint32_t)(MAKE_IPV4_ADDRESS( 168,  95,  1,  1 )) }};

-    wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

+    //wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

My guess is this is a routing issue. Maybe the firmware send the ping request to wrong interface.

Thanks.

0 Likes
Anonymous
Not applicable

Jaeyoung,

Thank you for looking into this.

The trouble I'm having is with TCP connections.  I'm glad you were able to fix the ping problem but I don't think that is actually a fair test of the problem I'm seeing. A TCP connection on the STA interface stops responding when an SoftAP connection is established.  This was with LwIP.

The fact that you said you don's see the issue in LwIP makes me think we are talking about different problems.

0 Likes
JaeyoungY_71
Employee

Hi Jason,

Yes, as I mentioned in my first answer I was not able to reproduce the STA/AP mode not working together in LwIP. I used LwIP in the SDK 3.1.2 on a 43362WCD4 board. As you can see from the results of my apsta screen, I am able to make connection in STA mode even after the Soft AP mode is brought up and am connected to the http server.

Which board are you using? Perhaps I can try to match your exact environment and run more tests.

Thanks,

Jaeyoung

0 Likes
Anonymous
Not applicable

Hi Jaeyoung,

I think I know the problem I hit but you didn't.

In my test environment, the STA interface uses the same network section as

AP interface (both using 192.168.0.x).

That is why I got ping timeout.

Thanks.

Anonymous
Not applicable

hi,

Just to clarify the issue.

The ping is just to show the symptom.

The main problem is the http/mqtt requests to public server will fail

once someone associate the wiced soft AP (in apsta mode).

So please help to fix this issue.

Thanks.

Anonymous
Not applicable

Hi Jaeyoung,

Can you reproduce this issue now?(with my updated reproduce steps)

0 Likes
JaeyoungY_71
Employee

Hi Sam,

If you see my previous screenshot, my equivalent to your 168.95.1.1 address is 10.0.1.1.

-192.168.0.1 is associated to the AP network I setup

-10.0.1.3 is associated with the STA network I connect to (airportxtrm)

1. Connect with STA mode, I am assigned the IP 10.0.1.3

2. Set AP network up with 192.168.0.1

3. Ping 10.0.1.1 after the AP network gets set up

4. You can see in the screen that all the pings gets replied to.

These two functions look the same, is it something different that you substituted in the code?

-    wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

+    //wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

Could you maybe try a different network for the STA mode? Can you let me know which board you are using?

Thanks,

Jaeyoung

0 Likes
Anonymous
Not applicable

Hi Jaeyoung,

ping 168.95.1.1 means to ping a public server on Internet rather than local network.

I double check this again and found this issue happen on both BCM43362 and BCM4390.

Make sure you do below steps:

1) ping 168.95.1.1 ( It looks fine after boot)

2) Try to associate the "Wiced soft AP" with your PC

3) Then you will find the ping becomes *timeout* once you associate the "Wiced soft AP"

Note, I comment out wiced_ip_get_gateway_address() because I don't want to ping the gateway ip.

I want to ping a ip on Internet (168.95.1.1)

0 Likes
JoYi_1844281
Contributor II

Sam,

Please change IP address to another segment of your Internet access AP!

Your both interface on the same segment 192.168.0.0/24!

You need two different network segment on AP and STA interfaces!

This is the reason why you always failed!

0 Likes
Anonymous
Not applicable

Hi Jone,

Did you really test this with pinging public server instead of local network ip?

I already fixup the network segment conflict issue.

The problem is it fails to ping public ip once the Wiced soft AP is associated.

I repeat the reproduce step again:

1) Make sure you are using FreeRTOS+LwIP build

2) Modify code for below change:

-static wiced_ip_address_t  ping_target_ip;

+static wiced_ip_address_t  ping_target_ip = { WICED_IPV4, { .v4 = (uint32_t)(MAKE_IPV4_ADDRESS( 168,  95,  1,  1 )) }};

-    wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

+    //wiced_ip_get_gateway_address( WICED_STA_INTERFACE, &ping_target_ip );

3) build and boot then you can see ping ok

4) Try to associate the "Wiced soft AP" with your PC

5) Then you will find the ping becomes *timeout* once you associate the "Wiced soft AP"

Note, 168.95.1.1 is a ip on internet, you can replace it to 8.8.8.8 or other ip on the internet.

0 Likes
JoYi_1844281
Contributor II

Hi Sam,

There are some thing wrong in LwIP portion when enable both AP/STA interface!

The wiced_udp_send call by the wiced_dhcp_server will change the default route from STA interface to AP interface. Disable the netif_set_default in internal_udp_send will cause the DHCP packet fail to send via AP interface !

Anonymous
Not applicable

Hi Jone,

Thanks for the information, it looks like a sdk bug that needs fix.

Looking at the discussion in this thread, you can find that I spend a lot of

time to clarify this issue so I'd like to know if someone can reproduce this

issue and if someone is working on this issue.

0 Likes
JaeyoungY_71
Employee

Hi Sam,

We've followed your code and were able to reproduce the problem you are having. We will look into it and will keep you posted on updates to solve this. Thank you for your patience.

Thanks,

Jaeyoung

0 Likes
Anonymous
Not applicable

Hi Jaeyoung,

Any progress for fixing this issue?

I'd appreciate if you can post the patch of this fix for sdk-3.1.2.

0 Likes
Anonymous
Not applicable

Hey Jaeyoung,

If you can provide any kind of confirmation, either it is an issue only we are facing or if you are working on it, it will fill up the communication gap.

Its been more than 5 months since this issue has been raised, but is still unsolved. I thought major purpose of this community was to help developers solve issues like this.

I'm afraid broadcom as an entity, has not been keen on doing that.

0 Likes
Anonymous
Not applicable

Hi,

Just FYI.

We have got a fix for this issue, the test looks good.

0 Likes
MichaelF_56
Moderator
Moderator

sam.lin and forrest.chien

I see that this was resolved working through your local Distribution WICED FAE at Edom.

Could you share a summary of your findings and the resultant fix with the rest of the group here on the thread as it appears there are others with the same issue.

It appears that there may be a patch involved which will be released as part of the upcoming SDK offering.

gangi nsankar

0 Likes
Anonymous
Not applicable

Hey Sam,

Could you please share the fix. It will help us in our development. We can reiterate a few functionalities which we dumped because of lack of support on this.

0 Likes
MichaelF_56
Moderator
Moderator

I checked with the developers and the fix will be applied to SDK 3.4.x, which should be released later this month or early November.

0 Likes
Anonymous
Not applicable

Oh Sam!!

so many times you had to repeat the same thing to convey the problem we are facing. I almost gave up  on using the both interfaces after realizing this issue. 

thanks for keeping it alive.

0 Likes
Anonymous
Not applicable

Hi

I built the snip\apsta, and I can associate to my AP.(dlink-2640). It also got an IP address, but I am unable to ping the gateway (192.168.0.1). Resylts in a timeout See log below.

Can some one please help?

Regards

Narayanan Raman

Starting WICED v3.3.1

Platform BCM943362WCD4 initialised

Started FreeRTOS v7.5.2

Initialising LwIP v1.4.0.rc1

WWD SDIO interface initialised

WLAN MAC Address : 44:39:C4:31:17:3D

WLAN Firmware    : wl0: Nov  7 2014 16:04:33 version 5.90.230.12 FWID 01-1600

Joining : dlink-2640

Successfully joined : dlink-2640

Obtaining IP address via DHCP

Network ready IP: 192.168.0.149

Pinging 192.168.0.1 every 1000ms with a 900ms timeout.

Network ready IP: 192.168.0.1

Pinging 192.168.0.1 .

Ping timeout

0 Likes
Anonymous
Not applicable

The ap/sta fix is not included in SDK-3.3.1.

You need at least v3.4.0 SDK to test it.

0 Likes