CC3135: No ARP messages from other nodes in Network Bypass Mode

Hi Olek,

Do you receive broadcast ARP messages when using the raw socket?

As far as not receiving ARP messages from other nodes, could you please clarify what is the undesirable behavior you are noticing? While ARP requests will be broadcast, the ARP responses by other nodes will only be directed at the requesting host. So, unless the CC3135 is the source of the ARP request, then the responses from the other nodes will not be sent back to the CC3135. If that is what you are observing, then that is the intended behavior of ARP.

If on the other hand you are not seeing ARP responses to requests sent by the CC3135, then I suggest you try a test on your local network with my ARP example code here to determine whether the issue is with your application code, the local network, or the raw socket implementation:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/845693/3134002#3134002

Please let me know whether your issue has to do with seeing ARP responses to ARP requests from other nodes, and whether you need more help with getting ARP to work in your code.

Regards,

Michael

Hi Michael,

Thanks for the prompt reply.

Yes, I do not receive broadcast ARP messages when using the raw socket. Actually, I do not receive any ARP messages.

Sending ARP requests is not a problem.

Please fix your ARP example code adding a conditional statement in Wireless_Decode_Arp_Packet(), for example the following way:

void Wireless_Decode_Arp_Packet(char* buf){ 
  struct arp_hdr* arp1; 
  struct arp_ethip* ethip; 
  struct arp_eth_hdr* ethhdr1; 

  ethhdr1 = (struct arp_eth_hdr*)buf; 
  arp1 = (struct arp_hdr*)(buf+ ETH_HDR_LEN); 
  ethip = (struct arp_ethip*)(buf + ARP_HDR_LEN + ETH_HDR_LEN); 
  if(ethhdr1->type[0]==0x08 && ethhdr1->type[1]==0x06) { 
   UART_PRINT("\n\rGot ARP response!\n\r"); 
   UART_PRINT("\n\rIP addr %i.%i.%i.%i ",ethip->ar_spa[0],ethip->ar_spa[1],ethip->ar_spa[2],ethip->ar_spa[3]); 
   UART_PRINT("maps to MAC addr %x:%x:%x:%x:%x:%x!\n\r",ethip->ar_sha[0],ethip->ar_sha[1],ethip->ar_sha[2],ethip->ar_sha[3],ethip->ar_sha[4],ethip->ar_sha[5]); 
  } 
}

Also, in Wireless_Arp_Test(), you need to declare at least 42 bytes for your buffer length in sl_Recv(). 40 bytes is too short. I would suggest setting the actual buffer length of 100 bytes here:
ret = sl_Recv(fd, buf, 100,0).

You can run your example code to see the issue - no ARP messages are being received.

Thanks,
Olek

Hi Olek,

Thank you for your suggestions on refining the ARP test code. The test code provided is a very simple example meant to be a quick way to observe a layer 2 ARP exchange. As such there are many areas that can use some polish, including the eth type checking to only attempt to decode ARP packets.

That being said, my provided code does work, at least on my CC3135 setup. Did you make any modifications to my code other than adding the type check and the sl_Recv() buffer change? I suggest you try running that Wireless_Arp_Test() function in a barebones demo such as the network_terminal demo if you haven't done so yet in order to verify the behavior of the provided sample code.

Regards,

Michael

Hi Michael,

You have missed my point. In order to detect the ARP messages you need to have a conditional statement filtering out these messages, otherwise your Wireless_Arp_Test() function will report all messages received by the unit, not only ARP messages. I reported a bug, not the code refining.

This post is about CC3135 NWP, not CC3235. There might be small differences between the internal code in both units. I would suggest that you try your test on CC3135 or CC3135MOD before telling me that it works unless you are absolutely certain that the relevant pieces of firmware in CC3135 and CC3235 are exactly the same.

Yes, I tried my code on a barebones demo. Please check your part.

Thanks,

Olek

Hi Olek,

I made a typo in my previous post. Prior to providing my suggestions to you in my previous post I had of course tested the code on a CC3135 device to ensure that it works as expected. I have edited my previous post to reflect that. I have also tested the same code on another device and the ARP functionality works correctly, so I'm pretty sure that the issue is on your end and not in my code.

As a sanity check, did you remember to modify the mac[] and src_ip[] arrays in Wireless_Build_Arp_Packet() so that they have your CC3135 device parameters? If the ARP packet has the wrong src MAC and IP, then you will never get any responses back to your CC3135.

Regards,
Michael

Hi Michael,

I have checked my setup with two other out-of-the-box CC3135 BoosterPacks. They work slightly differently; I am receiving ARP messages but only for a short while. While receiving ARP messages, I am getting two NetApp Events: first #9 (SL_NETAPP_EVENT_DHCP_IPV4_ACQUIRE_TIMEOUT) and then, after a while, #1 (SL_NETAPP_EVENT_IPV4_ACQUIRED). After that, no ARP messages are being received.

At the same time, my network applications are all disabled. I am checking their status using command:

sl_NetAppGet (SL_NETAPP_STATUS, SL_NETAPP_STATUS_ACTIVE_APP, &u8AppBitMapLength, (_u8 *)&u32AppBitMap);

and it returns all zeros in u32AppBitMap with return code zero. If I issue:

sl_NetAppStop(SL_NETAPP_HTTP_SERVER_ID | SL_NETAPP_DHCP_SERVER_ID | SL_NETAPP_MDNS_ID);

the return code is 0x183B. It is positive, meaning it is not an error, but also not zero for ok. What does it mean?

My first booster pack had all network applications disabled in configuration using UniFlash. It did not receive any ARP messages and did not get any NetApp Events.

I hope you can give me a workaround or ask TI to fix the issue.

Thanks,

Olek

Hi Olek,

I have my CC3135 programmed with the default settings, with only the latest servicepack programmed and no other settings changed.

Could please replicate the steps I have done and see if you still don't receive ARP packets?

1. Import the network_terminal example from the SDK
2. Ensure you have done the proper porting steps in order to get the network_terminal example working on your plaform
3. Test the network_terminal example by running the wlanconnect command, the ping command, etc.
4. Replace the existing wlan_cmd.c with the following attached wlan_cmd.c file:/cfs-file/__key/communityserver-discussions-components-files/968/0246.wlan_5F00_cmd.c
5. Modify Wireless_Build_Arp_Packet() with your device's IP and MAC address, and provide the IP address of a device on the LAN (such as the AP). you will need to modify mac[], src_ip[], and dest_ip[].
6. Rebuild and run the network_terminal example
7. Once the example is running, use wlanconnect to connect to Wi-Fi, and then use the 'p2pstart' command to perform the ARP request

Do you see the ARP request get performed successfully? Have you used a Wi-Fi air sniffer or a packet capture on the AP WLAN interface to ensure that the ARP traffic is received correctly by the AP? I suggest you use an air sniffer to check and ensure that the ARP is ack'ed by the AP and then re-broadcast to your LAN.

If you still are facing issues with getting ARP requests working, then please go and collect the NWP logs from the deivce. The instructions to do so can be found here:https://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

The steps for capturing the logs are the same between the CC3120+CC3220 and the CC3135.

Having the logs will allow me to see the running state of your device, and I would appreciate it if you could provide those.

Regards,
Michael

Hi Michael,

Our conversation is going in a wrong direction. Please forward my e-mails to TI firmware team if you have not done this already.

Thanks,

Olek

Hi Olek,

As part of the debug process for this issue, I need to either be able to reproduce the issue you are seeing or otherwise collect the information needed to dig through the firmware on my end to figure out the root cause. So far, we have been working towards getting a successful reproduction of your issue, and have also been working towards collecting the information needed by me and the rest of my team in order to figure out why we aren't able to replicate you use case.

As such, I would appreciate it if you could provide the NWP logs, perform the debugging tasks, and provide the information requested. Please rest assured that your thread has the relevant teams involved.

Regards,

Michael