ADDP and RCI libs

Embedded Devices Plug N' Play
,
1

Hello.

We are developing an application very similar to your CfgWiz, from the Digi Connect Integration Kit.

By now, we have detected three problems:

  • if we send a request of 2423 bytes, with RCIWriteDeviceConfig the operation fails. If we divide the request in two calls to RCIWriteDeviceConfig, both calls are successful. The RCI Specification states that “the largest request that can be processed is 32KB”, but we are fare away from that.

  • if we change the device root’s password, the ADDPRebootDevice function keeps waiting for the default password (dbps).

  • if we remove the check “Enable user logins” in the device, we can’t use with success the RCIConnect function anymore. Neither passing the password and/or username as NULL or “” is working.

Do you have any ideas of which could it be the problem or any workaround?

Thanks in advance.

Additional information of our system:

addp*.lib original file’s date: 01/July/2004, 11:54:54
rci*.lib original file’s date: 28/July/2004, 19:32:50

Model: Digi Connect ME
Firmware Version: 1.9.0.6 (Version 82000856_F6 07/21/2006)
Boot Version: 0.0.0.1 (release_82000866_C)
POST Version: 1.1.3 (release_82000867_G)

2

For 1 + 3 try re-running your tests against the latest IPv6 firmware, as there are some fixes to the RCI interface not present in the F6 firmware: http://www.digi.com/support/productdetl.jsp?pid=2466&osvid=0&s=53&tp=2

For 2, how are you determining this?

You may also consider putting in a case with Digi Support after running the new firmware with Ethereal (http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=840)network traces: http://www.digi.com/support/eservice/login.jsp

3

Thank you for your quick reply.

We have upgraded to the lasted firmware, as you suggested.

Now, we can send the request of 2423 bytes with RCIWriteDeviceConfig. But if we change the network settings just before of that, as in the CfgWiz example, an exception rises. The call stack is something like that in that moment:

  • DeviceCFG.exe!_RCIInternalReadResponse() Line 632 + 0xc bytes
  • DeviceCFG.exe!_RCIInternalSend() Line 290 + 0xd bytes
  • DeviceCFG.exe!_RCIWriteDeviceConfig() Line 315 + 0x15 bytes
  • …

If we don’t change the network settings, it works fine.
Maybe if we use the RCI string to change the network settings and neither ADDPSetDHCP nor ADDPSetNetwork, we can go around this problem; although this was working well with the previous firmware.

The problem about the “Enable user logins” is fixed in the new firmware.

This problem remains:

  • if we change the device root’s password, the ADDPRebootDevice function keeps waiting for the default password (dbps).

> how are you determining this?

Well, we change the password using the web interface of the Digi. Then we use our program to do the test. As in the CfgWiz sample, we try with the default password first. When it fails, we request another one to the user. If it’s the right password, then we try to use it in the rest of operations. When the execution reaches the ADDPRebootDevice operation, it fails. If we put the “dbps” password ‘hard-coded’ there it always works with success.

In addition, we have found another problem in the new firmware. If we use RCI over serial to request all the configuration settings:

we are only receiving a partial answer. We receive about the first 4122 bytes of it.

Any ideas?

Thanks in advance again.

Additional information of our system:

addp*.lib original file’s date: 01/July/2004, 11:54:54
rci*.lib original file’s date: 28/July/2004, 19:32:50

Model: Digi Connect ME
Firmware Version: 2.4.5 (Version 82001116_H 10/18/2006)
Boot Version: 0.0.0.1 (release_82000866_C)
POST Version: 1.1.3 (release_82000867_G)