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.
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)