Bugreport CC3000HostDriver v10: netapp_ipconfig() reports incorrect SSID and MAC

Hi Johannes,

That is correct, we will fix it.

Thanks,
Alon.S

FWIW, while memcpy fixes the corruption issue it appears the incoming MAC address has been byte-reversed as though it were a network address that needed to be converted from network byte order to little-endian.  Never seen that done before.  Would be nice if the correct byte order would be used by the value returned through this function.

Hi Peter, 

Another option to memcpy is to add STREAM_TO_UINT32 and increase the offset, that will keep the little endianness. Below code is from the case HCI_NETAPP_IPCONFIG in the hci_event_handler( ) function (evnt_handler.c):

STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_MAC_OFFSET,*(unsigned long *)pRetParams);

pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT8((char *)pucReceivedParams,NETAPP_IPCONFIG_MAC_OFFSET+4,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 2;

STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+4,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+8,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+12,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+16,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+20,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+24,*(unsigned long *)pRetParams);
pRetParams = ((char *)pRetParams) + 4;
STREAM_TO_UINT32((char *)pucReceivedParams,NETAPP_IPCONFIG_SSID_OFFSET+28,*(unsigned long *)pRetParams);

Pedro

Pedro5084

Hi Peter, 

Another option to memcpy is to add STREAM_TO_UINT32 and increase the offset, that will keep the little endianness.

Why would we want to do that?  Neither the MAC address nor the SSID should ever have their byte order changed.

Pedro5084

Below code is from the case HCI_NETAPP_IPCONFIG in the hci_event_handler( ) function (evnt_handler.c):

Is that the change you've made to the driver source?  I suggest looking at the call at NETAPP_IPCONFIG_MAC_OFFSET+4, which is wrong in at least two, arguably three, ways.

Hi Peter, 

I think I misunderstood your comment: 

Peter Bigot

 while memcpy fixes the corruption issue it appears the incoming MAC address has been byte-reversed as though it were a network address that needed to be converted from network byte order to little-endian. :

From a MAC address of 00:37:6D:74:FB:5B the SPI buffer shows the MAC as 0x5B 0xFB 0x74 0x6D 0x37 0x00, where 0x00 is my most significant byte, so this will be little endianness, right? Do you see a different byte order? Is it at the spi buffer level or the returned MAC array? 

Pedro

What you describe is the behavior I see.  An argument can be made (though not, IMO, for a network API; see below) that there is value in converting 32-bit IPv4 addresses and 16-bit IP ports from network byte order to host byte order to simplify certain masking operations and value comparisons.  This does not apply to MAC addresses, since 48-bit integer types are not common and network programmers are used to extracting OUIs and other data from MAC addresses in their transmission order representation.  It is similarly a mistake to re-order the bytes within IPv6 addresses.

The SPI order had already been reversed from transmission order, and the sentence you quoted was meant to say this should not have been done.  The 6-byte MAC address should be kept in transmission order at all times.  If you can't fix whatever's reversing it then the order should be corrected before the value is returned to the user, which means you can't use memcpy.

The SSID in turn is in most cases an ASCII string like "linksys"; surely there's no argument that big-endian/little-endian has any significance here?  No bytes should be re-ordered, so memcpy is the correct approach.

Personally I would prefer to see ALL multi-byte integers used in network addresses (IPv4, IPv6, ports) kept in network byte order (big-endian), especially when stored in byte arrays as they are in SimpleLink data structures.  The only time it could be worth converting them to host byte order is when they're manipulated as integer values of type uint32_t (for IPv4 addresses) or uint16_t (for INET domain ports).  Even there I think the confusion that results from having to guess which order is being used warrants making any conversion to and from host byte order the responsibility of the user code.  This is what ntohs/htons and ntohl/htonl are for.

Hi Peter,

Thanks for your comments, it looks reasonable to me, will pass them to our team. 

Pedro