response 181 of 292:

Nov 8 23:51 UTC 1999

        You're assuming that ISPs are always responsible for their users. 
That's not always the case.  I've had very bad luck contacting certain
administrations (as a system admin on other systems) - occasionally they'll
simply state that they're just not responsible for what happens with a wingate
proxy server on their network, since they do not directly administrate them.
M-Net's approach was to ban wingates when they were recognized (they have a
distinctive login prompt).

response 183 of 292:

Nov 9 01:20 UTC 1999

Actually, the simplest approach is to add more disk space.  The fact
this is becoming more & more of a problem is almost certainly an
indication that we're way closer to capacity than we should be.

response 185 of 292:

Nov 11 15:41 UTC 1999

I couldn't dial in this morning - had to telnet.

response 187 of 292:

Nov 11 18:23 UTC 1999

Don't know that this is a "problem", but why, when I was reading the agora
"man of the century" item, at the More prompt, did bbs display:

(Fixed item 119 flags 38->18 mtime 382b073a)
(Fixed item 119 rcnt 54)

response 189 of 292:

Nov 15 15:15 UTC 1999

I logged on once and got NO CARRIER after some gibberish.  Second login got
me to bbs with some gibberish along the way, but I can only read the first
one to five lines of anybody's response then it turns to gibberish.  Tried
both 761-3000 and 761-5041.  A new user also phoned (in Russian) to ask why
he got NO CAREER instead of e-mail.  (I can read what I am typing just fine,
and this is line six already).  Trying to read e-mail got me a line or two
of readable e-mail plus gibberish, for each e-mail.  We may have to go out
and fix the NO CAREER problem for the Russians if it is not a grex problem,
so would like to know before this evening if this is a general problem.

response 191 of 292:

Nov 15 18:24 UTC 1999

  I keep having NO CAREER problems, too, but I've been doing on-campus
  interviews, so hopefully they'll go away..

response 193 of 292:

Nov 15 21:32 UTC 1999

That can be done intentionally by judicious process killing, I believe.

response 195 of 292:

Nov 16 03:31 UTC 1999

        Kiwanis has a desperate need for external 14.4 baud modems
and internal modems of all speeds.
        So dear user, if you or your company has some surplus, or soon
to be surplus, try to get them reused by getting them to Kiwanis, 
Ann Arbor.

response 197 of 292:

Nov 16 17:18 UTC 1999

  Kiwanis is a charitable organization.  Several Grexers are active
  in the Ann Arbor chapter, which (among many other things) refurbishes
  old computer systems so people who couldn't ordinarily afford a new
  computer can still get a functioning machine suitable for at least
  basic word processing and e-mail..

response 199 of 292:

Nov 18 06:34 UTC 1999

Every now and again, I get things like:

Ok: che

new resp items  conference

-->   0    0 agora  (where you currently are!)
      3    0 coop
      0    0 books
      0    0 classicalmusic
      0    0 scifi
      0    0 micros
      0    0 diy
      0    0 rialto
chemie (4)
          </UL>
               <UL>Uni courses: 3. Fachsemester - winter 1952/53
                                                                <LI>605/606
Prof
.Frau Moufang: Analytische Geometrie II (5)
                                           <LI>609 Dr.Burger: Einf&uuml;hrung
in
 die Funktionentheorie (4)
                          <LI>646 Prof.D&auml;nzer: Physikalisches Praktikum
f&u
uml;r Physiker, Teil
                    II
                      (6)
                         <LI>661 Dr.Haase: Photographisches Praktikum (3)

</UL>

<P
>August 10 - 15:
                Basel-St.Chrischona, V.Mennonite World Conference in der
                Schweiz.
 <P>I get a ride with the MCC people to Basel, Harold S.Bender rules as a
                                                                        benign
pope. Peter J. Dyck

After the name, things just froze until the window went away.

response 201 of 292:

Nov 18 09:08 UTC 1999

I don't think so -- crosstalk problems with an analog connection are
just going to hose TCP performance, but with all the error correction
and detection at the hardware level, not to mention the complexity of IP
and TCP, it's just not at all likely that a noise phone line is going to
inject data into a telnet session in quite the way Joe reports here.

It does appear that something has managed to "inject" a tcp packet into
his telnet session which is certainly rather odd, to say the least.
Since it looks extremely random, it's probably a software glitch
somewhere, and not a purposeful mistake.  It might be worth collecting
the data from multiple occurrences and seeing if there's any pattern in
them that would make it possible to determine where they come from.  It
would also be worth doing a web search to see if the text can be found;
if it can, determing the offset and size of that text within the html
might provide some interesting clues.  It might also be worth asking the
operator of that site if they have log records indicating when that page
was fetched, and if so, where it was fetched during a 5 minute window
surrounding Joe's hung session.  If you can find out where that data was
*supposed* to go, then it should be easy to figure out where it got
misdirected.

Now, the places where the data could have gone astray include:
 (1) grex -- but nobody else has reported this problem, so grex is not
        likely
 (2) the michnet dialups - a bug in the portmaster that copies other
        people's data into your session?

Joe in fact appears to use mostly michnet dialups, plus some sessions
from a desktop machine at ITD, so--
 (3) something at Joe's end -- if he's sharing his PPP connection with
        something else, like a NAT, or a web browser, or something,
        perhaps whatever manages that PPP connection has problems.
 (4) some sort of really weird bug in Joe's hardware or software --
        perhaps it's randomly inserting unused junk into buffers, or
        the tcp stack is buggy, or something.

If the problem only happens on dialup connections, and Joe can't account
for this data within his household, then I imagine the michnet folks
would be very interested in this bug.

response 203 of 292:

Nov 18 09:43 UTC 1999

I don't think you have a large enough sample size to draw any
conclusions as to switch capacity vs. communication speed.  For all you
know, chicago may use copper from a different vendor, or may not be
faced with a phone system that is expanded as rapidly so can plan their
trunk capacity better and not be pushing their circuits to the limit.  I
believe statistical multiplexors (which *do* rely on the gaps in voice
communications) are pretty scarce now -- and a good thing too -- because
as I understand it, 28.8K modems don't work *at all* on such lines.

In any event, Joe's symptom just doesn't fit with this.  A problem with
the analog link could cause garbled data, long pauses, or actual lost
data.  Any of these will show up in ip as dropped, delayed, or slowed
packets, and Joe would be complaining a lot about "network lag".
Instead, he's looking at a logical error such as the sort PPP might make
if its header compression algorithm got confused and sent a packet off
to the wrong destination.  Since PPP strips off and regenerates the TCP
sequence number in doing header compression this is actually *very*
likely.

response 205 of 292:

Nov 18 15:25 UTC 1999

Grex just hung up on me.