[Oberon] PPP

[eas-lab at absamail.co.za]

> peter_easthope at gulfnet.sd64.bc.ca wrote
> > A few weeks back Chris asked that the results of 
> > my studies and tinkering with PPP be made available.
> > 
> > The notes are now at a link under "Miscellaneous 
> > Links" here.
> > http://carnot.pathology.ubc.ca/
> 
> Edgar wrote:
> Thanks Peter ! I added the link to your stuff on 
> www.edgarschwarz.de/oberon.

Yes thanks. PPP implementation is no trivial task.

A problem which rarely occured in the past, now happens daily for me.
Apparently because of telco line degradation. 
I don't know if it has socio-political causes or if it will improve as
the weather changes  -- eg. man-holes flooding ?

The symptoms are shown by the 'trace':-
Dial script startedModem off-line, device 0 closed

Sending [ATZ]
Waiting 10s for [OK] {ATZ||OK}
Sending [ATX]
Waiting 10s for [OK] {|ATX||OK}
Sending [ATD 3407501]
Sending [ATM1]
Waiting 60s for [CONNECT] {|ATD 3407501|ATM1||CONNECT}
Calling [PPPMain.StartInst PPP 2nm4nx6x at za]
---- up to here is OK, then the following 2 lines do not occur:
End of script
IPCP is finally ready. Device opened.

We have to expect and accept some 'fail to connects'.
But this is more problematic.
As previously observed, there are very few n-o dial-up users.
Those who don't/can't use n-o internet connection for their
'stuff' really don't get the full n-o experience.

The above described problem would cause many inet-connectors
not to use n-o, especially since further dial-ups fail to dial the
modem !!    The modem lights react, but no dial tone is available.
Ie. if a 'fail' (apparently due to my bad line) occurs after the action:
 Calling [PPPMain.StartInst PPP 2nm4nx6x at za];
then the 'system' is caught in an unanticipated state.

Previously I needed to re-boot.  Then with much experimenting I 
found that with repeated Crtl/<break> immedidtely after I MM
the Configuration.DoText 'script' which does:
      NetSystem.SetUser pap:2nm4nx6x$za:<myPassWrd>@PPP ~
      Dialer.Dial PPP Device0 ~
      Dialer.State PPP Device0 ~   ,
  I can eventually get the modem to get a dial tone.

Obviously I've tested several modems and computers and n-o versions.

The fact that I need several attempts, suggest to me a complicated
real time interatction of n-o 'tasking' & V24 & the serial chip & the
modem.   

The combined interaction of these 'systems' doesn't reach the required
initial/reset state, unless I force a "TRAP 13  Keyboard interrupt"
at a SUITABLE TIME.  Ie. a 'Keyboard interrupt' at the right stage of some
cycle, allows the 'system' to reset.

The RFCs as indicated by Peter Easthope are references and don't
intend to give a broad overview - which is needed before any indepth
analyses of the existing source-code. 

Obviously those who have seriously worked with the source code, have
invested the labour in aquiring a broad overview.  It seems a pity that
this knowledge is not captured and documented.

While reading the RFCs (and colour-marking, as n-o does so well) 
and being annoyed by the many 'forward references', I was reminded of
my first reading of a Wirth writing: no need to multi-scann; written
like a mathematical theorem - apparently from a mind trained in years
of designing languages for single scan compilers.

I look forward to the day when documentation (text to pass information
between humans) is based on forms and templates with a strict syntax
instead of ad-lib.  Is XML something in this direction ?

Can someone point me to a broad overview of PPP before I analyse the
RFCs and source code ?    It's called successive refinement.


-- Chris Glur.