This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

mDNS advertiser does not start - returns code dependent on device name

I am trying to use mDNS with CC3000 on a WiFi network. I am using mbed devlopment environment. After CC3000 has connected to the WiFi and then used DHCP to get basic LAN set-up,  I use mdns_advertiser to start mDNS advertising. However, this fails and returns a code which depends upon the device name that I am trying to set. If I use CC3000, the return code is 189. If I use A_CC3000, the return code is 191. I am using CC3000 firmware version 1.24

My code is:

int32_t startmDNSRetCode = 0;
char _deviceName[] = "A_CC3000";

// Start the mdns service
startmDNSRetCode = wifi._socket.mdns_advertiser(1, (uint8_t *)_deviceName, strlen(_deviceName));

I have two questions:

- What does this return code mean ie what is the error?

- Is there a list of possible return codes and their meaning anywhere?

Thanks

John

  • Hi John,

    How are you testing the advertising? What are you using on the remote device to check for the advertised packets? Make sure you are on the same network and are listening to the packets before you make a single advertising call.

    Regarding the error codes, are the return values positive or values?

    Thanks & Regards,
    Raghavendra

  • Hi Raghavendra

    I am using 'mDNS Watch' from FEASS and I am not using a remote device at this time.

    All are on the same network and running before I make the advertising call. Return values are positive.

    Regards

    John

  • Is the version of the host driver correct for the firmware? (in case TI made any changes to the SPI data)

    Providing the SPI data transmitted by the CC3000 might be useful, either by a logic analyser or if you can get it from your MCU's memory at an appropriate time (output over UART or GDB etc), since the return value is pulled from the data transmitted.

    This sounds like a potential bug either in the documentation or the implementation for this function.

    Edit:

    Actually, looking at 1.11.1 I think there was an issue with the return value which looks rectified in 1.12. in mdnsAdvertiser the return variable was:

    int ret;

    which was being passed into:

    SimpleLinkWaitEvent() as a void *.

    It was being typecast to a uint8 in hci_event_handler().

    So there are a few issues with this. ret was not set to 0 so it will be garbage data. Only half of it is being assigned data later on, so it will vary.

    In 1.12 it is now defined as:

    INT8 ret;
     
    However I still don't see how this can give: 
     
    John Halfpenny said:
    If I use CC3000, the return code is 189. If I use A_CC3000, the return code is 191.
  • Hi John,

    Will you be able to confirm if you can observe the mDNS packets in the air (by capturing air traces)? We are not mDNS Bonjour compliant. I am not sure if there is something that the watch is expecting, which it is not receiving.

    Can you please try using our latest host driver 1.12 with the latest SP 1.26?

    Thanks & Regards,
    Raghavendra