On Jun 17, 3:19*am, mituag wrote:
> I have a linux device on which telnetd server is running.
> When I connect to this device through the windows command prompt I see
> that there are some negotiations going on between the server and the
> client.
>
> Once the negotiations are done I see a "login" at the prompt.
>
> Now, when I try to connect to the same device through my application,
> I do not see the login prompt as the server is waiting for some
> response. But currently there is no implementation in my application
> to respond to the server to carry out the negotiations.
>
> How can I suppress these negotiations?
> Is there any option in telnetd which can be set on the device which is
> running the telnet server so that we can skip the negotiations?

If you want to connect to a telnet server, your application has to be
a telnet client.

Spend the five minutes to write a simple 'refuse everything, ask for
nothing' responder to telnet options.

DS

On Jun 17, 9:08 pm, David Schwartz wrote:
> On Jun 17, 3:19 am, mituag wrote:
>
> > I have a linux device on which telnetd server is running.
> > When I connect to this device through the windows command prompt I see
> > that there are some negotiations going on between the server and the
> > client.
>
> > Once the negotiations are done I see a "login" at the prompt.
>
> > Now, when I try to connect to the same device through my application,
> > I do not see the login prompt as the server is waiting for some
> > response. But currently there is no implementation in my application
> > to respond to the server to carry out the negotiations.
>
> > How can I suppress these negotiations?
> > Is there any option in telnetd which can be set on the device which is
> > running the telnet server so that we can skip the negotiations?
>
> If you want to connect to a telnet server, your application has to be
> a telnet client.
>
> Spend the five minutes to write a simple 'refuse everything, ask for
> nothing' responder to telnet options.
>
> DS

Yes that is one possible way.
But since we do not want to get into the implementation of telnet
protocol we are not doing that.
Wont that require complete knowledge on the telnet protocol? Currently
we just use telnet as means of accessing the device and loading
software/changing few settings on the device.

We have another device which is linux based and runs a telnet server.
When we connect to this we see that there are no negotiations
whatsoever either from windows telnet client or from the application
which I have developed.

The config of this device is

ViBE 61just a name/type of the device)
Linux localhost 2.4.20-rthal5-TRACE #7 Thu Aug 24 09:44:01 CEST 2006
ppc

And the config of the device which carries out the negotiations is

XMU-64just a name/type of device)
Linux y 2.6.17.1-XMU_FIRM_01.00.004_CG #1 SMP Wed Jan 3 16:01:00 CET
2007 i686
686 i386 GNU/Linux

Mitesh

On Jun 17, 8:01*pm, mituag wrote:

> > Spend the five minutes to write a simple 'refuse everything, ask for
> > nothing' responder to telnet options.

> Yes that is one possible way.
> But since we do not want to get into the implementation of telnet
> protocol we are not doing that.

Then you can't talk to a telnet server. Telnet servers, by definition,
speak the telnet protocol. If you don't implement the telnet protocol,
you are not a telnet client. If you are not a telnet client, you will
not be able to speak properly to a telnet server.

> Wont that require complete knowledge on the telnet protocol? Currently
> we just use telnet as means of accessing the device and loading
> software/changing few settings on the device.

We're talking about *four* commands. It's literally five minutes work.
It would take less time to implement the protocol than to argue about
whether or not you need to.

However, the person who implements your telnet server or client
capability should have a reasonable knowledge of the telnet protocol.
Would you let a person not familiar with the HTTP protocol write a web
server or a browser? That would be really silly.

> We have another device which is linux based and runs a telnet server.
> When we connect to this we see that there are no negotiations
> whatsoever either from windows telnet client or from the application
> which I have developed.

Then on what basis did you conclude that it runs a telnet server? If
you see no telnet option negotiations, how did you determine that the
telnet protocol was being spoken?

Perhaps you are being mislead by the fact that most 'telnet' clients
speak protocols other than the 'telnet' protcol. The 'telnet protocol'
is in fact a real protocol and includes things like controlling line
mode or character mode, echo, binary or text modes, and a few other
things.

You can simply ask for nothing and refuse everything. To get a bit
fancier, you can add a simple list of things you wish to ask for or
accept. The implementation can be miniscule. Ask for all the things
you are configured to ask for on initial setup. If offered something,
accept it if it's no the accept list, otherwise refuse it. That's it.

DS

mituag wrote:
> On Jun 17, 9:08 pm, David Schwartz wrote:
>> On Jun 17, 3:19 am, mituag wrote:
>>
>> > I have a linux device on which telnetd server is running.
>> > When I connect to this device through the windows command prompt I see
>> > that there are some negotiations going on between the server and the
>> > client.
>>
>> > Once the negotiations are done I see a "login" at the prompt.
>>
>> > Now, when I try to connect to the same device through my application,
>> > I do not see the login prompt as the server is waiting for some
>> > response. But currently there is no implementation in my application
>> > to respond to the server to carry out the negotiations.
>>

Why not just open the telnet client with a pty? No need to suppress any
negotiations, etc.

If you don't want to do a pty, use "expect" (though I think that's a bit
harder). Writing the pty code (or cribbing from the 'net) gives you a
component that can be reused. Plus, if ever you decide to use a
different transport, it will be a lot easier (ssh for example).