Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Russell_W
Participant

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

Jump to solution

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!

0 Kudos
1 Solution

Accepted Solutions
Greg_Harbers
Contributor

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...

 

 

View solution in original post

(1)
12 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
Russell_W
Participant

@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 🙂

0 Kudos
Naama_Specktor
Employee
Employee

@Russell_W  thanks!

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

0 Kudos
Greg_Harbers
Contributor

Hi Naama, 

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

Regards

Greg

0 Kudos
Naama_Specktor
Employee
Employee

@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 

0 Kudos
G_W_Albrecht
Legend
Legend

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.

CCSE CCTE SMB Specialist
0 Kudos
FGA_Sys_And_Net
Explorer

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
Legend
Legend

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

CCSE CCTE SMB Specialist
0 Kudos
Greg_Harbers
Contributor

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...

 

 

(1)
Russell_W
Participant

@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

 

0 Kudos
Greg_Harbers
Contributor

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
Participant

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.

0 Kudos