Was running one of the latest 2.x firmware for year or more with no issue.
Upgraded firmware to 3.012 and shortly after rebooting the GL-MT300n-V2 I started losing local name resolution.
As time passed and computers got rebooted, local name resolution got worse and worse.
Now no computer can find another computer by name.
The only thing that works now between computers are 192.168.8.xxx style references.
All of my computers are wired and have statically configured 192.168.8.xxx IP addresses.
Other things like phones, rokus, printers, etc… use the router’s dynamic (DHCP) service.
After the FW upgrade the router stopped providing local name resolution - for the moment - only to static devices.
So far, the router provides correct responses to DNS queries for dynamic (DHCP) devices .
On the router’s “Clients” page, in the “Name” column, all of the computers with static addresses display only a * for the computers name.
All of the previous 2.x versions of the firmware displayed the names of the static IP computers and provided DNS service for those computers.
When I upgraded the firmware I selected the “Keep My Settings” check box.
Does anyone know how to fix this?
Thank You
Thanks posting this problem. Not noticed about this. But would like to put this in bug report
That might be the problem - you cannot keep settings during upgrade from v2 > v3.
Yeah, probably have to set them up again or clear settings. I am on v3 and my static hosts work fine. The hostnames are displayed in the lan ip page.
I did the Revert to Factory Settings.
I then had to re-enter three DHCP reservations.
One is for my printer that keeps getting lost to clients without a fixed IP.
The printer is never “Not Found” with a DHCP reservation.
The other two are for clients PUFF and MUFF.
I run a VPN application on those two clients that fails on disconnect if the client uses a static IP address.
Here’s an image of the LAN IP page after reverting the router to factory settings and re-entering the required static bindings.
Notice that the PUFF client and the Printer display only a * for the client name.
I took a look at the LuCI interface and here is what I found.
Notice the client Buzz was given an IPv6 lease yet is not reachable from client Muff.
The first time I ever saw one of these Cannot Access messages was shortly after updating the FW to 3.012.
This is such a mess I am not sure how to explain what is wrong.
Thank You
There is no lease to renew on a statically IP configured computer.
I rebooted all clients and nothing has changed.
Here are pings of the other clients from the client Muff.
Notice that the Static Win 7 based clients Barn, Plum, Toad and Zeus all reply in IPv6.
The DHCP configured client puff with a router configured IP address reservation replies in IPv4.
Also notice in the pings above that the statically IP configured client Buzz fails to reply to the ping.
Buzz is a Win 8.1 client. All others are Win 7 or WHS 2011 which is based on the Win 7 code.
Ah I see. Usually there is a separate range for statically configured machines (192.168.8.2-99). These are static dhcp leases you are configuring. The DHCP server handles 192.168.8.100-249
The think clients you have manually configured will not be active because they have not requested a lease.
If you want to statically configure your machines I think you need to do it here:
I disabled IPv6 on all 7 of my client computers and the router to eliminate all the IPv6 noise.
All of my other devices like printers, tuners and rokus don’t do IPv6.
I rebooted all computers and the router.
Now all pings of client names work and return IPv4 results.
There has to be something wrong with the router’s FW.
In the LuCI interface shown above you can enter host names to DHCP reservations.
The HTML interface permits only the MAC and IP address entries. No host name.
After entering the MUFF, PUFF and SEC… host names in the LuCI interface those three host names appeared in the HTML LAN IP page.
If a client requests DHCP without a DHCP reservation entered in the router, the router will hand out an IP address between .100 and .249.
But, you can set DHCP reservations within the .2 to .99 range and the router will hand out that IP address.
I have done this with .5 and .6 for the MUFF and PUFF clients and ave never had any issues.
And, now that I have no IPv6 in my network I also no longer have any lost host issues.
Although, I still get an * for all host names as shown below.
I did as suggested and entered all of the static hosts through the LuCI Host Names interface.
This changed nothing. I still get an * for all host names on the Clients page.
But, since eliminating IPv6 has now made all clients again reachable by name. I am going to end this post.
I have other net scanner applications that do show all of the host names for the static hosts.
I must assume that the router just does not bother to interrogate the host for its name.
The router will carry all of the traffic for any of those hosts yet it will not ask the host for its name.
There has to be something wrong with the router’s FW.
Thank You
This is part of a dhcp request, a client requesting a lease will tell the server its name (if configured). When you had ipv6 dhcp enabled it did so. Even though you had ipv4 manually configured - which led to a lot of confusion. Either DHCP both protocols or statically configure them. Personally, I don’t find it necessary to statically configure a machine - why configure it in two places?
Yes you can request .2-.99 IP’s from DHCP outside its range and it will supply them if the host has an entry with dhcp-host in the dnsmasq configuration - which is what the LAN IP page does.
the LuCI interface shown above you can enter host names to DHCP reservations.
The HTML interface permits only the MAC and IP address entries. No host name.
I think this should be added.
I still get an * for all host names on the Clients page.
These static hosts are currently configured outside the scope of the GL-iNET web ui - which seems to be focused on DHCP. Not many people manually configuring IP’s anymore.
Again, something about only 2 links in a post.
So again I resort to a picture of the text the system won’t accept.
I had a static lease for a linux VM on 192.168.8.158, I went into the LAN-IP page and changed it to 192.168.8.5 and clicked save and apply:
I then restarted networking to renew my lease:
alpine:~# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:77:49:13 brd ff:ff:ff:ff:ff:ff
inet 192.168.8.158/24 brd 192.168.8.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd49:51db:47d2:10:20c:29ff:fe77:4913/64 scope global dynamic
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe77:4913/64 scope link
valid_lft forever preferred_lft foreveralpine:~# rc-service networking restart
- WARNING: you are stopping a boot service
- Stopping chronyd … [ ok ]
- Stopping networking …
- lo … [ ok ]
- eth0 … [ ok ]
- Starting networking …
- lo … [ ok ]
- eth0 …
udhcpc: started, v1.29.3
udhcpc: sending discover
udhcpc: sending select for 192.168.8.5
udhcpc: lease of 192.168.8.5 obtained, lease time 43200 [ ok ]alpine:~# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:77:49:13 brd ff:ff:ff:ff:ff:ff
inet 192.168.8.5/24 brd 192.168.8.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe77:4913/64 scope link
valid_lft forever preferred_lft forever
I then ping from an android phone to the linux vm:
$ ping alpine
PING alpine.lan (192.168.8.5) 56(84) bytes of data.
64 bytes from alpine.lan (192.168.8.5): icmp_seq=1 ttl=64 time=5.52 ms
64 bytes from alpine.lan (192.168.8.5): icmp_seq=2 ttl=64 time=32.0 ms
64 bytes from alpine.lan (192.168.8.5): icmp_seq=3 ttl=64 time=3.35 ms
^C
--- alpine.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.355/13.647/32.065/13.053 ms
$ nslookup alpine 192.168.8.1
Server: 192.168.8.1
Address: 192.168.8.1#53
Name: alpine
Address: 192.168.8.5
None of this is setup in Hostnames.
Maybe the client you are using to nslookup ‘muff’ was manually configured? Is the domain search set correctly (lan) ?