Yet another -530 client not found error

[DavidHertzberg]

x509,

I did a little Googling, and—just below the heading "How to assign static IP address using Settings" [my emphasis] on this Pureinfotech article on "How to set a static IP address on Windows 10"—is a section "Assigning static IP address for Wi-Fi adapter".  So you wouldn't have to do scripting or get into your router's assignments table, but—from what you  and mbennett have said up-thread—a Windows update might silently reset any such settings.

Everyone,

I went searching for this because I couldn't believe that modern Windows doesn't have the equivalent of the System Preferences->Network->Location dialog in macOS, for x509 to use with his Wi-Fi.  This facility was developed in OS X to provide for Mac laptops that might be moved to different locations (hence the name) having different LANs, and is available as far back as my ex-wife's ancient Digital Audio G4 booting 2003's "Panther" OS X 10.3.

Although my MacBook Pro never leaves my study desk, I discovered Location after I bought a CalDigit Thunderbolt Station 3 Plus dock to connect it via a KVM switch to a an external monitor.  When my Apple 27-inch LED Cinema Display loses the video signal, it goes into a "deep sleep" mode—and needs to be "goosed" to wake up.  If my KVM switch is still set to take input from the CalDigit dock, it has lost the DisplayPort video because I shut down the MacBook Pro the input was indirectly coming from—so rebooting the MBP results in the dock "goosing" the monitor.  If  OTOH my KVM switch was formerly set to take input from the G4 via converted DVI, it has lost the DisplayPort video because I switched it to an awake MBP—and only rebooting the dock results in the dock "goosing" the monitor. In that second case I originally found that detaching and re-attaching either end of the Thunderbolt 3 cable between the MBP and the dock was sufficient to reboot the dock—as was unplugging and re-inserting the dock's power cord, but a woman at Apple Tech Support suggested that a method which wouldn't violate any mechanical port-insertion limits would be to plug the dock into a surge protector whose sturdy switch I could use to reboot the dock—so I'm doing it.

This created a problem with using Retrospect to simultaneously Recycle backup my MBP—using version 16 and an Ethernet connection wired via MoCA (inter-room Wi-Fi is slow in my apartment) to a "backup server" in another room—and my G4—using version 6.1 and a DAT tape drive SCSI-cabled directly to the G4.  Using the KVM switch to switch the Cinema Display from the MBP to the G4 works fine, because the G4 automatically "gooses" the monitor out of "deep sleep".  However using the KVM switch to switch the Cinema Display from the G4 to the MBP was killing the MBP's backup, because power-cycling the CalDigit dock was interrupting its Ethernet connection.  My solution was to create a Location named "Retrospect Priority" in addition to the "Automatic" one.  In "Retrospect Priority" the MBP's Ethernet connection is via a Moshi USB-C-to-Ethernet adapter (used with iffy StarTech USB32DPPRO before CalDigit), and the Ethernet connection through the dock is disabled—so power-cycling the CalDigit won't interrupt the MBP's Ethernet connection.

I took the trouble to explain this because, now that external docks are becoming popular, other administrators with DisplayPort or Thunderbolt 3 monitors in their installations may have similar problems.  The "deep sleep" feature is common to many such monitors—not just Apple's, and represents monitor manufacturers taking advantage of a DisplayPort (and Thunderbolt 3, which merges DisplayPort + PCIe + DC power) characteristic to lengthen monitor life—ignoring DP cable swappers and KVM switchers.  HDMI monitors also have a  "deep sleep" feature, but it can be disabled in some models.

[Nigel Smith]

17 hours ago, DavidHertzberg said:

So you wouldn't have to do scripting or get into your router's assignments table

Would just warn that different routers' DHCP servers behave in different ways. Some treat the address blocks reserved for statics as inviolate, some will continue to offer those addresses when no MAC address has been set, etc. I always belt-and-brace, putting MAC addresses in the router's table and setting static IPs on the clients, when I need a definitely-fixed IP.

Also, some routers force a certain (often limited) range for statics and others let you do as you will, so check your docs before planning.

[DavidHertzberg]

I am in fact doing what Nigel Smith calls "belt-and-brace" ("braces" are British English for what the rest of us call "suspenders") ; I have entries both in my router's MAC table and my MacBook Pro's System Preferences->Network->Locations for both my Moshi USB-C-to-Ethernet adapter port (X.Y.Z.201) and my CalDigit TS3 Plus Ethernet port (X.Y.Z.202)—X and Y and Z are "seekrit" numbers you couldn't 🤣 possibly guess..  My "Automatic" Location has the CalDigit port enabled, and my "Retrospect Priority" Location has the Moshi port enabled.  On my Retrospect Mac 16.6 "backup server", the Source for the MBP is defined with Add Source Directly as X.Y.Z.201—and my MBP usually uses the "Retrospect Priority" Location although the "Automatic" Location would give me slightly-faster Ethernet via Thunderbolt 3.

Yesterday afternoon I did a couple of tests, using my handy-dandy NoOpSun-FriBackup script with the No Files Rule (Selector in Retrospect Windows).  I first switched my MBP to the "Automatic" location and ran the script, which immediately issued a -519 error for the MBP.  (That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Directly.  My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.)

I then switched my MBP's Location to "Retrospect Priority" and reran the script.  It started to run fine, until I too-rapidly shut down the MBP while the script was still making its 4-minute run—eliciting a "backup server" -519 error.  (Point for Nigel Smith in the 6-months-back dispute; "the client was found, then disappeared".)

Getting back to Nigel Smith's final warning, x509 should certainly find out what range for fixed IPs his router allows.  I believe I checked the manual for my ancient Verizon Quantum G1100 "gateway", but I simply set up fixed IP addresses starting with X.Y.Z.200.

[Nigel Smith]

1 hour ago, DavidHertzberg said:

(That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Direct.  My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.)

You're viewing the Piton protocol too narrowly. It's the protocol(s) by which server and client communicate and includes discovery, access and data transfer (amongst other things) and is used in the unicast (defined IP client, as above), broadcast and multicast "location" (using that since "discovery" usually means "first time ever finding a client" in RS) of a client on the network and all subsequent communication.

You'll have to do a lot more digging with eg WireShark to know exactly why you saw what you saw -- I'd expect it to throw a -530 (because the client was still listening on x.x.x.202:497) or just work, not throw a -519 -- but I suspect that permanently binding the client to x.x.x.201 with "ipsave" might eliminate the issue.

-530 is quite clear -- the client couldn't be found. That -519 is separate implies that the client could be found but then there was a problem, but I'm probably reading to much into it. All we really know is that "network communication failed", for whatever reason.

[DavidHertzberg]

Nigel Smith,

You are correct about my having defined the Piton protocol too narrowly; Instead of writing "multicast Piton Protocol", I should have used the term Piton Name Service—per page 227 of the Retrospect Windows 17 User's Guide.  At last the -530 versus -519 difference is clarified.  On page 221 the UG says:

Quote

By default, Retrospect uses its Piton multicast method of searching for clients in the local subnet.

Page 228 says:

Quote

Multicast Piton Name Service uses the assigned address 224.1.0.38, which allows Piton to direct its queries only to those computers running Retrospect Client software.

Page 33 of the Appendices says:

Quote

Piton –Retrospect’s own proprietary protocol for communicating with backup clients. In the live network window, Retrospect uses the Piton name service to establish contact with clients.

In fact, a closer examination of the log for my first test run illustrates the difference between the overall Piton protocol and Piton Name Service in a rather interesting way (it turns out I didn't need WireShark. 😁).  The run actually "Finished scanning backup set data files to ... ", then issued the message "Can't access backup client ..., error -519 (network communications failed)".  It seems my "backup server" managed to find my MacBook Pro "client" by name, when it couldn't do so by Direct Access because the IP address the "client" was using didn't match the one defined in Sources.  Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up" and issued the -519 error—not a -530 error.

By contrast, the log for my second test run—where the IP address the "client" was using did match the one defined in Sources—says "Can't read state info, error -519 (network communications failed)" when I too-rapidly shut down the MBP after the "backup server" had successfully finished the backup stage.

Thus it's the Piton Name Service that needs to be fixed.  As I've predicted elsewhere, StorCentric will have to force this to be done for the forthcoming Drobo variant of the "backup server"—so hordes of new Retrospect users won't have to learn how to set up Direct access to avoid -530 errors.

[Nigel Smith]

Not so fast...

3 hours ago, DavidHertzberg said:

Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up"

This is what I think might be happening (and why a WireShark run would help):

1. Client is on "Automatic" location -- x.x.x.202
2. You switch to "Retrospect Priority", client address now x.x.x.201, and immediately run the server script
3. Server multicasts to all devices, asking for client
4. Client responds, but we know the client doesn't instantly reflect a network change, so says "Yay! Me! Here and ready on x.x.x.202!"
5. Scan gets done
6. By now, the client is listening is on x.x.x.201:497 (or, rather, is no longer listening on x.x.x.202:497)
7. Server initiates the backup "Hey, x.x.x.202, give me all these things!"
8. Silence...
9. More silence...
10. Server assumes network communication has failed and throws -519

Step 4 is total guesswork from me -- all we know is that there must be some mechanism for a multicasted client to tell the server its IP address. If I'm right, they might be able to fix this on the client, though it may dependent on the OS promptly informing all network-using services of an IP change (the client unnecessarily spamming the OS for updates would be horribly inefficient). Or they might be able to fix this on the server, with a re-multicast after step 8's failure to pick up the new address.

But, even in these days of devices often changing networks, I doubt the above crops up very often and probably isn't worth fixing (directly, at least). x509's "binding to a bogus address" is much more common, and if solving that solves other issues too -- bonus!

[DavidHertzberg]

Nigel Smith,

Your 10-step guess as to what might have been happening may be correct, although you got confused about the Location of my first test—it was "Automatic" (X.Y.Z.202) instead of "Retrospect Priority" (X.Y.Z.201).  I reran that test yesterday, but—after changing the Location of my MacBook Pro "client" machine—scheduled the backup run 15 minutes in the future and then shut down and re-booted my "backup server".  This time the No Files backup ran with no error. 😲

That raised the question of how the Retrospect Engine had been able to find the MBP Source, which I am sure I had defined with Add Source Directly as X.Y.Z.201.  The answer seems to be the "magic" of Piton Name Service.  When I did a Locate of that Source after the test, it found the MBP via Multicast as X.Y.Z.202.  (I intentionally did not do a Locate after re-booting the "backup server" but before the test run was scheduled, because I found 3 years ago that a pre-Backup Locate would eliminate a -530 error that otherwise would occur.)

So am I going to investigate this further in my installation, other than possibly making the effort (because of necessary script changes) to Remove and re-Add my MBP as a Source with Use Multicast?  No I am not, because of an experience I had with Tech Support over two years ago.  As the third paragraph of that post says, T. S. twice gave me test versions of Retrospect with extra logging.  I uploaded the results to my Support Case, and got back a reply that said basically "Yes we see a problem, but we can't do anything about it unless we can reproduce it on our own machines—because it seems to be at least partially related to network hardware."  I thereupon offered to snail-mail T. S. my two MoCA adapters (for which I had by then bought higher-speed replacements) and a 40-foot length of previously-bought-for-testing Radio Shack coax cable to run between them, but got back a reply that said basically "Thanks for the offer, but we cannot take responsibility for customer-owned hardware."  I then suggested they find someone in the Retrospect Inc. organization who had gone far enough in law school to be able to write a deed of gift to Retrospect Inc. that I could sign, but they didn't reply. ☹️

So, as the last paragraph in this up-thread post states, we'll just have to wait until StorCentric discovers the -530 problem for the forthcoming Drobo variant of the "backup server"—and provides Retrospect "Inc." engineers the necessary resources to find and fix the problem. 😢

 

[Nigel Smith]

3 hours ago, DavidHertzberg said:

So am I going to investigate this further in my installation... No I am not

Smart move, IMO!

These are deep waters, best left unrippled. Especially when you remember that network communication is not directly via IP address, but is next-hop routing via the mapping of IP addresses to gateway/MAC address in ARP tables. Table updates aren't instant, which is why I can quite easily see why my guess might happen -- step 5 is based on the MAC address of the previously  detected client, obviously still "valid" since the interface used wasn't changed (just the IP address). But when we get to step 7 it's aged out/replaced, the IP address is no longer valid, and you get a comms fail.

[MrPete]

Hi all! Sorry for the long delay. The Real World is intense for me right now

The following simple sequence has been a 100% reliable workaround for me:

1) AFTER an endpoint is stably connected to a LAN via any mechanism (wired, wifi, etc)...

2) Restart the Retrospect Client service (stop / start as described earlier)

The client NEVER gets confused under such conditions, at least in my way-too-extensive testing.

Confusion arises when the client initializes at the same time as the computer is initializing various things, including a variety of network-connected startup services etc. And/or if the network connection changes (eg wired to wifi, or to a different wifi.)

[x509]

This thread, plus some of the weird things Windows updates does to network settings, probably explains why there is such grief around Windows networking.  Way back in the 1980s, I was a product manager for networking protocols and stacks.  That was before TCP/IP took over the world.  Aside from LAN protocols, I dealt with SNA and DECNet, also oddballs like Banyan Vines.  Thinking back on those days, I can't imagine what i was thinking.  When TCP/IP became the One Protocol To Rule Them All, and Microsoft aligned its LAN networking around TCP/IP, life was supposed to get better.  I must have been smoking some strong stuff back then.

I like the belt and braces approach above.

[MrPete]

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.) This requires a dynamic solution for both server and client.

AFAIK, at the server end, all methods work just fine.

The only serious problem with dynamic IP's is on the client end, as has been discussed.

[Nigel Smith]

On 5/30/2020 at 11:12 PM, MrPete said:

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.)

Totally agree, with both this and your previous post. We never static just for Retrospect, simply restart the client when needed (though the occasional missed backup can be annoying, it isn't the end of the world, and "moving" clients often miss backups anyway). But on a relatively "fixed" home or small business network, where IPs are only usually DHCPed because it's the default option, b'n'b helps with problems caused by... let's say "less compliant"... DHCP servers.

[DavidHertzberg]

On 5/30/2020 at 6:12 PM, MrPete said:

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.) This requires a dynamic solution for both server and client.

AFAIK, at the server end, all methods work just fine.

The only serious problem with dynamic IP's is on the client end, as has been discussed.

MrPete,

For the problem described inside parentheses in your first paragraph, have you defined your subnets per pages 228–229 of the Retrospect Windows 17 User's Guide—and have you added such clients using the Subnet Broadcast access method per the Access Tab alluded to (not described) on page 223?

My impression is that Subnet Broadcast—which I've never used for its intended purpose—searches for the "client" machine using the Piton Name Service on each of the subnets defined on the "backup server".  If that doesn't do what you need, here's why and how to create a feature request Support Case for enabling multiple Direct Access addresses for a particular "client".

 

[rfajman]

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

[DavidHertzberg]

On 6/1/2020 at 5:26 PM, rfajman said:

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

rfajman,

You've left out a key word after "dedicated Gigabit Ethernet": you should have written "dedicated Gigabit Ethernet WHATSIS".  Is the WHATSIS a piece of hardware—such as a router or "gateway", or is it a piece of software—such as something in Microsoft Windows 10?

The WHATSIS apparently has an interface, and that interface is checkable and configurable via a command file.  Some Googling seems to show that Gigabit Internet interface is a connection between a computer and a router.  You may have a Windows 10 problem, but I'll let someone who knows Windows explore (no pun intended) that further—based on further information about your script that you must provide.

P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.

Edited June 8, 2020 by DavidHertzberg
Question mark ending 2nd sentence of first paragraph. P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.

[x509]

On 6/1/2020 at 2:26 PM, rfajman said:

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

rjafman,

Can you post this script.  Thanks.

[MrPete]

On 6/1/2020 at 3:50 AM, DavidHertzberg said:

MrPete,

For the problem described inside parentheses in your first paragraph, have you defined your subnets per pages 228–229 of the Retrospect Windows 17 User's Guide—and have you added such clients using the Subnet Broadcast access method per the Access Tab alluded to (not described) on page 223?

My impression is that Subnet Broadcast—which I've never used for its intended purpose—searches for the "client" machine using the Piton Name Service on each of the subnets defined on the "backup server".  If that doesn't do what you need, here's why and how to create a feature request Support Case for enabling multiple Direct Access addresses for a particular "client".

 

David,

**yes** . I've used Subnet search properly. Used multicast. Used Piton.

And here is the key:

* When an endpoint changes its IP address,

* And does not fully (manually) restarting the Retrospect service,

* THEN: the endpoint will NOT (ever) properly listen for the server's "calls". Period. (This COULD be specific to certain general configurations, but I have seen it on various setups.)

This is easily proven using SysInternals TCPview.

To repeat what I wrote earlier this year: when the Windows client deals with an IP address change, it starts listening to 169.254.*.* -- ie NOT a real IP address. The only workaround is to restart the client service. (NOTE: I can believe under some circumstances this may not happen. I've just not seen it )

Edited August 19, 2020 by MrPete
Clarification

[x509]

Ignoring the two spam messages by this newcomer, I have read through this thread, and just thrown up my hands.  I have not been to this forum because of distractions for other important issues ( but I don't have Covid-19 !!).  So I'm going to pay The Man for the V17 upgrade, try to see if subnet detection works (or not) and then file a support case.

About a month ago, I slowly, somewhat painfully edited my router's IP address assignment table so that all devices on the LAN now have assigned IP addresses.  But that is a band-aid, and could get problematic to manage if I add an Access Point to to the home Wi-Fi to deal with recent performance issues.

Honestly, I've had to devise several band-aids around managed scripts.  I know I'm only a home user, small potatoes, but Retrospect, or whatever they call themselves these days, should stand behind their product.

Also just wondering if anyone has had any experience with Drobo NAS systems?  In various forums, Drobo is hardly ever mentioned, and everyone seems in love with Synology.

[DavidHertzberg]

MrPete and x509,

It sounds as if both of you could use the "ipsave" command described in this Knowledge Base article.  This 2019 post in another thread and its follow-ons describes the command's successful use on Windows "client" machines.  Other posts you can find by doing a Forums search for "ipsave" describe its successful use on Mac "client" machines, but as a Mac user I didn't want to scare you.

The facility was added in Retrospect Windows 10.0, but—starting with that release in 2015—Retrospect Inc. adapted a policy of having the "What's New" chapter in the User's Guides be written by marketing-oriented Product Management people—and having the information in that chapter overwritten in the next UG release.  In this case, the astonishingly-specific 🤣 information was:

Quote

Retrospect is more resilient to network hiccups and address changes that affect client connectivity and stability.

x509,

Here's an Ars Technica post by a Drobo user (I'm not one), written in response to my announcing that Retrospect Inc. had been acquired by StorCentric—which also owns Drobo.  I saw somewhere in the last year or so that disks used in a Drobo NAS, which can be of different sizes—a formerly-touted feature, can only be read by another Drobo NAS because of proprietary formatting.  IME the head of R. T. S. will hit the roof if we say anything too critical.

[Nigel Smith]

5 hours ago, x509 said:

So I'm going to pay The Man for the V17 upgrade, try to see if subnet detection works (or not) and then file a support case.

Subnet detection works, and always has.

The problem isn't detection by the server, but that the RS client stops listening. It doesn't "rebind" when the client machine's IP address changes -- both MrPete's stop/start and the "ipsave" command David mentions above will solve this, but both mean that the user has to know that there's a problem (unless you can automate it, triggered by the network change).

This isn't just a problem with Retrospect and Windows, I've seen it with other "listener" daemons and other OSs.

WRT to Drobos -- to (again!) echo David, one of the reasons we started using them when they first came to the UK was the ability to use different size disks. We could buy an enclosure, put a couple of disks in and then later upgrade it by adding bigger-but-now-cheaper disks, without having to copy of all the data of and swap disks and reformat the RAID and copy the data back on... Now that big disks are (relatively) cheap and other NASs now allow "volume expansion" on the fly (with limitations) it's not such a selling point to us -- but it might be for me at home. Another good point was that you could move all the disks from one enclosure to another and the Drobo volume(s) would just work as before -- useful if eg a PSU failed. A downside at the time was their (lack of) speed, probably because of the overheads of their proprietary "RAID" system on "consumerish" hardware -- I daresay things are much better now, but I haven't tried any of the current models.

Edited August 19, 2020 by Nigel Smith

[DavidHertzberg]

MrPete,—and maybe x509,

With my simple-minded experience, I'm having trouble understanding why for you "an endpoint changes its IP address".  I remembered something about a problem Nigel Smith had in the past, but couldn't find the thread for most of an evening.  Here it is, starting—for your purposes—with this post describing a procedure that worked for him.  The remainder of that thread explains his situation, ending with a post that explains why his procedure is the only one that solved his problem—which may or may not be similar to yours.

(My simple-minded experience consists of an home installation with a "client" in the study and a "backup server" in the bedroom.  In 1998 I replaced my previous PhoneNet network with a re-purposed piece of in-the-wall coaxial cable running between the two rooms, now attached at each end to a MoCA adapter in turn cabled to an Ethernet switch.  I did a test two years ago, and discovered that 802.11g WiFi between the two rooms only ran at 20% of the cable speed—because of multiple Sheetrock walls and a refrigerator in the signal path.  Thus WiFi on all my computers is turned off, so I never have any endpoint address change—unless I alter my "client"'s static DHCP IP in my router that's specified in its Sources definition's Direct Access address.)

You might consider his 10-step procedure, because it handles a 2-subnet-with-Fortigate-switching problem that's IMHO at least as generalized as yours.

[Nigel Smith]

5 hours ago, DavidHertzberg said:

With my simple-minded experience, I'm having trouble understanding why for you "an endpoint changes its IP address".

Most setups, unlike yours, use DHCP for the majority of their machines and/or have wireless enabled. While static addresses are a fix for the binding problem that isn't always practical (eg a workplace with more potentially-connected devices than available IP addresses) or a complete solution (eg my laptop may be static on "my" ethernet, but if I take it to another department I'll have to use wireless).

Unfortunately my post was solving a different problem, which is probably specific to our setup, and won't help here. So currently the only solutions appear to be:

1. Static IPs on clients (may not be practical), or
2. Turn RS client off and on again (only possible where you allow this), or
3. Use the "ipsave" command

Note that rebooting the computer often doesn't solve the problem -- whatever glitch resulted in RS Client being bound to the Windows Private IP before the OS registered the NIC's "new" DHCP-assigned address is usually repeated.

I'd use the "ipsave" command since we don't let users turn off RS Client -- ideally this would be scripted, since I don't trust users to notice there's a problem, and it'll be something I'll have to look at when we redeploy RS across our estate if this is a frequent problem for us.

On 8/19/2020 at 5:07 AM, x509 said:

About a month ago, I slowly, somewhat painfully edited my router's IP address assignment table so that all devices on the LAN now have assigned IP addresses.  But that is a band-aid, and could get problematic to manage if I add an Access Point to to the home Wi-Fi to deal with recent performance issues.

Shouldn't be an issue since you should be extending your network and so using the same router for all DHCP assignments, rather than adding a second network complete with second DHCP server and gateway connecting back to your original network etc. Extension will give you far fewer configuration headaches -- unless you need that second, segregated, network for some reason.

[MrPete]

22 hours ago, DavidHertzberg said:

With my simple-minded experience, I'm having trouble understanding why for you "an endpoint changes its IP address".

I would call your experience "simple" but not "simple-minded." 😄

We have a multi-site LAN permanently connected via (OpenVPN) VPN. Plus, for clarity and security purposes, we have multiple subnets, separating server backbone, internal endpoint, IoT, and guest nets. As the guy responsible for all of that, my MS Surface Pro 6 may be connected anywhere at any time. Sure, not all of those are available for backup... but at the least my laptop may want to be backed up from any site.

In practical terms, that means my one laptop may show up with any of at least four different IP's. Oh, and up to four MAC addresses (2 different WiFi MACs, and two docking station ethernet MACs.)

The hard part: even if it were only one IP per site (ie both Wifi and wired sharing an IP -- NOT supported by all systems!), I have watched as Windows brings devices up and the RS client attaches. As Nigel says, the client can easily bind to an unusable ip (169.254.*.*) even though the ethernet/wifi adapter ends up on a valid IP.

The mayyybe good news: I've pinged tech support to go back and see what is going on.

* The bug report for this (8512) was supposedly being worked on months ago.

* It is NOT listed in release notes.

* I DO see some evidence that something has changed. Until I hear back, I'm not willing to invest the time and energy to completely redo my extensive testing.

* I suspect they slipstreamed some kind of solution, even if incomplete or still having a bug or ten. 😄

[rfajman]

On 6/1/2020 at 6:40 PM, DavidHertzberg said:

rfajman,

You've left out a key word after "dedicated Gigabit Ethernet": you should have written "dedicated Gigabit Ethernet WHATSIS".  Is the WHATSIS a piece of hardware—such as a router or "gateway", or is it a piece of software—such as something in Microsoft Windows 10?

The WHATSIS apparently has an interface, and that interface is checkable and configurable via a command file.  Some Googling seems to show that Gigabit Internet interface is a connection between a computer and a router.  You may have a Windows 10 problem, but I'll let someone who knows Windows explore (no pun intended) that further—based on further information about your script that you must provide.

P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.

The "WHATSIS" is a small Gigabit Ethernet switch.  I'm not really clear on what your point is, but I haven't really been following this discussion here.

[DavidHertzberg]

On 6/1/2020 at 5:26 PM, rfajman said:

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

rfajman,

Thank you for,  3 months later, confirming my point in the post you quote in the post directly above this one.  As I'd guessed, the WHATSIS is hardware.

My "backup server" doesn't have more than one NIC, so I never knew Interfaces—described on page 297 of the Retrospect Windows 16 User's Guide—are a Retrospect feature (which is why I'm now initial-upper-casing "Interface").  But I don't know how you'd run within Retrospect "a command file that runs in the background", much less one that "periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary."  It sounds as if you actually run a Windows command file that checks and reestablishes a proper Windows configuration of hardware and/or software—one that is reflected within a Retrospect Interface.

Since you mention "pretty high speed wireless Internet access provided by the place where we live", it also sounds as if your Gigabit Ethernet switch is used only for Retrospect backups.  That would imply you are having a periodic hardware or Windows problem with your switch, which your Retrospect Interface "sniffs out".  I suggest you temporarily modify your command file  to not reestablish the proper configuration, but instead to send you an e-mail or other message.  When you get that message, you should then test communication over the switch using programs other than Retrospect.

As x509 wrote in response to your 1 June post, "Can you post this [command file] script.  Thanks."  Please post the un-modified reestablishing version.