Jump to content
maxhowarth

error 530. the gift that keeps on giving.

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×