Cannot use remote tools over tcp/ip

[Oskar]

Hi, all,

A few days ago I searched past messages and what I found helped me get the remote
tools (File Viewer and others) running over tcp/ip with a manual server. I'm
developing for a CEPC platform with PB 3.0 under NT 4.0 SP6.
However, now I'm using another development workstation and I can't use the remote
tools anymore over tcp/ip with the same platform. The Windows CE image is OK
because I can remotely connect (over tcp/ip with manual server) to the same CEPC
from the previous WS.
I suspect that it has something to do with the WS but I can't tell who or what is
preventing the communication from working. Task Manager reports only one
cemgr.exe process during the communication test, if it's of any help.
I've tried both DHCP and fixed IP addresses for both the CEPC and the WS. I've
also tried fixed (5000) and non-fixed ports for the manual server.
I've tried to connect, and always failed, after applying SP4, SP5 and SP6 to the
WS. The previous one has SP5.
When I start the cemgrc on the CEPC the debug window outputs the following:
Loaded 'C:\WINCE300\PUBLIC\PRUMAXALL\RELDIR\X86_DEBUG\CEMGRC.EXE', no matching
symbolic information found.
Loaded 'C:\WINCE300\PUBLIC\PRUMAXALL\RELDIR\X86_DEBUG\TCPIPC.DLL', no matching
symbolic information found.
0x81299de0: *InsertTCB: SetIdleTimerReset
0x81299de0: InsertTCB: setting fTCBTimerOn to 1
0x81299de0: InsertTCB: Restarting TCBTimer
0x81261850: *TCBTimeout: ClearIdleTimerReset
0x81261850: TCBTimeout: setting fTCBTimerOn to 0
0x81261850: TCBTimeout: NOT Restarting TCBTimer
[Skipped the right above 6 sentences 9 more times]
Unloaded symbols for 'C:\WINCE300\PUBLIC\PRUMAXALL\RELDIR\X86_DEBUG\TCPIPC.DLL'
Unloaded symbols for 'C:\WINCE300\PUBLIC\PRUMAXALL\RELDIR\X86_DEBUG\CEMGRC.EXE'

On the other hand, the Platform Manager on the WS displays the connection dialog
but it also timeouts.
Any ideas of what I could try or what could be going on?

Thanks in advance.
Oskar

[Paul G. Tobey]

Are you sure that you're launching CEMGRC.EXE with the specified set of
parameters? When you are using a manual server configuration, the
workstation will tell you, when you try to connect to the CE device, what
the right parameters are for communication with it. For TCP/IP, the
parameters include the port number (configured on the WS), and either the
hex representation of the WS name or the hex representation of the WS IP
address. It's possible that your new WS is asking you to put the name on
the CEMGRC.EXE command line, but that your workstation (or whatever you have
configured for WINS servers on the CE device), can't resolve the name.

Try the following:

1. On the workstation, in eMbedded Visual C++, verify the following under
Tools/Configure Platform Manager: There is an entry representing your
device (H/PC Pro or whatever). Open the entry and choose the default device
and click Properties... Choose TCP/IP Transport for Windows CE from the
list and click Configure. Make sure that the Fixed Port checkbox is on and
that the port is set to 5000. Click OK and then click Advanced. Verify
that Manual Server is selected from the list. Click OK to close all dialogs
and complete the Platform Manager configuration.

2. Attempt to connect to the device using the remote tool of your choice.
The tool should pop up a dialog telling you what parameters to use on the
CEMGRC command line. Ignore those parameters and use the set we'll figure
out below:

/S /T:tcpipc.dll /D:8813<more junk>00

The <more junk> is going to represent the IP address of the workstation, as
follows: the hex codes representing the ASCII string containing the IP
address. For example, if my IP address is 192.35.15.6, the <more junk>
would be 3139322e33352e31352e36. This is because 31 is the hex value of the
ASCII code for the number '1', 32 is the hex code for '2', etc. 2e is the
hex code for '.', etc.

3. On the device, run CEMGRC with the right command line. It might be
something like:

CEMGRC.EXE /S /T:tcpipc.dll /D:88133139322e33352e31352e3600

4. On the WS, click OK to accept the dialog telling you what command line
should be used. The WS should now receive the packets from the CE device
and establish the connection. If this *doesn't* happen, verify that you can
ping the CE device from the workstation. If *that* works, then load a
network sniffer and see if packets are arriving from the CE device at the
workstation after CEMGRC starts. It's also possible that you'll need to
reboot the workstation. I've noticed that the server that runs to receive
the CE devices messages doesn't always exit cleanly, leaving a copy running
that the CE device can connect to, but then the tools run another copy which
never receives a connection.

Paul T.

"Oskar" <oberr...@ikerlan.es> wrote in message
news:777301c081ed$a29240e0$46862ecf@cpmsftngxa06...

[Oskar]

Thanks a lot, Paul. That did the trick. Platform Manager was telling me to use a
weird IP address (126.0.0.1) for the WS in the command line of the Platform
Manager Client. Instead, I translated the actual IP address of the WS and
discarded what it had told me to use.
Now I can use the remote tools again.
Thanks again.
Oskar
PS: I wonder where PM got that IP address.

Try the following:

Paul T.

Thanks in advance.
Oskar

.

[Paul G. Tobey]

I don't know; it looks like a loop-back address...

Paul T.

"Oskar" <oberr...@ikerlan.es> wrote in message

news:4ad201c08532$d09d6990$34862ecf@cpmsftngxa05...

[Bill T]

I tried this process and both the performance monitoring and system
inofrmation tools failed to connect (after timing out). This makes me
wonder if the approach can only be used in a very specific configuration
which does not match mine. Here is my configuration:
- X86 CEPC
-MS ethernet download
- LAN with DHCP
- Single debug ethernet port

Based on step 4, it sounds as though an application ethernet port may be
required. When I run ipconfig on the target, it responds with "No interfaces
present". Consequently, I am unable to ping the CE target as indicated in
step 4.

"Oskar" <oberr...@ikerlan.es> wrote in message

news:4ad201c08532$d09d6990$34862ecf@cpmsftngxa05...