SMB devices (1400 and 1500 series): SmartConsole/SCS decides they are running R80.20SP??

[Russell_W]

I have been working for a spell with some R80.20.x Gaia Embedded-running 1500 series appliances which, in SmartConsole, would spontaneously and without explanation start showing their version as R80.20SP rather than R80.20.

When this happens there is a yellow warning triangle next to the version number of the appliance in question, in the Gateways & Servers view of SmartConsole.

This appears to be cosmetic but it drives customers who are inclined to believe there is no such thing as a "cosmetic issue" a little batty.  Their management console is literally telling them "your version is wrong."  If you hover over the warning icon, the message that appears is "Version of the Security Gateway object does not match the version of the installed software on the Security Gateway."

The version on the object itself cannot be edited -- the drop down only shows the version that the product thinks it "detects."  And policy will still install, but you'll see R80.20SP for the device in the associated Install Policy Details dialog.

Were this a regular Gaia device, the version mismatch would definitely be a problem, so I can understand customer concern.

I can find no knowledge base articles or Checkmate posts discussing this, despite seeing this on 1500s and, if memory serves, their predecessor 1400s alike.  Anyone ever seen this?  Got any ideas?

Thanks!

[PhoneBoy]

This "bug" would make no sense on the 1400 series as they run R77.20 (and there is no SP version of that).
If the version is changing randomly, that's worthy of a TAC case.
My guess is this can be fixed with dbedit, though I don't know the precise steps to do that offhand.

[Russell_W]

@PhoneBoy thx for the reply and yes, when it changes it does so out of nowhere -- which I guess would qualify as "randomly." 

Going back and checking my notes we have seen this on a set of new 1500 series appliances (which replaced a set of 1400 series appliances, hence the brain fog about that) since initial install of the 1500s at R80.20.30.

We initially got rid of the problem via update to R80.20.35, but ultimately the problem came back on its own.  It went away again when we updated to R80.20.40.  Things held in proper place a little longer this time, but now the problem has returned on one of the 1500 appliances.  Based on our experience under R80.20.30 and R80.20.35, we figure that appliance won't be alone in its wrong-versioning for long.  In any case, we haven't been able to nail down what this is about, since the SW version in the DB object keeps being auto-changed by code and with no clear pattern (other than always changing it from R80.20 to R80.20SP).

@G_W_Albrecht SCS and SmartConsole versions and JHFs are current, and the issues have persisted across multiple SCS versions (originally R80.40, currently R81.10), multiple SC builds (within both R80.40 and R81.10 trains) and multiple SCS JHFs (within both R80.40 and R81.10 trains).

The issue appears to be the SMBs (plural) and/or the DB object(s), but I can't imagine DB objects (nothing more than a collection of fields and values in a DB) spontaneously "changing themselves," especially in such granular and precise fashion.  My guess would be the SMBs (plural) or some interaction issue between the SMBs (plural) and the SCS.

@Naama_Specktor we don't have a TAC case yet, but given your interest and @PhoneBoy 's reply that having the object version shift "randomly" is worthy of a TAC case, we'll open one.

Appreciate the replies.  Again, I couldn't find anything out there about this, and having chased it around for a few months I figured I'd see if it was a simple matter of my KB search skills failing.  Pretty odd 🙂

[Naama_Specktor]

@Russell_W  thanks!

if you opened a ticket to SR # , I'll appreciate it if you will share the number 🙂 

[Greg_Harbers]

Hi Naama, 

we opened a case for this almost a year ago, SR# 6-0002961150

Regards

Greg

[Naama_Specktor]

@Russell_W 

hi 🙂

my name is Naama Specktor and I am from checkpint.

I will appreacite it if you will share TAC SR # , here or in PM,

thanks!

Naama 

[G_W_Albrecht]

I have had the same issue once with SMB - i think it was version related, so update Jumbo and Dashboard of the SMS, if the issue is not resolved i would delete the SMB and define it again in Dashboard.

[FGA_Sys_And_Net]

Hello,

We had the same issue with SMB 1550 and 1600 (R80.20.40) and bellow the TAC answer:

We can solve our issue by logging in to GUIDBEDIT (make sure you have disconnected from SmartConsole to avoid lock issues )

under the "network_objects" table search for our gateway object and search for "svn_version_name" field name and change the value from "R80.20SP" to "R80.20", in some cases the value will be empty so just add the right version (in our case its R80.20)

make sure before leaving, save your changes and log off GUIDBEDIT. do not log to SmartConsole and GUIDBEDIT at the same time to avoid lock issues.

---

Case number: 6-0003232570

After an upgrade the problem reappears. So it's just a workaround.

Kind regards,

[G_W_Albrecht]

So this issue maybe will disappear with R81.10.xx firmware 😎

[Greg_Harbers · Accepted solution]

We have seen the same issue and we think we know the cause of it, and a reasonanbly reliable workaround.

If you use SmartUpdate to identify a 1500 series gateway, the version will change in SmartConsole to R80.20SP. To fix it, from Smartconsole, edit the gateway object, edit the version and reselect R80.20 as the version. In our experience this will "stick" and stay that way until you attempt to use smartupdate to upgrade the firmware of the gateway.

We were using smartupdate to upgrade multiple gateways, it worked reliably aside from changing the version in Smartconsole to R80.20SP, so after the gateway upgrade has completed we had to edit the gateway objects to reset the versions.

A TAC case was logged for this, the response we got was that SmartUpdate is not supported with the 1500s and we should use LSM, not quite applicable for our environment.

When it comes to 1500 firmware upgrade time, our choices are to use SmartUpdate knowing that we will have to edit each of the gateway objects and reset the version, or manually upgrade each gateway via the device web portal.

Roll on CDT support for SMBs...

[Russell_W]

@Greg_Harbers  -- thanks much.  This was exactly the scenario -- while I don't have this detail on the historical occurrences, for this one, a "Get Gateway Data" had been done on all gateways.  One of the 1500s got weird and the other didn't, so I didn't connect the dots.

I also hadn't tried to reset the version in the gateway object in SmartConsole, because there is only one version shown -- R80.20.  But sure enough, I went in, selected it, and despite selecting what was already there (and the only choice to boot), it rejiggled the object after hitting "OK" -- including logging an unpublished change -- and its R80.20SP reference onscreen went bye-bye.

Hopefully this will stick, but again, you definitely identified the scenario and the way to resolve it.

And yeah -- LSM is not exactly the turn-to for an SMB deployment where you only need the fingers on one hand to count the total number of appliances.  That's not a functional answer for maintaining a not-large deploy.

@Naama_Specktor, see detail in this post, and see the SR that @Greg_Harbers referenced.  The situation that prompted this thread was near-identical to what he described.  We weren't using SmartUpdate to upgrade the devices, but we did a "Get Gateway Data" on the packages tab.  On one of the 1500s (not all) -- and note that all the 1500s are running R80.20.40 -- that was apparently enough to tweak the version number on the GW object for just that one 1500.

@FGA_Sys_And_Net, and @PhoneBoy, I suspect the GuiDBEdit approach pretty much does exactly the same thing -- or at least effectively the same thing -- as what @Greg_Harbers laid out.  Net, "change the version back by hand."

Cheers and thank you all very much!

CISSP - CCSM Elite - CCTE - CCME

[Greg_Harbers]

One more bit of info...

When we first stuck this issue we were running R80.40 on the SmartCentre. We have since upgrade management to R81, the issue still exists.

[Russell_W]

We've seen the issue with the SCS on R80.40 (through JHF 139) as well as R81.10 (through JHF 45), so right there with you.

[G_W_Albrecht]

Seems to me that this is caused by the fading out of legacy SmartUpdate 😎

[PhoneBoy]

SmartConsole will support upgrading the firmware for 1500s directly in R81.20.
I believe this is only supported with R80.20.40 and above firmware.
No legacy SmartUpdate required there 🙂 

[TJ_Aus]

Hello. 
We have had similar issues including this one in the past since we first started using the 1500s. After some work I found you could just re-select the version in the gateway object and then push policy as Greg already mentioned (even though it already has R80.20 selected). Management servers are R80.40 JHFA 158
I had raised a case for it back in 2020 and when I found the workaround, our engineer created a KB article for it. I have found our engineer's e-mail trail but not the article (I do have the service request)
This still occurs on R80.20.40, especially after adding a new 1500 gateway (never seen the issue on the 1400s)

I found you can get this to occur every time if you go into the old "Manage Licenses and Packages" GUI  (Checkpoint SmartUpdate) and select the gateway and chose "Get Gateway Data". Then you go back into the Smart Console Gateways & Servers view and the version will be missing. Sometimes it would have R80.20SP

Here is one of our gateways before I just did the above in bold now (I have rubbed out the name and IP address)

Now after:

However the gateway object still shows R80.20

[Alon_Alapi]

Hi,

Thank you for reporting this.

We are investigating the issue.

I will keep the thread updated on our findings. 

Alon

[TJ_Aus]

Hello. Is this the issue that will be fixed soon in a pending JHFA as per PRJ-41127, PMTR-85721?