Connection problems

[Steve Clark]

I too have been having connection problems recently, using Socketeer and
dial-up.

When I try to log on when I get home from work (around midnight) my
computer usually sticks trying to negotiate after connecting. If I try
again later then I usually manage to connect ok.

What appears to be critical is that when I fail I am trying to connect
with 213.130.146.204 but when I succeed it is by connecting to
213.130.146.203.

Does anyone else have a similar problem?

[Tennant Stuart]

Post by Steve Clark
I too have been having connection problems recently, using Socketeer and
dial-up.
When I try to log on when I get home from work (around midnight) my
computer usually sticks trying to negotiate after connecting. If I try
again later then I usually manage to connect ok.
What appears to be critical is that when I fail I am trying to connect
with 213.130.146.204 but when I succeed it is by connecting to
213.130.146.203.
Does anyone else have a similar problem?

Oooh? How can you tell?

This happened once before with Argonet, and there was a command we
would type into a task window, which gave significant results. But
I'm not sure we could now do that if the mail/news has locked up.


Tennant

[Steve Clark]

Post by Tennant Stuart

Post by Steve Clark
I too have been having connection problems recently, using Socketeer and
dial-up.
When I try to log on when I get home from work (around midnight) my
computer usually sticks trying to negotiate after connecting. If I try
again later then I usually manage to connect ok.
What appears to be critical is that when I fail I am trying to connect
with 213.130.146.204 but when I succeed it is by connecting to
213.130.146.203.
Does anyone else have a similar problem?

Oooh? How can you tell?
This happened once before with Argonet, and there was a command we
would type into a task window, which gave significant results. But
I'm not sure we could now do that if the mail/news has locked up.

With Socketeer the (full-size) connection statistics window gives all
sorts of interesting information. You can use it to follow a log-on from
start to finish so you can see exactly where it is in the process.

Incidentally, I just logged on now to ....204 without problems - it only
seems to hang up around midnight.

BTW I live in London.

[Paul Vigay]

In article <***@ormail.co.uk>,
Steve Clark <***@ormail.co.uk> wrote:

[Snip]

Post by Steve Clark
With Socketeer the (full-size) connection statistics window gives all
sorts of interesting information. You can use it to follow a log-on from
start to finish so you can see exactly where it is in the process.

Does Socketeer tell you the DNS settings too? (I can't try it because it's
not 32-bit unfortunately).

It might be interesting to see if you get different DNS server IP addresses
if you set the dialup settings to dynamic, rather than the fixed addresses
which Voyager uses.

Paul

[Nick Roberts]

Post by Tennant Stuart

Post by Steve Clark
I too have been having connection problems recently, using
Socketeer and dial-up.
When I try to log on when I get home from work (around midnight) my
computer usually sticks trying to negotiate after connecting. If I
try again later then I usually manage to connect ok.
What appears to be critical is that when I fail I am trying to
connect with 213.130.146.204 but when I succeed it is by connecting
to 213.130.146.203.
Does anyone else have a similar problem?

Oooh? How can you tell?
This happened once before with Argonet, and there was a command we
would type into a task window, which gave significant results. But
I'm not sure we could now do that if the mail/news has locked up.

Try "Show Inet$RemoteIP" in a command window any time after connecting.
You don't even have to do it while connected, it stays set until
overwritten the next time you connect.

[Paul Vigay]

Post by Nick Roberts
Try "Show Inet$RemoteIP" in a command window any time after connecting.
You don't even have to do it while connected, it stays set until
overwritten the next time you connect.

I would also recommend typing "*Show Inet$Resolvers" both before and after
connecting, and please report the values to the support email address.

Incidentally, although the topic has been discussed here quite a bit, I've
only received two reports to the official support email address, so I
presume it's not affecting that many people at all.

Whilst I do check the newsgroups from time to time, this is not an official
forum for reporting support issues, because I reserve the right to not read
newsgroups for extended periods of time, so can't guarantee to investigate
topics discussed here.

Paul

[Tennant Stuart]

Post by Paul Vigay
Incidentally, although the topic has been discussed here quite a bit,
I've only received two reports to the official support email address,
so I presume it's not affecting that many people at all.

Fair enough, although the email/news is now working very well again,
despite making no changes to Voyager software or the modem driver.

Post by Paul Vigay
Whilst I do check the newsgroups from time to time, this is not an
official forum for reporting support issues, because I reserve the right
to not read newsgroups for extended periods of time, so can't guarantee
to investigate topics discussed here.

Fair enough, although it's through the newsgroup we discover that other
people are suffering the same support issues, and that the fault is not
anything to do with all the excuses we have been fobbed off with.


Tennant

[Paul Vigay]

In article <***@orpheusmail.co.uk>,
Tennant Stuart <***@orpheus.co.uk> wrote:

[Snip]

Post by Tennant Stuart
Fair enough, although it's through the newsgroup we discover that other
people are suffering the same support issues, and that the fault is not
anything to do with all the excuses we have been fobbed off with.

Who's fobbing you off with excuses? Certainly not me, and I resent implied
comments like that.

I've been as accurate and straight-forward as I can in my newsgroup
comments. I won't bother commenting on this newsgroup if you're going to
make comments like that.

[Tennant Stuart]

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
Fair enough, although it's through the newsgroup we discover that other
people are suffering the same support issues, and that the fault is not
anything to do with all the excuses we have been fobbed off with.

Who's fobbing you off with excuses? Certainly not me, and I resent implied
comments like that.
I've been as accurate and straight-forward as I can in my newsgroup
comments. I won't bother commenting on this newsgroup if you're going to
make comments like that.

As soon as we reoprt a problem, we're told it's our software that's at
fault, or we're using the wrong modem driver, even though up until then
everything has been working well; and now also everything is working well
despite making no change whatsoever to Voyager or our modems.

Somebody somewhere found out what the real problem was, and fixed it,
without telling the rest of us. Who knows when it'll go wrong again.

Right now there's a lot of excitement about the resolver numbers being
not as expected, but we've used them successfully since Orpheus began.


Tennant

[Paul Vigay]

In article <***@orpheusmail.co.uk>,
Tennant Stuart <***@orpheus.co.uk> wrote:

[Snip]

Post by Tennant Stuart
As soon as we reoprt a problem, we're told it's our software that's at
fault, or we're using the wrong modem driver, even though up until then
everything has been working well; and now also everything is working well
despite making no change whatsoever to Voyager or our modems.

That's not fobbing you off. That's a genuine enquiry as to find out what,
if anything, might be posing a problem at your end.

Post by Tennant Stuart
Somebody somewhere found out what the real problem was, and fixed it,
without telling the rest of us. Who knows when it'll go wrong again.

Don't start making accusations like that. Absolutely nothing has changed at
the Orpheus end - and if it had, I'd say so.

Post by Tennant Stuart
Right now there's a lot of excitement about the resolver numbers being
not as expected, but we've used them successfully since Orpheus began.

Then you've been lucky. Those resolver numbers are Pipex's which are NOT
guaranteed to work and are NOT the responsibility of Orpheus. Therefore
this constitutes "a problem at your end. Like I said, please don't accuse
Orpheus of being at fault when it is locally something on your machine (ie.
incorrect resolver values or a clash of software).

Paul

[Tennant Stuart]

In article <***@bc63.orpheusinternet.co.uk>,
Nick Roberts

Post by Nick Roberts

Post by Tennant Stuart

Post by Steve Clark
I too have been having connection problems recently, using
Socketeer and dial-up.
When I try to log on when I get home from work (around midnight) my
computer usually sticks trying to negotiate after connecting. If I
try again later then I usually manage to connect ok.
What appears to be critical is that when I fail I am trying to
connect with 213.130.146.204 but when I succeed it is by connecting
to 213.130.146.203.
Does anyone else have a similar problem?

Oooh? How can you tell?
This happened once before with Argonet, and there was a command we
would type into a task window, which gave significant results. But
I'm not sure we could now do that if the mail/news has locked up.

Try "Show Inet$RemoteIP" in a command window any time after connecting.
You don't even have to do it while connected, it stays set until
overwritten the next time you connect.

Okay Nick, I will, plus Paul's suggestion of "Show Inet$Resolvers",
which incidentally just gave me the response...

inet$resolvers : 158.43.240.4 158.43.240.3

..even though I've not logged on at all since switching on today.


Tennant

[Paul Vigay]

In article <***@orpheusmail.co.uk>,
Tennant Stuart <***@orpheus.co.uk> wrote:

[Snip]

Post by Tennant Stuart
Okay Nick, I will, plus Paul's suggestion of "Show Inet$Resolvers",
which incidentally just gave me the response...
inet$resolvers : 158.43.240.4 158.43.240.3
..even though I've not logged on at all since switching on today.

Those resolvers are wrong, and nothing to do with Orpheus - so that could
certainly account for you not being able to check email and/or news if
indeed you even manage to connect ok.

Where is your computer picking up those resolvers from? Either your Voyager
is corrupt or you have some other internet software installed on your
machine, which is interfering with things?

Paul

[Colin Matthews]

Post by Paul Vigay

Post by Tennant Stuart
inet$resolvers : 158.43.240.4 158.43.240.3
..even though I've not logged on at all since switching on today.

Those resolvers are wrong, and nothing to do with Orpheus - so that
could certainly account for you not being able to check email
and/or news if indeed you even manage to connect ok.

I get the same resolvers. (And intermittent connection problems. But
I'm not complaining about Orpheus, for which continued thanks!)

Colin

[Paul Vigay]

I get the same resolvers. (And intermittent connection problems. But I'm
not complaining about Orpheus, for which continued thanks!)

Hmm. I'm wondering if this is possibly the root of peoples problems....

Those resolvers are incorrect and shouldn't be set. From memory I think
they're the old Argonet resolvers, so this would indicate that something
inside Voyager either hasn't updated to Orpheus properly, or another copy
of Voyager and/or internet software has been seen on the machine.

If you have these resolvers whilst online then it's bound to cause problems
somewhere, which I think could point to why some people are having
problems....

regards,
Paul

[Colin Matthews]

Post by Paul Vigay
Those resolvers are incorrect and shouldn't be set. From memory I
think they're the old Argonet resolvers, so this would indicate
that something inside Voyager either hasn't updated to Orpheus
properly, or another copy of Voyager and/or internet software has
been seen on the machine.
If you have these resolvers whilst online then it's bound to cause
problems somewhere, which I think could point to why some people
are having problems....

I have this line in !Voyager.!Run : if "<inet$resolvers>"="" then set
inet$resolvers 158.43.240.4 158.43.240.3

Colin

[Alan Griffin]

I've just logged on, and the computer froze immediately after
authentification.

I did an alt-break, and cancelled the news download - still frozen.
Another alt-break and disabled mail fetch - computer unfroze.

Every time I clicked on mail-fetch, the computer immediately froze.

I disconnected and immediately reconnected, and everything worked
fine, and my news and mail downloaded.

Is it because I was connected to a different server?

Alan Griffin

[Ben Crick]

Post by Colin Matthews
I have this line in !Voyager.!Run : if "<inet$resolvers>"="" then set
inet$resolvers 158.43.240.4 158.43.240.3

Me 2! Should I overwrite these numbers with
213.130.128.32 and 213.130.128.33 for the Orpheus servers
or will that make things worse?

Should I amend both !Voyager.!Run and !Voyager.Stack.Startup
with the Orpheus server numbers?

Ben

[Paul Vigay]

Me 2! Should I overwrite these numbers with 213.130.128.32 and
213.130.128.33 for the Orpheus servers or will that make things worse?
Should I amend both !Voyager.!Run and !Voyager.Stack.Startup with the
Orpheus server numbers?

Yes, Name servers should be consistent, so you should replace all
occurrences of the incorrect ones with 213.130.128.32 and 213.130.128.33

I suspect this might be what's causing the problems some people are having.
I knew it was probably something local to the user. :-)

[Ben Crick]

Post by Paul Vigay
Yes, Name servers should be consistent, so you should replace all
occurrences of the incorrect ones with 213.130.128.32 and 213.130.128.33
I suspect this might be what's causing the problems some people are having.
I knew it was probably something local to the user. :-)

Thanks, Paul!

Ben

[Paul Vigay]

In case anyone is still having problems with Voyager stalling after
connecting to Orpheus, I've written some instructions explaining the
problem. They're now online at
http://www.orpheusinternet.co.uk/support/riscos/voyager/problems.html#dns

Hope they make sense.

Paul

[Alan Griffin]

Post by Paul Vigay
In case anyone is still having problems with Voyager stalling after
connecting to Orpheus, I've written some instructions explaining the
problem. They're now online at
http://www.orpheusinternet.co.uk/support/riscos/voyager/problems.html#dns
Hope they make sense.

Thank you Paul.
I have had no more problems since I changed this.
Should the upgrade have done this for me automatically?

Alan Griffin

[Paul Vigay]

Post by Alan Griffin
Should the upgrade have done this for me automatically?

It should have, but I think one of the early versions of the upgrader
didn't change all the files correctly. I think v1.04 was the first one
which did - but I'll double-check.

Paul

[Dr J E Hurley]

Post by Paul Vigay

Post by Alan Griffin
Should the upgrade have done this for me automatically?

It should have, but I think one of the early versions of the upgrader
didn't change all the files correctly. I think v1.04 was the first one
which did - but I'll double-check.
Paul

I am afraid I used 1.04 and have the incorrect numbers (which may explain my
problem which started all this off). So will follow the upgrade
instructions.

John

[Tennant Stuart]

Post by Paul Vigay

Post by Paul Vigay
In case anyone is still having problems with Voyager stalling after
connecting to Orpheus, I've written some instructions explaining the
problem. They're now online at

http://www.orpheusinternet.co.uk/support/riscos/voyager/problems.html#dns

Post by Paul Vigay
Hope they make sense.

I have had no more problems since I changed this.

I have not (yet) changed the numbers, but have no more problems either.


Tennant

[Paul Vigay]

In article <***@orpheusmail.co.uk>,
Tennant Stuart <***@orpheus.co.uk> wrote:

[Snip]

Post by Tennant Stuart
I have not (yet) changed the numbers, but have no more problems either.

Yes, but you're also relying on the availability and reliability of Pipex's
DNS servers - so don't complain to me if they suddenly stop working again
for no reason! :-)

[Tennant Stuart]

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
I have not (yet) changed the numbers, but have no more problems either.

Yes, but you're also relying on the availability and reliability of
Pipex's DNS servers - so don't complain to me if they suddenly stop
working again for no reason! :-)

Well, having proved my point, I did eventually change the numbers.

And then tonight (0:34am), the problems started happening again:

Inet$RemoteIP : 213.130.146.204

inet$resolvers : 213.130.128.32 213.130.128.33


I've been doing these two commands for weeks now, and the difference is
definitely in what I assume is a server number, but not exclusively...

About a quarter of logins go to 213.130.146.202 which *always* works.

About a quarter of logins go to 213.130.146.203 which *always* works.

About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.


One explanation of this is that there are four servers, except two of
them have the same Inet$RemoteIP number, and one of those goes wrong.


Tennant (HTH)

[Dr J E Hurley]

Post by Tennant Stuart
About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.

Yes problems started again late yesterday and this morning aftter a period
of respite.

[Steve Clark]

Post by Tennant Stuart

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
I have not (yet) changed the numbers, but have no more problems either.

Yes, but you're also relying on the availability and reliability of
Pipex's DNS servers - so don't complain to me if they suddenly stop
working again for no reason! :-)

Well, having proved my point, I did eventually change the numbers.
Inet$RemoteIP : 213.130.146.204
inet$resolvers : 213.130.128.32 213.130.128.33
I've been doing these two commands for weeks now, and the difference is
definitely in what I assume is a server number, but not exclusively...
About a quarter of logins go to 213.130.146.202 which *always* works.
About a quarter of logins go to 213.130.146.203 which *always* works.
About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.
One explanation of this is that there are four servers, except two of
them have the same Inet$RemoteIP number, and one of those goes wrong.

This correlates with what I reported elsewhere on this thread. It's only
213.130.146.204 which gives problems.

I've bundled up a collection of Socketeer debug scripts and sent them to
PV in the hope they will help him get to the bottom of it.

[Paul Vigay]

In article <***@ormail.co.uk>,
Steve Clark <***@ormail.co.uk> wrote:

[Snip]

Post by Steve Clark
This correlates with what I reported elsewhere on this thread. It's only
213.130.146.204 which gives problems.
I've bundled up a collection of Socketeer debug scripts and sent them to
PV in the hope they will help him get to the bottom of it.

And I've escalated the problems to our telecoms engineers who are
investigating the problem as I type this. Thanks.

[Tennant Stuart]

Post by Paul Vigay
[Snip]

This correlates with what I reported elsewhere on this thread. It's
only 213.130.146.204 which gives problems.
I've bundled up a collection of Socketeer debug scripts and sent them to
PV in the hope they will help him get to the bottom of it.

And I've escalated the problems to our telecoms engineers who are
investigating the problem as I type this. Thanks.

Do you know how many servers there are supposed to be? From the figures
it looks like there are four, two of which have the same identity - since
one of those twins is the bad server, that might be where the fault is.


Tennant

[Alexr]

Post by Steve Clark

Post by Tennant Stuart
Inet$RemoteIP : 213.130.146.204
inet$resolvers : 213.130.128.32 213.130.128.33
I've been doing these two commands for weeks now, and the difference is
definitely in what I assume is a server number, but not exclusively...
About a quarter of logins go to 213.130.146.202 which *always* works.
About a quarter of logins go to 213.130.146.203 which *always* works.
About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.
One explanation of this is that there are four servers, except two of
them have the same Inet$RemoteIP number, and one of those goes wrong.

This correlates with what I reported elsewhere on this thread. It's only
213.130.146.204 which gives problems.

I have had occasional failed connections with the ANT suite. I have been
saving the session log when this happens, and these show fairly consistent
problems when assigned to 213.130.146.204 - 7/10 connections failed with
pop3 timed out after 60 seconds, and an inability to resolve any other
sites. 6 of 7 failed connections were around midnight, the 7th about 7am.
Not as problematical as Voyager, in that one just clicks to hang-up, then
try a little later hoping to miss the dreaded server.

Connection with 213.130.146.203 has not produced any problems;
213.130.146.202 has resulted in one news fetch being aborted in midfetch
when the remote system hung up on me, and one other recent occasion around
midnight with "failed to resolve pop.orpheusnet.co.uk" followed shortly
thereafter with the total collapse of ANT: InetSuite with a fatal internal
error. I dial in from St Albans.

Alex.

* Nothing is foolproof to a sufficiently talented fool.

[Nick Roberts]

Post by Tennant Stuart

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
I have not (yet) changed the numbers, but have no more problems either.

Yes, but you're also relying on the availability and reliability of
Pipex's DNS servers - so don't complain to me if they suddenly stop
working again for no reason! :-)

Well, having proved my point, I did eventually change the numbers.
Inet$RemoteIP : 213.130.146.204
inet$resolvers : 213.130.128.32 213.130.128.33
I've been doing these two commands for weeks now, and the difference
is definitely in what I assume is a server number, but not
exclusively...
About a quarter of logins go to 213.130.146.202 which *always* works.
About a quarter of logins go to 213.130.146.203 which *always* works.
About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.
One explanation of this is that there are four servers, except two of
them have the same Inet$RemoteIP number, and one of those goes wrong.

If there are two servers with the same IP address, it's likely that
everybody would notice problems, not just a subset. And the
same-numbered servers would rarely, if ever, work.

I was hit by a pseudo-freeze last night, which is the first time it has
ever happened to me when accessing Orpheus from home. Resolver IPs are
as above, as is the remote IP.

I call it a "pseudo"-freeze, because (as I am using POPstar &
NewsHound), my machine didn't freeze; however, POPstar and NewsHound
both refused to resolve the server names to IP addresses, while
FreeTime got hung up on "Connecting to server", so I would guess that
this was also a resolver issue.

I think it unlikely that it is the resolver module at fault, as I'm not
using the Internet stack inside Voyager, but the RISC OS 4 ROM version.

Eventually it all worked (with the same remote IP address each time),
but it took 3 or 4 tries.

[Tennant Stuart]

Post by Nick Roberts

Post by Tennant Stuart

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
I have not (yet) changed the numbers, but have no more problems either.

Yes, but you're also relying on the availability and reliability of
Pipex's DNS servers - so don't complain to me if they suddenly stop
working again for no reason! :-)

Well, having proved my point, I did eventually change the numbers.
Inet$RemoteIP : 213.130.146.204
inet$resolvers : 213.130.128.32 213.130.128.33
I've been doing these two commands for weeks now, and the difference
is definitely in what I assume is a server number, but not
exclusively...
About a quarter of logins go to 213.130.146.202 which *always* works.
About a quarter of logins go to 213.130.146.203 which *always* works.
About one half of logins go to 213.130.146.204 which usually works,
except during the bad times (it seems that another bad time has just
begun) when it crashes on news/email fetch about *half* of the time.
One explanation of this is that there are four servers, except two of
them have the same Inet$RemoteIP number, and one of those goes wrong.

If there are two servers with the same IP address, it's likely that
everybody would notice problems, not just a subset. And the
same-numbered servers would rarely, if ever, work.

How else do you explain the addresses are 25% 202, 25% 203, 50% 204?

Post by Nick Roberts
I was hit by a pseudo-freeze last night, which is the first time it has
ever happened to me when accessing Orpheus from home. Resolver IPs are
as above, as is the remote IP.
I call it a "pseudo"-freeze, because (as I am using POPstar &
NewsHound), my machine didn't freeze; however, POPstar and NewsHound
both refused to resolve the server names to IP addresses, while
FreeTime got hung up on "Connecting to server", so I would guess that
this was also a resolver issue.
I think it unlikely that it is the resolver module at fault, as I'm not
using the Internet stack inside Voyager, but the RISC OS 4 ROM version.

And your experience shows this is nothing to do with Voyager.

Post by Nick Roberts
Eventually it all worked (with the same remote IP address each time),
but it took 3 or 4 tries.

You will find that when it works with the same remote IP address, that
was the mysterious 204 pair, going from the bad one to the good one.


Tennant

[Nick Roberts]

Post by Tennant Stuart

Post by Nick Roberts

Post by Tennant Stuart
One explanation of this is that there are four servers, except
two of them have the same Inet$RemoteIP number, and one of those
goes wrong.

If there are two servers with the same IP address, it's likely that
everybody would notice problems, not just a subset. And the
same-numbered servers would rarely, if ever, work.

How else do you explain the addresses are 25% 202, 25% 203, 50% 204?

I don't have any definitive suggestions - but if your suggestion were
accurate, everybody would be suffering the 25% failure rate, and I am
experiencing nothing like that severe.

I have recent experience of what happens to an intranet when two
machines have the same IP, because it occurred at work a fortnight ago:
one switch crashed, and when it rebooted for some reason it insisted on
using the same IP as another switch. The end result was that the two
involved subnets absolutely crawled (file copies that should have taken
seconds took minutes and often failed), and the more time-sensitive
parts of the rest of the network showed considerable unreliability.

The point is the entire IP protocol is built around uniqueness of
addresses. If that principle is breached, the protocol can't ensure
that the right packets get to the right servers in the right order, and
Bad Things Happen (TM).

Post by Tennant Stuart

Post by Nick Roberts
I was hit by a pseudo-freeze last night, which is the first time it
has ever happened to me when accessing Orpheus from home. Resolver
IPs are as above, as is the remote IP.
I call it a "pseudo"-freeze, because (as I am using POPstar &
NewsHound), my machine didn't freeze; however, POPstar and
NewsHound both refused to resolve the server names to IP addresses,
while FreeTime got hung up on "Connecting to server", so I would
guess that this was also a resolver issue.
I think it unlikely that it is the resolver module at fault, as I'm
not using the Internet stack inside Voyager, but the RISC OS 4 ROM
version.

And your experience shows this is nothing to do with Voyager.

I wasn't trying to suggest that it was anything to do with Voyager. The
nearest I've ever come to this is the suggestion that it may be the
auto-upgrader trying to find a non-existent site.

The reason I posted the above was to counter Paul's suggestion that it
may be a problem with the Voyager resolver or one of the Voyager
fetchers (or indeed, anything to do with Voyager at all other than the
dialler - and if it where the dialler at fault it would be persistant).

Post by Tennant Stuart

Post by Nick Roberts
Eventually it all worked (with the same remote IP address each
time), but it took 3 or 4 tries.

You will find that when it works with the same remote IP address,
that was the mysterious 204 pair, going from the bad one to the good
one.

I'm sorry, but I reiterate - it cannot be anything this obvious. Having
two machines with the same IP address acting as internet gateways would
have obvious and measurable characteristics:

1) Both servers would be unreliable due to IP clashes, not just one;

& 2) it would affect everybody at the roughly the same rate.

Item 2 is observably not the case; and item 1 is incompatible with your
suggestion.

[Alan Griffin]

Post by Paul Vigay
They're now online at

Post by Paul Vigay
http://www.orpheusinternet.co.uk/support/riscos/voyager/problems.html#dns
Hope they make sense.

Thank you Paul.
I have had no more problems since I changed this.
Should the upgrade have done this for me automatically?

I'm sorry to have to report this, but my computer froze again tonight just
as before when trying to do a mail download. Every time I clicked on
"mail" it froze.

What else could be causing this?

Alan Griffin

[Graham Sumner]

Post by Paul Vigay
Yes, Name servers should be consistent, so you should replace all
occurrences of the incorrect ones with 213.130.128.32 and 213.130.128.33
I suspect this might be what's causing the problems some people are
having. I knew it was probably something local to the user. :-)

Thanks Paul, I've been having similar probs off and on for a while. I was
catching up on my reading of the ng when I saw this thread.

Changed the figures and all is working OK.

Graham

[R Fred Williams]

Post by Paul Vigay

I get the same resolvers. (And intermittent connection problems. But I'm
not complaining about Orpheus, for which continued thanks!)

Hmm. I'm wondering if this is possibly the root of peoples problems....
Those resolvers are incorrect and shouldn't be set. From memory I think
they're the old Argonet resolvers, so this would indicate that something
inside Voyager either hasn't updated to Orpheus properly, or another copy
of Voyager and/or internet software has been seen on the machine.
If you have these resolvers whilst online then it's bound to cause
problems somewhere, which I think could point to why some people are
having problems....

Time for a "me too", I feel.

A bit of data mining:-

A search reveals that the dodgy numbers turn up in two places in
my Voyager setup:-

!voyager.!Run
and
!voyager.Stack.Startup:-

My version of !VoyUpdate was 1.03, which includes neither of the above
files within its "updates.!Voyager" directory.

(f/x - logs on, checks orpheus support...)

Right:- The version of the voyager updater on orpheus support at the
moment is 1.04, which contains a replaceent for the "Startup" file, with
different resolver addresses. Haven't checked what else has changed yet.

Conclusion: The resolver failure issue will affect anyone who upgraded
Voyager to Orpheus-connectability prior to 28th June '05.

ttfn
Fred

[Nick Roberts]

Post by R Fred Williams

Post by Paul Vigay

Post by Colin Matthews
I get the same resolvers. (And intermittent connection problems.
But I'm not complaining about Orpheus, for which continued
thanks!)

Hmm. I'm wondering if this is possibly the root of peoples
problems....
Those resolvers are incorrect and shouldn't be set. From memory I
think they're the old Argonet resolvers, so this would indicate
that something inside Voyager either hasn't updated to Orpheus
properly, or another copy of Voyager and/or internet software has
been seen on the machine.
If you have these resolvers whilst online then it's bound to cause
problems somewhere, which I think could point to why some people
are having problems....

Conclusion: The resolver failure issue will affect anyone who
upgraded Voyager to Orpheus-connectability prior to 28th June '05.

I doubt if this is the problem, TBH.

This is what is shown if I do a show Inet$Resolvers, and I virtually
never have any problem downloading from Orpheus.

Interestingly, these aren't the resolvers specified in my OS Internet
configuration, so presumably Voyager has forcibly overwritten them,
which is a bit naughty.

Even more interestingly, they do not match the contents of the file
Stack.Files.ResConf inside !Voyager, which has them set to
213.130.128.32 and 213.130.128.33 which I assume are correct. It's the
Stack.Startup script which sets them to the old Voyager settings.

Given that I am using the resolver built in to RISCOS 4, does this use
the Inet$Resolvers setting (Argonet settings), those specified in the
OS TCP/IP Configuration settings (actually NTL, but functional) or
what?

[Tennant Stuart]

Post by Paul Vigay
[Snip]

Post by Tennant Stuart
Okay Nick, I will, plus Paul's suggestion of "Show Inet$Resolvers",
which incidentally just gave me the response...
inet$resolvers : 158.43.240.4 158.43.240.3
..even though I've not logged on at all since switching on today.

Those resolvers are wrong, and nothing to do with Orpheus

Those numbers are in !Voyager.!Run date-stamped as 18th August 1999.

Looks as though you forgot to modify the file in your Orpheus converter.

In fact, the !Run is the *newest* file in the !Voyager directory that
isn't updated all the while - two of the modules hail from 1995.

Post by Paul Vigay
- so that could certainly account for you not being able to check email
and/or news if indeed you even manage to connect ok.

But I *am* able to check email and/or news, have done for a week now.

Post by Paul Vigay
Where is your computer picking up those resolvers from? Either your
Voyager is corrupt or you have some other internet software installed
on your machine, which is interfering with things?

I've only just turned on this RiscPC, and inet$resolvers still gives
those numbers. The only internet software here besides that supplied
within Voyager is Antispam and Netsurf. DialUp etc is on my Iyonix.


Tennant