| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4666.1 | | a-61.tunnel.crl.dec.com::needle | Money talks. Mine says "Good-Bye!" | Fri May 09 1997 15:53 | 15 |
| Windows NT is sending out SMB packets with the wrong source addresses and
causing long delays in mounting shares (once mounted, things work fine).
This is a known, reported problem to Microsoft, but resolution has been
very, very slow in coming. See
http://www.microsoft.com/kb/articles/q155/9/86.htm
for some of the details and a really disgusting, embarrassing suggestion for
a workaround (to paraphrase, "if you're seeing outside addresses on your
private network, simply route them").
We did things differently for V1.1, so you didn't see this problem.
j.
|
| 4666.2 | Don't think work around solves the problem | CSC32::G_DAVIDSON | | Mon May 19 1997 00:42 | 43 |
| Don't think the work around solves all problems.
Like Jay, I am also running version 4.0 Windows NT on an intel system. I
suspect that there is a problem with Netbios name resolution which is a
little more serious than just a timing issue. When I installed the new
tunnel client from the AltaVista software server the new version absolutely
wouldn't let me map any network shares no matter how many times I tried. It
simply wasn't able to recognize me, no matter if I supplied any valid share
along with my Domain and Username account within that domain. Only when I
reverted back to the old version was I once again able to access shares.
The major reason that I decided to try the new tunnel client is that I was
looking for a version of the tunnel that would stay connected reliably. I
have an ISDN line. Both my ISDN line and modem have never lost their
connection to the ISP. Furthermore I have never notice my internet
connection drop. Yet what I am seeing is that my tunnel frequently
disconnects almost everytime when it rekeys. I have tried going into the
registry upping some of the following tcpip parameters. By doing so I am
able to improve things so that I don't at least go down every time it
rekeys.
TcpMaxConnectAttempts: REG_DWORD:0x20
TcpMaxConnectRetransmission:t REG_DWORD:0x25
TcpMaxDataRetransmissions: REG_DWORD:0x15
TcpMaxRetransmissionAttempts: REG_DWORD:0x25
Do you have any other version of the tunnel (ie. even a field test version)
that I could try which doesn't break Netbios and can reliably remain
connected?
Just curious, is it necessary to rekey so often, or is it possible to let
the user of the tunnel control this through a variable setting? Is this an
option which I can presently control with the version of the software that
I am currently using? I was hoping that I could even turn rekeying off. I
suspect that if I could turn rekeying off that I could maintain my tunnel
connection. Boy wouldn't that be nice. You wouldn't believe how irritating
it is to have the tunnel going up and down on you like a yoyo. I might
actually be able to get some real work done instead of having to relog
into all of my sessions each time the tunnel drops.
Gail Davidson
[email protected]
|
| 4666.3 | | a-61.tunnel.crl.dec.com::needle | Money talks. Mine says "Good-Bye!" | Mon May 19 1997 16:32 | 20 |
| Sorry, I didn't mean to imply that the workaround was anything but a
brain-dead, ignorant idea that wasn't worth the time it took Microsoft
to write it up. The thought of simply setting up your "router" to
route red net packets to the blue net and vice versa is just plain silly.
There is no version of the AltaVista Tunnel which doesn't break SMB. We
didn't do it on purpose. We're working with Microsoft engineering to get
this fixed, but we've only been pushing for about 4 months, so things are
moving as quickly as ever with Microsoft. We hope to have a fix soon.
They've at least admitted to the problem and understand it.
As far as setting rekey intervals, the Tunnel 97 software supports rekeys
from between 30 minutes and 24 hours. With this release, that's a
system-wide setting at the server, and the current servers within Digital
only support the 30 minute rekey.
So other than not being able to mount shares, is the connection at least
staying up with the new version?
j.
|
| 4666.4 | Feedback on reliabiity of new tunnel software | CSC32::G_DAVIDSON | | Mon May 19 1997 17:11 | 10 |
| The version 2 tunnel was even more unreliable than the version 1
tunnel. Jay Walter is offering to do testing of the new tunnel software
if you want more detailed feedback on its reliability. If you want to directly
contact Jay, you can call him at (814)465-9986 or email address of
[email protected].
When I ran version 2 of the tunnel I had not altered any of my tcpip
settings in the register. I just recently upped the tcpip settings to
the values specified in note 4666.2. Since I have made these changes,
my tunnel has only gone down a few times today.
|