[Oberon] (no subject)

peter_easthope at gulfnet.sd64.bc.ca peter_easthope at gulfnet.sd64.bc.ca
Sun Jan 26 19:26:31 CET 2003


Hi Peter,
first I will admit that PPPMain.InstPPP is sort of a hack. I did put a lot of 
the original stuff
I got just in comments to keep it at hand if perhaps needed it in the future.

"Peter Easthope" <peter_easthope at gulfnet.sd64.bc.ca> wrote:
> Folk,
> Here are a few questions.
> 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.  There are these
> two lines of code.
> 
> (*MRUWant*)InInt(i); INCL(wo.O, NegMRU); wo.MRU:=1500;
> IF HDLC.debug THEN Debug.String("MRUWant "); Debug
Copy/Paste problem. Doesn't make sense really :-(
You can see that I copied these lines from below.

Doesn't hurt as it is but I changed it now to:
	(*MRUWant*) INCL(wo.O, NegMRU); wo.MRU:=1500;
	IF HDLC.debug THEN Debug.String("MRUWant "); Debug.Int(wo.MRU, 5) END;
So it's less confusing. 

> Hopefully a nice new update of PPP.Tool can appear.
I'm thinking of where to put it. Because I don't think it's necessary at the 
moment to send
an update to ETH just for documentation.

> 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.
No problem with that. You can send me your stuff and I can put it on my site 
as a
version under development before sending it to ETH eventually.

Cheers, Edgar



-- 
edgar at edgarschwarz.de                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/foren/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein
--
Oberon at inf.ethz.ch mailing list for ETH Oberon and related systems
http://www.lists.inf.ethz.ch/mailman/listinfo/oberon
------------------------------------------------------------
Message 3       1/2/2003  1:16 PM
Subject:	Oberon PPP 
From:		Edgar at edgarschwarz.de,Internet
To:		Peter Easthope
Copies:		edgar at edgarschwarz.de,Internet

Hi Peter,
Chris wrote:
> > 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.
So let's see whether we can help him. He's right in that a "methodology"
is needed. So here are my ideas which are open to discussion.
I don't have much time at the moment for PPP but I'm open for contributions
and can still give hints for some problems.
You seem to be interested at the moment to solve the problem of connecting
to a certain server (Like me a couple of years ago :-)
So how could we organize work efficiently ?
Here some thoughts:
- As long as I feel responsible for PPP a starting point could be
  www.edgarschwarz.de/oberon/ppp which means just giving PPP stuff an own 
     page.
- There I would put a current version for download.
  Perhaps not only an archive but also single files and a change history ?
- A link to material which you want to contribute on your server or
  some means for you to upload to my site ?
  The link would be easy and fast to implement. Uploading per HTML form of 
certain
  files to my site I already implemented for non Oberon purposes.
- www.edgar-schwarz.de/foren/oberon for discussions about problems.
  This would collect discussions on Oberon PPP instead of hiding it
  in the general mailing list.
  
Do you think this would count as a "methodology" for Chris :-?

Cheers, EdgarSchwarz

-- 
edgar at edgarschwarz.de                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/foren/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein
---------------------------------------------------------

To:	edgar at edgarschwarz.de
Subject:	Re: Oberon PPP 

Hello Edgar,

es> You seem to be interested at the moment to solve 
the problem of connecting to a certain server (Like me 
a couple of years ago :-)

Yes.

es> So how could we organize work efficiently ?
es> www.edgarschwarz.de/oberon/ppp
- There I would put a current version for download.

Good.

es>   Perhaps not only an archive but also single files 

That will work well until an interface changes and people
complain that a new Obj file doesn't work with their old
PPP.  People get into trouble where shortcuts are possible.

es> ... change history ?

Very useful.

es> - A link to material which you want to contribute on your server or
  some means for you to upload to my site ?

I prefer one "latest release" of the source and zipped Obj 
files rather than different flavours from different people.
Otherwise people will ask "who's version of PPP is best?"
We see too much of this in Linux.  Ideally the release will 
have all the "best" features with switches between 
alternative choices, if any exist.

Background documentation is another matter.  No harm
in the descriptions and histories of changes from different 
people being on different sites.  Beneficial in some ways.

es> www.edgar-schwarz.de/foren/oberon for discussions about problems.

Don't have a dictionary handy.  Is "foren" the German spelling
or is it a typing error?  (English: forum)

es> Do you think this would count as a "methodology" for Chris :-?

Difficult to say how he will respond.  More structure and
organization requires more housekeeping.  What you 
propose seems workable.  Perhaps send the same 
description to Chris and find what he says.

Regards,            Peter E.
----------------------------------------------------------
Message 1       1/7/2003 12:45 AM
Subject:	Re: Notes pertaining to Oberon PPP, 2003-01-06.
From:		Edgar at edgarschwarz.de,Internet
To:		Peter Easthope
Copies:		fischer at inf.ethz.ch,Internet
		muller at inf.ethz.ch,Internet
		edgar at edgarschwarz.de,Internet

Hi Peter,
> The comments translated to English are meant to be 
> included along with Edgar's original comments.
> So many North Americans are unable to read German.
Should have done them in English from the beginning.

> *** System Issues
> 
> NetSystem.Mod specifies this syntax.
> 
> NetSystem.SetUser { service ":" ["//"] [ user [ ":" password ] "@" ] host
> [ "/" ] } "~"
> 
> Prior to availability of PPP, the terms "service" and "host" 
> were OK.  They now seem a little inappropriate and confusing.  
> For example, DIAL is not a host and pap is a protocol rather 
> than a service.  I suggest replacing "service" with "servicetype" 
> and "host" with "servicename" in descriptions of 
> NetSystem.SetUser.
> 
> These are two options for Device0 in Oberon.Text.
> Device0 = { "PPPMain.InstPPP", "COM1 \silent"}
> Device0 = { "SLIP.InstallDevice", "COM1 compressed"}
> These are wrong in the sense that "silent" and "compressed"
> need be applied to specific routes of connection rather than 
> to all PPP and all SLIP connections respectively.
> 
> Terms Device0 and Route0 suggest multiple Devices and 
> multiple Routes.  Logically, the parameters of a service, as 
> supplied to NetSystem.SetUser, along with the name of a 
> dial script and a Device<m> might be associated with 
> Route<n> in Oberon.Text.  I wonder whether consideration 
> has already been given to a command such as NetSystem.Connect 
> Route<n>?  The designer of Oberon.Text (PJM?) must have 
> thought through all of this long ago.
> Some months ago the Native Oberon mailing list received 
> a message questioning the redundancy of the arguments 
> of the CALL command in the dial script when a PAP service
> is accessed.  A small benefit of the hypothetical 
> NetSystem.Connect command could be elimination of this 
> redundancy.
These are valid questions I also pondered with. They must be
answered together with the NetSystem people. Probably no change
will be possible for NO. But perhaps in Bluebottle NetSystem
is different. I will have a look.

Cheers, Edgar


-- 
edgar at edgarschwarz.de                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/forum/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein
---------------------------------------------------------
To:	edgar at edgarschwarz.de
Subject:	Re: Notes pertaining to Oberon PPP, 2003-01-06.

Edgar,

es> ... must be answered together with the NetSystem people.

NO allows multiple devices and routes.  NetBase.MaxDevices 
and NetIP.MaxRoutes are both set to 2 and these limits are 
easily increased up to 10.  This allows definition in Oberon.Text 
of various devices with differing options.  For example these two 
cases might be useful.
		Device0 = { "PPPMain.InstPPP", "COM1 \silent"}
		Device1 = { "PPPMain.InstPPP", "COM1"}

I will explain this in a revision of the notes.

Thanks,              Peter

----------------------------------------------------------
To:	edgar at edgarschwarz.de
Subject:	Failure in negotiation of IP address.

Edgar,

Here is a question about negotiation of the IP address
with a Vicom server.  Seems best to consult you before 
making rash changes.

Immediately after the report "LCP is finally ready!!"
Oberon PPP sends an IPCP Conf-Req with a zero IP
address, message id = 01.  

In response to this Conf-Req Vicom sends a Conf-Nak 
containing an address (C0A8B7FD).  This is exactly 
what I expect according to RFC 1332.  

Oberon PPP replies with Conf-Req, id = 02 containing 
the address just received from Vicom.  This response is 
not described in RFC 1332 and I wonder whether Vicom 
is expecting Conf-Ack.

Vicom appears to interpret this as a rejection of 
the proposed address.  It sends back a Conf-Req, 
id = 08, with the address incremented by 1 (C0A8B7FE).

Oberon PPP rejects message id=8.  A logical response
since it just accepted the address in message id=1.

Vicom never seems to recognize that the first
address was accepted and continues to offer the
second address.  Oberon PPP continues to reject it.

Pity that RFC 1332 is not more explicit about this.
The only solution I see is to try changing the message 
acknowledging the first address, from Conf-Req
to Conf-Ack.  Is this sensible?

Thanks,          Peter E.

------------------------------------------
2.1/es/25.04.2000
 \silentMRUWant     4MRUAllowAsyWant  00000000
 AsyAllow  FFFFFFFFTO     5myNetmask  Starting receiving-loop
Pustekuchen, macht Devicepolling
Provider: GulfNet3
papname: peter
pappasswd: retinue$
FSM.LowerUp
protocol: LCP  -  channel: PPP
state: Initial

FSM.Open
protocol: LCP  -  channel: PPP
state: Closed

22:18:07CheckPacket: len=    2
0D0A
Length too short, length:     2
22:18:07CheckPacket: len=   34
FF03C021 0102001C 01040200 02060000 
00000304 C0230506 037BE2FD 07020802 
8769
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: Stopped

0102001C 01040200 02060000 00000304 
C0230506 037BE2FD 07020802 

FSM.ReceiveConfigureRequest
protocol: LCP  -  channel: PPP
id:    2

reset CI
FSM.SendConfReq
protocol: LCP  -  channel: PPP
id:    1    state: Stopped

LCP.AddCI
protocol: LCP  -  channel: PPP
MRU AsyncMap 

FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfReq
state: Stopped
id:    1
0101000E 010405DC 02060000 0000

22:18:07SendPacket: len =    20
FF03C021 0101000E 010405DC 02060000 
00004F35 

LCP.ReCI: AuthType
x =-16349
LCP.ReCI: NegUPap added to his options

RejMagic RejPFComp RejACComp FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:    2
0402000E 0506037B E2FD0702 0802

22:18:07SendPacket: len =    20
FF03C021 0402000E 0506037B E2FD0702 
0802A8F7 

22:18:08CheckPacket: len=    0
22:18:08CheckPacket: len=   20
FF03C021 0201000E 010405DC 02060000 
000071B6 
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: ReqSent

0201000E 010405DC 02060000 0000

FSM.ReceiveConfAck
protocol: LCP  -  channel: PPP
id:    1

22:18:08CheckPacket: len=    0
22:18:08CheckPacket: len=   24
FF03C021 01040012 01040200 02060000 
00000304 C0233CBD 
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: AckRcvd

01040012 01040200 02060000 00000304 
C023

FSM.ReceiveConfigureRequest
protocol: LCP  -  channel: PPP
id:    4

LCP.ReCI: AuthType
x =-16349
LCP.ReCI: NegUPap added to his options

FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfAck
state: AckRcvd
id:    4
02040012 01040200 02060000 00000304 
C023

22:18:08SendPacket: len =    24
FF03C021 02040012 01040200 02060000 
00000304 C02304BC 

Main.LCPUp: auth requested by peer
22:18:08SendPacket: len =    25
FF03C023 01010013 05706574 65720872 
6574696E 75652404 7A

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   96
FF03C023 0201005A 55736572 6E616D65 
2F706173 73776F72 64206163 63657074 
65640050 4150206C 6F67696E 2072656A 
65637465 642C2075 7365726E 616D6520 
00557365 726E616D 652F7061 7373776F 
72642072 656A6563 74656400 50417ED8 
LCP is finally ready!!
FSM.LowerUp
protocol: IPCP  -  channel: PPP
state: Initial

FSM.Open
protocol: IPCP  -  channel: PPP
state: Closed

FSM.SendConfReq
protocol: IPCP  -  channel: PPP
id:    1    state: Closed

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfReq
state: Closed
id:    1
0101000A 03060000 0000

22:18:09SendPacket: len =    16
FF038021 0101000A 03060000 00001328 

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   28
FF038021 01060016 0206002D 0F010306 
C0A8B7FE 8106C0A8 B7FE376A 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

01060016 0206002D 0F010306 C0A8B7FE 
8106C0A8 B7FE

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:    6

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:    6
0406000A 0206002D 0F01

22:18:09SendPacket: len =    16
FF038021 0406000A 0206002D 0F016437 

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   16
FF038021 0301000A 0306C0A8 B7FD9DD9 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

0301000A 0306C0A8 B7FD

FSM.ReceiveConfigureNak/Reject
protocol: IPCP  -  channel: PPP
id:    1

FSM.SendConfReq
protocol: IPCP  -  channel: PPP
id:    2    state: ReqSent

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfReq
state: ReqSent
id:    2
0102000A 0306C0A8 B7FD

22:18:09SendPacket: len =    16
FF038021 0102000A 0306C0A8 B7FDD457 

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   22
FF038021 01080010 0306C0A8 B7FE8106 
C0A8B7FE BE53
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

01080010 0306C0A8 B7FE8106 C0A8B7FE 

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:    8

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:    8
04080004 

22:18:09SendPacket: len =    10
FF038021 04080004 4945

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   16
FF038021 0202000A 0306C0A8 B7FDBD23 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

0202000A 0306C0A8 B7FD

FSM.ReceiveConfAck
protocol: IPCP  -  channel: PPP
id:    2

22:18:09CheckPacket: len=    0
22:18:09CheckPacket: len=   22
FF038021 010A0010 0306C0A8 B7FE8106 
C0A8B7FE EAC3
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: AckRcvd

010A0010 0306C0A8 B7FE8106 C0A8B7FE 

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:   10

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: AckRcvd
id:   10
040A0004 


----------------------------------------------------------
Message 2       1/9/2003  5:20 AM
Subject:	Re: Failure in negotiation of IP address.
From:		Edgar at edgarschwarz.de,Internet
To:		Peter Easthope
Copies:		edgar at edgarschwarz.de,Internet

Hi Peter,
it seems you are beginning to see the light !
The problem is that this topic in 1332 is VERY short.

> Immediately after the report "LCP is finally ready!!"
> Oberon PPP sends an IPCP Conf-Req with a zero IP
> address, message id = 01.
Requesting the server to give me an address.

> In response to this Conf-Req Vicom sends a Conf-Nak 
> containing an address (C0A8B7FD).  This is exactly 
> what I expect according to RFC 1332.
Agreed.

> Oberon PPP replies with Conf-Req, id = 02 containing 
> the address just received from Vicom.  This response is 
> not described in RFC 1332
Yes. I guess it means to show that the address was accepted.

> and I wonder whether Vicom is expecting Conf-Ack.
Possible. Or no response at all ? Saying: you wanted an address,
I sent it and so it's done.

> Vicom appears to interpret this as a rejection of 
> the proposed address.  It sends back a Conf-Req, 
> id = 08, with the address incremented by 1 (C0A8B7FE).
As I read 1332 this would mean that Vicom is telling me his address.
So the question is whether it is already available or has to negotiated
with a configure-nak (Paragraph 2).
You could try to take this as server address ?!?

> Pity that RFC 1332 is not more explicit about this.
You say it :-(
> The only solution I see is to try changing the message 
> acknowledging the first address, from Conf-Req
> to Conf-Ack.  Is this sensible?
Could work. Or perhaps no reply at all.
Here some guesswork seems to be necessary. Perhaps a log 
with Vicom together with Linux or Windows could tell you 
what Vicom expects.

Regards, Edgar
----------------------------------------------------------
 To:	edgar at edgarschwarz.de
 Subject:	Re: Failure in negotiation of IP address.

Edgar,

es> As I read 1332 this would mean that Vicom is telling me his address.
... You could try to take this as server address ?!?

Possible, but according to the human administrator, the 
the Vicom machine is 142.31.196.10.

es> Here some guesswork seems to be necessary. Perhaps a log 
with Vicom together with Linux or Windows could tell you 
what Vicom expects.

Will pursue these suggestions.  Thanks for your help.

Regards,        Peter E.
----------------------------------------------------------
To:	edgar at edgarschwarz.de
Subject:	Negotiation of IP address.

Hello Edgar,

Phew!  This is no cake-walk!

es> Perhaps a log with Vicom together with Linux or 
Windows could tell you what Vicom expects.

Got a log with MacOS 7.6 connecting to Vicom but 
make little sense of it.  Annotations appear repeatedly 
and everything else is binary.  Not enlightening.  No 
other system is available for now.

There is something in PPP.Log which I missed earlier.
The frames are now numbered and the message id's 
and padding are different.  Otherwise it is the same
as the log sent about a week ago.

In frame 12, id=1, (see following) Oberon asks  Vicom 
for an IP address by sending a 0 address.  In frame 17, 
id= 1, Vicom sends an address with a Conf-Nak code.  
Thus far, all according to RFC 1332 (as I understand).

Frame 18 is a Conf-Req from Oberon to Vicom 
containing the address just proposed---with id 2
rather than 1.

pe> ... whether Vicom is expecting Conf-Ack.
es> Possible. Or no response at all ? Saying: you 
wanted an address, I sent it and so it's done.

Without a confirmation Vicom is never sure the 
proposed address was transmitted without 
corruption.

Please let me know what you think of this.  If you 
approve of frame 18 having id 1 (as a test at least), 
can you suggest how this might be accomplished?

(Seems that frame 18 originates in 
PPPFSM.ReceiveConfNakRej at these lines.

		| ReqSent, AckSent:	HDLC.UNTIMEOUT(f.HDLCConfig, Timeout); 
			SendConfReq(f, newtransmit)	
			(* They didn't agree to what we wanted - try another request *)

Is Conf-Naq used in a special way in address negotiation?  
If I simply change SendConfReq(f, newtransmit) to 
SendConfReq(f, retransmit) will other cases be "messed 
up".)

Thanks,          Peter E.

2.1/es/25.04.2000
\silent
MRUWant  1500
MRUAllow
AsyWant  00000000
AsyAllow  FFFFFFFF
TO     5
myNetmask set to 255.255.255.0
 Starting receiving-loop
Pustekuchen, macht Devicepolling
Provider: GulfNet3
papname: peter
pappasswd: retinue$
FSM.LowerUp
protocol: LCP  -  channel: PPP
state: Initial

FSM.Open
protocol: LCP  -  channel: PPP
state: Closed

->->-> Frame     0 received from peer.
14:01:00CheckPacket: len =     2
0D0A
Length too short, length:      2
->->-> Frame     1 received from peer.
14:01:00CheckPacket: len =    34
FF03C021 01EC001C 010405DC 02060000 
00000304 C0230506 018BC890 07020802 
6135
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: Stopped

01EC001C 010405DC 02060000 00000304 
C0230506 018BC890 07020802 

FSM.ReceiveConfigureRequest
protocol: LCP  -  channel: PPP
id:  -20

reset CI
FSM.SendConfReq
protocol: LCP  -  channel: PPP
id:    1    state: Stopped

LCP.AddCI
protocol: LCP  -  channel: PPP
MRU AsyncMap 

FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfReq
state: Stopped
id:    1
0101000E 010405DC 02060000 0000

<-<-<- Frame     2 going to peer.
14:01:00  SendPacket: len =    20
FF03C021 0101000E 010405DC 02060000 
00004F35 

LCP.ReCI: AuthType
x =-16349
LCP.ReCI: NegUPap added to his options

RejMagic RejPFComp RejACComp FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:  -20
04EC000E 0506018B C8900702 0802

<-<-<- Frame     3 going to peer.
14:01:00  SendPacket: len =    20
FF03C021 04EC000E 0506018B C8900702 
0802EA3A 

->->-> Frame     4 received from peer.
14:01:00CheckPacket: len =     0
->->-> Frame     5 received from peer.
14:01:00CheckPacket: len =    20
FF03C021 0201000E 010405DC 02060000 
000071B6 
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: ReqSent

0201000E 010405DC 02060000 0000

FSM.ReceiveConfAck
protocol: LCP  -  channel: PPP
id:    1

->->-> Frame     6 received from peer.
14:01:00CheckPacket: len =     0
->->-> Frame     7 received from peer.
14:01:00CheckPacket: len =    24
FF03C021 01EE0012 010405DC 02060000 
00000304 C0232826 
FSM.ReceiveData
protocol: LCP  -  channel: PPP
state: AckRcvd

01EE0012 010405DC 02060000 00000304 
C023

FSM.ReceiveConfigureRequest
protocol: LCP  -  channel: PPP
id:  -18

LCP.ReCI: AuthType
x =-16349
LCP.ReCI: NegUPap added to his options

FSM.SendData
protocol: LCP  -  channel: PPP
code: ConfAck
state: AckRcvd
id:  -18
02EE0012 010405DC 02060000 00000304 
C023

<-<-<- Frame     8 going to peer.
14:01:00  SendPacket: len =    24
FF03C021 02EE0012 010405DC 02060000 
00000304 C0231027 

Main.LCPUp: auth requested by peer
<-<-<- Frame     9 going to peer.
14:01:00  SendPacket: len =    25
FF03C023 01010013 05706574 65720872 
6574696E 75652404 7A

->->-> Frame    10 received from peer.
14:01:00CheckPacket: len =     0
->->-> Frame    11 received from peer.
14:01:00CheckPacket: len =    96
FF03C023 0201005A 55736572 6E616D65 
2F706173 73776F72 64206163 63657074 
65640050 4150206C 6F67696E 2072656A 
65637465 642C2075 7365726E 616D6520 
00557365 726E616D 652F7061 7373776F 
72642072 656A6563 74656400 50417ED8 
LCP is finally ready!!
FSM.LowerUp
protocol: IPCP  -  channel: PPP
state: Initial

FSM.Open
protocol: IPCP  -  channel: PPP
state: Closed

FSM.SendConfReq
protocol: IPCP  -  channel: PPP
id:    1    state: Closed

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfReq
state: Closed
id:    1
0101000A 03060000 0000

<-<-<- Frame    12 going to peer.
14:01:00  SendPacket: len =    16
FF038021 0101000A 03060000 00001328 

->->-> Frame    13 received from peer.
14:01:00CheckPacket: len =     0
->->-> Frame    14 received from peer.
14:01:00CheckPacket: len =    28
FF038021 01F00016 0206002D 0F010306 
C0A8B6FE 8106C0A8 B6FE5B2E 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

01F00016 0206002D 0F010306 C0A8B6FE 
8106C0A8 B6FE

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:  -16

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:  -16
04F0000A 0206002D 0F01

<-<-<- Frame    15 going to peer.
14:01:00  SendPacket: len =    16
FF038021 04F0000A 0206002D 0F0162B9 

->->-> Frame    16 received from peer.
14:01:00CheckPacket: len =     0
->->-> Frame    17 received from peer.
14:01:00CheckPacket: len =    16
FF038021 0301000A 0306C0A8 B6FD45C0 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

0301000A 0306C0A8 B6FD

FSM.ReceiveConfigureNak/Reject
protocol: IPCP  -  channel: PPP
id:    1,  reqID:    1

FSM.SendConfReq
protocol: IPCP  -  channel: PPP
id:    2    state: ReqSent

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfReq
state: ReqSent
id:    2
0102000A 0306C0A8 B6FD

<-<-<- Frame    18 going to peer.
14:01:00  SendPacket: len =    16
FF038021 0102000A 0306C0A8 B6FD0C4E 

->->-> Frame    19 received from peer.
14:01:01CheckPacket: len =     0
->->-> Frame    20 received from peer.
14:01:01CheckPacket: len =    22
FF038021 01F20010 0306C0A8 B6FE8106 
C0A8B6FE 0541
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

01F20010 0306C0A8 B6FE8106 C0A8B6FE 

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:  -14

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: ReqSent
id:  -14
04F20004 

<-<-<- Frame    21 going to peer.
14:01:01  SendPacket: len =    10
FF038021 04F20004 07BA

->->-> Frame    22 received from peer.
14:01:01CheckPacket: len =     0
->->-> Frame    23 received from peer.
14:01:01CheckPacket: len =    16
FF038021 0202000A 0306C0A8 B6FD653A 
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: ReqSent

0202000A 0306C0A8 B6FD

FSM.ReceiveConfAck
protocol: IPCP  -  channel: PPP
id:    2

->->-> Frame    24 received from peer.
14:01:01CheckPacket: len =     0
->->-> Frame    25 received from peer.
14:01:01CheckPacket: len =    22
FF038021 01F40010 0306C0A8 B6FE8106 
C0A8B6FE E8F9
FSM.ReceiveData
protocol: IPCP  -  channel: PPP
state: AckRcvd

01F40010 0306C0A8 B6FE8106 C0A8B6FE 

FSM.ReceiveConfigureRequest
protocol: IPCP  -  channel: PPP
id:  -12

FSM.SendData
protocol: IPCP  -  channel: PPP
code: ConfRej
state: AckRcvd
id:  -12
04F40004 

<-<-<- Frame    26 going to peer.
14:01:01  SendPacket: len =    10
FF038021 04F40004 DE6C

------------------------------------------------------------
To:	Edgar at edgarschwarz.de
Subject:	Oberon PPP 

Edgar,

es> Here some guesswork seems to be necessary. Perhaps a log 
with Vicom together with Linux or Windows could tell you 
what Vicom expects.

Yes, you are correct.  I will need to get a good log, probably 
from Linux.  I tried changing the id of message 18 but the 
negotiation was no better.  Without reliable information 
I am just "shooting in the dark".

Regards,        Peter E.
-----------------------------------------------------
bcc: edgar at edgarschwarz.de
Subject: Re: Negotiation of IP address.

Edgar,

es> Sorry for not replying earlier. But I have a lot of work at the moment.
I will try to give your problem a look on the weekend.

Thanks but don't spend more time on it for now.
I've worked out what is happening and can get 
a connection.

A year or so ago, you must have done the same 
"repair" as I have done but somehow the 
modification was not included in the PPP
release in Native 24.08.2002.  If I had 
studied your original repair more carefully, 
might have avoided some strife.

Soon I will describe the matter in the  
PPPChanges.Text and send you a copy.

Regards,       Peter E.

-----------------------------------------------------
bcc: edgar at edgarschwarz.de
bcc: peter_easthope at gulfnet.sd64.bc.ca
Subject: PPPChanges.Text

Greetings Edgar,

PPPChanges.Text and my modified PPP*.Mod
files are now available here.

http://carnot.pathology.ubc.ca/OberonPPP/

To get the descriptive notes, open the URI
with Desktops.OpenDoc ^, select the link
PPPChanges.Text and execute 
HyperDocTools.Fetch PPPChanges.Text ~.

Wednesday I will be back at UBC and will 
be able to put a link to this in my Web 
page.  Then I can mention it in the Native
Oberon list.  Hopefully that will make
Chris G. happy for a short while.  =8~)

If you want anything corrected or changed,
just let me know.

Regards,     Peter E.

------------------------------------------------


http://carnot.pathology.ubc.ca/peter.html



More information about the Oberon mailing list