Socket, I can't enter username and password correctly.

I want to create a socket to a server and get data on that socket using perl, following is my script:

use IO::Socket::INET;
my $sock = new IO::Socket::INET
    PeerHost => '',
    PeerPort => 23,
    Proto => 'tcp'
die "Socket could not be created. $!\n" unless $sock;
$usr = substr $str,1,8;
if ($usr=="USERCODE")
$usr = "myusername";
$pswd = substr $str,1,8;
if ($pswd=="PASSWORD")
$pswd = "mypassword";
print $str
close ( $sock );

All I get is the result: "Authorization failed", which means "myusername" and "mypassword" are not correctly read by the socket (if I enter them from cmd line, they work well).
I tried "myusername\n", "myusername\r\f", they are failed as well.
But when I write VBscript with "myusername" + vbcrlf
it works. (vbcrlf means clear character and linefeed character in VB)
That's very strange, please help.
Who is Participating?
I'm not sure what you're asking. Pressing the Esc key does nothing in particular when Perl is reading from the keyboard.

You can send an escape by sending its ASCII code "\033".
Not that this is likely to affect your problem, autoflush should be set before you send anything.

If vbcrlf works, have you tried attaching "\r\n" to both the username and password sends?

$usr = "myusername";
$sock->send( "$usr\r\n");
binhboongAuthor Commented:
Thank you, I tried but it didn't work, even actually \r\n is the same as vbcrlf.
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Port 23 is normally served by a telnet daemon and the script you've shown us is not speaking Telnet protocol.

What can you tell us about the server that's listening to port 23?

With only what you've told us so far, it's unlikely that we can solve this problem for you. If you have some control over the server side, you should instrument it or examine its log files so as to find out why it is disallowing the login. If you don't have the ability to track things down at that end, I'm afraid you may ultimately need to use a packet sniffer type tool to determine what's different about the network-level interaction offered by this script and by your VB app.
binhboongAuthor Commented:
Thank you, 23 is just what I bring from VB script, it works there. So I don't pay much care about it. I hope it's not the cause of the failure.
Can you tell me more about the packet sniffer type tool you mentioned?
Please help.
perl -w -Mdiagnostics -e 'if ($usr=="USERCODE"){} if ($pswd=="PASSWORD"){}'
Argument "USERCODE" isn't numeric in numeric eq (==) at -e line 1 (#2)
    (W numeric) The indicated string was fed as an argument to an operator
    that expected a numeric value instead.  If you're fortunate the message
    will identify which operator was so unfortunate.
Argument "PASSWORD" isn't numeric in numeric eq (==) at -e line 1 (#2)
I'm so blind. Thanks, ozo.

But in this case, the comparisons probably turn into if( 0 == 0 ) so we aren't any closer to understanding why the authentication fails.


As for Packet Sniffers, I've never used one on Windows. See this article for possible pointers:

There may be newer ones, but Ethereal is one I've heard favorably mentioned.
binhboongAuthor Commented:
Can you please explain what your script is for ozo?
Thanks anyway jmcg, is my problem going to an deadend?
Well, I'm not sure it's at a dead end, but without some additional information, I'm certainly stuck.

Ozo was pointing out that you had used the wrong comparison operator (the numerical comparison == instead of the string comparison 'eq') in your tests where you looked for the strings USERCODE and PASSWORD coming back from the server.


At one point, you mentioned that if you entered username and password from the command line, everything worked. Can you say more about that? How were you communicating with the program on the remote side by entering something on the command line?
binhboongAuthor Commented:
I telnet directly to the server just to make sure that username and password are correct. Don't know why it can work with VB but not with perl.
Now I'm trying to use Net::telnet instead, here is my script:
use Net::Telnet;
  $telnet = new Net::Telnet ( Timeout=>10,
print $telnet->cmd('myfirstcommand');

Using telnet, I can pass the login proccess, but my problem now is the output log in binh.txt includes hexa or binary code, which is not expected.
I just want to get text string output only, like when I enter command and the output text is thrown out on the pc screen.
How can it be possible?
Is this possible for me to replace the previous question with this one?
OK, you solved problem number 1 by speaking Telnet protocol. If the server is expecting to speak Telnet, you're going to be frustrated if you try to talk to it with a raw socket.

Problem number 2 is that the terminal control strings that do things like clear the screen are showing up as binary characters in your raw logfile. This is the expected behavior even if you did not expect it.

It may be simple to turn the logfile into simple text or it might not be. Are there just a few extra characters at the beginning? Or are there extra characters (cursor positioning codes, for example) sprinkled all through your output?
binhboongAuthor Commented:
< 0x00000: ff fd 03 ff  fb 03 ff fb  01                        ÿý.ÿû.ÿû.

> 0x00000: ff fc 03 ff  fd 03 ff fd  01                        ÿü.ÿý.ÿý.

< 0x00000: 03 55 53 45  52 43 4f 44  45 3a                     .USERCODE:

> 0x00000: 62 69 6e 68  0d 0a                                  binh..

< 0x00000: ff fe 03                                            ÿþ.

< 0x00000: 62 69 6e 68  0d 0a                                  binh..

< 0x00000: 03 50 41 53  53 57 4f 52  44 3a                     .PASSWORD:

above is what I extract the first lines from the log file, as you can see they are hex strings followed by text strings of the same content.
How can I get rid of hex strings to get text strings only?
Most of that appears to be the Telnet protocol negotiation. It's important to be able to see that in the logfile when one is debugging. That's the intended use for dump_log.

You should try input_log instead to see if the results are any more satisfactory.

The other way to capture the data stream coming back from the remote host is from the result of the waitfor method -- but it looks like you're already doing that with the print statement on your last line. Once you get past the login sequence, are you still getting binary sequences inserted?
binhboongAuthor Commented:
It's good to use input_log and output_log instead of dump_log. I can get rid of some binary date unneeded. But there is a command that the server order the user to press Esc key to exec. Is it the way the server prevents user who telnets to exec that command? Any idea to send a character like pressing the Esc key?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.