[ronjohntaylor]

OK Back from Osteopath.

On 07-11-2018 in this forum, I tried different methods of accessing the NEMS RPi and detailed what happened there but to reiterate even when I use the IP address and port it gives the same symptoms.

I have a SMART Ether Switch and have attached the Stats from it.  Port 14 is the NEMS port and as you can see there are no bad packets on this port.

I ran a ping and found some interesting results. See Attachment.

Check out what happens when I run Ping nems.local....

nems.local       uses IP6 not IP4

Hmmmm...

[Robbie Ferguson]

Oh interesting... I wonder if/how that affects things. I mean, it should technically work... but if there's any DNS issue it's possible nems.local would resolve incorrectly. Especially after a few builds, it's always possible you could have some kind of DNS caching happening.

Would it be possible to add the ipv6 address to your hosts file for nems.local just to be sure?

Let me know if you need help, or if that "fixes" it - it'll at least be a neat thing to try to rule it out.

It's been an intense day... gonna take a break. But I'll get your replies tomorrow (or tonight if I happen to be watching my laptop).

Thanks!

[ronjohntaylor]

Hi Robbie,

You asked...
Would it be possible to add the ipv6 address to your hosts file for nems.local just to be sure?

Not sure which host file on which device you are referring to?  My Laptop? Nems?

Also my router does not support static leases for IP6 (only IP4) so the IP6 allocations are going to be dynamic and therefore allocating to host file might be futile?

As I have said previously I have allocated a static lease (IP4) to the host nems  and when I use that host name it should resolve to the IP4.
I checked my host file on my windows 10 laptop and it did not contain an IP4 entry for the host nems so I have added an IP4 entry to see if it makes any difference.

I have had issues with DNS's in the past and had to use googles DNS's to get around the problem.  This was with a web server https://app.airdata.com/main?flight=last.  They did a change of host and I could not get it unless I manually configure the Primary and secondary DNS's to Googles 8.8.8.8 & 8.8.4.4
However after about a week my RSP's DNS's seemed to pick it up and I could go back to auto DHCP allocation.

I also tried this on my laptop.  I manually assigned Googles DNS servers for IP4 & IP6

IPv6 address: 2001:8003:f1cd:a600:f819:7e65:1682:60a

fdaa:8e94:5373:0:f819:7e65:1682:60a

IPv6 DNS servers: 2001:4860:4860::8888

2001:4860:4860::8844

IPv4 address: 10.0.0.102

IPv4 DNS servers: 8.8.8.8

8.8.4.4

Primary DNS suffix: gateway

DNS suffix search list: gateway

Manufacturer: Realtek

Description: Realtek USB GbE Family Controller #2

Driver version: 10.12.1007.2016
Physical address (MAC): 20-47-47-F9-2A-F2

However it did not seem to make any difference. :-( so I have reverted back to automatic DNS.

I will now try something else But will need to reboot so see next post

[Robbie Ferguson]

Hmm, yeah it just more and more sounds like an internal DNS configuration issue (eg., with your router, not NEMS).

Is there any way you can just disable IPv6 for your NEMS MAC address on your DHCP server and let it serve up the IPv4 only?

Cheers,
Robbie

[ronjohntaylor]

In the attachment I found a button that is supposed to disable IPv6 on the local network. This is supposed to turn of IPv6 for the whole subnet listed in the DHCP from what I read in help file.
However If I look at my ethernet adaptor it still shows it with an IPv6 address so I am at a loss as to where to go.

I did some reading and could only find posts a few years back that say they don't support IPv6 at this stage.
My router is at least a few 4 years old so I think it might be relevant.

I also tried changing to WiFi rather than wired and it seemed better but still failed with similar symptoms. It was that trickster MURPHY trying to fool me I think!

I really did not think it would fix it as the WiFi is part of the same router.
I was clutching at straws.

I rebooted NEMS and ran the ifconfig command on NEMS

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 10.0.0.32  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::8d49:441a:3784:c570  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:18:69:5a  txqueuelen 1000  (Ethernet)
        RX packets 180  bytes 42514 (41.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 234  bytes 29969 (29.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

As you can see it still has an IPv6 address

I will leave the IPv6 local off and see what happens.

Getting splinters scratchin the old noggin!!



Some hours later:......
I looked at the URL addresses see attachments RPI1-3

In RPI1 I noted that the URL was http://nems:8888

If I hovered over the links in RPI3 I noted that they had actual files to link to like status.html & Index.html etc
So why does not the original link from RP--Monitor not read http://nems:8888/index.html   ?????

[Robbie Ferguson]

As I said, IPv6 itself shouldn't be a problem - but it seems there is a DNS issue internally at your place (just a guess) - so like you, drawing at straws.

Can you please try https://nems.local (not https://nems)? https://nems.local is the correct address - so just want to rule out the fact that you've omitted the .local from the URL (which certainly could cause issues with resolution).

Keep me posted.

Robbie

[ronjohntaylor]

OK I just read your last post.

I tried changing the nems to nems.local in my reserved hosts on my router but it would not allow the "."
It allows dashes and underscores but not dots.

Murphy strikes again.

I then decided to change the host file on my laptop to include nems.local and it accepted (it being a simple text file).

I then changed my desktop shortcut to nems.local.

However then I lost WAN access on my network and I had to reboot my router/modem to get the WAN back again.  This took some 15 Minutes
Murphy strikes again.

I don't know if my fiddling cause some corruption of the router tables in the router but now it has been flushed and should have got rid of any old stuff.

I did some testing and NEMS seems happier.

It is disappointing that I can't allocate the hostname in the router as now I will have to update the hosts file in my desktop.  
This is the whole point of DHCP.
I remember the bad old days before bootp and dhcp when we had to run networks on static IP's and keep host files up to date.
Sends shivers down my spine even now.

I can also understand why they disallow dots as a dot has special meaning in file naming.

Anyway back to the land of nod....

Cheers

[Robbie Ferguson]

Well, here's hoping at least this means things work better for you.

DHCP should be using just the device hostname (nems). The reservation should be assigned via the MAC address, and "nems.local" means nothing to your DHCP server.

I think you may be getting mixed up between the two .. and rightly so.

The hostname according to DHCP (nems) is not the same thing as the domain name according to your browser (https://nems.local). One is a Linux hostname (nems), the other is a AVAHI schema (nems.local) for name resolution on the local network. Ie., your browser.

Your DHCP server should be using the Linux hostname "nems" whereas your browser would be using the AVAHI name "nems.local" (and always precede it with https:// to avoid having your browser try to search Google for it).

Hope that helps :)

[ronjohntaylor]

Good Morning Robbie,

Interesting. Never had that explained to me like that before so thank you for doing so.
Just had a bit of a look on Wiki and it's similar to Apple's Bonjour which I have avoided on Windows PC's in the past as it usually caused me grief with Apple getting it's hooks into the PC.

Soooo..... the naming of the host nems in my DHCP static leases is correct as far as a host name is concerned but AVAHI uses SDP to set up a service directory for the browser.
In my reading I read that the mDNS protocol sets up a resolution of host names to IP addresses for small networks that do not include a name server or in other words a mini DNS.

The interesting things as it left out the words "MAC address".

Sooo .... Am I correct to assume ..... 

DHCP Host name tries a MAC address to an IP address and the mDNS ties a host name to the IP address but can use different names?

Smoke and mirrors Ha ha.

Having said all the I just did a RPi Monitor and it did the same time out trick.

Like I said earlier when I hover over the link RPi Monitor and look at the link shown at the bottom of my browser it shows "nems.local:8888"
I am assuming that Apachi will assume that on port 8888 it will use a default of index.html.

I can make it fail by

1. loading RPi-Monitor
   
2. assuming it works, I then click on reload icon in the browser a number of times.  However a <ctrl><F5> seems to work no problems.
   
   
   

Blowed if I know ....
It's not something that I use a lot so it only seems to be me so might be something for the long game...

I would much rather be able to set down time and acknowledge problems than worry about this if I have a choice.

Frustrated...

[ronjohntaylor]

In relation to RPi-Monitor:

I did more reading today & looked at routing tables (using Route Print and ipconfig /all) and so forth but did not glean much from that.
Pasted below for completeness
===========================================================================
Interface List
 16...20 47 47 f9 2a f2 ......Realtek USB GbE Family Controller #2
 17...48 e2 44 f5 67 d9 ......Dell Wireless 1830 802.11ac
 23...4a e2 44 f5 67 d9 ......Microsoft Wi-Fi Direct Virtual Adapter #3
 12...4a e2 44 f5 6f d9 ......Microsoft Wi-Fi Direct Virtual Adapter #4
  5...48 e2 44 f5 67 da ......Bluetooth PAN HelpText
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.0.0.138       10.0.0.102     25
         10.0.0.0    255.255.255.0         On-link        10.0.0.102    281
       10.0.0.102  255.255.255.255         On-link        10.0.0.102    281
       10.0.0.255  255.255.255.255         On-link        10.0.0.102    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      169.254.0.0      255.255.0.0        10.0.0.42       10.0.0.102     26
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link        10.0.0.102    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link        10.0.0.102    281
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      169.254.0.0      255.255.0.0        10.0.0.42       1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 16    281 ::/0                     fe80::3291:8fff:fecb:4e7e
  1    331 ::1/128                  On-link
 16    281 2001:8003:f1cd:a600::/56 fe80::3291:8fff:fecb:4e7e
 16    281 2001:8003:f1cd:a600::/64 On-link
 16    281 2001:8003:f1cd:a600:7044:54b6:b081:cb6b/128
                                    On-link
 16    281 2001:8003:f1cd:a600:f819:7e65:1682:60a/128
                                    On-link
 16    281 fdaa:8e94:5373::/48      fe80::3291:8fff:fecb:4e7e
 16    281 fdaa:8e94:5373::/64      On-link
 16    281 fdaa:8e94:5373:0:7044:54b6:b081:cb6b/128
                                    On-link
 16    281 fdaa:8e94:5373:0:f819:7e65:1682:60a/128
                                    On-link
 16    281 fe80::/64                On-link
 16    281 fe80::f819:7e65:1682:60a/128
                                    On-link
  1    331 ff00::/8                 On-link
 16    281 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\Users\ronjo>


However what I did try was

1. I edited my host file on my laptop to
   10.0.0.32        nems
   
   
   
2. This gave me a JSON failure
   
   
   
3. I then edit it to
   
   10.0.0.32        nems.local, it was a bit slow but it worked.
   I refreshed the link <ctrl><F5> a number of times and it was successful
   

When I ssh to nems it tells me that the host name is nems.  AVAHI .local for mDNS is nems.local so it's sort of telling me that if AVAHI is implemented then it wants to see the AVAHI nomenclature in the host file.
Is this correct?