|
|
| Author |
Message |
| 25 new of 292 responses total. |
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.
|
jazz
|
|
response 225 of 292:
|
Nov 20 13:54 UTC 1999 |
Yup, I was using "ISDN CODEC" for what most people mean when they're
talking about "ISDN modems" - the box that sits between the ISDN line jack,
acts as a terminator, and may or may not route packets or manage PPP or mlPPP.
In this case it's clearly acting as a router if it's doing NAT, so "ISDN
router" would be my term of choice, but I didn't want to rule out the
possibility it was a fairly dumb serial device like a Motorola Bitsurfr.
I was thinking the ISDN router would be the likely culprit, but now
I'm wondering, since it doesn't seem likely that the router would recieve the
packet in question under normal circumstances - since there was only one box
sitting behind the router at the time the problem was seen - and it would be
unlikely that a third party could produce a packet that accidentally matched
a source/destination port pair and sequence number for a telnet session, and
that still wouldn't explain the connection hanging, something which I hadn't
read correctly before (and therefore didn't take into account).
|
gull
|
|
response 226 of 292:
|
Nov 20 18:41 UTC 1999 |
I've always heard it referred to as an "ISDN pipeline," but that might be
some company's proprietary name for them.
|
scg
|
|
response 227 of 292:
|
Nov 20 20:37 UTC 1999 |
Pipeline is Ascend's name for its routers.
|
flem
|
|
response 228 of 292:
|
Nov 20 20:39 UTC 1999 |
I think the technical term is "ISDN thingy". :)
|
gelinas
|
|
response 229 of 292:
|
Nov 20 22:38 UTC 1999 |
ISDN router works. I know it's not really a modem, since modems convert
from digital to analog and back, but that's what 3Com calls it, probably
to avoid confusing J Random Dialup User with too much accuracy. ;)
|
mdw
|
|
response 230 of 292:
|
Nov 21 08:13 UTC 1999 |
Grex wouldn't know anything at all about the ISDN router. TCP header
compression works by taking all the bits that are easily predictable
(like the IP header, tcp sequence number, etc.), & throwing them out.
They're put back into the packet by the receiving end. As long as the
two ends don't get confused, there shouldn't be any problems doing this.
However, in Joe's case, one end is also handling ISDN connections from N
other users, and Joe's end is doing NAT translation. So both ends have
at least the opportunity to get confused, and send packet data, with
forged "apparently real" tcp sequence numbers out. These forged packets
will contain someone else's data, which will explain Joe's confusion,
and since the real sender doesn't know this packet was sent, the real
sender's tcp sequence number will be behind the client's sequence
number. So, when the real sender sends data to the client, the client
will just toss it as "old" data. If Joe can, typing blindly, convince
the other end to send enough data, he *might* be able to get it to
resync, but that would definitely be a pretty desperate measure.
|
