Client hostname in DHCP and mDNS ?

Hi Chris,

The CC3100/CC3200 has mDNS implemented for discovery. So not sure you will need the send a host name with the DHCP request...I also think this is a better solution, not sure how many routers will actually use this information to add to its DNS.

You use the following API to register the service, including its name.

You register the name with the pServiceName parameter. The way that it works, is that you add the name of the device at the front, the service type in the middle and the root domain (.local) at the end.

So for example, if you want to add a web server which can be accessed at http://myCC3100device.local, then you register myCC3100device._http._tcp.local

By the way, this is all handled internally if you utilise SmartConfig, so you will not need to register manually, as it will be done for you by just adding the name of the device in the space provided. I have an iPhone app developed and have this integrated within it, as a simple step to add one or more of my devices.

Additionally, you can also change the name via the web configuration pages that are provided with the CC3100/CC3200. 

Glenn.

Hi Glen,

Thank you for the information and clarification. For my intended application I wouldn't be able to use SmartConfig (or an app based on it) because there's no way to guarantee the client would be IOS etc. (most likely usage is via someone with a Windows7/8 or laptop, but again that can't be guaranteed and they could be using anything with a browser).

I'm hoping I can make the CC3100 device run web server in AP mode, which would give the user a way to access the device directly (and give them a way to enter the credentials to switch from AP to WiFi client, if available).

I have just run a test with an Android tablet and Wireshark and when I try to open http://randomdevice.local in Chrome I don't see any packets requesting randomdevice._http._tcp.local etc. so I'm not sure registering a service will work; I'm hoping to be able to directly define the host name.

Hi Chris,

I've been researching this further and have also been having difficulties.

First of all, my Macintosh and Windows machines provide different results. When using SmartConfig to join a Wifi Router, I am able to easily name my device and hence give it a DNS name, for example I name it kitchen, which then gives me the DNS name kitchen.local. On my Macintosh machine I can then ping this name and also use this name to access the devices web server, however on my Windows machine I cannot do this.

As you have determined the sl_NetAppMDNSRegisterService just registers the service name and not the DNS name (though it does provide the DNS name, when you look at the records for this service). I cannot see any APIs that will help with setting the mDNS DNS name. Perhaps we can register using this API, but need to use a specific service name...reading the RFCs for more information.

The CC3100 has a web server built in, that provides access to the setup, and it also has a Device Configuration section, where you can set Domain Name, however my tests so far indicate changing this text field makes no difference.

In my iOS app, I am able to easily list and resolve the devices (that have been added by SmartConfig). But i am doing this using an API that looks for a specific service (http in my case) to resolve the address. I am not sure how you can set this up for a browser via the SimpleLink APIs. Will need to research this further.

Glenn.

Some more information.

For testing and analysis I am using mDNS apps on an iOS device, they are mDNS Watch or Discovery. Android should have a similar app, or you should be able to find one for Windows.

To change the actual DNS name of the CC3100 Device, you change the name of the device. You can do this via the setup page of the devices configuration, by changing Device Name in the Device Configuration section. Alternatively you can change the name programatically, with the below code:-

    unsigned char device_urn[29] = "LivingRoom";
    sl_NetAppSet (SL_NET_APP_DEVICE_CONFIG_ID,
    NETAPP_SET_GET_DEV_CONF_OPT_DEVICE_URN,
    strlen((const char *)device_urn),
    (unsigned char *) device_urn);

Even though I now can see via mDNS Watch that my DNS name for my web service is LivingRoom.local, I still cannot access it via a web browser. So more investigation is required.

EDIT: I can access via any of my Apple device, Macintosh, iPhone and iPad. No luck with an Android device or Windows when connected to a router.

I can however use the http://simplelink.net or what ever I have set up for my Domain Name on the web config page, when I am connected directly to the device (i.e. when it is in AP mode). So looks like mDNS will need an extra service to be running on a Windows Machine, which is not really an option when you are trying to make it simple to work with any computer out there.

My analysis may not be completely accurate, so I'd be interested in hearing others people results.

One other thing, I could not find any API which enabled me to change the Domain Name of the device, even though this is an option available on the Web Config page of the device, so I assume there must be an API somewhere to allow this?

Glenn.

Hi Glenn,

Thank you very much for your work on this.

I think Windows doesn't use mDNS unless you install Apple's Bonjour for Windows. Windows (7 and up) has its own version of name resolution (LLMNR?) that uses UDP port 5355; mDNS runs on 5353. It looks like it's a pretty simple protocol so I will look into writing my own CC3100 code to support it.

I don't see much in the way of Android supporting local name resolution. I will keep looking.

I am looking at the same thing right now.  You are correct about mDNS and LLMNR.  If you implement both of those, you should have Windows, Mac, and iOS covered.  But Android is another story.  I have never gotten my Android tablet to resolve correctly with mDNS although I think its supposed to.  I get the impression that Google is not supportive of IoT that doesn't communicate through the cloud.  They want to promote cloud based everything so that they use the data for their purposes. 

However, I REALLY think the CC3100/3200 should report the hostname in the DHCP negotiation.  It's a trivial change, but it allows the router to sometimes resolve a local name, but more importantly, most routers will also show the device with the hostname when doing configuration.  This is a big deal.  If I create a wireless Dishwasher and a wireless SprinklerController, a user seeing "192.168.1.34, 192.168.1.35" versus "Dishwasher, SprinklerController" makes a HUGE difference.  IP addresses are very intimidating to users and should (IMHO) never be shown in a consumer product.  If I can make my device easily identifiable for port forwarding in the router, that is important.  

Having said all that... I have no clue if cc3100/cc3200 does it or not... :)  But, for any Internet of Things devices, local name resolution is critical to a user-friendly approach (aka. don't show any IP addresses).  So at the very least, LLMNR will be getting implemented on my design.  Fortunately, we have enough sockets on this device to do it. 

Hi Valkyrie-MT,

Thanks for your input. I'm hoping to be able to use the CC3100's built-in mDNS but realize I will have to write my own LLMNR code. Thankfully the CC3100's 8 sockets will give me a little more breathing room to do this compared to the 4 of the CC3000.

I completely agree the CC3100/3200 should send the client hostname during DHCP negotiation, I understand the code space limitation on the CC3000 prevented this but hopefully that will not be an issue with the new modules. Hopefully TI will make this small change; in my opinion they should do every single little thing they can do to make their IoT modules as accessible as possible.

Can anyone from TI comment on the DHCP client hostname status?

Ok, so I went into Wireshark to check things out.  First, I can confirm that the cc3100 does not send the hostname in the DHCP negotiation.  It should be Option 12 like this from another device:

Here is the option list from the cc3100:

Also, with respect to the local name resolution, notice the second red line there?  That is the mDNS A record broadcast and sure enough it shows the local name to be <MAC address in hex>-mysimplelink.local.  So for me, entering http://060008002822-mysimplelink.local into my iPad worked perfectly!  The mDNS service actually responded to the iPad's name request perfectly.  Now the only detail is figuring out how to change it from this name to something relevant to my device.  Here is what the response looks like from the cc3100:

Valkyrie-MT, have you tried sl_NetAppSet() per Glenn Vassallo's suggestion?

All,

I would like to confirm that we are not publishing the host name URL the during the DHCP process.

We are supporting mDNS (Bonjour protocol) to advertise the Host name and HTTP URL and it can be modified by an API for more services.

Below is an example for Android device using TI SmartConfig application in which we have the mDNS embedded and it can direct you (by a click) to the Web Server.

Similar Bonjour browser for windows are also exists.

I hope this is answering the query.

------------------------------------------------------------------

1. Connect with your android device
2. run the WiFi Starter application from Texas Instruments - https://play.google.com/store/apps/details?id=com.pandaos.smartconfig
3. Use the application to check which devices are connected (probably only you)
4. click on the device - it will take you to the device WebPage - there please confirm the domain Name

Best Regards,

Nir Nitzani

Hi Nir,

Thanks for responding and clarifying the current state of play.

For devices that are App based like mine, things work fine, as you can use an API to access the registered mDNS services. This is pretty seamless when you use SmartConfig from within an iOS or Android App (just as you have shown above).

However, for devices that use a web browser to configure and use, mDNS will only work on Apple devices (iOS and Macintosh). If you want to also enable local name resolution on Windows machines, you will need to use other mechanisms, the one suggested by Valkyrie is LLMNR.

Requesting a user installs an mDNS browser to find the device, reduces the breadth of devices that can be developed for the CC3100/CC3200. As this begins to make things too complicated, especially for consumer products.

Hence, people are requesting that as much as possible should be done within the firmware to support local name resolution, as this then enables much larger user scenarios, and hence more devices based on CC3100/CC3200 technology.

Glenn.

Hi Glen,

On Windows PC there number of methods

• Safari uses Bonjour to find devices advertising web pages on your network. 
• Internet Explorer, via the Bonjour toolbar plugin, also provides easy discovery of Bonjour-advertised web pages

I understand the request for Host name in the DHCP and also appreciate the feedback, but currently it's not supported and we will look into it for next generations.

Best Regards,

Nir Nitzani

Nir - Thanks for the clarification

Chris - If you do write a LLMNR implementation, feel free to share it :-)

Glenn.

Can you please give us a clarification on "we will look into it for next generations" means?

Do you mean next-generation hardware (e.g. this will never be supported in the CC3100/3200 hardware), or do you mean a future service pack?

"we will look into it for next generations" that is a very disappointing statement considering I pointed this out on the cc3000 in October 2013 - http://e2e.ti.com/support/wireless_connectivity/f/851/t/296516.aspx

Adding hostname to DHCP is a simple change and is a non-breaking change to the API.  Also, no matter what happens, I can (and will) write my own mDNS and LLMNR implementations.  However, the one thing I have no ability to work around is the missing DHCP Hostname.  I cannot fix that.  Only TI can. 

Please consider making this change, particularly because there is no way for us as developers to do it. 

Thanks,

-Valkyrie-MT

P.S. I notice that in the Nir's second Android screenshot, 192.168.1.1 was used instead of the local name.  So, I assume that means TI also does not have local name resolution working for Android.  That is consistent with my understanding that the Android platform doesn't do local name resolution, although, it's been a year since I tried last. 

Hi Chris,

Yes, Glenn is correct.  I have confirmed it with Wireshark.  Setting the Device URN with the NetAppSet command does set the mDNS A Record for local name resolution of the web browser. 

Hi Valkyrie-MT,

Thanks, that's good news. It sounds like we'll be able to use the mDNS built in to the CC3100 without having to write our own.

I do understand TI's stand on LLMNR and, while it's not ideal, I am OK with having to write my own.

I do not, however, understand TI's stand on sending the client name in the DHCP negotiation. We are literally talking about changing a few bytes in a packet that you're already sending (DHCPREQUEST) to support option 12. I have a very hard time believing this is undoable.

On the hostname in DHCP, I am going to assume that when Nir said future generation, he meant software, not hardware... right? 

Hi All,

We have been focusing on a standard way for service discovery and hence used the mDNS in our Revision-1.

 What looks like a simple add-on or fix is not the always the case and we are committed to provide a full system solution, for example in this case:

• Which API will be used to set the Host name – there are differences between mDNS URL and the Host name

i.e – this requirement below won’t work with our default mDNS naming 060008002822-mysimplelink.local

The labels must follow the rules for ARPANET host names.  They must

start with a letter, end with a letter or digit, and have as interior

characters only letters, digits, and hyphen.  There are also some

restrictions on the length.  Labels must be 63 characters or less

• Host name option wasn't originally defined for the purpose of service discovery (although in fact it is being used that way by some systems (mainly Microsoft systems)
• In order to avoid interoperability with different DHCP server one must follow the  full RFC – here is the link: http://tools.ietf.org/html/draft-ietf-dhc-host-option-considerations-02

i.e:

      if a DHCP server supplies both Host Name and Domain Name options

      to a client, the host name SHOULD NOT be fully-qualified

      if a DHCP server supplies only a Host Name option, the host name

      SHOULD be fully qualified; the server MUST append only DNS domain

      names in forming a fully-qualified name

      a client MUST check to see whether a Host Name option contains a

      fully-qualified name and if so, MUST NOT append the value of the

You are highlighting very good features and suggestions over the forum and this is highly appreciated. You should also need to understand that I'm not able to commit on our plans for the next device content over the forum.

Best Regards,

Nir Nitzani

Nir,

• With respect to the API, the current opcode "NETAPP_SET_GET_DEV_CONF_OPT_DEVICE_URN" name does not suggest anything specific to mdns.  I set the device urn to "cc3100" and it resolves perfectly to cc3100.local using mDNS right now.  The cc3100 is apparently adding the ".local" suffix.  So, that exact same value can be used for the DNS hostname option.  So the API does not need to change.  If the urn includes a ".", just exclude the hostname option. 
• Nir said that "Host name option wasn't originally defined for the purpose of service discovery (although in fact it is being used that way by some systems (mainly Microsoft systems)"
  
  • I'm not sure what that statement is referring to.  Microsoft systems have nothing to do with the DHCP hostname option.  Let me summarize the local Name resolution landscape:
    
    • Microsoft Windows Desktops use NetBIOS over TCP, LLMNR, DNS, and mDNS (when bonjour is installed)
    • Microsoft Windows Phones used LLMNR (and possibly router DNS)
    • Apple iOS and MacOS devices use mDNS (and possibly router DNS)
    • Android devices use only router DNS to resolve names.  If the DNS server supplied by the router does not resolve the name, it will not resolve. 
    • Additionally, the router itself uses the name provided during DHCP to assign names for end-user configuration of services on the home router. 
  • So, the purpose for adding the hostname option to DHCP is to identify the device to the router and Android devices. 
• Resolving hostname conflicts is a concern, but the router will do that for you.  When you request a hostname, the router should ping for the name to verify that it is not in use.  If so, DHCP will fail.  DHCP failure is already something that the cc3100 handles, so this would be a DHCP failure.  Since the hostname is specified by the cc3100 host processor, the cc3100 is only obligated to return the failure state.  There is nothing for the cc3100 to do to try to resolve a conflict, just report the DHCP failure. 

I don't expect to get device feature commitments over a forum.  The cc3100 is a fantastic leap over the cc3000.  Given the huge improvement over the cc3000, a change like this is tiny. 

P.S. here is a video that shows the problem.  https://www.youtube.com/watch?v=O3CgOcYmspU

Is there any updates on this in new service pack??

Glenn Vassallo said:

My analysis may not be completely accurate, so I'd be interested in hearing others people results.

Yesterday I managed to change default URL used by SimpleLink http server by slightly different API call:

unsigned char domain_name[29] = "LivingRoom";
    sl_NetAppSet (SL_NET_APP_DEVICE_CONFIG_ID,
    NETAPP_SET_GET_DEV_CONF_OPT_DOMAIN_NAME,
    strlen((const char *)domain_name),
    (unsigned char *) domain_name);

It has been took from CC3100\CC3200 SimpleLink™ Wi-Fi® Network Processor Subsystem article 12.9.5 Set or Get Domain Name.

Hello,

I'm heavily interested on that topic. Our product will be most of the time in station mode and serves as http client. The device should be recognizable in the router device list. Without that feature, if the hostname option is missing in DHCP request, I found that some routers show something like "Unknown device", others "reuse" a name they already know of a completely different device that was maybe once connected with the same IP address.

So is there any plan to add the hostname for CC3200?

Partially this issue it can be solved by mDNS and LLMNR. Offcourse support for hostname will be better...

Although from a slightly different angle, the solution to the host and domain name problem, is possibly better solved by using the host and/or domain name as supplied by the DHCP server.

I raised the question some months ago in a different thread (post linked below) but received no response. Having had a look at the earlier post from Nir Nitzani regarding the DNS RFC I fail to see the issue. The current DNS/DHCP implementation does not seem to follow the RFC, and the features being requested does not take it away from the RFC, I believe it brings the CC3x00 implementation closer.

e2e.ti.com/.../478001

Andre