R4.4 breaks wan management and ACS management

Hello,

Just upgraded a large number of r201 and r201p to latest cnPilot-R201P_4.4-R6_201807271638

Once upgraded wan management no longer reponds even though DBID_LAN_LOGIN_ONLY=0 and  webWebRemoteLegalIP contains our IP addresses

This worked fine in 4.3.4r8 then upgrde to 4.4-R6 snd 210 devices can't be managed now.

cNMaestro is also stuck "running job" with no way to abort/stop it (3 devices remaining for 3 hours)

How do you suggest we go about restoring WAN management?

Tim

Hi Tim,

We tried in our lab, remote WAN management UI access works fine after upgrading from 4.3.4-R8 to 4.4-R6.

For security reasons in 4.4-R6, by default remote UI access is enabled only via https (mentioned in 4.4 Release note as well). Can you please try accessing the device UI via https.

If needed you can enable remote UI access via both "http & https" (Administration->Management->Web Access->Web Access Protocol->http&https). But by default it is only "https" in 4.4 release.

Please send config file from one of your device and screenshot of "Administration->Management" page, if above recommendation doesn't solve your issue.

Thanks,

Divakar

Hi 

Please send the cnMaestro version details.   

Note: We have provided an abort job option in the software update jobs from cnMaestro 1.6.3 release onwards to avoid the device upgrade stuck issues.

Regards,

Niraj

Hello,

This also broke all of our dual WAN (two tagged vlans) configs for some reason. Re: https only, if the web port is set to 8080 I can't seem to ssh to it. Something in our config must break the config. When I'm done visiting sites today I'll send you our configs. Downgraded to 4.3.4r8 restored wan management. Factory defaulting router and resetting it up also seems to have worked.

Tim


@Timothy Alexander wrote:

Hello,

This also broke all of our dual WAN (two tagged vlans) configs for some reason. Re: https only, if the web port is set to 8080 I can't seem to ssh to it. Something in our config must break the config. When I'm done visiting sites today I'll send you our configs. Downgraded to 4.3.4r8 restored wan management. Factory defaulting router and resetting it up also seems to have worked.

Tim


Tim, I have the same experience and an open ticket being worked on. Upgrading broke any VLAN setup... defaulting the router and re-provisioning fixed it.

I requested (again) an option to "default and sync" routers from cnMaestro. This would solve the current problem, and several other past problems.

-Chris

Hi 

Please send the configuration of the device and step to replicate this behavior (Email Id: niraj.mahapatra@cambiumnetworks.com).

Regards

Niraj


@uberdome wrote:

@Timothy Alexander wrote:

Hello,

This also broke all of our dual WAN (two tagged vlans) configs for some reason. Re: https only, if the web port is set to 8080 I can't seem to ssh to it. Something in our config must break the config. When I'm done visiting sites today I'll send you our configs. Downgraded to 4.3.4r8 restored wan management. Factory defaulting router and resetting it up also seems to have worked.

Tim


Tim, I have the same experience and an open ticket being worked on. Upgrading broke any VLAN setup... defaulting the router and re-provisioning fixed it.

I requested (again) an option to "default and sync" routers from cnMaestro. This would solve the current problem, and several other past problems.

-Chris


you sort of can and we are going to do this method to upgrade ours reading everyone's issue and we have to make a bulk change to our provision and upgrade path because they don't re-check the firmware upgrade file. 

if you save the config files from them,  save them in an HTTP directory they can reach later. name it as the mac addres.cfg of the routers config. 

set a generic config file to be issues by DHCP option 66  Cambium-cnPilot-R.cfg 

in this config include 

WebRemoteLegalIP= your access IP here
DBID_SUPER_WEB_PASSWORD=your web gui passwordhere

Password=your web gui passwordhere
DBID_LAN_LOGIN_ONLY=0

wireless_access_web=1

DBID_PRV_CONFIGFILE=$(PN).cfg

the unit will reboot and then grab a partnumber specific config file

cnPilot R201P.cfg

cnPilot R201.cfg 

and so on. 

in this config tag these commands

DBID_PRV_CONFIGFILE=(your config file location)$(MA).cfg
DBID_UPGRADE_RULE=http://yourwebsite/CNPilots/cnPilot-R200P_current.bin

they will upgrade to the newest firmware in the default state and grab your config after they reboot. 

this will give you the result your after.....    not the easiest setup, but will also stop people from hitting the factory reset button then calling to complain the service isn't working.    we've been using this method to provision all of our routers and make new ones ready out of the box so nothing gets field configured. drop and go. 

I think the reason that uberdome suggested this is that if it pulls current config then factory default router, upload new firmware, then "pull" the config (with any changes cnMaestro would need to make to maintain inter-firmware compatability)

Simple provisioning from factory default setup, I belive we both do. I've got generic configs which pull down via option66 or via acs (or both, in my case.)

Tim

I am using cnMaestro for provisioning. Perhaps this is just not the most efficient or effective? 

Either way, I think the cnMaestro tool should be improved with this functionality. If we are going to be actually told to default units and then push configurations... the software should have that functionality integrated.

Separately from that need, do you guys have specific reasons for running your own provisioning server instead of using cnMaestro?

1 Like

cnMaestro does need a big update for R type routers. There's no reason we shouldn't have all the config options available in a simple configuration option just like the E series.

Router config is really bad right now. 

Or they should put out a firmware that "defaults" the router, then re-applies the config, because defaulting the router also fixes other problems, like the wifi calling problems.

Hi all,

we are facing this issue too with nearly the same configuration: 3 WAN interfaces with different vlan tag (for internet access, management and voip).

If we update by accessing from management interface  (from an older than 4.3 fw), the firs stept (the one to update the bootloader) already briks the router. We loose remote access (ping stops too). Locally it's still accessible but two of the three interfaces disappear (internet and voice). Management is still present but now inaccessible from aour management servers.

After this has been observerd, we tried to update (just to test) locally some devices, but this time the behaviour is slightly different: while upgrading, the router hangs with power led blinking indefinitely and even after power cycling it, it is not accessible and pingable in lan too (tried http, https, and ping). It needs to be resetted and configured again.

There is obviously something weird with this fw and multiple WAN interfaces and VLANs.

I'm going to open a ticket with support for this.

Kind regards

Rocco

Hi Rocco,

Please open a  support ticket and provide your Multiwan VLAN  configuration to replicate this issue.

Regards

Niraj 


@roccoptr wrote:

Hi all,

we are facing this issue too with nearly the same configuration: 3 WAN interfaces with different vlan tag (for internet access, management and voip).

If we update by accessing from management interface  (from an older than 4.3 fw), the firs stept (the one to update the bootloader) already briks the router. We loose remote access (ping stops too). Locally it's still accessible but two of the three interfaces disappear (internet and voice). Management is still present but now inaccessible from aour management servers.

After this has been observerd, we tried to update (just to test) locally some devices, but this time the behaviour is slightly different: while upgrading, the router hangs with power led blinking indefinitely and even after power cycling it, it is not accessible and pingable in lan too (tried http, https, and ping). It needs to be resetted and configured again.

There is obviously something weird with this fw and multiple WAN interfaces and VLANs.

I'm going to open a ticket with support for this.

Kind regards

Rocco


As a work around, follow the steps i posted on page 1.   We've used that method with no problems.  Hopefully a fix will be available soon so they can be updated normally. 

Although the work-around shared appears to solve the specific immediate problem, I still think a default+sync option is important for cnMasetro. The methods shared here overwrite / merge configs, so if there was an error in a configuration, or an old variable that is no longer used, those old variables and errors would remain. 

For example, until recently, we were always able to use the same configurations for R200 and R190V routers. When the WiFi calling issue came up, it was temporarily resolved by changing a variable (that was apparently only used for the R200 configurations). We pushed this variable to R200 and R190V routers treating them as the same. This was a mistake and broke NAT functionality on the R190V. This could not be resolved by just pushing a new configuration, because the variable needed to be removed entirely from the R190V. 

There weren't many R190V routers in our system at the time, so manually defaulting each one was not unreasonable... but it would have been much nicer to have a start-over sort of option.

1 Like

Hi All,

The new updated image will shortly be available for Multiwan scenario issues. Please do not upgrade to the 4.4-R6 image in R-Series, whoever is using MultiWan scenarios networks.

Please send an email if you have any queries(Email id:niraj.mahapatra@cambiumnetworks.com or support@cambiumnetworks.com).

Regards,

Niraj

I e-mailed you a config which breaks WAN management. Same settings on R4.3.4r8 works fine

This is a single WAN/no vlan tagging config.

Tim

Hi Tim,

 

Thanks for sharing the information and we will check this behavior.

I have shared a test image for this issue, Please verify the image and provide your valuable observation.

 

Regards

Niraj

 Hi Tim,

This behavior is not related to Multiwan configuration issue.

You are not able to access the device remotely because, by default,  HTTP service is disabled in 4.4 release  OR  HTTP service is disabled after upgrading 4.3.4-R8 to 4.4 images.

After upgrading to 4.4 release, User/Admin can push/upload the below configuration to enable the HTTP and HTTPS service for remote  GUI access.

“way_access_web=http&https”

Is it not safe to leave http enabled, but have it redirect all traffic to https immediately? That seems to be the least impactful solution for this issue.