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.
JBRenesasRulz Forum Moderator
https://renesasrulz.com/https://academy.renesas.com/https://en-us.knowledgebase.renesas.com/
In reply to Jeremy:
In reply to Peter Giacomini:
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.
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 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.