Connection log for gdms.cloud or https://acs.gdms.cloud


#1

TL;DR: Is there a log for gdms.cloud that we can use to check if the phones are even trying to connect?

We have a customer with two sites, A and B. Site A has 4 GXP2140 phones and site B has three. Previously, they were running firmware 1.9 or something (1.0.9? I can’t remember - it had a 9 in it). For various reasons, we were using our old provisioning server that sent XML data with P codes in it and that worked fine. Now, we wanted to move these phones to gdms.cloud and needed a procedure that could be followed remotely in the field by the customer, as this is a hosted customer and we can’t just send someone on-site to do the work.

We developed a procedure that worked perfectly in our lab and worked fine on the phones at location A. It also worked fine on one phone in location B. But the other two phones in location B never seem to connect to https://acs.gdms.cloud and are showing as “Provisioning” in the web interface.

What we need is a log that shows whether or not those two phones have even tried to connect to the ACS server or not. There does not seem to be anything like that. We’ve confirmed that MAC addresses and serial numbers are correct, and since the other phones all worked properly, we need to be able to diagnose why the remaining two did not work, without having any networking or IT support on-site. This is a “simple hosted customer” with no real technical knowledge, so we need to be able to say “log in to the phone web interface and type XXX into field YYY.”


#2

I don’t know all the steps you have taken but, almost certainly you need to factory reset the phone. Even if I enter all the info into the phone directly or update with pcodes to try and get the phone connected to GDMS. I couldn’t do it.

Factory reset worked 100% of the time and is now part of my procdoc.


#3

Yes, step one of the process was to factory reset the phones. No P-codes were used to try to get the phones to connect. They were previously all running 1.0.9.102. Our procedure (which was not created specifically for this customer, and has worked elsewhere as well) worked on 5 of their 7 phones. The remaining two should have started in the exact same state as the first 5, and were factory reset just like the others, including one at that specific location (which means the person following our instructions got it right the first time).

What I want it a gdms connection log to see if the phones are even trying to connect. That will at least let us point the finger at the phone, the customer’s network, or similar site-specific problems. If they are making connections, but not downloading their configs, then that points us towards something else.


#4

Sorry, I should have just answered the question. No. There are no logs. At least none that I have access to or have ever found.

My mind went right to the factory reset because of the number of times I’ve simply had to double check the firmware had actually updated, seems to fail frequently when going from firmware that is not compatible with GDMS to firmware that is compatible. If the firmware is correct then factory reset. I had to factory reset some phones 3 or 4 times to get them to connect but, it sounds like you are seeing the green dot showing they are connected. They just are not loading up correctly.

Is that accurate?


#5

No green dot. Just spinning “Provisionining” (which is not useful). Here’s what’s happened thus far, since I know you want to helpful and try to solve the problem. :slight_smile:

  1. Phones factory reset (mainly to reset admin password so they can log in locally)
  2. User asked to login as admin/admin and change password to admin2, just to get past the prompt
  3. User asked to go to TR-069 page on phone GUI
  4. User asked to enter https://acs.gdms.cloud in ACL URL field
  5. User asked to click Save and Apply at the bottom
  6. User asked to wait while phone reboots, gets its first info from GDMS, and then we pushed new firmware (1.0.11.39) and final programming

Again, this procedure worked great for all but the last two phones. We’ve asked them to start with the procedure from the top again, including factory resetting the phone, but they’re minimally staffed and busy, so they haven’t had time to do this part yet. Luckily, the one phone at location B that is working is the boss’s phone, so he’s happy. :slight_smile:


#6

We may have a solution. Stand by while things get tested…


#7

You really shouldn’t need to have the user login at all.

If the mac and SN have been added to GDMS. Factory reset the phone. If there’s no green light, the phone is not fundamentally connecting. The green light is only used to indicated the phone is communicating with GDMS and, unlike the UCM, does not indicate if the account is registered.


#8

You are incorrect. Firmware 1.0.9.102 does not have the ACS URL filled in after factory reset. So yes, someone needs to log in to put that information in the field.


#9

After a significant amount of embarassment from our customer, they admitted that when they printed our two-page instructions to take to where the phones are, they only took one page. It is was the second page that said “go to the TR-069 section and enter blah blah blah.”

So, completely user-based error.

However, that does not mean that it is not a good idea to have some sort of ability to see if connections are even been made from a device that you own from within the GDMS web interface.


#10

Dear user,

Thank you for using the GDMS platform! As costwisewpg claimed, if the device is using the recommended firmware version, factory reset the device can resolve the connection issue of the device in the GDMS platform. If the device has never been connected to the GDMS platform, we cannot check the reason of the issue from the GDMS background server side, and we may need the user to capture the trace file and syslog from the device Web UI so that we can address the issue. For GXP21xx devices, you may ask the user to upgrade the device to 1.0.11.39 and factory reset the device. If this issue still cannot be resolved, you may ask the user to capture the logs from device Web UI and send to us for troubleshooting. Thanks for your testing!

Thank you!


#11

Yes, we’re very aware of how GDMS works, what firmware is required, and other issues. As we wrote previously, in the end this was user error.

HOWEVER, it would still be absolutely wonderful to be able to access the raw HTTPS request logs for devices we own so see if they’re connecting, where they’re connecting from, what firmware version is in use, etc. This would be a very useful diagnostic tool for people (like us) who can’t get packet traces from remote phones because we don’t have staff in those locations that know how to do it. Asking users who are low-level employees without much technical skills and do not know what “IP address” means to do packet traces is not an option.


#12

Dear user,

Thanks for your feedback! This is indeed a nice suggestion for the GDMS platform. I will pass this suggestion to our GDMS platform development team for evaluation. Thanks for your testing!

Thank you!