Something seems to be not functioning in Community version (database writes)

@devangn I just booted up the other one which is functioning. While it does not have an installation date, I do have it labeled as “version 6” and one gateway in it. It appears to be the original gateway which was created with the installation as the creation date is 2016. However, it appears I had modified that one to my provider. It has a date of October 24, 2022.

If I recall correctly, this was installed after everyone was getting reports from MySQL of not having a compatible OS and you all here told everyone to select “Buster” as the OS for MySQL, and it would work out.

I then added a new gateway without issue.

This is also Debian 11 in VirtualBox using the iNextrix installer.

Something has had to of changed since October and recently.

There are two completely separate databases. There is the ASTPP database which ASTPP needs to do anything. Then there is the Freeswitch database that is used for Freeswitch internal operations, such as sip_profile, and is not specific to ASTPP. That database defaults to SQLite. I looked through the install script and it doesn’t appear to be altering that default configuration, so as far as I can tell Freeswitch will be using SQLite unless you manually change that.

I do not use the install script but It looks like it is installing Freeswitch v1.4. If that is right that is a really really really old version. I manually install Freeswich v1.10 and it works just fine. The install script should probably be updated to use a newer version of Freeswitch because v1.4 is ancient, just like the version of CodeIgnitor used.

I am aware of SQLite. However, they are using MySQL to store things including gateway info in it.

This is the version installed by their script:

FreeSWITCH version: 1.10.9-release-21-a615e85afc~64bit

I should also mention on the local VPS I have which is functioning fine, I have done no updates to it. I wonder if I should save a current snapshot then perform a OS update to see it the problem comes up.

I must have been looking at an old version of the script.

So you mean, with this setup, you are able to create new Gateway with correct and working entry in DB and FS?

As of currently. NO, I am unable to create a new gateway with no information being put into the database.

But, as mentioned, on an installation from this past October, with no updates to the system, it all functions correctly.

@devangn Bit of an update.

After paying a little more attention, this installation was done on Debian 10, not Debian 11.

There had been no updates since October 2022 on it since the installation. I ran the updates and there were a little over 300 updates. After a reboot, the ASTPP installation continues to function well.

I guess this is a Debian 11 issue.

Edit:
I just tried your iNextrix installer script with Debian 10. It now fails badly.

Maybe we need to get the community version 6 actually functioning before working on version 7?

I think I am closing down on the issue @devangn

I went back to my script which uses MariaDB and PHP7.4

Doing some testing, I was able to save a couple of fake gateways.

However, when I use my actual provider, the error appears.

I think it is related to using non alpha numeric characters. For example, the password could contain characters such as [{.,|!% and the user name also has an underscore "" in it.

When I try to use those, the save to the database fails

After doing even more testing, I have gotten closer to the problem.

Here is a password example:

C{ldxNYs0%81

It does not like that password. That what is causing the gateway informaton to not be saved

This has reminded me of another security issue with ASTPP community. Their authentication for logging into the UI is the same authentication used for SIP. So it is saved as a decryptable password. Modern UI’s since long ago use a one way hash, which is much more secure.

Back to your issue, I think SIP passwords have some limitations in what characters can be used. Or maybe that is specific to ASTPP or something the UI is limiting. I would get rid of the “{” and “%” if possible

It’s been a while since I looked, but I think there are two separate logins. One is for SIP, and the other is using customer account number,

If there was an issue with a SIP password, then we should see the password saved into the database, but being reported in the FreeSwitch log as an issue. So it tells me probably something is going on with the code writing into the database.

As for passwords, I did notice they were not hashed + seeded into the database.

The UI login for ASTPP community (admin and reseller), uses exactly the same PHP password encrypt/decrypt functions as customer SIP accounts. They use decryptable passwords and save them as such in the database. That is not a modern (as in everything in the last 10 years at least) or secure way of doing things. Doesn’t matter what version number they give it.

I just tested, and sure enough, the log in and SIP are the same. That needs to be fixed

It’s been like that since day 1 so I wouldn’t hold my breath.