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
In reply to Jeremy:
Hi Jeremy,
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
In reply to Peter Giacomini:
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"