I run static IP addresses on my LAN, all of it served out by the router where the MAC address to IP address assignment is made. Most devices (where possible) are set to DYNAMIC IP, but of course the router serves up the pre-defined static IP out to the device. If that is not possible some devices actually have the IP address set to STATIC and it's directly updated on the device itself.
OK, all good.
The other day we picked up a Google Home Hub Display device, my wife wanted to have something in the kitchen that would serve up the cooking recipes and give her easy access to on-line stuff w/o having to rely on a laptop or another display. Easy enough right?
Well, I pre-allocate my IP blocks per groups of devices, meaning: media devices are lumped into an IP address range, as are the PCs, the mobile devices, and so on.
I needed to make room for the Google Hub and that meant I had to bump my NAS box from it's IP address to something new. No problem there, router was updated, NAS re-booted, it picked up the new IP.
I then updated my HOSTS file to reflect the new addresses, re-booted (just to be safe) only to discover upon a re-boot that my NetDrive mapping would no longer find the NAS box. So off I went investigating and found that if I replace the alias I was using in the NetDrive resource mapping with an actual IP address the connectivity is back up (see this logging in the debug listing below).
That leads me to believe that the Samba client is maintaining a mapping of the actual IP address the alias was previously pointing to and re-using it instead of querrying it up each time.
The question therefore is: does anyone know where that alias to IP address mapping is cached in the Samba configuration?
While the static IP address setup works, I really do not want to use that in the NetDrive resource setups and would prefer to use the alias instead and rely on the HOSTS file driven mapping.
btw: doing 'ping nas' from CLI successfully shows the new IP address, I can also point the browser to that nas box and reach it successfully.
Samba client 3.6.0 build 20190324 based on 4.10.6
This build is maintained by netlabs
2019/09/04 21:31:20.24: 9 1: Working with 64 bit fileio NDFS
2019/09/04 21:31:20.38: 9 1: NdpIOCTL init thread
2019/09/04 21:32:00.74: 9 2: NdpCreateConnection in
2019/09/04 21:32:00.74: 9 2: NdpCreateConnection send CONNECT
2019/09/04 21:32:00.74: 1 2: Connecting to \\admin:*********@home:nas\vol1. Master HOME:1
2019/09/04 21:32:05.79: 4 2: Connection to nas failed (Error NT_STATUS_IO_TIMEOUT)
2019/09/04 21:32:05.79: 9 2: NdpCreateConnection [0] 87
2019/09/04 21:32:05.79: 9 2: NdpCreateConnection in
2019/09/04 21:34:37.75: 9 2: checkMountResource in tid#2
2019/09/04 21:34:37.75: 1 2: Connecting to \\admin:*********@home:nas\vol1. Master HOME:1
2019/09/04 21:34:42.77: 4 2: Connection to nas failed (Error NT_STATUS_IO_TIMEOUT)
2019/09/04 21:34:42.77: 9 2: NdpMountResource rc=58
2019/09/04 21:43:58.58: 9 2: NdpMountResource in
2019/09/04 21:43:58.58: 9 2: dircache_create: 10 seconds, 32 entries
2019/09/04 21:43:58.58: 9 2: dircache_create: 0x6d3f20, rc = 0
2019/09/04 21:43:58.58: 9 2: checkMountResource in tid#2
2019/09/04 21:43:58.58: 1 2: Connecting to \\admin:*********@HOME:192.168.1.4\vol1. Master HOME:1
2019/09/04 21:43:58.59: 4 2: Server supports NT1 protocol
2019/09/04 21:43:58.62: 4 2: session setup ok. Sending tconx <vol1> <********>
2019/09/04 21:43:58.63: 4 2: tconx ok.
2019/09/04 21:43:58.63: 9 2: NdpMountResource rc=0
2019/09/04 21:43:58.63: 9 2: NdpRsrcQueryInfo in
2019/09/04 21:43:58.63: 9 2: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:44:05.21: 9 2: NdpCreateConnection in
2019/09/04 21:44:05.21: 9 2: NdpCreateConnection send CONNECT
2019/09/04 21:44:05.21: 1 2: Connecting to \\admin:*********@HOME:192.168.1.4\vol1. Master HOME:1
2019/09/04 21:44:05.22: 4 2: Server supports NT1 protocol
2019/09/04 21:44:05.23: 4 2: session setup ok. Sending tconx <vol1> <********>
2019/09/04 21:44:05.24: 4 2: tconx ok.