[Oberon] Multiple incompatibilities with ISPs & PPP project

[eas-lab at absamail.co.za]

Peter Easthope wrote:
> The PPP.Log is really not so difficult to follow;
> quite effective and even interesting!
> It can be thought of as the transcript of a 
> conversation between the two automatons.

> In the majority of cases the problem will be 
> in the LCP (Link Control Protocol) negotiations
> which involve only the first 5 or so frames in 
> each direction.

Thanks for pioneering this. 
For fear of opening-a-can-of-worms, I've avoided digging deeper.
It would be interesting/valuable to see a few steps of explanation eg:
    automaton1, automaton2, corresponding trace/log;
with reference to the appropiate RFC(s).
Then I'll also try to follow it and hopefully add some value.

=========
Digression  re. how (I think) OPEN colaborative software should proceed.
=========
* Only after one years usage/complaining did I get an acknowlegement
of an error existing for 'grow-to-full-screen of certain viewers',
for n-o version beta 2001.
* Only after specifically asking about a fix/work-around did I get a
reply regarding a source patch.   Further queries as to the method
of 'finding the fault' refered to: 
  "Compiler.Compile \f    = locate the failing Stmt".
This is CLOSED, NOT OPEN colaboration.

Two examples of OPEN colaboration:
    I have been victim of, found and revealed:
1. the assumption that char "@" (and perhaps other chars) are not part
of the ISP login 2 parameters: userID and Userpassword strings;
(while apparently 'conventional) is not per RFC.
Consequently although many/most users can connect, some will fail
with the existing n-o code - when eg. char "@" is in the userID or
Userpassword string(s).

2. the assumption that the number of emails 'available' will always 
be given when 'getting into' pop3 server, without asking (AFAIR it
needs the "STAT" command), was built into TextMail.Mod.
Again this apparently usually worked, but is not per RFC.
--- ------ ---
In both of these examples, the solution is trivial - ie. at a lower level. 
What needs to be OPEN is the explanation of the fundamental
cause of the problem, not just a specific/arbitrary solution.

OPEN colaboration discusses the underlying principles; not a
"try to push button 43" solution, as a commercial supplier would
give a client.
==================

> Hopefully a nice new update of PPP.Tool can appear.

*  Yes, but let's seek a frame work (methodology) where a
     continual process of improvement is possible.

*  I've got a problem with PPP.Tool:
  it breaks the (apparently unwritten) rule that *.Tool is a list of
  mnemonics with minimum explanitory text.
   (I think also  that *.Toot should be specified as viewable under the
    'minimum' system: via Edit.Open and with UserTrack char width
    as per minimum/default - VGA, I guess).
Its not clear what the usefull text of presently named PPP.Tool should
be called; perhaps PPP.Text ?
Re. files not named strictly according to their contents, imagine if we 
  started getting source file called SrcFile.Dog..etc !  The way that *.Obj 
  and *.Sym is 'frozen' by the system, should apply to the naming
  of other files, as far is possible.   This is consistent with strict typing.
The justification of removing the freedom to choose is: remove descision
making from the trivial level to avoid repeatly deciding the same 
answer/question.  Rather free up the mind for higher tasks by automating
the trivialities.   Remove the 'art' as much as possible.
Presumably CVS helps enforce the discipline of working as much as
possible according to pre-determined rules ?
BTW as far as possible I avoid naming files: <string1>.<string2>, since
this is the syntax for <module>.<exportedCommand>, and  executing 
unintended commands is common.

*  I'd like to see (the renamed) PPP.Tool forming the basis of a
collaborative effort to getting more S3 users able to access internet.

> es> There are means for tracing the stuff. But the main 
> point I guess is your familiarity with the protocol so 
> you are able to find the point where there is a problem.

Yes. Hopefully by refining the existing text, a sufficiently simple yet
full tutor/basis-for-design-and-maintenance text can be evolved ?
Hopefully Peter E. can pass on his 'beginner's view' so far.
I'll try to understand it and add some thing and pass it back.
Perhaps after several iterations, finally vetted by Andre, an improved
product will emerge ?

> Yes, the RFCs are somewhat readable =8~)) although
> a reference at the level of the O'Reilly & Associates
> books would certainly help.  For example, how do the
> Internet layers, LCP, IPCP, correspond to the ISO-OSI
> network model?  The RFCs assume knowledge of 
> abstract basics which not all novices possess.  

I've collected some good tutors under linux (which I consider THE 
reference) re. networking. If this project reaches critical mass, the
material at the level of O'Reilly & Associates is available.
And for us heavy n-o users, on line is better than any paper book.

But I have serious gaps in my n-o knowledge and find no documentation
re. the following:--

> PPPMain.InstPPP does 
> 
> Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos);
> 
> reads the parameters for the command from this line
> in Oberon.Text,
> 
> Device0 = { "PPPMain.InstPPP", "COM1 \silent"}
> 
> and then uses InInt(i) to read an integer, 4.  
> ....
> 1. Where does InInt read 4 into i from?  "4" is not a 
> parameter of  "PPPMain.InstPPP" in Oberon.Text.

?? I can't see how/why the Texts.OpenScanner(S, 'looks' at Oberon.Text !
Presumably some other module sets 'global' S via Oberon.OpenScanner ?

So I tried to eg. see which number line is being scanned, for what ever
text is being scanned, via the following trace addition:-
		PROCEDURE InInt(VAR n:INTEGER);
		BEGIN
Out.Char("#"); Out.Int(S.line, 6);
			WHILE (S.class = Texts.Char) & (S.c = 0DX) DO Texts.Scan(S) END; 
...
Which gives:
TRAP -14  NIL reference ( 00000CBCH ) (PC Native 11.10.2001)
PPPMain.StartInst  PC = 627
	S =  00000014H
	ao =  00000038H
	papname = "2nm4nx6x at za"
	pappasswd = "<my password>"
	provider = "PPP"
Oberon.Call  PC = 4854   <--- extra layer of complication
	Mod =  00360480H
	P = PPPMain.StartInst  PC = 228
	i = 8
	j = 17
	name = "StartInst"  <--- extra layer of complication
	new = FALSE
	par =  00291400H
	res = 1
TextFrames.CallCmd  PC = 12011
...
??!! It seems that the Oberon.Call needs to be analysed, which 
perhaps leads into 'installation' and 'tasks' which I suspect are not 
documented.

Questions:

1. is there documentation re. "installing" ?

2. surely PPP*Mod can't be analysed without indepth knowledge
     of 'task handling' ?

3. What about real time aspects  of PPP ?

> es> Another point is that I would like to collect information 
> on problems with PPP on Oberon somewhere. I don't have 
> the urge to take every article concerning PPP from
> the mailing list and put it somewhere else. 
> 
> A by-product of the study of PPP is a collection of 
> troubleshooting tips, notes, suggestions and small 
> modifications to the PPP*.Mods.  Edgar has first 
> refusal on this material and my ego imagines some
> of it included in a future release.  Otherwise and, if 
> Edgar doesn't object, it could go on my server for 
> public access. 

Sounds good !

-- Chris Glur.