Telnet problem

Okay, since my previous question was so easy…
Maybe this really isn’t an embedded question, but I don’t know.

When connected to the board via a serial link and qtalk, everything
works fine (now that the term problem is fixed). However, when I connect
via telnet, I get some odd symptoms. In all cases here, I am logged in
via both methods simultaneously, with identical logins and environments.

Using telnet, if I go to the /etc directory, for example, I can “ls” and
“ls -al” just fine. In the “/” directory, on the other hand, “ls” still
works, but “ls -al” gives:

ls -al

total 54885
And that is it. At that point, I have to type ^] quit. I can then
reconnect, and it continues to work ok.

Doing a bit more playing around, there appears to be some relationship
to size of the data. With a test file that contains 780 bytes, I can do
“more tmp.txt” via telnet and it will work a couple of times fine, and
then suddenly appear to hang. Often, if I wait awhile (a minute) it will
respond, though sometimes even then it has not returned. But even while
hung via telnet, via the serial/qtalk terminal I can execute the same
command and it works fine.

With a 714 byte file via telnet, what I see is that it always works. But
I do notice that sometimes it returns instantly, and sometimes there is
a pause of a couple of seconds (or even 5 or 6) before returning. As the
file gets larger, the problem gets worse. Again, via the serial port,
there is never a pause; it always works, even with large files.

So does all this trigger any thoughts on what might be happening?

I am running the ttcpip stack with QNX 6.2.1 on a Technologic Systems
TS5400 board.

When your ls hangs, do a pidin from the serial port - who is the
ls waiting on?

Duane Clark <dclark@akamail.com> wrote:

Okay, since my previous question was so easy…
Maybe this really isn’t an embedded question, but I don’t know.

When connected to the board via a serial link and qtalk, everything
works fine (now that the term problem is fixed). However, when I connect
via telnet, I get some odd symptoms. In all cases here, I am logged in
via both methods simultaneously, with identical logins and environments.

Using telnet, if I go to the /etc directory, for example, I can “ls” and
“ls -al” just fine. In the “/” directory, on the other hand, “ls” still
works, but “ls -al” gives:

ls -al

total 54885
And that is it. At that point, I have to type ^] quit. I can then
reconnect, and it continues to work ok.

Doing a bit more playing around, there appears to be some relationship
to size of the data. With a test file that contains 780 bytes, I can do
“more tmp.txt” via telnet and it will work a couple of times fine, and
then suddenly appear to hang. Often, if I wait awhile (a minute) it will
respond, though sometimes even then it has not returned. But even while
hung via telnet, via the serial/qtalk terminal I can execute the same
command and it works fine.

With a 714 byte file via telnet, what I see is that it always works. But
I do notice that sometimes it returns instantly, and sometimes there is
a pause of a couple of seconds (or even 5 or 6) before returning. As the
file gets larger, the problem gets worse. Again, via the serial port,
there is never a pause; it always works, even with large files.

So does all this trigger any thoughts on what might be happening?

I am running the ttcpip stack with QNX 6.2.1 on a Technologic Systems
TS5400 board.


cburgess@qnx.com

Colin Burgess wrote:

When your ls hangs, do a pidin from the serial port - who is the
ls waiting on?

Hmm, well it appears that it is not ls that is hung, or at least it is
not appearing in the pidin list. The only related thing I see is the
telnetd and sh processes, and they both appear normal:

167947 1 sbin/telnetd 10r SIGWAITINFO
172044 1 bin/sh 10r REPLY 12295

The SIGWAITINFO appears to be the normal state of telnetd; it shows up
that way even when not hung. So it looks like something that happens
after ls has finished executing. By the way, when hung, the terminal
will not even respond to ^C.

Might you be having networking troubles - do you see any other
networking related probs?

Duane Clark <dclark@akamail.com> wrote:

Colin Burgess wrote:
When your ls hangs, do a pidin from the serial port - who is the
ls waiting on?


Hmm, well it appears that it is not ls that is hung, or at least it is
not appearing in the pidin list. The only related thing I see is the
telnetd and sh processes, and they both appear normal:

167947 1 sbin/telnetd 10r SIGWAITINFO
172044 1 bin/sh 10r REPLY 12295

The SIGWAITINFO appears to be the normal state of telnetd; it shows up
that way even when not hung. So it looks like something that happens
after ls has finished executing. By the way, when hung, the terminal
will not even respond to ^C.


cburgess@qnx.com

Colin Burgess wrote:

Might you be having networking troubles - do you see any other
networking related probs?

I don’t think so. While telneted in, I can execute programs (located
both locally and across a qnet network) which print lots of stuff to
stdio, and they spit out data across the telnet connection just fine.

The things that are affected are commands like more, ls, and vi. Hmm,
all of which buffer data to some extent, before spitting it out to the
terminal. Unlike printf which I think just buffers single lines.

what is pid 12295? which sh are you running?

Colin Burgess <cburgess@qnx.com> wrote:

Might you be having networking troubles - do you see any other
networking related probs?

Duane Clark <> dclark@akamail.com> > wrote:
Colin Burgess wrote:
When your ls hangs, do a pidin from the serial port - who is the
ls waiting on?


Hmm, well it appears that it is not ls that is hung, or at least it is
not appearing in the pidin list. The only related thing I see is the
telnetd and sh processes, and they both appear normal:

167947 1 sbin/telnetd 10r SIGWAITINFO
172044 1 bin/sh 10r REPLY 12295

The SIGWAITINFO appears to be the normal state of telnetd; it shows up
that way even when not hung. So it looks like something that happens
after ls has finished executing. By the way, when hung, the terminal
will not even respond to ^C.


cburgess@qnx.com


cburgess@qnx.com

Colin Burgess wrote:

what is pid 12295?

12295 1 sbin/devc-pty 10r RECEIVE 1

which sh are you running?

Just the plain /bin/sh, though I also tried tcsh which I downloaded off
SourceForge. I executed it (tcsh) from the login sh shell. It had the
same symptoms.

Just trying to narrow the possibilities, did you try the large stack?

Duane Clark <dclark@akamail.com> wrote:

Colin Burgess wrote:
what is pid 12295?

12295 1 sbin/devc-pty 10r RECEIVE 1

which sh are you running?

Just the plain /bin/sh, though I also tried tcsh which I downloaded off
SourceForge. I executed it (tcsh) from the login sh shell. It had the
same symptoms.


cburgess@qnx.com

Colin Burgess wrote:

Just trying to narrow the possibilities, did you try the large stack?

I tried it now. Same symptoms.

Duane Clark <> dclark@akamail.com> > wrote:

Colin Burgess wrote:

what is pid 12295?


12295 1 sbin/devc-pty 10r RECEIVE 1


which sh are you running?


Just the plain /bin/sh, though I also tried tcsh which I downloaded off
SourceForge. I executed it (tcsh) from the login sh shell. It had the
same symptoms.

Can you try running dumper, and seeing if any dumps are being generated?

Duane Clark <dclark@akamail.com> wrote:

Colin Burgess wrote:
Just trying to narrow the possibilities, did you try the large stack?

I tried it now. Same symptoms.


Duane Clark <> dclark@akamail.com> > wrote:

Colin Burgess wrote:

what is pid 12295?


12295 1 sbin/devc-pty 10r RECEIVE 1


which sh are you running?


Just the plain /bin/sh, though I also tried tcsh which I downloaded off
SourceForge. I executed it (tcsh) from the login sh shell. It had the
same symptoms.


cburgess@qnx.com

Colin Burgess wrote:

Can you try running dumper, and seeing if any dumps are being generated?

Okay, gave that a try, but no dump was made. Not even after doing a ^]
quit in telnet. I did force a dump just to make sure dumper was working
right.

I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem. You might want to post a query on
Duane Clark <dclark@akamail.com> wrote:

Colin Burgess wrote:
Can you try running dumper, and seeing if any dumps are being generated?


Okay, gave that a try, but no dump was made. Not even after doing a ^]
quit in telnet. I did force a dump just to make sure dumper was working
right.


cburgess@qnx.com

Colin Burgess <cburgess@qnx.com> wrote:

I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem. You might want to post a query on

Whoops - accidentally posted…

You might want to post on qdn.public.qnxrtp.os, and mention the
size issue and the type of network driver running…

Duane Clark <> dclark@akamail.com> > wrote:
Colin Burgess wrote:
Can you try running dumper, and seeing if any dumps are being generated?


Okay, gave that a try, but no dump was made. Not even after doing a ^]
quit in telnet. I did force a dump just to make sure dumper was working
right.


cburgess@qnx.com


cburgess@qnx.com

Colin Burgess wrote:

Colin Burgess <> cburgess@qnx.com> > wrote:

I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem. You might want to post a query on


Whoops - accidentally posted…

You might want to post on qdn.public.qnxrtp.os, and mention the
size issue and the type of network driver running…

Ok. I appreciate the time you’ve spent on this.

Colin Burgess wrote:

I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem…

Right you were. That comment got me to thinking the right way, and I
guess I have to kick myself for not thinking of it sooner.

The board has two ethernet interfaces, both running Davicom DM9102
interfaces (which is not officially supported by QNX). It turns out I
was running two different beta drivers simultaneously (oops, not
deliberately; and neither written by me), and I was connecting to the
port running one from Jumptec. When I configured both ports to use the
other (I can’t seem to find who wrote it, at the moment) it started
working fine. So sorry for the trouble, and thanks again for getting me
steered the right direction.

Hi Duane…

QNX folks are nice, aren’t they? Glad to hear that you solved your problem.

Regards…

Miguel.


Duane Clark wrote:

Colin Burgess wrote:

I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem…


Right you were. That comment got me to thinking the right way, and I
guess I have to kick myself for not thinking of it sooner.

The board has two ethernet interfaces, both running Davicom DM9102
interfaces (which is not officially supported by QNX). It turns out I
was running two different beta drivers simultaneously (oops, not
deliberately; and neither written by me), and I was connecting to the
port running one from Jumptec. When I configured both ports to use the
other (I can’t seem to find who wrote it, at the moment) it started
working fine. So sorry for the trouble, and thanks again for getting me
steered the right direction.

Your welcome. Glad to hear it resolved itself. You may want to ping
(sorry, couldn’t resist it! ;v) the support line at Jumptec to let them
know their driver has some troubles.

Duane Clark <dclark@akamail.com> wrote:

Colin Burgess wrote:
I’m at a loss right now, I’m afraid. It certainly sounds like
a networking related problem…

Right you were. That comment got me to thinking the right way, and I
guess I have to kick myself for not thinking of it sooner.

The board has two ethernet interfaces, both running Davicom DM9102
interfaces (which is not officially supported by QNX). It turns out I
was running two different beta drivers simultaneously (oops, not
deliberately; and neither written by me), and I was connecting to the
port running one from Jumptec. When I configured both ports to use the
other (I can’t seem to find who wrote it, at the moment) it started
working fine. So sorry for the trouble, and thanks again for getting me
steered the right direction.


cburgess@qnx.com