0

Feeling a bit lost after many days of relentless digging and looking for inspiration...

The story so far:-

  1. I have a Microchip PIC32-based wifi-dev board running TCP/IP stack v5.36.
  2. After boot-up, the app works fine when requesting the default 'mchp.local' domain name in the browser. The web browser receives updates correctly every second from the embedded web server on the PIC.
  3. After an indeterminate time however (usually about 1 hour or so), the 'mchp.local' page times out and the browser reports

'ERR_NAME_NOT_RESOLVED: The server at mchp.local cannot be found. because the DNS lookup failed.'

  1. And yet, I can access the app on its corresponding IP address (in this case 172.16.15.103) and I see the app is running fine.
  2. I also see infinite loop in the the main() routine is running as expected and the web server is responding to changes when I request pages using just the IP address.
  3. I have tested using Chrome on Windows and Mac machines - same issue.
  4. I have tried using Packet Peeper (a free network packet analyser for Mac OS X) to filter out all messages NOT on UDP port 5353 (as per RFC 6762) and I see nothing useful.
  5. I have trace-debugged the code and found that the mDNS state machine is in DEFEND mode, both before and after the moment when the app stops responding with DNS "ERR_NAME_NOT_RESOLVED".
  6. I suspect the problem lies in the multicast DNS module but my findings so far do not help me to piin point the root cause.

Any clues? Where should I look next?

My environment: Mac OS X 10.9.5 (Mavericks) Browser: Chrome v.44 Embedded Kit uC: Microchip PIC32MX695F512H Embedded Kit WiFi interface: Microchip MRF24WB0MA Dev Tools: PICKit3, MPLAB X IDE v2.25, Packet Peeper 2014-06-15

quixote
  • 23
  • 6
  • If the browser is running on the remote Mac OS client, and the app is running on the embedded kit, then `mchp.local` is resolving on the Mac OS client, or the embedded kit? What is doing the resolution? – Rick Buford Aug 15 '15 at 06:07
  • Running "nslookup mchp.local" shows the DNS is being resolved globally (via 8.8.8.8) but this seems to contradict RFC 6762 (s22.1) which states that all .local addresses must be resolved locally. Having said that, I am not sure if nslookup always resolves locally or globally.. – quixote Aug 16 '15 at 08:19
  • 8.8.8.8 is Google's public DNS and is not resolving your "mchp.local" request. `nslookup` should be using the first nameserver listed in your resolv.conf for it's lookup. Perhaps add the output of `cat resolv.conf`? – Rick Buford Aug 16 '15 at 19:15
  • more resolv.conf gives this: # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # nameserver 8.8.8.8 nameserver 208.67.222.222 – quixote Oct 08 '15 at 14:41
  • Sorry, I'm less familiar with Mac OS X, so had to look: http://serverfault.com/questions/478534/how-is-dns-lookup-configured-for-osx-mountain-lion says to use the `networksetup` command to configure your client to use a local DNS server. – Rick Buford Oct 09 '15 at 12:36

0 Answers0