My apologies for not having followed protocol. I was not yet a list member
when I posted the query and had not read the FAQ/Policy statement.
-Stewart Weiss
weiss@roz.hunter.cuny.edu
ORIGINAL QUERY
My original query to the list is duplicated here for the reader's
convenience:
> This describes a problem that starting happening last week, which
> I have been able to diagnose only partly.
>
> The ls -l command, when issued over a modem line to a vt100 terminal
> interface, does not display the directory contents completely. After
> about the 5th or 6th line, it cuts out most of the listing midway in
> a file's state and resumes displaying the remainder of the directory
> afterwards. As an example:
>
> drwxr-xr-x 2 weiss 1536 Mar 2 21:54 bin/
> -rw------- 1 weiss 132 Jul 10 1996 calendar
> -rw------- 1 weiss 3832 Oct 18 22:05 config.tel
> drwx--x--- 16 weiss 1024 Mar 2 21:54 csadm/
> -rw------- 1 weiss 0 Mar drwxr-x--- 11 weiss 512 Mar 2 21:54 reviews/
> drwxr-xr-x 2 weiss 1024 Mar 2 21:54 roadmap/
> -rw------- 1 weiss 3135 Oct 2 12:40 seminars
>
> omitting all files between csadm and resources.
>
> What I have discovered is that
> * if I do ls -l > temp and then display temp using the more command,
> the output is normal
> * it happens no matter what directory I am listing
> * it happens consistently
> * it does not happen in a shell window of any size
> * if does not happen with a simple ls command
> * it seems to happen with any ls option that requires a long listing
> * it only happens when the dialup goes through one particular modem.
>
> Does anyone know enough about what the -l option to the ls command
> does to give me some insight into what might have gone wrong? It
> seems to be that some control character is interacting with some
> modem setting, but I do not have a clue as to which or how.
RESPONSE DATA
I received 19 responses.
All but two agreed that the cause of the problem was that the sending
modem was sending characters at a much faster rate than the receiving modem,
and because the two modems were not "handshaking" properly, data was being
lost on the receiving end. Most described this as a "flow control" problem,
stating that the problem was that the modems were using different methods
of flow control -- software versus hardware -- and therefore lost data.
All but one agreed that the problem had nothing to do with the ls -l
command per se, stating that any command that generated a lot of output
quickly would have the same effect. Suggestions were given to test that
hypothesis by using the "file *" command or cat-ing a large file.
The proposed solutions were divided. Most proposed that I check the modem
settings and make sure that hardware flow control was being used. One
suggested the opposite, to use software flow control. Some people suggested
making other changes, such as replacing cables, or even the modem. Some
people suggested seeing if the problem occurs when the modems are set to
the same speed.
One of the most useful suggestions was that I count the number of characters
displayed in the ls -l output up to the point where it is cut off, and use
that to determine where the problem might lie - which modem or which line
of communication was the problem (computer to sending modem, modem to modem,
or modem to terminal).
FURTHER STEPS AND CONCLUSIONS
I call the modem attached to the Sun workstation (a SPARC 10) the sending
modem, and the one that is attached to what I called the "terminal"
(actually a Macintosh running a terminal emulation package), the receiving
modem.
I verified that the sending modem was using hardware flow control.
The terminal emulation package on the receiving modem had both software
(xon/xoff) and hardware (rts/cts) flow control enabled. I tried changing the
flow control modes on the receiving modem last night (this is a home modem
and I can only test things from home) to no avail. The problem is the same
whether hardware, software, or both are enabled.
I tried cat-ing files of several thousand lines and had no problem.
Because the sending modem is set to detect the speed of the one that
initiated the call and adjust its speed accordingly, both modems are
operating at the same speed (9600). This is confirmed at connection time
by the display "Connect 9600". This fact argues against the hypothesis
that it is a flow control problem.
A count of the number of characters displayed before the output is lost
is 396. This is much smaller than the size of the buffer that either modem
uses for buffering data, and so this too argues against there being a flow
control problem. 396 = 11*9*4, so I am not sure if this is a packet size.
Because the two modems were communicating without any problems up until
last week, the problem must be the result of an event that took place
since then. But I have set the state of the sending modem to the exact
same state that it had then, and the problem persists. I have not yet
verified that the state of the receiving modem is what it had been. That
is my next step. The possible triggering event is that when I fingered
a student of mine, he had mischeiviously linked his .plan file to an
answerbook .pag file in binary format, and I now think it is possible that
some of the binary output might have changed the receiving modem's settings.
No other events took place.
In the event that its state is the same as it had been, I will try
dialing a different dial-up from the home modem and seeing if the same
problem occurs. Short of that, I have no other explanation at this time.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT