|
|
| Author |
Message |
| 25 new of 292 responses total. |
bdh3
|
|
response 200 of 292:
| 
Nov 18 08:37 UTC 1999 |
What you are seeing is overloaded voice swiches thrashing as they deal
with an enviroment of lots of data users over voice lines. Your 'onramp'
to the 'information superhighway' is a dirt road and most 'data' users
are driving lamborghinis. Get used to it. Or buy an ISDN or xDSL line.
|
mdw
|
|
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.
|
bdh3
|
|
response 202 of 292:
|
Nov 18 09:29 UTC 1999 |
Perhaps so. But I can assure you that in the heart of 'Silicon Valley'
I cannot get much more than a 28.8 connection (from everything from the
Hyatt to a 'single point' in a house while I can get at least a 44.6
connection from my house in south chicagoland with the same exact
equipment. (From SF proper down the CALTRAIN some number of tens of
miles I have noted the same.) Thus I conclude that the more 'data'
connections over a 'phone system' the more likelyhood of shitty
performance. Voice telephone 'switches' rely on the concept of 'pauses'
where somebody breaths and somebody else considers a response. The fact
is with 'modem' communication over 'voice' lines there are no such
things thus while a 'switch' may be able to 'handle' 100000 people
speaking over the same set of copper (corroded and 'dirty') wires it may
only be able to handle considerably less number of 'data' conversations.
Don't rule out a funamental inability of the 'infrastructure'.
|
mdw
|
|
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.
|
mdw
|
|
response 204 of 292:
|
Nov 18 09:45 UTC 1999 |
(Which reminds me -- something else Joe might try is to turn off header
compression.)
|
aruba
|
|
response 205 of 292:
|
Nov 18 15:25 UTC 1999 |
Grex just hung up on me.
|
jazz
|
|
response 206 of 292:
|
Nov 18 16:36 UTC 1999 |
I'm confused by Beady's remarks, as well. Almost all core switch
traffic is entirely digital, and has been for some time - a DS-0 is a DS-0
whether you're screaming your lungs off at a rock concert or whether it's
completely silent, and is only re-switched to a different path when there is
a network event.
This really is a fascinating problem. My bet would be with whatever
PPP server Merit is using (are they still Livingston Portmasters?) becoming
confused when routing or reassembling packet fragments. But I've never seen
anything like that from a Portmaster.
|
gull
|
|
response 207 of 292:
|
Nov 19 01:41 UTC 1999 |
Re #202: I bet it's got more to do with the local copper...or even modem
incompatibilities. Back when Michnet still had an 800 dialin, the best I
could get from Alma to the *local* Alma dialup was 21,600 baud, but I'd get
a full 28,800 to the 800 number -- which you'd expect to be the noisier
connection. The new modems they put in here at Tech are finicky and
sometimes won't talk 28.8 to my modem at all, and insist that I manually
force it to fall back to 14.4.
|
gelinas
|
|
response 208 of 292:
|
Nov 19 03:03 UTC 1999 |
Time to stop guessing, guys. I use ISDN from my home. I only use a
standard modem when I am out of town, which I'm not right now.
I think Marcus is on the right track: TCP injection. The only other
machine on this side of the ISDN modem is not on the network right now.
(If I plug it into the modem, the modem never hangs up, so that <expletive
deleted> NT machine is generating *some* kind of network traffic even
when no one is logged in to it. Blast.)
Now, this isn't the first time I've seen this behaviour on grex. My thought
was that it was something Backtalk was doing. I don't remember seeing
it any where else. Note, though, that I don't use Backtalk. (That *is*
the name of the web interface to Picospan, isn't it?)
So far as I know Merit is still using Portmasters. However, I think I
would have seen complaints about this in ITD's Online Consulting queue,
or seen other discussion of it, if it were happening to other users.
Just as you (and i) would expect other grex users to report it here,
if they were seeing it.
Tell you what. I'll start dumping the injections to a text file to
report here. I'll also work through UM to see if Merit is seeing other
complaints about this kind of behaviour.
|
mdw
|
|
response 209 of 292:
|
Nov 19 03:34 UTC 1999 |
It's true Jan Wolter (one of the authors of backtalk) does have a german
background, and has worked in academia, but I still doubt a bug in his
code is going to somehow go feral and start generating web pages
containing german class lists. Backtalk is, in any event, an ordinary
cgi script - it doesn't have the ability to hack into the kernel and
munge another processes tcp connection - or even its own (apache is
between it and the outside world.)
Some ISDN connections still use header compression. If you've got knobs
(virtual or otherwise) to twiddle on your end, it's certainly worth
experimenting with them.
|
gelinas
|
|
response 210 of 292:
|
Nov 19 04:28 UTC 1999 |
No knobs. Drat.
Well, you probably know the conferences here better than I do; I'm just a
newcomer. I've no reason to think the quoted text wouldn't appear in a
response here. Apparently, you do.
|
scg
|
|
response 211 of 292:
|
Nov 19 04:48 UTC 1999 |
What sort of ISDN equipment are you using on your end? Are you using NAT?
|
gelinas
|
|
response 212 of 292:
|
Nov 19 05:03 UTC 1999 |
It's a 3Com OfficeConnect LAN Modem. Yes, I'm using NAT, and allowing
"Automatic Incoming NAT".
|
goose
|
|
response 213 of 292:
|
Nov 19 05:44 UTC 1999 |
I just had a really wierd thing happen, maybe related, maybe not. After
waiting for a free port after it got down to 5 to go this appeared:
Nov 19 00:21 Nov 19 00:21 40977 -1 23733 203.246.133.92 LOST HEAD
Then when the port was free it only printed "Grex" and when I pressed
enter or any other key a few more characters would appear until the standard
grex login: prompt was in full view. But it wouldn't take my username it only
displayed anohter 'login:" after every keystroke for dozens of prompts.
finally it took my username, but not my password. I disconnected using my
terminal program, and reconnected only to find that it connected me with this
already 'open' port. ad I typed my password correctly and then disconected
someone could have aped my account. What up?
|
n8nxf
|
|
response 214 of 292:
|
Nov 19 12:04 UTC 1999 |
I had that happen to me too, a month or so ago.
|
scott
|
|
response 215 of 292:
|
Nov 19 13:27 UTC 1999 |
Extremely slow net connection?
|
aruba
|
|
response 216 of 292:
|
Nov 19 14:50 UTC 1999 |
Re #213: I've had that happen many times with Kermit for DOS. (STeve calls it
"tty constipation".) When I used to start up Kermit, something weird about my
system made it give me an error message about half the time. I can't remember
what it said, exactly, but it was something about not being able to interface
happily with the modem.
If I then went ahead and tried to connect to Grex, the terminal would be
constipated. I learned, after a few of those, to watch for the message when
Kermit started, and if I saw it, exit right away and start it again. It
almost always wasn't there on the second try, and then everything worked fine.
|
keesan
|
|
response 217 of 292:
|
Nov 19 17:08 UTC 1999 |
I got gibberish again today (on my 14.4 modem) and then a disconnect. I may
have fixed the problem by unplugging the power from my fax-phone switch for
10 seconds. Last time the problem occurred at both 14.4 and 2400 connect
speeds and usually my setup works perfectly Despite having five phone lines
plugged into my switch (one through a 1-2 adaptor). Jim did something fancy
with the system to make it work with extension phones, fax, phone, modem,
answering machine, and maybe it gets overloaded occasionally.
|
jazz
|
|
response 218 of 292:
|
Nov 19 21:47 UTC 1999 |
I have to wonder where the NAT is occuring that's mentioned in #212
- if I'm reading correctly, the ISDN CODEC, which has either a DHCP-assigned
or static address associated with the point-to-point bonded ISDN connection
(mlPPP, I'd wager) is performing NAT on behalf of several hosts attatched to
it, which may either have dynamically assigned or statically assigned
addresses (in the RFC 1918 range), *but* that there is only one functioning
host attatched to the CODEC.
I thought about the possibility of a program associated with a tty
failing to die gracefully upon recieving a SIGHUP and spewing output to the
terminal after the original owner had logged off of the tty, but that'd be
more likely to be processed HTML via lynx than unprocessed HTML source.
|
mdw
|
|
response 219 of 292:
|
Nov 19 22:21 UTC 1999 |
Extra output from a background process also wouldn't cause the telnet
session to "hang". In fact, however, there are at least 2 reasons why
this shouldn't happen -- (1) telnetd can't open a master pty if the
slave side is still "in use" by the previous owner, (2) when telnetd
runs, it calls "revoke" on the line which should mark any existing
descriptors "non-read/write".
|
gelinas
|
|
response 220 of 292:
|
Nov 20 03:46 UTC 1999 |
Hmmm. I don't understand the reference to the CODEC. The IP address
is assigned to the port on the Network Access Server, in this case a
Portmaster (I *think* Merit is still using Portmasters exclusively).
(And yes, Multi-link PPP is a possibility; I've configured my modem to
establish a second link when network usage demands it. It's been a while
since I got the link that busy. I usually see it when I insist on continuing
to work with telnet and the web while FTPing files.)
All packets come into the ISDN modem for the same address. The modem then
figures out which host on my side is supposed to get them. And then the
host has to figure out which window to display them in.
Oh, and yes, I've assigned static addresses to the machines on my side of
the network. (For instance, this Mac is currently 192.168.1.2.) But as
noted, only one machine is actually on the network right now.
|
senna
|
|
response 221 of 292:
|
Nov 20 06:45 UTC 1999 |
How do you change the spacebar prompt settings in party? A user was
trying to change the menu and ended up getting stuck with having to
space to talk, just like it used to be. They were quite frustrated.
|
scg
|
|
response 222 of 292:
|
Nov 20 07:44 UTC 1999 |
:set space and :set nospace.
|
mdw
|
|
response 223 of 292:
|
Nov 20 08:02 UTC 1999 |
I think what you are calling an "ISDN modem" is what jazz is calling an
"ISDN CODEC". It's definitely not really a modem -- they do make ISDN
modems, but they're most commonly used for the ISP side of 56K
connections (56K requires that one side of the connection be digital).
I don't think I'd call it a "CODEC" either, but I don't have a better
name for the box you evidently have at home which is doing the IP
address translation. In any event, that box is certainly the prime
suspect, quite possibly on conjunction with the portmaster (or whatever
it is) that's at the other end.
|
bmoran
|
|
response 224 of 292:
|
Nov 20 12:42 UTC 1999 |
That very same type of screen showed up in several responses in the
rec.food.coffee newsgroup a few days ago. Might have been a bigger problem
than just a few notes on grex.
|
