Hi Eric,
Thanx for the details, here's some info that may be of interest,
10004 means that your target machine did not return anything before the connection
timeout expired.
BTW you appear to be connecting to port 23 (telnet) to complete a remote exe command
the rexec daemon runs on port 512. Also your script implies that you have actually
telnet'd
into the 10.1.1.1 box - it's alittle more low level and nitty gritty than that.
btw The test expression does not actually contact the server, it just tests your
expression against the
sample text you provide using the match criteria (as an anticipation of what you
expect the real
server to return).
Unfortunately you will not be able to describe the rexec protocol in v6.02 because of
difficulties 6.02 has processing leading nulls in some protocols - this one is an
example.
btw Are you sure you need to use rexec to get your results?
I have not worked with the rexec protocol directly so I can't offer precise help, but I
can give an educated guess. Note you will have to pass over a username and password
before
the Unix box will even allow you to run something remotely. (all in plain text by the
way(!)). Also
this protocol relies on sending and receiving leading nulls, something v5 and v6 have
problems with.
Some random details found on the net:
1. Client makes TCP connection to REXEC port (512).
2. Client sends TCP port number (decimal ASCII, null-terminated)
of stderr port. If the first byte is a NULL, then server
won't make any stderr connection - skip step 3.
3. Server makes TCP connection to client's stderr port
4. Client sends target username (null-terminated).
5. Client sends target password, NULL, remote command, NULL,
and then command's stdin, followed by a FIN.
6. Server sends one null byte (=no error), or a non-null
byte, followed by error message(s).
7. Server sends output of command.
8. Server sends FINs on stdout, stderr connections.
Flying blind here (i.e. not having something to test against) I would try this
interpretation of the protocol (using version 7+ - which handles leading %000's
correctly
in expect statements):
TCP, port 512, timeout 5
Send=%000usernamehere%000passwordhere%000echo success%000
Expect=%000success
If you are really driven to try this you could download the 7.02 eval on a test box
and give it a go. I'd be interested to know if this educated guess actually works....
:)
hope this helps,
Adrian.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 12:00 PM
Subject: [WhatsUp Forum] Custom TCPIP service
> hello,
>
> I'm currently using WUG 6.02, I'm trying to retrieve a result of the
> following command through the custom service.
> in the "send command" field I've put : rexec 10.1.1.1 echo success (this
> is for testing purposes before going further; 10.1.1.1 is a unix server)
> I've tried several things in the 'expected command' field, but I can't
> retrieve any 'success' in return; however it works with the 'test
> expression tab'.
>
> here are the results of the debug:
>
> (C:\Program Files\WhatsUp\WhatsUp1.wup) map poll start
> >>> COHS CHECK 23 on 10.1.1.1
> connected
> rexec 10.1.1.1 echo success<255><254>%<255><253><24>failed to receive after
> command (10004)
> <<< COHS EXIT=10004
> TCP/IP Service check complete. FAILED
> (C:\Program Files\WhatsUp\WhatsUp1.wup) map poll complete
>
> Any advise would be helpfull, thanks.
>
> Eric Gillis,
> Network engineer
>
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
> An Archive of this list is available at:
> http://www.mail-archive.com/whatsup_forum%40list.ipswitch.com/
>
>
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/whatsup_forum%40list.ipswitch.com/
