On Mon, 17 Jul 2000, Chris Holt wrote:
> On 17-Jul-00, David Woolley wrote:
> >
> > A few months back I changed ISPs. Under my old ISP, if I had a crash or
> > needed to reset, I could reboot and restart Miami and reconnect
> > instantly.
> >
> > Now, under my new ISP, this almost never happens. Usually, it gets stuck
> > on "Finding DNS servers". If I click "Canel" then Miami locks up. If I
> > leave it for a couple of minutes, it sometimes reconnects, but Miami
> > locks up. In almost every case, the only way to go offline is to switch
> > off my modem.
> >
> > I've played around with a few settings, but no joy. Can anyone help me
> > out, this is becoming really annoying.
>
> Have you tried making the DNS servers permanent entries? I am already
> required to do that, as the DNS servers that get "looked up" by Miami, are
> not correct for my ISP. (due to them using another provider for the POP
> in my area)
It's preferable to use the automatic method when it works, since if the
ISP is doing their job right it means you'll automatically track any
changes they make to the DNS IPs. However, if they do it wrong then you
may need to make static entries and perhaps even disable the automatic
ones to get around it.
> I get nearly instant reconnects as you used to.
When the automatic method is working correctly, it adds negligible
overhead to the connection time. But if the termserver is misbehaving or
delivering unusable DNS IPs, then you may have trouble.
On Mon, 17 Jul 2000, Chris Holt wrote:
> On 17-Jul-00, Michael M. Rye wrote:
> >
> > Are you using the "Quick Reconnect" feature in Miami ???
> > Do you have it set to the "File" option ???
>
> I've always had that option disabled and I get a reconnect almost
> instantly, just as David used to.
There's no reason to enable Quick Reconnect if it works without it.
On Tue, 18 Jul 2000, Tim Seifert wrote:
>
> Not all ISPs support reconnection (one of mine doesn't), some will
> support it fully; and some will let you do it, if they don't know you're
> attempting it. The file option is the best choice for them (instead of
> your stack polling the ISP to get the information it wants about the
> current connect, Miami recalls the data it saved when it first
> connected, for the current session).
Yes, reconnection is not something explicitly supported in the standards
at all. First of all, there are really only two good reasons for wanting
such a feature in the first place:
1) The phone rate structure adds a significant penalty to new calls.
2) The ISP has so few lines that you don't want to let go of one once
you've gotten past the busies (note the positive feedback in this
arrangement).
If neither of these applies, and you're simply conecrened about saving 20
seconds of call setup time after a crash, then you've got way too many
crashes. You can't keep TCP connections across a crash anyway, and
starting with a fresh call might fix some "poisoning" that had occurred
earlier. Also, DTR hangup is more reliable than the "+++" kludge, but you
can't use DTR hangup if you want to reconnect after a crash.
> One of my ISPs will hang up immediately, if I try to reconnect, without
> using the file option. The other one will quite happily let me
> reconnect; in fact, this one is often quicker to let Miami re-connect by
> polling the ISP, instead of using the file.
This is mainly a function of the PPP implementation, and whether it
supports going back to LCP negotiations after having an NCP open.
> Though, sometimes it will wait forever for the server to respond with
> the data, requiring a couple of reboots, to avoid hanging up and
> re-dialling (Miami will, otherwise, either wait for ages, then complain,
> or hang up).
You might try to get PPP logs of the series of attempts.
On Wed, 19 Jul 2000, David Woolley wrote:
> On 19-Jul-00, Tim Seifert wrote:
>
> > How likely is a crash, at that stage? Just as likely as any program
>
> When exactly does it save?
That's an important issue. Obviously it saves when going online
initially. It may or may not save when reconnecting, since it might not
be smart enough to avoid it. The time following a crash often has a
heightened risk of additional crashes if hardware is involved, so it
wouldn't be a good time to be writing disk.
> IBrowse writes to the cache, and occasionally crashes whilst doing so.
It helps to use a separate scratch partition for things like browser
caches. Not only does it validate faster, but if it gets really fouled up
you can just reinitialize it without losing anything important.
> The single most unstable programme I use is IBrowse. I use IBrowse on the
> Net (and sometimes offline). Hence, when I'm on the Net, I try to avoid
> disk writes. It is inevitable, such as when downloading files, so I don't
> do anything else whilst I'm doing that.
IBrowse doesn't crash very often here. Maybe you're too generous with the
RAM cache and it's getting into low-memory trouble.
On Fri, 21 Jul 2000, Tim Seifert wrote:
> By: Michael M. Rye <[EMAIL PROTECTED]>
> On: Thursday, July 20, 2000 7:13 AM
>
> > The quick reconnect is used in conjunction with the "CD" check
> > box of the modem hardware config. If Miami detects a carrier
> > using the CD line (i.e. the modem is still connected), it will
> > not try to use the file. Miami will use the file if it detects
> > that the modem is not already connected (CD again).
>
> Don't you mean the other way around? If you try to reconnect, and Miami
> determines your MODEM is already on-line, it reads the file to get the
> connection information, rather than polling the ISP.
Neither is quite correct.
If CD is not asserted, or "Use CD" isn't enabled, then it's not a
"reconnection" at all, and goes through the dialer and everything. If CD
is asserted and "Use CD" is enabled, it reconnects either by reinitiating
LCP negotiations if Quick Reconnect is disabled, or by using the data in
the file or RAM area as appropriate.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
