On Sat, Jun 15, 2013 at 4:06 PM, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 15 June 2013 16:12
To: hecnet at Update.UU.SE
Cc: Paul_Koning at Dell.com; md.benson at gmail.com
Subject: Re: [HECnet] Losing my fixed IP
On 2013-06-15 16:59, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any
decent speed, we're having to change packages meaning we will lose
out fixed IP in November. I'd like to work towards being able to
stay on HECnet before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often? Many ISPs
give
dynamic IP addresses, but you actually stay on the same address for
months,
which makes it a rather small problem. I haven't had a change in address
in
over 6 months myself.
And even if you do, with dynamic DNS you still have a hostname that
stays
fixed. All you need is for the things that connect to you, or check your
address, to be able to deal with names.
Well, they also need to recheck every so often... :-) My bridge program,
for
example, only do name resolution when processing the config file.
Johnny
I built the user mode router to do periodic DNS queries asynchronously so it
will automatically get updated, provided you use a service like dyndns, and
without any pauses waiting for DNS to respond.
Hello!
Robert if I remember correctly, it was originally built to run first
on a R.Pi device, and as a service on Windows? (That should be a
statement not a question, but I'm surmising my way across this
thread.)
Incidentally Cory and Dave they are back. Right now there's a big glut
of Daleks parked near you Dave. Better send the Doctor out first if a
version of myself is visiting you.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 15 June 2013 16:12
To: hecnet at Update.UU.SE
Cc: Paul_Koning at Dell.com; md.benson at gmail.com
Subject: Re: [HECnet] Losing my fixed IP
On 2013-06-15 16:59, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any
decent speed, we're having to change packages meaning we will lose
out fixed IP in November. I'd like to work towards being able to
stay on HECnet before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often? Many ISPs
give
dynamic IP addresses, but you actually stay on the same address for
months,
which makes it a rather small problem. I haven't had a change in address
in
over 6 months myself.
And even if you do, with dynamic DNS you still have a hostname that
stays
fixed. All you need is for the things that connect to you, or check your
address, to be able to deal with names.
Well, they also need to recheck every so often... :-) My bridge program,
for
example, only do name resolution when processing the config file.
Johnny
I built the user mode router to do periodic DNS queries asynchronously so it
will automatically get updated, provided you use a service like dyndns, and
without any pauses waiting for DNS to respond.
On Jun 15, 2013, at 11:14 AM, Johnny Billquist wrote:
On 2013-06-15 17:03, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
...
Proxy access is not standardized or documented (at the protocol level). I think it's simply this: the access control fields in the session control protocol are optional. If they are omitted, it's up to the receiving node to decide what to do about it (if the application protocol in question has the notion of access control). In some systems, the answer is "reject". In others, the answer is "use a default account" (RSTS has this).
Well, proxy is something that needs to be enabled on both sides for it to work, so it definitely involves passing some information in the packets. So it has to be documented somewhere. Keep searching.
I don't think so. RSTS has no notion of proxy, but I distinctly remember having proxies on VMS work when accessed from RSTS with no access control specified.
paul
On 2013-06-15 17:03, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
On 2013-06-15 14:59, Bob Armstrong wrote:
My workaround for that is to use DECnet proxy information.
However, I'm not sure that is available in 11M.
Sadly, there is no proxy support on M - only M+.
I still don't understand how it works when talking to a VMS system,
though? LENTO is doing the same thing in either case, but with a VMS system
on the far end all is well and with an RSX system on the other end it
doesn't work.
In all cases, if account information is passed in the request, it is used. For any OS. If no account information is passed, but both requesting node includes proxy information, and responding nodes make use of proxy information, this is used to get an account under which to process the reqeuest.
With VMS, if a request comes in without any account information, VMS applies the default account as the user under which to run the request. The requesting node have no involvement in this.
Proxy access is not standardized or documented (at the protocol level). I think it's simply this: the access control fields in the session control protocol are optional. If they are omitted, it's up to the receiving node to decide what to do about it (if the application protocol in question has the notion of access control). In some systems, the answer is "reject". In others, the answer is "use a default account" (RSTS has this).
Well, proxy is something that needs to be enabled on both sides for it to work, so it definitely involves passing some information in the packets. So it has to be documented somewhere. Keep searching.
A variation which some OSs might use (I forgot) is to handle the case where a user name is supplied but no password.
I wonder what the expected behavior of that should be? Seems like just failed access to me (unless the account actually have an empty password).
Johnny
On 2013-06-15 16:59, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any decent
speed, we're having to change packages meaning we will lose out fixed IP
in November. I'd like to work towards being able to stay on HECnet
before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often? Many ISPs give dynamic IP addresses, but you actually stay on the same address for months, which makes it a rather small problem. I haven't had a change in address in over 6 months myself.
And even if you do, with dynamic DNS you still have a hostname that stays fixed. All you need is for the things that connect to you, or check your address, to be able to deal with names.
Well, they also need to recheck every so often... :-)
My bridge program, for example, only do name resolution when processing the config file.
Johnny
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
On 2013-06-15 14:59, Bob Armstrong wrote:
My workaround for that is to use DECnet proxy information.
However, I'm not sure that is available in 11M.
Sadly, there is no proxy support on M - only M+.
I still don't understand how it works when talking to a VMS system,
though? LENTO is doing the same thing in either case, but with a VMS system
on the far end all is well and with an RSX system on the other end it
doesn't work.
In all cases, if account information is passed in the request, it is used. For any OS. If no account information is passed, but both requesting node includes proxy information, and responding nodes make use of proxy information, this is used to get an account under which to process the reqeuest.
With VMS, if a request comes in without any account information, VMS applies the default account as the user under which to run the request. The requesting node have no involvement in this.
Proxy access is not standardized or documented (at the protocol level). I think it's simply this: the access control fields in the session control protocol are optional. If they are omitted, it's up to the receiving node to decide what to do about it (if the application protocol in question has the notion of access control). In some systems, the answer is "reject". In others, the answer is "use a default account" (RSTS has this).
A variation which some OSs might use (I forgot) is to handle the case where a user name is supplied but no password.
paul
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any decent
speed, we're having to change packages meaning we will lose out fixed IP
in November. I'd like to work towards being able to stay on HECnet
before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often? Many ISPs give dynamic IP addresses, but you actually stay on the same address for months, which makes it a rather small problem. I haven't had a change in address in over 6 months myself.
And even if you do, with dynamic DNS you still have a hostname that stays fixed. All you need is for the things that connect to you, or check your address, to be able to deal with names.
paul
On 2013-06-15 15:28, Bob Armstrong wrote:
if a request comes in without any account information, VMS applies
the default account as the user under which to run the request.
Ah - and 11M+ can't do this? Didn't know that... Thanks.
Right. No RSX have any default account for DECnet. However, M+ have proxy, which can be made to work pretty close.
Johnny
if a request comes in without any account information, VMS applies
the default account as the user under which to run the request.
Ah - and 11M+ can't do this? Didn't know that... Thanks.
Bob
On 2013-06-15 14:59, Bob Armstrong wrote:
My workaround for that is to use DECnet proxy information.
However, I'm not sure that is available in 11M.
Sadly, there is no proxy support on M - only M+.
I still don't understand how it works when talking to a VMS system,
though? LENTO is doing the same thing in either case, but with a VMS system
on the far end all is well and with an RSX system on the other end it
doesn't work.
In all cases, if account information is passed in the request, it is used. For any OS. If no account information is passed, but both requesting node includes proxy information, and responding nodes make use of proxy information, this is used to get an account under which to process the reqeuest.
With VMS, if a request comes in without any account information, VMS applies the default account as the user under which to run the request. The requesting node have no involvement in this.
Johnny
