Registration for deployment resetting on every reboot After upgrading to Freepbx 17 and debian 12

Commercial Modules
1

After upgrading succesfully many installs, one with commercial modules (sysetm admin enabled) is having a rare bug.
Deployment id is deavtivated on old system, reactivated in new one, and after a reboot or shutdown, every time system gets deactivated and no deployment is enabled…
System is a virtualized debian 12 with freepbx17 based on official scripts, all is working perfect, all modules and apt upgrade until today.
Mac addresses and ip is fixed not random or dhcp, virtual net driver was tested on vmxnet3 and e1000 with same results, deployment gets deactivated every reboot.}
What could it be?
Best regards

2

My deployment goes through Sangoma portal for activation and I had to do a “hardware reset” at the portal

3

yes, thats the normal procedure but keeps resetting…

4

You need to contact support. We can’t really tell you why this is happening.

5

sangoma support send to the community forum xD…which other support exist for commercial modules?

6

@kgupta @mwhite @penguinpbx

What is up with this? Why would Sangoma Support send someone to the community forums to solve why activation keeps getting reset? How is the community expect to provide support for this? It’s not OSS and is 100% a commercial thing.

7

Hey

If you are losing the activation then potential reason could be that, you might have two(or multiple) network interfaces in your system.

Freepbx uses the MAC address of the default route associated interface based on “ip route” output…

For example -

  1. ETH1 with mac ABC and ETH2 with mac DEF
  2. on first boot or on first time activation - Default route is associated with ETH1 (ip route) then Freepbx will use ABC to register the deployment.
  3. now, on second boot, default route change to ETH2 (ip route) then Freepbx will find that this deployment is already registered with another MAC (i.e. ABC) so it will ask you to reset the hardware.
  4. now again on further reboot , if default route gets change then the same cycle i.e. hardware reset needs to repeat.

Now, default route can change if this is something controlled by DHCP or some other dynamic Networking settings.

Request you to please check your interface/routes settings and try to have one default route for one dedicated interface.

We have discovered this recently on Debian with v17 so we will look into this to find more robust solution. v16 functionality wise also working in the same way but seems no one has tried such combination of default route with interfaces with v16 so we did not caught such scenario so far.

also @fmvillares please DM me your support case so I can try to check that internally.

Best Regards
Kapil

1 Like
8

thanx for the reply, the issue was an automated dhcp misconfig in debian that brings up 2 default routes at the same time.deleting the wrong one seems to be the solution.

Best regards

9

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.