Our deployments became not activated after enabling a second Ethernet interface

Our deployments became not activated after enabling a second Ethernet interface. I was able to re-activate them by resetting the hardware lock using the portal. I now only have one “Zend Reset” remaining for each deployment and the IP address will change at least one more time before moving the deployments into production next weekend.

It really makes me nervous not knowing what will cause a deployment to become not activated and only having one “Zend Reset” available for each deployment. Does anyone know what the zend using to create the hash that’s used? Or who I can contact to get the “Zend Reset” increased?

I have been using using FreePBX/Asterisk in one form or another for 12 or more years. These are my first deployments using commercial modules and I’m not liking it much.

Changing a IP address wont cause that. Changing the MAC address will meaning adding a new interface deactivates the license as the hardware has changed and the license is locked to your hardware.

Even we do not know 100% what will cause the hardware lock to change. This is part of Zend Guard software that is used to protect PHP code and license it.


Thanks for the reply. I have a Sangoma 300B with 5 interfaces. I activated the deployment having only ETH4 (the green port) enabled. Recently I also enabled ETH2 to connect to another network with no hardware changes. Enabling ETH2 resulted in the deployment no longer being activated following a reboot.

The Perhaps Zend uses the first active MAC? So it seems Zend is also locking us to using a specific MAC address(es).

I feel a little bit better now… Thank you for your time.

Yes this is correct.

Zend locks to whichever interface is used when it registers with our license server. Meaning if you enable a new interface it should not be the interface that has the gateway on it used to reach outside your network or the zend ID will change.

1 Like

The interface being a gateway does not seem to matter. When I enabled ETH2 I did not add a gateway for that interface. I suspect that if I enable eth3 Zend would be okay, but if I enabled eth0 or eth1 I would need to re-activate. I suppose that Zend could be using the MACs all of the active interfaces in its hash.

Here is my routing table :
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.x.1.0 * U 0 0 0 eth4
x.x.0.0 * U 0 0 0 eth2
link-local * U 1004 0 0 eth2
link-local * U 1006 0 0 eth4
default x.x.1.1 UG 0 0 0 eth4

ya they could be doing that. Again they are very closed lipped on that due to the nature of their business and what the product is used for.

I have a machine which about 50% of the time after a reset losses it’s license. But for some reason I can go to the site to request a reset and it always works… Hate to say it but I suspect Zend is highly buggy…

What do you mean a reset?

Reboot, ie nothing special at all.

What do you mean by this. Which site.

Portal.schmoozecom.com login
edit the appropriate deployment (and at one point I ended up accidently changing the deployment number for the same machine),
Reset Hardware Lock

It will allow me to go beyond the 2 ZEND resets, by special request which seems to be automated. I’ve been talking about moving to new hardware and have always been terrified to do so because if suddenly I can’t license it won’t be pretty. If you want we can probably schedule to do a restart or 2-3 in the evening here one day which is day time there which is probably pretty convenient for you guys:-)

As a note this machine has a total of 5 NICs. One build into the server (an old HP server), and a Intel NIC with 4 additional interfaces on it. I have never had this problem with any other freepbx server as mine but all of them are a little more sane in terms of their network interfaces.

Just for reference. I just installed the new kernel patch, and my PBX lost it’s registration status. Re-Activated and hopefully all is good but for some reason it immediately (even before a reboot) lost activation!

I am having a similar problem. I created the Deployment ID when setting the machine up in the lab, using the built-in ethernet port, although there was an additional 4-port card installed, to be used in production. However, with no hardware changes whatsoever, just plugging a network cable into one of the other ports as I was moving to the production location causes the deactivation. This seems to be the same thing that happened to James Ronald.

This would seem like a common scenario: multi-port machine for multiple subnets, set up in the lab using just one of the ports, and then moved to where those subnets are. Is it really by design that this deactivates the installation?

Even if Zend does not want to give all the details of the Zend Guard Zend Host ID, there must be some understanding of the kinds of changes that will and will not cause deactivation. Could that list of changes that will and will not cause deactivation be posted somewhere publicly?

I’m not sure why people keep opening years old threads. The Deployment IDs are tied to MAC addresses of the interface. So you can use the same machine with the same interface. VMs can allow you to assign MACs as well so in theory you can move a Deployment ID between VM instances and use the same MAC.

So you are free to change your IPs, subnets on the interface you activated on. Change interfaces you need to move the deployment iid

Sorry. We don’t know this.

One would think. However, based on my experience and that of James Ronald, the deployment can deactivate even without changing any MACs, or any other hardware for that matter.

I added to this older thread because this problem is not yet fixed, and I didn’t want to scatter information about the same problem onto different threads. However, I have been doing more investigation, and have posted my findings on a new thread: Plugging a network cable into FreePBX causes deactivation

Thanks again for your comments.

This problem will never be fixed with send guard