Re. [Oberon] helpful additions to Oberon.Text

[eas-lab at absamail.co.za]

cg> Did you miss my discussion about not using "@" as a parsing token
by assuming that it won't be included in the <Password>
or <ServiceName> strings. 

Peter E.  wrote:

> No.  In fact I refer to this issue briefly 
> in the "Notes on Oberon PPP" cited in  
> http://carnot.pathology.ubc.ca/. 
> 
> James Carlson> RFCs 1334 (for PAP) and 1994 (for CHAP)
> describe the peer name field as just a sequence of octets ...
> 
> Accepted.  If you have worked out an improved 
> means of handling the parameters please publish
> it here or at least forward it to someone 
> affiliated with the ETH so that it might
> be incorporated in the next release.
> 
> If only a few more of us could volunteer as 
> much time for Oberon/AOS as does André Fischer.

Well yes, but I'm convinced of the efficiency of heirarchical guidance:
  'management by objective',
  'top down design'
     etc.

Even apparently 'dispersed' systems like an ant colony, or the 
free-market economy are directed by a higher uniform coordinator.
Ant genes and 'economic rules' in these cases.

I'm again harping on the same complaint: that ETH-oberon
is not centrally coordinated enough to allow effective outside
contribution.   I've had to privately hack my e-mailer and 
NetSystem/Dialer/ppp to avoid being force to use M$-outspook.
I'm probably the world's heaviest user of ETH-oberon internet
connection facilities.  We see that most posters to this list
use outspook.  A senior ETH member has even degenerated to 
top posting ( apparently outspook 'promotes' top-posting ?).
Due to lack of commitment ETH-oberon's NetSystem/Dialer/ppp
facilities are falling into disuse.

In this specific matter of "handling the parameters" we need first
a 'higher authority' to acknowledge (or not) that the previous
system of using "@" as a token separator is unsound.
Otherwise we are just making a better journey to the wrong
destination.

I've made my contribution by investigating the higher question,
of whether "@" is a valid/possible char  for Username or password.

Chris Glur --

PS. several posters to News: comp.protocols.ppp are very clued up.
My first evaluation of posters's "quality" rejects all top posters.
Then I see if they answer *each* question, or just give an overview.

James Carlson and other(s) have pointed out that following the
RFCs is even not 'good enough'.

Here's a post that demonstrates assumptions that can give problems later
 -  like n-o's assumption that no UserId/Password will contain "@".
--------Subject: Re: LCP terminated by peer
> ]Try to remove "noauth" option.
> 
> That is only relevant if the other side wants to authenticate itself to
> you. You will need it if you have an ethernet card, since pppd assumes
> that if you have an ethernet card, you are the ISP. Bad assumption in
> this day and age, but that is one of pppd's "features". 
--------
There is also an invalid assumption in our TextMail.Mod .
Just because it worked for the last 10 years, doesn't prove it's OK.

PSS. just look at this quality coaching that's available off the net.

And for n-o users, you can 'color/hi-lite' the:
   "rcvd [LCP ConfReq ...auth chap"
corresponding to his: 
   "The peer asks you to identify yourself via standard CHAP.
etc. ...... "   --------

From: James Carlson <james.d.carlson at sun.com>
Subject: Re: pppd & sighup

shojo64 at aol.com (shojo) writes:
> I am Currently trying to set up my modem (Creative Modem Blaster v.92,
> 56K)and am having trouble staying connected.  There is a login and
> password prompt which is negotiated succesfully.  Then, there is some
> info I don't understand before the signal hangs up(SIGHUP).  

SIGHUP by itself just means that the peer has hung up.  It doesn't
convey much more information than hearing <click> <dial-tone>.

> Apr 26 19:48:08 little-vehicle pppd[2988]: sent [LCP ConfReq id=0x1
> <asyncmap 0x0> <magic 0xee0a7963> <pcomp> <accomp>]
> Apr 26 19:48:08 little-vehicle pppd[2988]: rcvd [LCP ConfReq id=0x1 <
> 00 04 00 00> <mru 1524> <asyncmap 0xa0000> <auth chap MD5> <pcomp>
> <accomp> <mrru 1524> <endpoint [MAC:00:c0:7b:98:cc:21]> < 1b 04 02
> 02>]

The peer asks you to identify yourself via standard CHAP.

> Apr 26 19:48:08 little-vehicle pppd[2988]: sent [LCP ConfRej id=0x1 <
> 00 04 00 00> <auth chap MD5> <mrru 1524> < 1b 04 02 02>]

You refuse to identify yourself by any means at all -- neither CHAP
nor PAP.

> Apr 26 19:48:08 little-vehicle pppd[2988]: rcvd [LCP ConfReq id=0x2
> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
> [MAC:00:c0:7b:98:cc:21]>]

The peer persists, and this time asks you to identify yourself with
PAP.

> Apr 26 19:48:08 little-vehicle pppd[2988]: sent [LCP ConfRej id=0x2
> <auth pap>]

You once again refuse to identify yourself.

> Apr 26 19:48:09 little-vehicle pppd[2988]: rcvd [LCP TermReq id=0x3]

The peer gives up in frustration.

> Can anybody point me in a direction?

Yes.  Your authentication information is misconfigured.

In general, you need to specify the 'user' option to pppd to provide
your local user name, and then put your credentials into the
appropriate file.  Assuming CHAP is right for this peer, do this in
pppd's configuration:

        user yourname

and this in /etc/ppp/chap-secrets:

        yourname * "your password" *

-- 
James Carlson, Solaris Networking         <james.d.carlson at east.sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
-----------------------
PSSS. Judging from the volume of Newsgroup queries ppp setup is one 
of the users greatest problems - it's worth knowing how to handle.