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 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.
My last theory on the issue with the DHCP Server response was not correct. I did some additional testing and it looks like the RS9113 is not responding as expected to the transmission of the DHCP response. The laptop sends 5 DISCOVER requests and I see all of them received by the DHCP Server and responses for all are sent to the WiFi NSAL. They are all sent to the RS9113 on the SPI, but the Redpine driver never gets the transmit complete event it waits on after the transmit. I will try the latest Redpine pack today, but it may be time for me to open up a support case with the Redpine support team for this issue if that doesn't resolve the problem.
We also spent a little time looking at the SPI clock issue. I changed the frequency to 20 MHz in the configurator and we took a look at the clock on a scope. We found that the SPI clock comes out at 30 MHz rather than 20 MHz and the clock edges are significantly rounded as compared to the 15 MHz configuration. This is with the pin drive set at the maximum. The rounded edges are probably OK since there should still be plenty of setup and hold time for the data, but it was unexpected. The RS9113 requires that the SPI be reconfigured to transmit data on the opposite edge above 25 MHz, so I put that on my list to try when we get back to this issue.
I have attached a scope trace for the 20 MHz configuration case.
I just wanted to send the latest status. I updated to the latest Redpine pack into SSP 1.5.0-rc.1. I still have the same issue with the DHCP server not providing a response through the RS9113. I added some code to dump all the interactions on the SPI bus starting after the Redpine comes up as an AP into a log file and captured the corresponding tcpdump output into a second file. I have attached the log files in case you want to see them. I marked the critical sections with ">>>>>>>>>". I see the response to the DHCP DISCOVER sent to the RS9113 and it responds with a success code (0x0 0x58) for the frame. Since the framework is configure to use the NetX IP stack, my understanding is this should be a complete, valid IP frame. I want to spent a little time decoding it, but a quick look seems to indicate that it is a proper DHCP response. I plan to open a support case with Redpine later this afternoon after examining the attached files in more detail.
I also did a little more experimentation with why the DHCP response was originally sent to the primary network interface. I originally though it was due to adding the DHCP server through the configurator. That was incorrect. It turns out that when that was occurring, I had both the primary and secondary network interfaces configured to be on the same sub-net. When I configure them for different sub-nets, the DHCP response was sent to the secondary network interface.
dhcp_trace.txtdhcp_trace.txt
Here's the other file:
10:50:59.464374 IP (tos 0x0, ttl 255, id 63119, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 8c:85:90:ca:f9:31, length 300, xid 0x8fe6cfe3, Flags [none] (0x0000) Client-Ethernet-Address 8c:85:90:ca:f9:31 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 10: Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server Domain-Name, Option 119, Option 252, LDAP Netbios-Name-Server, Netbios-Node MSZ Option 57, length 2: 1500 Client-ID Option 61, length 7: ether 8c:85:90:ca:f9:31 Lease-Time Option 51, length 4: 7776000 Hostname Option 12, length 15: "PeterGiminisMBP" 10:51:00.862081 IP (tos 0x0, ttl 255, id 63120, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 8c:85:90:ca:f9:31, length 300, xid 0x8fe6cfe3, secs 1, Flags [none] (0x0000) Client-Ethernet-Address 8c:85:90:ca:f9:31 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 10: Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server Domain-Name, Option 119, Option 252, LDAP Netbios-Name-Server, Netbios-Node MSZ Option 57, length 2: 1500 Client-ID Option 61, length 7: ether 8c:85:90:ca:f9:31 Lease-Time Option 51, length 4: 7776000 Hostname Option 12, length 15: "PeterGiminisMBP"