Re (2): [Oberon] PPP and overall Oberon coordination
eas-lab at absamail.co.za
eas-lab at absamail.co.za
Mon May 19 19:34:38 CEST 2003
cg> 1. there is possibly a loginID and loginPassword to the ISP
*before* entereing the ppp level.
Peter Easthope wrote:
> In general, yes this is possible.
> What is this server system you are dealing with?
Well, I don't/shouldn't have to know what kind of server system
I am dealing with. Provided that it complies with the applicable RFCs.
But you finally have stimulated the suspicion that I've been talking
(to more than one person) about a different level than what they
are disagreeing with me.
Here's how I (currently) see the situation:
Level 1.
Calling modem negotiates with ISP modem.
No problem here, but I'd like pointers to info. of how this is
implemented.
Level 2.
Serial data is passed to ISP, which traditionally included client's
login ID and password. These 'phrases' can apparently include any
ascii chars except <lineterminators> - which apparently parse these
tokens. Apparently with ppp usage this level of authentication is
seldom used, and apparently nor does my present system.
Apparently with the existing n-o system, any login ID and password
would be specified in the "Dial = {" section of Oberon.Text ?
And here the 'phrases' are deliniated by <doubleQuote,newLine>,
so there might be a problem if <doubleQuote> was a char, of the
ID or password ?
This is the level that I have been inappropriately arguing about !!
level 3.
Once ppp starts, if PAP authentication is used (most common
currently), the login ID and password are negotiated after the
LCP negotiation stage. Apparently the HDLC Framing facility
at this level, makes 'character breaking' possible, so that any
'abnormal chars' (eg. "@") in the login ID and password can
be masked.
Apparently the PAP authentication login ID and password
are obtained/used in n-o from/via NetSystem.SetUser .
So apparently at this level "@" could be 'masked', as could
"%" and "/" ?
------------------
> OK. Please describe your best plan for
> organization of authentication parameters in Oberon.
Since I have the "@" char in my PAP authentication login ID
I will test that the prevously proposed methods to handle this
work OK. Which I previously mistakenly rejected.
Meanwhile other(s) should check and correct my description above,
so that in future we can be 'reading from the same score' !
-- Chris Glur.
More information about the Oberon
mailing list