"Connection request error: Incorrect connection request credentials" on factory reset

I’m having a problem where attempting to summon a device in the GenieACS UI fails with a “Connection request error: Incorrect connection request credentials” error after the device has been factory reset from GenieACS. My theory is that the factory reset is removing the credentials the device uses to authenticate with GenieACS, so it is either rejected by the ACS or is showing up as a new device that cannot be added due a device with the same serial already existing.

I have cwmp.auth set to true. If I manually delete the device from GenieACS it does eventually show up again, after which summoning succeeds without issue, but manually removing the device every time one goes through a factory reset isn’t an option for me. Could I run a provision that removes the device from the database entirely on a factory reset? Either that or get the device to reconnect without the error.

I’ve played with a few different provisions for the factory reset event, but here’s what I currently have.

const now = Date.now();
clear("Device", now);
clear("InternetGatewayDevice", now);
clear("Tags.Provisioned", now);

It’s worth noting that it seemed like device parameters did successfully update. The custom SSID, for example, returned to the default after the factory reset but before deleting the device from GenieACS.

Thanks in advance for any advice.

I had that problem before. My way around that is using curl. this example was taken from a bash script:

    parte1='http://YOURACS.com:7557/devices/?query=%7B%22_id%22%3A%22'
    parte2='%22%7D&projection=InternetGatewayDevice.ManagementServer.ConnectionRequestURL'
    completo=$parte1$devid$parte2

    respuesta=$(curl -s  $completo )
    # crurl = Connection Request URL
    crurl=$(echo $respuesta  | python -m json.tool  | grep value | egrep 'http[^\"]*' -o)

    
    ip=$(echo $crurl |egrep "[0-9\.]+:" -o |egrep ".*[^:]+" -o)

    # does the CPE answer?
    ping -w 1 -c 1 $ip >/dev/null 
    if [ "$?" -ne 0 ];     then
        logger doing nothing 
    else 
        # triggering a connection request ... directly to the CPE using the ConnectionRequestURL taken from ACS before
        curl -s $crurl --digest -u user:password
        # in case of error, try again without password
        [[ "$?" -ne 0 ]] && ( logger forzando ... ;  curl -s $crurl )
    fi 

this scenario assumes you have the user/password for all CPE.

hope it helps.

I don’t think I understand what implementing this looks like. Is this just some sort of listener script that runs in the background and triggers a connection request from the ACS to the CPE whenever the CPE goes offline? Would I have to run this per device for every CPE I have on GenieACS?

Thanks for helping out!

if it’s just an specific case (let’s say Customer Support is asking for your help) you can simply use curl to summon the affected device, using the proposed parameters in both cases. You could get the connection request url from the CPE setup if you don’t have it on ACS database

the script I posted is just an example of the curl parameters. In other words, you force a connection request by talking directly to the CPE.

I see, thanks! I’m just wondering if there is a way of automating this setup. If a customer or our ISP initiates a factory reset I’d like to be able to have it automatically reprovision or configure itself to reappear in GenieACS without manual intervention. Do you know if there’s a way of doing that?

Search the forum. This comes up many times and has been answered.

I’ve been through the forum a few times and have been unable to find anything that seems to apply to my specific scenario. I’ve gathered that the most common solution for the error that I get is to configure the AUTH parameter, but as previously mentioned, even if I set it to just be “true” I still get the incorrect connection request credentials. I don’t see any posts that mention deleting or removing entire devices from GenieACS so they can be re-added on a device’s next connection.

I did find this through the forum (Provisions · genieacs/genieacs Wiki · GitHub) but as far as I can tell object instances are different than actual devices; I believe that I would need to delete the entire device in order to fix my problem? Or would deleting the management server credentials be sufficient?

If you are using the default GenieACS inform script, then the auth credentials get set on the CPE automatically.

As for factory reset, listen for the 0 BOOTSTRAP event and remove any tags you have on the CPE and then allow your existing scripts to run through the provisioning process. If you need more help, then I suggest you email sales to engage with a support contract.

These are the scripts I wrote and use.

Sorry for the delay in getting back to this. I’ve figured out the issue, sort of… at least I think I did.

The first problem was that factory resetting at least this particular device did not trigger a 0 BOOTSTRAP event to occur, only a 1 BOOT event. So anything that I was setting in a preset on the 0 BOOTSTRAP didn’t matter.

In order to get the device to reappear and reconnect to the ACS (inside the 1 BOOT preset due to the aforementioned circumstances) it looks like I have to do both of the following:

First I have to clear the database parameters using clear(), as follows

clear("Device", now);
clear("InternetGatewayDevice", now);
declare("Tags.Provisioned", null, {value: false});

I’m not sure if this is a good idea for something to have happen to every device on every boot but I don’t really see any other option since it looks like I can’t distinguish between a boot and a factory reset?

Second I provision the device’s ConnectionRequestUsername and ConnectionRequestPassword as well as the PeriodicInform information. All of this I copied directly from the inform script which I believe is the default GenieACS script but I don’t know that for sure, other people may have added that before me.

Hopefully that helps anyone else!

then no boostrap event on cwmp log files? are you sure?

root@acs3:~/bin# ./eventos.sh
     77 "0 BOOTSTRAP,1 BOOT"
      1 "0 BOOTSTRAP,1 BOOT,4 VALUE CHANGE"
   2777 "1 BOOT"
      1 "1 BOOT,0 BOOTSTRAP"
     92 "1 BOOT,4 VALUE CHANGE"
    496 "2 PERIODIC"
      1 "2 PERIODIC,4 VALUE CHANGE"
   2550 "4 VALUE CHANGE"
     58 "4 VALUE CHANGE,2 PERIODIC"
   3122 "6 CONNECTION REQUEST"
      3 "8 DIAGNOSTICS COMPLETE"
root@acs3:~/bin# cat eventos.sh
#!/bin/bash                                                                                                       
cat /var/log/genieacs/genieacs-cwmp-access.log* |grep nformEvent  |egrep -o '"[0-9]+ [0-9A-Z ,]*"'  |sort  | uniq -c
root@acs3:~/bin# 

Here is the output of that script for me.

      1 "1 BOOT"
   7440 "2 PERIODIC"

If I unzip and run that script on that file here’s the events from the day that I posted that update:

      3 "1 BOOT"
      1 "1 BOOT,4 VALUE CHANGE"
  15296 "2 PERIODIC"
      2 "4 VALUE CHANGE"

Update: I performed a factory reset on a different model of router (TP-Link Archer C5 vs TP-Link EX220) and the same thing happened. After a factory reset it only triggered a 1 BOOT event, not a 0 BOOTSTRAP.

Inform; cpeRequestId="1000" informEvent="1 BOOT" informRetryCount=0

page 65: about bootstrap event:

Indicates that the Session was established due to first-time CPE installation or a change to the ACS URL. The specific conditions that MUST result in the BOOTSTRAP EventCode are:
• First time connection of the CWMP Endpoint to the ACS from the factory.
• First time connection of the CWMP Endpoint to the ACS after a factory reset.
• First time connection of the CWMP Endpoint to the ACS after the ACS URL has been modified in any way.
Note that as with all other EventCode values, the BOOTSTRAP EventCode MAY be included in the Event array along with other EventCode values. It would be expected, for example, that on the initial
boot of the CPE from the factory, the CPE would include both the BOOTSTRAP and BOOT EventCodes.

firmware bug?

That seems probable. I have two different TP-Link devices (Archer C5 and EX220) and both seem to behave this way. At the moment those are the only two devices that I have available to factory reset, but hopefully soon I’ll be able to test a different brand, probably an Adtran device. I’ll add to this thread if that problem persists across devices of other brands, since that to me would imply that maybe somehow GenieACS is only receiving boot events, not bootstrap events?

Thanks for y’all’s help!

considering what @akcoder mentioned several times in this forum I say it’s more likely to be the CPE’s faults in not sending the bootstrap event.

about EX220, fixed it by installing the firmware on the Brazilian tplink site /br and set to use tr181