error 530. the gift that keeps on giving.

[DavidHertzberg]

BTW, what may either be a Retrospect feature (designed to prevent inadvertent double-submission of the same script scheduled twice in succession) or another Retrospect bug exists. I discovered it when testing by scheduling two Repeat Never runs of the same "sacrificial" script scheduled 5 minutes apart, then shutting down my "backup server" and re-booting the "backup server" at least 15 minutes after the scheduled time for the first run. The second scheduled run had disappeared from the Activities list. I was scheduling the "sacrificial" script twice in succession because the "real" script—which does not use the No Files Rule—would have run 15 minutes longer.

[DavidHertzberg]

Executive Summary of this post (15.6.1.105 on "backup server" and MacBook Pro Client; MBP now booting under macOS 10.13 High Sierra, Mac Pro "backup server" still booting under macOS 10.12 Sierra):

• For MBP "client", I get a -530 Bug 1 (first script fails if "backup server" booted after script's scheduled time) and -530 Bug 2 (second script also fails if "backup server" booted after script's scheduled time, even if first "sacrificial" script failed) when MBP "client" was Added with Use Multicast.
• For MBP "client", I get no -530 Bugs under same circumstances when MBP "client" was Added with Add Source Directly (using fixed IP address). This persisted for 3 weeks, so -530 Bug 3 (-530 Bugs 1 and/or 2 reappear a week or two after MBP "client" Removed and re-Added after Client reinstalled on MBP) may have been fixed—or apparent config corruption doesn't occur when Client re-Added with Add Source Directly.
• Use Multicast refers to Retrospect's use of its proprietary "Piton protocol" over assigned multicast address 224.1.0.38. This enables an enterprise's "backup administrator" to Add new "client" machines to be backed up over the enterprise LAN, even though the "backup administrator" doesn't have the training required of a member of the IT staff (explained in the last sentence in the first paragraph here). The "backup administrator" doesn't have to know anything about a "client" machine's IP address, only to be able to recognize its unique name as known on the LAN. Once a "client" is Added, communication between its Client software and the "backup server" takes place over well-known port 497; if this communication fails for a "client"—possibly because of a LAN IP address change, the "backup server" sends out another "Piton protocol" request in order to update its "client" database. The "Piton protocol", which was developed shortly after 2000, is one of the features that makes Retrospect easy for an enterprise to keep using—without the aid of a trained member of the IT staff or a consultant.

Those of you administrators who have "clients" either connecting for Proactive backups or connecting to the "backup server" over WiFi: does the LAN IP address of those "clients" change?

[DavidHertzberg]

Further news on this immediately-preceding post, not too good for some of you administrators with Verizon FiOS.

Friday night it occurred to me: "What if it's my FiOS router that's inhibiting Multicast?"  Sunday I had a countervailing thought: "That would be a funny kind of inhibition; the router doesn't prevent my 'backup server' from Adding a 'client' Using Multicast, but prevents Multicast from Finding the 'client' when executing a Backup script unless I do a Locate before the script starts."

So this evening I phoned 1-(800)-VERIZON.  The first T.S. person I talked to was so scripted that he sounded like my ancient memories of Roy the Toy Boy from the original Electric Company, but at last I got to talk to a "senior" T.S. person.  He put me on hold several times while he communicated with an even-more-"senior" person, but at last I got an answer—relayed from their "FiOS Gateway" support company rather than directly from the manufacturer Actiontec.  The short version is that the latest "security" updates to the ROM of my FiOS G1100 "gateway" (a modem coax-cabled to the FiOS ONT box plus an Ethernet router), which was installed on 9 October 2018, inhibit Multicast as used in the PITON Protocol.

This is no longer a personal problem for me, because I've switched to using Add Source Directly—as described in the immediately-preceding post.  I can do this because I've assigned both my "client" machines—which are Ethernet-cabled to the "gateway"—fixed IP addresses.  I don't think that will be possible for those of you who connect "client" machines to your LAN using WiFi, because it's my impression—correct me if I'm wrong—that such connections cannot be constrained to a fixed IP address.  However I intend to add a post to my Ars Technica Networking thread, explaining the problem and asking if I'm correct about not being able to assign fixed IP addresses to WiFi-connected "clients".

It occurred to me this evening that maybe I could solve the Use Multicast problem by getting a different router.  The "senior" Verizon T.S. person said that I could buy one and put the G1100 "gateway" into bridge mode, with all the equipment on my LAN connected to the other router.  He warned that this would slow down my LAN's Internet connection speed by 20%—which I don't care about (especially since Verizon is going to raise my FiOS speed to 100mbps in May as compensation for my losing Cinemax), but that it would also prevent me from using Guide (and Info?) on my TV—which I do care about.  Since I'm fine with having to use Add Source Directly, I'm not going to buy a second router—but you WiFi-users may have to.

[DavidHertzberg]

Quote

Error: tried to copy a quoted passage from an Ars Technica thread, including the header specific to that Forum..

[DavidHertzberg]

In the Ars Technica Networking forum thread concerned with my -530 bugs, one of the experts wrote on 25 March 2019:

Quote

So... everything works fine now? Because you added the target devices you want to backup by specifying the target IP address instead of using their multicast based device browser?

Hehe, if that is the case, "Welcome to backup software." They always have quirks like this. Multicast registration is not a great way to enumerate hosts on a network. The hosts have to be online for at least a while and have to be configured by some software to discover the IGMP router (your gateway device in this case) and you have to hope there is nothing on the network that might filter or alter that traffic, which the MoCA adapters might be doing in some effort to cooperate with your Verizon gateway which probably has IGMP configuration specifically setup for their own video over IP/coax services. They might be interfering out of some feature designed to save power or just are buggy and their developers broke IGMP over the moca adapters because they intend them to work independently on a network that might be running IGMP for video services over coax.

In any case, my recommendation would be for you to enjoy being able to do proper backups with the manual IP configuration of your targets. Report to the software devs that multicast is an unreliable host discovery/registration mechanism because of the complexity of home networks and the fact that a lot of home gateways might not support it at all or might subvert it for their own purposes. In business networks, IGMP is considered potentially unsafe and is either blocked/disable by default or configured for specific uses that will not necessarily work happily with their software.

If they want to use multicast, they can try out mDNS. That might work better as it is used by things like Apple airplay and other zero configuration based network services. IPv6 has its own multicast discovery service so that would probably work better too, well maybe.

To which I replied on 27 March 2019 (square-bracketed clarifications added particularly because I'm not permitted to name Retrospect in that Ars thread):

Quote

Monday night into Tuesday morning I tried [a further] test....  I successfully replaced Verizon's black coax cable from the [FiOS] ONT to the Verizon [FiOS] "gateway" with my 40-foot RG-6 cable, replaced Verizon's Ethernet cable from the ONT to the "gateway" with a 30-foot cat5e cable I happened to have lying around, and moved the "gateway" out into the central hallway of my apartment.  Then I replaced the stapled-to-the-wall cat5e cable with an across-the-floor cat5e cable from the "backup server" to the megabit Ethernet switch in my bedroom and, using a shorter cat5e cable I had lying around, I connected the "gateway" to the bedroom switch—thus bypassing the MoCA segment entirely [my emphasis].  When I moved my MacBook Pro into the bedroom and cat5e-cabled it to the switch there, I could back it up with Add Source Directly but not with Use Multicast.

I think this pretty conclusively proves that my problem is either entirely with the [Retrospect] backup software, or with the software plus something in the Netgear megabit Ethernet switch in my bedroom .  You may ask why I am ignoring the possibility of something in the "gateway"; I am doing so for historical reasons [described in the 8 February 2017 11:27 post in my Support Case #53525].  Phase I [of my -530 bugs] started on 30 January 2017 when I replaced the D-Link 100Kbps Ethernet switch in my study with a Netgear 1Mbps switch (the only one I could get at Best Buy at 8 p.m.).  At that time I didn't change the Verizon-provided "gateway", which was IIRC an Actiontec DSL "gateway" rather than a FiOS "gateway" (I didn't get FiOS until 9 October 2018).  After I had already dis-assembled the test setup in my first paragraph in this post, it occurred to me that somehow the MoCA segment could be exercising a "malign influence" even though it was downstream of my MacBook Pro "client" during the test.  However this possibility seems so unlikely that I have also ignored it.

I updated my long-running Support Case #61302 accordingly.  I also in a further Additional Note quoted the Ars Technica expert mentioning the possibility of some connection between the bug and IGMP-inhibiting firmware in both my current and old Verizon "gateways", even though the old "gateway" was strictly for DSL and didn't involve video.

[Nigel Smith]

On 3/14/2019 at 4:32 AM, DavidHertzberg said:

I don't think that will be possible for those of you who connect "client" machines to your LAN using WiFi, because it's my impression—correct me if I'm wrong—that such connections cannot be constrained to a fixed IP address.

Generally -- yes, you can use static IPs on (your own, controlled) Wi-fi connections. How you do that will depend on your router's interface (can you assign by MAC, do you "block out" a range from DHCP distribution and manually set from that range on the client, etc). Some low-end boxes may not offer the facility at all, of course...

[DavidHertzberg]

About 6 weeks ago I started getting -559 network connection timeout errors after about 2 hours while running my weekly "Sat. Backup" full backup of my MacBook Pro (the first of 3 drives plus a Favorite Folder backed up in that script).  There had not been any change in any of my software or hardware, so I guessed that at least one of my two Netgear Gbps Ethernet switches was  starting to feel its age.  I replaced both switches with non-Netgear 100Mbps switches I had lying around, and the problem went away—without slowing anything down except (moderately) the MBP's Compare phase of "Sat. Backup". 

Since NewEgg was having a US$15 sale on TP-Link 8-port Gbps switches (Heavens to Betsy, my home LAN is becoming obsolete because I'm not upgrading it to 10Gbps ), I ordered a pair of them.  Even though replacing both 100Mbps switches with the Netgear Gbps switches one at a time didn't cause the -559 problem to recur, a week ago Sunday I replaced both switches with the newly-arrived TP-Link Gbps switches.  The -559 problem still didn't recur last Saturday, so Sunday night I went into experimental mode and Deleted-Added my MBP with Use Multicast.  Both a pre-scheduled "sacrificial" "NoOp Sun.-Fri Backup" script and "real" "Sun.-Fri Backup" script failed with -530 errors when I booted my Mac Pro "backup server" machine after the time when they were scheduled to run.  I therefore Deleted-Added my MBP with Add Source Directly, and have had no further problems.

IMHO this experience proves that my -530 Bugs 1 and 2 are not caused by a "security improvement" that was made solely in Netgear's Gbps Ethernet switches.  Because I started getting -530 Bug 1 immediately after I replaced the failed D-Link 100Mbps switch in my study with a Netgear Gbps switch on 30 January 2017, without any change in my then-current Verizon DSL "gateway" router, my guess is that the "security improvement" was made to several manufacturers' Gbps Ethernet switches.  And no doubt there is a contributing factor of Retrospect's implementation of its Multicast feature failing to keep up with the "security improvement".

[DavidHertzberg]

A week and a half ago, as part of an effort to convert files on her old Digital Audio G4 left in my care in 2005 by my ex-wife—who died on 13 January 2021—to a format readable by modern computers, I moved a thumb drive created on the G4 to my 2016 MacBook Pro.  While I was painstakingly using LibreOffice on the MBP to convert each of 800 MS Word 5.1a files to the .docx format, I checkmarked the thumb drive in drives backed up for my MBP Source in Retrospect.  I immediately started getting -530 errors unless I did a Locate for the Source before or while the "sacrificial" script was running.

I then Removed and re-Added my MBP as a Source, using Add Source Directly with both the HDD and the thumb drive check-marked in the Options tab Volumes pane pop-up Selected Volumes.  The -530 errors went away.  Obviously I also re-checkmarked the MBP in the Sources tab of any scripts intended to back it up.

In 2019 I'd Added the MBP with Add Source Directly, but it seems just altering the Options tab Volumes pane pop-up Selected Volumes made Retrospect Mac 16.6 re-Add it sneakily with Use Multicast.  I'll file a new Support Case, or add this as an Additional Note for my long-running Support Case #61302.