UNIX for Dummies Questions & Answers

Hey all,

Just found your forum...Looks super rich with info! Can't wait to get through it all.

I am currently writing a web app in .net that telnets into a unix server (require uid + passwd), runs a command, and returns that output to be displayed on the web page.

I have gotten through the initial TelNet option negotiation and have hit the log on screen. Of course, I'm transferring bytes in my network stream so all my i/o is ascii.

I've been able to enter my username and am prompted for a password. I send an array of bytes, which is my passwd, but the unix box sits there. Finally, half a minute later, I receive the text:

/dev/pts/96: 3004-031 Password read timed out -- possible noise on port

I've tried using ascii 13, and 10 to attempt a carriage return, and I've even sent negotiation 'Go Ahead' command even though they're suppressed.

Does anyone know what my UNIX box is waiting for?

Hi Gord,

Is it possible that your password contains any Unix control characters? I've had problems before with password that contan chrs such as #$^*! etc.

Cheers
Helen

Thank you for the reply!!

This is just KILLING me lol.

No, i've even reset the unix passwd to ensure simplicity.

I'm guessing there has to be something that tells Unix to accept the passwd. Enter in the console sense, but to pass an ASCII enter (I think it's 13) after the password doesn't trigger it.

G

Suppose my password was fred1. How would the system know my password was not fred12? Answer, because I press the return key after the password. How did you ever make it to the password prompt? You have to send a return after the user name as well. Again, my user name might be fred1 or fred12...

You know what's weird? I didn't have to enter an ascii enter for the username.

Then I was stuck at the password. It would time out. Since then I've added an ascii carriage return but the login fails. Presumeably because the unix box is interpreting the ascii cr as a part of my password.

I don't know if simply sending a byte of cr is interpreted as a character by Unix or if it carries out cr's functionality.

This is so cool - but weird.

Why not use a manual telnet client and observe what you have to do on the keyboard? That .net makes me think Windows. If so, open a cmd command line window and use the telnet command.

Yeah - that's how I started.

When you open a telnet session you are prompted for username. You enter that, you hit enter. Then you are prompted for password. You enter that then you hit enter.

But this doesn't help, as I haven't hit enter after my username, and the UNIX box will prompt me for the password.

This suggests that there's something in the stream writing that hits a carriage return for you.

However, the stream writer won't work the same way for the password.

Now I am forced to look at what UNIX is reading in and all the invisible functionality that I can't see.

G