Thread View: demon.ip.support.os2
1 messages
1 total messages
Started by Brian {Hamilton Kelly}
Sun, 14 Feb 1999 00:00
Green ROMP woes: Help required in interpreting CAPI log file
Author: Brian {Hamilton Kelly}
Date: Sun, 14 Feb 1999 00:00
Date: Sun, 14 Feb 1999 00:00
229 lines
12950 bytes
12950 bytes
[Please note cross-posts, and follow-up]
Can anyone advise me as to the interpretation of the logs generated by
the "CAPI Trace" facility of Teles' v3.10a OS/2 implementation of Capi
Mk.1, please?
Knowing that the Green ROMP had now been changed to use 158.152.1.222 as
the "other end" of the PPP connection, I thought it was about time I
tried once more to make use of it[1]. Formerly, I could connect OK, and
perform PAP authentication: however, the resultant connection had no
routing whatsoever.
Since the "upgrade", I can still connect and PAP authenticate, but the
connection is immediately torn down (and upsets KA9Q/2 so much that it
reports an access violation SYS3175).
I switched on logging using "CAPI Trace", and took the following data
into a file:
CAPI:
DATA B3 RCV
DATA B3 SND
DCHAN
BCHAN
S0
Looking at the resultant log, I suspect that the only information that
might be important is that reported in the D and B channel send and
receive packets, together with the various state transitions, so I've
extracted these below. The data in the packets logged as CAPI->bchan and
bchan->CAPI seem to bear little or no relationship to the sent and
received data: is this because the packets logged only show the first 64
bytes of each exchange?
The log starts out as follows:
| 18:16:53.82 0009 0020 LISTEN_REQ ctrl 0 info 0000003f EAZ 0200 service 0082
| 18:16:53.82 0009 0020 LISTEN_CNF ctrl 0 info 0000
| 18:16:55.32 0009 0040 CONNECT_REQ ctrl 0 bchan 83 info 0000003f service 07/00
| EAZ 9 DAD 80 [08452120667]
(I'm excising the bits logged as CAPI->dchan as well)
| 18:16:55.32 0009 0040 CONNECT_CNF PLCI 0005 info 0000
| 18:16:55.33 (dchan): CONNECT REQ [0:5] OK
| 18:16:55.33 D snd: 00 85 7F
| 18:16:55.34 D rcv: 00 85 73 06
(I'm reformatting these lines: CAPI Trace puts 24 bytes on each line in
the log, but I think splitting at 16 makes things more readable)
| 18:16:55.34 D snd: 00 85 00 00 08 01 01 05 04 02 88 90 18 01 83 6C
07 81 xx xx xx xx xx xx 70 0C 80 30 38 34 35 32
31 32 30 36 36 37
The bytes obscured by xx above constitute the outgoing number of the
line used for the call: BT have set up my ISDN card at the exchange to
expect only 6 digits of MSN information. I also see in this packet the
called number: 08452120667; I presume that the 81 and 80 are some codes
indicating either end of the connection, whilst the 07 and 0C are the
lengths of the respective digit strings, including those indicators.
| 18:16:55.37 D rcv: 00 85 01 02
Does this acknowledge the connection request?
| 18:16:55.80 D rcv: 02 85 00 02 08 01 81 02 18 01 89
| 18:16:55.80 D snd: 02 85 01 02
| 18:16:55.80 (dchan): AWAIT_SETUP_ACK: setup ack/call sent[169F:5] ch: 89
| 18:16:57.27 D rcv: 02 85 02 02 08 01 81 07
| 18:16:57.27 D snd: 02 85 01 04
| 18:16:57.27 (dchan): AWAIT_ALERT: conn[169F:5]
What's all that chit-chat?
| 18:16:57.27 D snd: 00 85 02 04 08 01 01 0F
| 18:16:57.27 0009 8000 CONNECT_ACTIVE_IND PLCI 0005 CAD 80 [08452120667]
| 18:16:57.27 0009 8000 CONNECT_ACTIVE_RSP PLCI 0005
| 18:16:57.27 0009 0060 SELECT_B2_PROT_REQ PLCI 0005
| Protokoll: HDLC-transparent
| Data Length: 2048
| Link Address A: 03
| Link Address B: 01
| Modulo Mode: 8
| Window Size: 1
I don't understand why the connection is being limited to a window size
of one: the cFos set-up certainly asks for more, and the cFos driver has
been provided with adequate memory to manage the feat. When I connect
using the native OS/2 stack, I find a window size of 7 logged. Still, I
don't believe that is my main problem...
| 18:16:57.27 0009 0060 SELECT_B2_PROT_CNF PLCI 0005 info 0000
| 18:16:57.28 0009 0080 SELECT_B3_PROT_REQ PLCI 0005
| Protokoll: transparent
| 18:16:57.28 0009 0080 SELECT_B3_PROT_CNF PLCI 0005 info 0000
| 18:16:57.28 0009 00a0 CONNECT_B3_REQ PLCI 0005
| 18:16:57.28 0009 00a0 CONNECT_B3_CNF PLCI 0005 NCCI 0005 info 0000
| 18:16:57.28 0009 8001 CONNECT_B3_ACT_IND NCCI 0005
| 18:16:57.28 0009 8001 CONNECT_B3_ACT_RSP NCCI 0005
| 18:16:57.28 D rcv: 00 85 01 04
| 18:16:57.28 0009 00c0 DATA_B3_REQ NCCI 0005 len 4 data 1f88:59ca number 85 flags 0000
Now comes the first transmission of *data* over the B-channel:
| 18:16:57.29 B1snd: FF 03 C0 21
| 18:16:57.29 0009 00c0 DATA_B3_CNF NCCI 0005 number 85 info 0000
| 18:16:58.41 B1rcv: FF 03 C0 21 01 01 00 1D 01 04 05 EA 03 04 C0 23
| 05 06 9E 79 94 B7 07 02 08 02 11 04 05 EA 13 03
| 00
| 18:16:58.41 0009 8002 DATA_B3_IND NCCI 0005 len 33 data 1fe8:0e10 number 00 flags 0000
Encouraging sign :-) That 33 ties in with the length of the B1rcv above.
I'd still like to know what it all means, however. I note that the first
two bytes of everything sent or received are "FF 03"
| 18:16:58.41 0009 8002 DATA_B3_RSP NCCI 0005 number 00
| 18:16:58.42 0009 00e0 DATA_B3_REQ NCCI 0005 len 15 data 1ff0:0000 number 86 flags 0000
| 18:16:58.42 B1snd: FF 03 C0 21 04 01 00 0B 11 04 05 EA 13 03 00
| 18:16:58.42 0009 00e0 DATA_B3_CNF NCCI 0005 number 86 info 0000
| 18:16:58.45 B1rcv: FF 03 C0 21 01 02 00 16 01 04 05 EA 03 04 C0 23
| 05 06 9E 79 94 B7 07 02 08 02
| 18:16:58.45 0009 8003 DATA_B3_IND NCCI 0005 len 26 data 1fe8:1610 number 01 flags 0000
| 18:16:58.46 0009 8003 DATA_B3_RSP NCCI 0005 number 01
| 18:16:58.46 0009 0100 DATA_B3_REQ NCCI 0005 len 26 data 1ff0:0000 number 87 flags 0000
| 18:16:58.46 B1snd: FF 03 C0 21 02 02 00 16 01 04 05 EA 03 04 C0 23
| 05 06 9E 79 94 B7 07 02 08 02
| 18:16:58.46 0009 0100 DATA_B3_CNF NCCI 0005 number 87 info 0000
| 18:17:00.51 0009 0120 DATA_B3_REQ NCCI 0005 len 22 data 1ff0:0000 number 88 flags 0000
| 18:17:00.51 B1snd: FF 03 C0 21 01 01 00 12 02 06 00 00 00 00 03 04
| C0 23 07 02 08 02
| 18:17:00.51 0009 0120 DATA_B3_CNF NCCI 0005 number 88 info 0000
| 18:17:00.55 B1rcv: FF 03 C0 21 02 01 00 12 02 06 00 00 00 00 03 04
| C0 23 07 02 08 02
| 18:17:00.55 0009 8004 DATA_B3_IND NCCI 0005 len 22 data 1fe8:1e10 number 02 flags 0000
| 18:17:00.55 0009 8004 DATA_B3_RSP NCCI 0005 number 02
| 18:17:03.61 0009 0140 DATA_B3_REQ NCCI 0005 len 22 data 1ff0:0000 number 89 flags 0000
| 18:17:03.61 B1snd: FF 03 C0 21 01 02 00 12 02 06 00 00 00 00 03 04
| C0 23 07 02 08 02
| 18:17:03.62 0009 0140 DATA_B3_CNF NCCI 0005 number 89 info 0000
| 18:17:03.67 B1rcv: FF 03 C0 21 01 03 00 1D 01 04 05 EA 03 04 C0 23
| 05 06 5A 09 78 94 07 02 08 02 11 04 05 EA 13 03
| 00
| 18:17:03.67 0009 8005 DATA_B3_IND NCCI 0005 len 33 data 1fe8:2610 number 03 flags 0000
| 18:17:03.67 B1rcv: FF 03 C0 21 02 02 00 12 02 06 00 00 00 00 03 04
| C0 23 07 02 08 02
| 18:17:03.67 0009 8005 DATA_B3_RSP NCCI 0005 number 03
| 18:17:03.67 0009 8006 DATA_B3_IND NCCI 0005 len 22 data 1fe8:0e10 number 04 flags 0000
| 18:17:03.67 0009 8006 DATA_B3_RSP NCCI 0005 number 04
| 18:17:03.68 0009 0160 DATA_B3_REQ NCCI 0005 len 15 data 1ff0:0000 number 8a flags 0000
| 18:17:03.68 B1snd: FF 03 C0 21 04 03 00 0B 11 04 05 EA 13 03 00
| 18:17:03.68 0009 0160 DATA_B3_CNF NCCI 0005 number 8a info 0000
| 18:17:03.72 B1rcv: FF 03 C0 21 01 04 00 16 01 04 05 EA 03 04 C0 23
| 05 06 5A 09 78 94 07 02 08 02
| 18:17:03.72 0009 8007 DATA_B3_IND NCCI 0005 len 26 data 1fe8:1610 number 05 flags 0000
| 18:17:03.73 0009 8007 DATA_B3_RSP NCCI 0005 number 05
| 18:17:03.75 0009 0180 DATA_B3_REQ NCCI 0005 len 26 data 1ff0:0000 number 8b flags 0000
| 18:17:03.75 B1snd: FF 03 C0 21 02 04 00 16 01 04 05 EA 03 04 C0 23
| 05 06 5A 09 78 94 07 02 08 02
| 18:17:03.75 0009 0180 DATA_B3_CNF NCCI 0005 number 8b info 0000
| 18:17:03.75 0009 01a0 DATA_B3_REQ NCCI 0005 len 26 data 1ff0:0000 number 8c flags 0000
I notice that henceforth the initial "FF 03" has been dropped; looking at
logs of successful connections show a similar alteration at this point in
the (successful) dialogue: is this indicative of the switchover to using
PPP on the link?
| 18:17:03.75 B1snd: C0 23 01 03 00 18 08 64 72 61 67 6E 68 6C 6C 0A
| xx xx xx xx xx xx xx xx xx xx
Those last 0x0A bytes are my Demon password; the 0x08 bytes preceding
them (and the count) are my nodename "dragnhll". Presumably therefore
the above forms part of the PAP authentication.
| 18:17:03.75 0009 01a0 DATA_B3_CNF NCCI 0005 number 8c info 0000
| 18:17:04.05 B1rcv: C0 23 02 03 00 05 00
What did *that* say? It seems to be the very last communication across
the B channel: everything else is on the D channel.
| 18:17:04.38 0009 8008 DATA_B3_IND NCCI 0005 len 7 data 1fe8:1e10 number 06 flags 0000
| 18:17:04.39 0009 8008 DATA_B3_RSP NCCI 0005 number 06
| 18:17:07.25 D rcv: 02 85 01 05
Is that the other end asking for a disconnection: or what?
| 18:17:07.26 D snd: 02 85 01 05
| 18:17:10.86 0009 01c0 DISCONNECT_B3_REQ NCCI 0005
| 18:17:10.86 0009 01e0 LISTEN_REQ ctrl 0 info 0000003f EAZ 0000 service 0000
| 18:17:10.86 0009 01c0 DISCONNECT_B3_CNF NCCI 0005 info 0000
| 18:17:10.86 0009 01e0 LISTEN_CNF ctrl 0 info 0000
| 18:17:10.86 0009 8009 DISCONNECT_B3_IND NCCI 0005 info 330a
| 18:17:10.86 0009 8009 DISCONNECT_B3_RSP NCCI 0005
| 18:17:10.86 0009 0200 DISCONNECT_REQ PLCI 0005 cause 80
| 18:17:10.87 0009 0200 DISCONNECT_CNF PLCI 0005 info 0000
| 18:17:10.87 (dchan): DISCONNECT REQ disc[169F:5]
| 18:17:10.87 D snd: 00 85 04 04 08 01 01 45 08 02 80 80
| 18:17:10.89 D rcv: 00 85 01 06
| 18:17:11.07 D rcv: 02 85 04 06 08 01 81 4D 08 03 82 E4 08
| 18:17:11.07 D snd: 02 85 01 06
| 18:17:11.07 (dchan): AWAIT_DISCONNECT/OTHER_REL: disc/rel/rel_ack[169F:5]
| 18:17:11.07 D snd: 00 85 06 06 08 01 01 5A
| 18:17:11.07 0009 800a DISCONNECT_IND PLCI 0005 info 0000
| 18:17:11.07 0009 800a DISCONNECT_RSP PLCI 0005
| 18:17:11.09 D rcv: 00 85 01 08
| 18:17:20.54 (dchan): TMO[0:0] Status: 0
| 18:17:20.54 D snd: 00 85 53
| 18:17:20.55 D rcv: 00 85 73 02
And that's it! As I said, something in the above interchange (when
passed on through the cFos driver), results in KA9Q ACCVIOing.
I'd be grateful for some help in interpreting the above; if anyone needs
the whole log to assist me, then I'll gladly mail it to them.
Alternatively, if someone can point to a WWW (or other) site that
explains how to interpret these B and D channel messages, I'll do it
myself.
[1] I have no problems using the Green ROMP in conjunction with the
standard in-built OS/2 TCP/IP stack; my problems only arise when
accessing it through KA9Q/2 and a cFos driver (that makes the ISDN link
look to KA9Q as if it were a modem).
--
Brian {Hamilton Kelly} bhk@dsl.co.uk
"You're one of the very rare few who can argue ad hominem, ad absurdum
and ad nauseam simultaneously...worse still it looks like you want to
carry on ad infinitum..." WPSM on alt.config 1998/06/27
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads