Secondary network interface does not come up if primary (Ethernet) not connected

We have a custom board with both an Ethernet configured as the primary network interface and WiFi (Redpine) configured as the secondary network interface using SSP 1.3.0.

When the Ethernet cable is not connected, the WiFi does not communicate with the IP stack.

The following scenario does work: WiFi primary network interface without Ethernet as Secondary interface, the WiFi comes up as either an AP or Client.

The following scenario does work: WiFi primary network interface with Ethernet as Secondary interface, the WiFi comes upon as either an AP or Client and the Ethernet comes up with either DHCP or a fixed IP address.

The following scenario does not work: When the Ethernet (no cable connected) is the primary network and the WiFi is an AP, the SSID shows up in the list of networks on a client, but the client does not obtain an IP address from the DHCP server (the NetX DHCP server is set up for the second network interface in this case).

The following scenario does not work: When the Ethernet (no cable attached) is the primary network and the WiFi is a client with the WiFi network interface configured for DHCP (the NetX DHCP client is configured to support the second network interface) an IP address is assigned by the router, but the system does not respond to a ping or access attempts to any of the NetX applications (FTP, Telnet, etc.).

The following scenario does not work: When the Ethernet (no cable attached) is the primary network and the WiFi is a client with the WiFi network interface configured for a fixed IP address, the system does not respond to a ping or access attempts to any of the NetX applications (FTP, Telnet, etc.).

According to the ThreadX NetX documentation "Internal IP Thread" section, the internal IP thread does not enter the event checking loop until after the link enable call to the primary network interface. Does the Internal IP Thread enter the event loop if the primary network interface does not come up?

Are there any other scenarios that would cause the the second network interface to be ignored?

thanks,

pete

  • Hi Pete,

    Please wait a little bit more until Synergy experts respond to your post. Thank you for understanding.

    JB
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    https://en-us.knowledgebase.renesas.com/

  • In SSP 1.3.x the SF_WIFI_NSAL_NX is hard-coded to use IP interface 0, so it can only be the primary interface. In SSP 1.4.0 (and later) this should be fixed (though isn't listed in the release notes)
  • In reply to Jeremy:

    Jeremy,

    Thanks for the info. We will eventually update our project to the latest release, but we are waiting since we have made a number of changes to several frameworks and are working towards a field trial. We didn't want to push the schedule back to redo the changes and incorporate the new updated features that we implemented ourselves before they were available in the later SSP versions (HTTPS, mbedTLS, cellular/GPS support, etc.).

    How difficult is the change to the SF_WIFI_NSAL_NX framework? We have already modified a dozen or so files in the WiFi framework to support WiFi enterprise security, Redpine FW update through SPI, and numerous WLAN features (antenna selection, radio band, etc.). We could make the modifications to our version of SSP 1.3.0 in the short term if the work isn't too extensive.

    thanks,
    pete
  • In reply to Jeremy:

    Hi Jeremy,

    We decided it was worth the effort to upgrade to the latest SSP release (1.5.0-rc1) now before we do a field trial.

    Are all the changes required to support the WiFi as a secondary interface in the Synergy SSP section of SF_WIFI_NSAL_NX or are there changes that need to be made in the Redpine supplied portion of the framework?

    thanks,
    pete
  • In reply to Peter Giacomini:

    The changes required are in SF_WIFI_NSAL, however you might need a version of the redpine pack that is compatible with SSP 1.5.0-rc1. Also included in SSP 1.5.0-rc1 are fixes for wifi Issue ID: 11136 and Issue ID: 11337 (the details are in the release notes for SSP 1.5.0-rc1)
  • In reply to Jeremy:

    Hi Jeremy,

    Thanks for the additional guidance.

    I was able to compile our project with SSP 1.5.0-rc1, but as you indicated I had to modify the Redpine pack to account for SF_WIFI_NSAL differences. The changes were minor and localized to a single file, but I still need to go through the compiler warnings and test the code to see if additional changes are required.

    I will take a longer look at the fixes from the release notes to see if more changes are required. I think we are OK with 11337 since we have a large packet buffer pool with oversized (2K) buffers.

    thanks,
    pete
  • In reply to Jeremy:

    Hi Jeremy,

    I was able to make some good progress, but still have a couple of issues remaining.

    I updated our project to 1.5.0-rc1. I had to make some changes since we started the project a long time ago with SSP 1.1.3 before a lot of the higher level framework API's existed. Everything I have retested is working except for the remaining WiFi issues.

    I updated the latest Redpine WiFi Framework pack to be compatible with 1.5.0-rc1. The changes were minor compared to what we already changed to support the enhanced RS9113 features we wanted. Just to let you know, the testing I am doing right know does not have our enhancements included since I wanted to get the WiFi working as the secondary network interface with SSP 1.5.0-rc1 before adding them back in.

    I am now able to bring the Redpine WiFi up as a client when it is the secondary network interface using either a fixed IP address or the NetX DHCP Client. This works as desired whether the Ethernet is connected or not.

    I am still having an issue with using the Redpine in AP mode. I see the SSID on my client, but the NetX DHCP Server is still not providing an IP address. The code that sets up the DHCP Server used to work with SSP 1.3.0 when the Redpine was the primary network interface. I tested the AP mode with SSP 1.5.0-rc1 with both the WiFi as the primary and secondary network interface and neither succeed in obtaining an IP address. Is there some difference in either the WiFi or DHCP Server code with SSP 1.50-rc1 as compared to SSP 1.3.0 that requires changes at the application layer for AP/DHCP Server mode?

    We are also having an issue with the SPI clock maximum rate with the RS9113. The Redpine RS9113 documentation states that it should run up to 25 MHz in low speed mode and up to 85 MHz in high speed mode, but we can't get it to run above 15 MHz. We still need to take a look at this with a scope, but I figured I'd mention it in case someone else has already resolved this. We saw the same issue with the SK-S7G2 and the RS9113 EVK, so I don't believe it is an issue with our custom board.

    thanks,
    pete
  • In reply to Peter Giacomini:

    What is the code you are using for the DHCP server on the wifi. I am not aware of any changes. Do you use the correct interface index for the secondary (wifi) interface?

    Which SPI interface do you use, RSPI or SPI on SCI?
  • In reply to Jeremy:

    Hi Jeremy,

    Below is an excerpt of the routine used to set up the DHCP server. I didn't include the code that checks status since all the calls return NX_SUCCESS. init_dhcp_server() is called after verifying NX_IP_INITIALIZE_DONE with nx_ip_status_check() for the primary interface and after the call to:

    status = nx_ip_interface_attach(&g_ip0, "WIFI 2nd", ip, mask, g_sf_el_nx0); // I have tried 192.168.1.1 and 10.0.1.100 for ip and mask is 255.255.255.0 using IP_ADDR(...).

    =====

    synergy_gen/network.c generated code excerpt:

    VOID g_sf_el_nx0(NX_IP_DRIVER *p_driver)
    {
    nsal_netx_driver (p_driver, &g_sf_wifi0, (sf_wifi_nsal_cfg_t *) &g_sf_wifi0_nsal_cfg);
    }

    =====

    UINT init_dhcp_server(ULONG ip, ULONG mask)
    {
    UINT address_added;
    UINT status;

    #if 0 // I tried both manually creating the server and creating it in the configurator.
    status = nx_dhcp_server_create(&g_dhcp_server0, &g_ip0, &g_dhcp_server0_stack_memory[0], 2048, "g_dhcp_server0 dhcp Server", &g_packet_pool0);
    #endif

    status = nx_dhcp_create_server_ip_address_list(&g_dhcp_server0, 1, ip+1, ip+8, &address_added); // I tried replacing ip+x with IP_ADDRESS(...)

    status = nx_dhcp_set_interface_network_parameters(&g_dhcp_server0, 1, mask, ip, ip); // I also tried making the DNS server zero and commenting out this call.

    status = nx_dhcp_server_start(&g_dhcp_server0);

    }

    =====

    We are using SCI 1 SPI to interface to the RS9113.

    thanks,

    pete

  • In reply to Peter Giacomini:

    I have tested your code for an AP and DHCP server with a different wifi module (WINC1500), and it code does work.

    I am looking into the max frequency of the SPI on SCI.
  • In reply to Jeremy:

    Hi Jeremy,

    Since the DHCP Server works with a different module, I guess the issue must be somewhere in the Redpine part of the code. I will put some breakpoints in and try to trace the DHCP request packet reception and response to find out why it doesn't work with the RS9113.

    thanks,
    pete
  • In reply to Jeremy:

    Hi Jeremy,

    I traced the DHCP Server request coming form the WiFi through the DHCP Server and back out the call to _nx_ip_packet_send(). The request is marked as coming from network interface 1 when it is passed to the DHCP Server, but the response is sent to the ethernet by _nx_ip_packet_send(). I guess I need to look at the new WiFi NSAL Framework for changes to indicate that the response should go to the second interface and not the first. Any guidance on where to start looking for differences?

    I am using R11AN0226EU0101 Wi-Fi Framework Module Rev.1.01 Mar 26, 2018 as a reference. Is this the latest version?

    thanks,
    pete
  • In reply to Jeremy:

    Hi Jeremy,

    I made a little more progress today.

    I switched from adding the DHCP Server through the configurator to adding it with nx_dhcp_server_create() after the IP stack reached the NX_IP_INITIALIZE_DONE state. The DHCP Server response gets sent to the WiFi NSAL now rather than the Ethernet NSAL. I see the response packet being added to the Redpine RS9113 transmit queue. However, I am still not getting assigned an IP address on the client.

    I ran tcpdump to monitor the DHCP sequence (tcpdump -vv -i en0 -n port 67 and port 68) on my laptop. I see several DHCP DISCOVER requests from the laptop in the dump, but no responses. I did verify that the tcpdump will capture the whole DHCP sequence (DISCOVER, OFFER, REQUEST, ACK) when I connect to my normal network AP.

    i also tried an experiment of reducing the SPI speed (all the way down to 1 MHz), but that had no effect.

    I will spend some time following the response packet in the Redpine code after it gets put on the transmit queue tomorrow to try and find out why it isn't making it back to the client.

    thanks,

    pete

  • In reply to Peter Giacomini:

    There is a pack for for the RS9113 for SSP 1.4.0 on the redpine website (www.redpinesignals.com/.../RS9113.N00.WC.REC.SSP.1.2.0.zip, the pack file is in the Redpine/ directory). This might help as SSP 1.4.0 also had the modification to the wifi NSAL to allow the wifi to be the seconadary interface.
  • In reply to Jeremy:

    Hi Jeremy,

    Thanks for the info. I pulled down the new pack and will take a look at installing it this afternoon. It must have been posted recently since I did check before I updated to the latest SSP in our project.

    I have a theory about why the DHCP Server responses aren’t being transmitted and want to look at that first. We have some Python scripts that modify framework code in synergy directory tree prior to the build to add the Redpine enhancements and I will probably need to fix those if any of the Redpine files in the new pack that we modify with the scripts are different.

     

    thanks,

    pete