[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