Reply
New Member
Posts: 25
Registered: ‎11-16-2017
Kudos: 4

Re: [USG] Firmware v4.4.36 now available

I´ll upgrade tonight from 4.4.32dev.5134342 and hope that it will work. Since the FW 4.4.29, I have to say, that I hate FW-Updates...

 

I give feedback asap.

 

Brgrds

New Member
Posts: 24
Registered: ‎03-11-2017
Kudos: 24
Solutions: 1

Re: [USG] Firmware v4.4.36 now available


@driftninja wrote:

 @UBNT-cmb

 

On a USG from remote location from the controller, the USG will get stuck on "Provisioning". Same issue from 4.4.29. Have to roll back to 4.4.18. I have a "Site to Site" VPN with multiple USGs. The main USG4 where the controller lives will update fine to 4.4.34. When trying to update the remote USG3 and USG4s, It will get stuck on provisioning and send a Commit Error due to overlapping DHCP networks. This is when updating from the interface. This happens on just firware 4.4.29 and now 4.4.34, all other past firmwares will update fine. I have just SSH updated one of the remote sites with 4.4.36 and same issue. Reboot loop after a minute or 2. I updated the Local USG4 and no issues. Errors logged. 

 

 configuration commit error. Error message: { "COMMIT" : { "error" : "￾[ service radius-server ]\nStopping FreeRADIUS daemon: freeradius.\nStarting FreeRADIUS daemon: freeradius.\n\n￿1\n￾[ interfaces ethernet eth2 dhcp-options ]\nRenewing DHCP lease on eth2 ...\n\n￿1\n￾[ service dhcp-server ]\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nDHCP server configuration commit aborted due to error(s).\n\n￿0\nCommit failed\n" , "failure" : "1" , "success" : "1"} , "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "12a9e517d7394b506d9c713448" , "SET" : { "failure" : "0" , "success" : "1"}}

 

then a minute later

 

configuration commit error. Error message: { "COMMIT" : { "error" : "￾[ service dhcp-server ]\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nDHCP server configuration commit aborted due to error(s).\n\n￿0\nCommit failed\n" , "failure" : "1" , "success" : "1"} , "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "12a9e517d7394b506d9c713448" , "SET" : { "failure" : "0" , "success" : "1"}}

 

Currently stuck on Provisioning. Still able to ping the USG3 and will be downgrading back to 4.4.18. 

 

Any ideas here? I feel like the tunnel is the issue, but quite scared to remove the tunnel and upgrade hoping the upgrade will work. 

 


The only time I've seen overlapping dhcp range errors on commit it was because I had custom settings in config.gateway.json for one of the dhcp subnets, and the upgrade changed the name of the subnet in the config, so now my custom setting in config.gateway.json was creating a new, separate dhcp server subnet with the same ip range as the renamed range in the config.  As an example of what I'm talking about, this is in my config.gateway.json:

 

{
        "service": {
                "dhcp-server": {
                        "shared-network-name": {
				"net_nc_dmz_eth1_172.31.255.0-24": {
					"subnet": {
						"172.31.255.0/24": {
							"static-route": {
								"destination-subnet": "172.31.0.0/16",
								"router": "172.31.255.254"
							}
						}
					}
                                }
			}
		}
	}
}

The important part of the above code is the name of the dhcp subnet:

"net_nc_dmz_eth1_172.31.255.0-24"

I've found that it sometimes changes on upgrade.  It was only a few releases back that they added _eth1 to the name for example.  Anyway, if they changed the name, and you have the old name in your config.gateway.json, you get the error you referenced.  You need to move the config.gateway.json aside, do the upgrade, log into the gateway, find out how the name changed, updated the name in your config.gateway.json, put the config.gateway.json back in place, then do a force provision to get your custom changes applied again.

Emerging Member
Posts: 71
Registered: ‎12-02-2016
Kudos: 8

Re: [USG] Firmware v4.4.36 now available

[ Edited ]

Just an FYI I have had no issues since installing this update (about 7 days on it without any issues). I do not have GEOIP on as it has not worked properly any time I have tried using it.

 

I have IPS enabled, I have on one network a USG pro 4, 1 24port 250W switch, 3 8 poe 150w switches, 3 AP HD, ` ACAP Pro wireless access point. (I also have not on this controller being they are different but a few powerbeams to connect offices with wifi that work great. SO far so good.  I was really hesitent to upgrade form 4.4.29 to this as the previous to 4.4.29 was crap for my setup and kept crashing things.

New Member
Posts: 3
Registered: ‎11-30-2016
Kudos: 7

Re: [USG] Firmware v4.4.36 now available

Installed on 2 sites brandnew USG3 behind draytect Vigor 130 VDSL-modems.
Had difficulties to adopt them. Upgraded them via ssh to 4.4.36 . Since that one of them is continiously cycling through between 'offline' and 'adopting'.
Several times I resetted them to factory defaults and went through the whole adoptionprocess - no change...

New Member
Posts: 34
Registered: ‎10-12-2016
Kudos: 8
Solutions: 2

Re: [USG] Firmware v4.4.36 now available

[ Edited ]

ATTN everyone with "DISCONNECTED" USG post upgrade! I know this isn't the most ideal solution - when in fact it is a band-aid solution - but I invite you to follow these three simple steps and spare yourselves the Disconnected device the next time you upgrade:

 

 

Prevent Upgrade Problems, Avoid Device Disconnection and Inform errors

 

 

P.S. This won't work on Firmware v4.4.36 when GeoIP is enabled.

My Equipment:
CK Gen1, USG 3P, USG 4P, US-8-150W, US-16-150W, US-24-500W, AP-AC-Lite, AP-AC-LR, AP-AC-PRO, ERLite-3, ERPoe-5, ES-5XP, ES-8XP
UVC-NVR, UVC-Micro, UVC-Dome, UVC-Pro
mFi Switch, mFi mPort, mFi mPower, Temperature Sensor, Current Sensor, Wall Mount Motion Sensor
New Member
Posts: 5
Registered: ‎08-08-2016

Re: [USG] Firmware v4.4.36 now available

@gdledford1069

 

Thank you for the info. Im not using a edited config.gateway.json. I have taken a USG and just plugged it in locally and updated it just fine. Theres got to be something going on with the USG seeing the Site to Site DHCP ranges and causing a issue. Im gonna keep digging. Im gathering the nerve to drop the tunnel and try to upgrade. If it fails then its gonna hurt. 

New Member
Posts: 2
Registered: ‎08-19-2018
Kudos: 1

Re: [USG] Firmware v4.4.36 now available

Be careful as this update wiped out all my IP settings.  I had to go back to factory default and start over.  When I hit update I wasn't expecting to spend my afternoon and evening redoing my network.  Not pleased with this update.  No other update did this.  Also, restoring from backup didn't restore IP addressing.

New Member
Posts: 12
Registered: ‎09-22-2013

Re: [USG] Firmware v4.4.36 now available

GeoIP : never enabled it.

Still had certificate / no WAN issue on guest network.

 

Just forget this alpha "release" ...

New Member
Posts: 5
Registered: ‎08-08-2016

Re: [USG] Firmware v4.4.36 now available

[ Edited ]

@gdledford1069 wrote:

@driftninja wrote:

 @UBNT-cmb

 

On a USG from remote location from the controller, the USG will get stuck on "Provisioning". Same issue from 4.4.29. Have to roll back to 4.4.18. I have a "Site to Site" VPN with multiple USGs. The main USG4 where the controller lives will update fine to 4.4.34. When trying to update the remote USG3 and USG4s, It will get stuck on provisioning and send a Commit Error due to overlapping DHCP networks. This is when updating from the interface. This happens on just firware 4.4.29 and now 4.4.34, all other past firmwares will update fine. I have just SSH updated one of the remote sites with 4.4.36 and same issue. Reboot loop after a minute or 2. I updated the Local USG4 and no issues. Errors logged. 

 

 configuration commit error. Error message: { "COMMIT" : { "error" : "￾[ service radius-server ]\nStopping FreeRADIUS daemon: freeradius.\nStarting FreeRADIUS daemon: freeradius.\n\n￿1\n￾[ interfaces ethernet eth2 dhcp-options ]\nRenewing DHCP lease on eth2 ...\n\n￿1\n￾[ service dhcp-server ]\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nDHCP server configuration commit aborted due to error(s).\n\n￿0\nCommit failed\n" , "failure" : "1" , "success" : "1"} , "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "12a9e517d7394b506d9c713448" , "SET" : { "failure" : "0" , "success" : "1"}}

 

then a minute later

 

configuration commit error. Error message: { "COMMIT" : { "error" : "￾[ service dhcp-server ]\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nConflicting subnet ranges: 172.16.64.0/24 overlaps 172.16.64.0/24\nDHCP server configuration commit aborted due to error(s).\n\n￿0\nCommit failed\n" , "failure" : "1" , "success" : "1"} , "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "12a9e517d7394b506d9c713448" , "SET" : { "failure" : "0" , "success" : "1"}}

 

Currently stuck on Provisioning. Still able to ping the USG3 and will be downgrading back to 4.4.18. 

 

Any ideas here? I feel like the tunnel is the issue, but quite scared to remove the tunnel and upgrade hoping the upgrade will work. 

 


The only time I've seen overlapping dhcp range errors on commit it was because I had custom settings in config.gateway.json for one of the dhcp subnets, and the upgrade changed the name of the subnet in the config, so now my custom setting in config.gateway.json was creating a new, separate dhcp server subnet with the same ip range as the renamed range in the config.  As an example of what I'm talking about, this is in my config.gateway.json:

 

{
        "service": {
                "dhcp-server": {
                        "shared-network-name": {
				"net_nc_dmz_eth1_172.31.255.0-24": {
					"subnet": {
						"172.31.255.0/24": {
							"static-route": {
								"destination-subnet": "172.31.0.0/16",
								"router": "172.31.255.254"
							}
						}
					}
                                }
			}
		}
	}
}

The important part of the above code is the name of the dhcp subnet:

"net_nc_dmz_eth1_172.31.255.0-24"

I've found that it sometimes changes on upgrade.  It was only a few releases back that they added _eth1 to the name for example.  Anyway, if they changed the name, and you have the old name in your config.gateway.json, you get the error you referenced.  You need to move the config.gateway.json aside, do the upgrade, log into the gateway, find out how the name changed, updated the name in your config.gateway.json, put the config.gateway.json back in place, then do a force provision to get your custom changes applied again.


You are spot on here. I looked at the config.gateway.json of a 4.4.29 USG and found it does use the eth1 addition. The USG that im trying to update from 4.4.18 to 4.4.36 has duplicate DHCP entrys. Its trying to add a "net_LAN_eth1" and there is also a "_LAN_" with the same scope. Problem is, I dont use a config.gateway.json. I did at one point a while back. I am wondering if it is just not reverting back to default. Ive tried to reboot the controller, and USGs to loose the old config but its stuck in there. I have also replaced the USG3 with a USG4 at one location also, long after i removed the config.gateway.json and it is still getting the old config from somewhere. 

 

Thanks for pointing me in the correct direction. Ill do some more diggin. 

 

 

New Member
Posts: 11
Registered: ‎09-21-2017
Kudos: 2

Re: [USG] Firmware v4.4.36 now available

Upgraded USG3 to 4.4.36 along with AP and Switch to 4.0.10 on Friday and been solid over the weekend. Man Happy

New Member
Posts: 5
Registered: ‎10-30-2014

Re: [USG] Firmware v4.4.36 now available

Upgraded USG to 4.4.36 (as well as APs and switches to latest) in one hit. So far, had a couple of up/down WAN events post upgrade and then no issues sice

 

Enabled IDS feature and no CPU spikes or USG crashes that were a problem with previous release.

 

So far, so good. Great release.

New Member
Posts: 31
Registered: ‎06-22-2018
Kudos: 11
Solutions: 1

Re: [USG] Firmware v4.4.36 now available

After updating my USG-3 Pro to the latest firmware it seems that port forward logging no longer works. I used to be able to see syslog entries with WAN_IN-3000 identifiers when going through the firewall with a port forward rule. But that seems to have stopped working for a UDP protocol rule but still works for a TCP protocol rule. This is a bit of a nuisance since I use syslog to monitor access from outside world. Jan
New Member
Posts: 31
Registered: ‎06-22-2018
Kudos: 11
Solutions: 1

Re: [USG] Firmware v4.4.36 now available

I was able to get the logging to work again after disabling IPS blocking of P2P traffic. My UDP forward rule was used for OpenVPN to an internal OpenVPN server. IPS did not block that traffic, as indeed it should, but for some odd reason it chose to disable logging of the port forward traffic even if I enabled logging in the port forward rule. Could anyone explain exactly what the IPS P2P rule does ? and is this to be expected based on some stretch of logic I dont understand ? Jan
New Member
Posts: 22
Registered: ‎03-26-2017
Kudos: 1

Re: [USG] Firmware v4.4.36 now available

Had been on a fairly old version of USG firmware, perhaps 4.4.18 or such but current on my UCK and UAP/USW (all release branches not dev).

 

After upgrading to the latest release for UAP/USW, my USG immediately started showing lost heartbeats intermittently and would go into an adopting/failure loop several times before recovering. Hoping this would be cured with 4.4.36, and wishing for no new problems, I rebooted my USG3, and when it returned installed 4.4.36 through the cloud key controller web interface. Went smoothly and so far, a couple days in, have not noticed any new problems. I do NOT run with GeoIP nor with IPS yet.

 

Question please: Do I need to bounce the USG one more time to complete secure boot provisioning/config? 

 

 

New Member
Posts: 1
Registered: ‎09-12-2018

Re: [USG] Firmware v4.4.36 now available

@UBNT-cmb

so this is on a new install with a little time before implementation (tomorrow now).

ran into a few issues when upgrading

ck-gen1.X (USB-C)

-devices would not get DHCP in vlan (possibly default vlan also, i cant remember)

-couldnt ping usg

-status LED was 

I had some VLANs confirgured, and devices got angry.

 

after rebooting, forgetting and readpoting, manually downgrading and upgrading again, and plenty of other manual reboots, everything works other than the LED on USG4

it will flash white when rebooting, but goes to off when running (i confirmed with help desk)

Went from older version usg fw (i believe 4.3 or .2, possibly even earlier)

 

On my home network (ck2+ usg4 and various switches) the upgrade went just fine

New Member
Posts: 25
Registered: ‎11-16-2017
Kudos: 4

Re: [USG] Firmware v4.4.36 now available

After a couple of days, I can report that the FW is running smoothly.

 

Note: Never ever turned on the GeoIP optiop. 

Emerging Member
Posts: 78
Registered: ‎05-07-2018
Kudos: 45
Solutions: 2

Re: [USG] Firmware v4.4.36 now available

Controller 5.9.29

 

After upgrading couple of sites I am getting Heartbeat Missed and then Disconnected on devices in that network.

 

An odd thing is that I will see another device in the network send multiple informs rapidly.  It almost seems like something is rewiting the other informs to some other device.

 

[2018-12-19 14:46:19,802] <inform-173> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=33, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696292
[2018-12-19 14:46:19,913] <inform-183> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=0, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696292
[2018-12-19 14:46:20,119] <inform-178> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=1, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696293
[2018-12-19 14:46:26,298] <inform-180> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=6, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696299
[2018-12-19 14:46:26,405] <inform-187> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=0, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696299
[2018-12-19 14:46:26,611] <inform-185> INFO  inform - from [fc:ec:da:b0:88:41](AP-AC-LR Basement, U7LR, 4.0.10.9653): state=CONNECTED, last_inform=0, ext/stun_ip=xx.xx.xx.xx, dev_ip=192.168.1.11, up=696299

When the Heartbeat Missed and Disconnected issues do not occur, you will see the normal mix of devices informing in the log.

 

One site with a USG-PRO-4 stopped doing this after a second reboot of the USG-PRO-4.  Another site with just a USG continues to have the issue.

New Member
Posts: 26
Registered: ‎03-09-2018
Kudos: 3

Re: [USG] Firmware v4.4.36 now available

Downgrade option went away. Running a USG 3P for 5 days after soft restart without any issues. I am running the speed test service and IPS.

Emerging Member
Posts: 93
Registered: ‎12-17-2016
Kudos: 12
Solutions: 1

Re: [USG] Firmware v4.4.36 now available

[ Edited ]

I was using this version on my USG 3P. I just got a USG Pro and upgraded it to this version out of the box. After adopting and provisioning the USG Pro, I get this with IPS enabled (I pay for a 250/10Mb connection):

 

USG-Pro-4_IPS.png

 

I'd have to say that the Christmas present to myself paid off. Now to replace the loud fans...

Ubiquiti USG PRO 4 | UniFi Switch 24 | UniFi Switch 8 | UAP-AC-M-PRO | UAP-AC-M (2) | TP-Link TL-SG108E | Synology DS718+ (UniFi Controller in Ubuntu Server VM)
New Member
Posts: 3
Registered: ‎06-04-2016
Kudos: 1

Re: [USG] Firmware v4.4.36 now available

Having some issues with my ISP/Modem and the USG since the .34 and .36 updates. 

 

https://www.reddit.com/r/Ubiquiti/comments/7726eh/unifi_security_gateway_3p_drops_connection_if/

 

This seems to describe my problem exactly, but it's from a year ago. Not sure if this was ever addressed. I pulled the USG out of frustration and am running pfSense for the time being; this is stable so far. 

 

Reply