Deep Analysis: PAD Connection Success vs Failure¶

CRITICAL REVELATION: The First Connection (100→102) Actually SUCCEEDS!¶

Timeline Analysis - First Connection (100→102)¶

Phase 1: PAD Request Retransmissions (14:39:06 - 14:39:11)¶

14:39:06.700 TX: [09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - PAD Request #1
14:39:07.910 TX: [09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - PAD Request #2 (1.2s later)
14:39:09.240 TX: [09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - PAD Request #3 (1.3s later)
14:39:10.552 TX: [09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - PAD Request #4 (1.3s later)  
14:39:11.846 TX: [09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - PAD Request #5 (1.3s later)

Analysis: 5 identical PAD requests sent with ~1.2-1.3 second intervals. NO RESPONSE RECEIVED.

Phase 2: Protocol Switch - Initialize X.25 (14:39:12)¶

14:39:12.910 HDLC DMA 1: DMA CommandInitialize    : 0x017B70 
14:39:12.911 HDLC DMA 1: DMA CommandReceiverStart : 0x017B80

Critical: After 5 failed PAD requests, system switches to X.25 protocol and initializes receiver.

Phase 3: X.25 SABM/UA Exchange - SUCCESSFUL! (14:39:13-14:39:15)¶

14:39:13.417 TX: [01 3F 00 64] - SABM from node 100
14:39:13.876 RX: [01 3F 00 66] - SABM response from node 102 *** RECEIVED! ***

14:39:14.114 TX: [01 73 00 64] - UA from node 100
14:39:14.683 TX: [01 73 00 64] - UA retransmission
14:39:14.770 RX: [01 73 00 66] - UA response from node 102 *** RECEIVED! ***

14:39:15.017 TX: [09 01 00 64] - Connection ready from node 100
14:39:15.537 RX: [09 01 00 66] - Connection confirmed from node 102 *** RECEIVED! ***

STUNNING DISCOVERY: The X.25 handshake SUCCEEDS COMPLETELY! - SABM sent and acknowledged - UA sent and acknowledged - Connection established and confirmed

What Really Happened¶

PAD Layer Failed, X.25 Layer Succeeded:¶

PAD service request (0x44) fails - No response to 5 attempts
System falls back to direct X.25 - Bypasses PAD layer
X.25 SABM/UA handshake succeeds - Full bidirectional acknowledgment
Connection established - Both nodes confirm with 0x01 frames

The "Second Buffer" Mystery Solved:¶

Looking at lines 38-40 and throughout:

38: ByteCount: 0x000E 
39: DATA: 0x21 0x00 0x86 0xE4 0x00 0x66 0x00 0x00 0x00 0x64 0x02 0xEC 0x04 0x00
40: Loading Buffer from 0x0006D49C Key=BlockToBeTransmitted ByteCount=14

This second buffer contains a different frame being prepared simultaneously! The system is pipelining frame preparation while transmitting the PAD requests.

Frame Analysis - Buffer A vs Buffer B¶

Buffer A (0x06D498) - PAD Requests:¶

[09 44 21 13 00 0E 00 66 00 64 00 04 04 00 DA 10] - 16 bytes

Buffer B (0x06D49C) - Unknown Protocol:¶

[21 00 86 E4 00 66 00 00 00 64 02 EC 04 00] - 14 bytes

Buffer B Analysis: - Starts with 0x21 (not 0x09) - Different protocol - Contains node addresses 0x66, 0x64 - Never transmitted - Remains in preparation state - Possibly a response frame template or alternative protocol attempt

Revised Protocol Flow¶

Successful Connection Sequence:¶

1. PAD Service Request (0x44) → NO RESPONSE (5 attempts)
2. Fall back to Direct X.25
3. Initialize DMA Receiver 
4. X.25 SABM → SABM Response ✓
5. X.25 UA → UA Response ✓  
6. Connection Ready → Confirmed ✓
7. CONNECTION ESTABLISHED ✓

Key Insights:¶

1. Multi-Layer Protocol Stack:¶

Layer 3: PAD service discovery (fails)
Layer 2: Direct X.25 connection (succeeds)
Layer 1: HDLC transport (works throughout)

2. Graceful Degradation:¶

System doesn't fail completely when PAD unavailable
Automatically falls back to direct X.25
Maintains connectivity at lower protocol layer

3. Buffer Management Strategy:¶

Dual buffer preparation - Multiple frames prepared simultaneously
Pipeline optimization - Next frame ready while current transmitting
Protocol flexibility - Different frame types prepared in parallel

4. Response Timing Analysis:¶

PAD requests: No response (timeout ~1.3s each)
X.25 SABM: Response in 459ms (14:39:13.417 → 14:39:13.876)
X.25 UA: Response in 656ms (14:39:14.114 → 14:39:14.770)
Connection ready: Response in 520ms (14:39:15.017 → 14:39:15.537)

Connection Status: SUCCESS (Not Failure!)¶

The first connection (100→102) actually succeeds through X.25 fallback, not PAD service. This completely changes our understanding of the protocol behavior.

Second Connection Analysis (102→100) - TRUE FAILURE¶

Timeline Analysis - Second Connection (102→100)¶

Phase 1: Routing Protocol Exchange (14:50:47-14:50:49)¶

14:50:47.720 RX: [09 00 21 13 00 19 00 64 00 66 FF FF 00 01 DE 08] - Command from 100
14:50:48.242 TX: [09 20 21 13 00 13 00 66 00 64 FF FF 00 01 DE 0E] - Response from 102  
14:50:49.824 TX: [09 29 00 64] - Status poll to 100

Analysis: Routing exchange successful - proper command/response/poll sequence.

Phase 2: PAD Connection Negotiation (14:50:49-14:50:57)¶

14:50:49.824 RX: [09 00 21 13 00 0E 00 64 00 66 00 00 04 00 DA 14] - PAD request from 100
14:50:50.691 RX: [09 22 21 13 00 0E 00 64 00 66 00 00 04 00 DA 14] - PAD acknowledgment  
14:50:51.707 TX: [09 42 21 13 00 07 00 66 00 64 00 00 FF D8 DE 42] - Data frame with ack required

Multiple retransmissions of 0x42 frame (14:50:52-14:50:57)

Analysis: Extended PAD negotiation with multiple acknowledgment cycles, but no final resolution.

Phase 3: X.25 SABM Attempts - Complete Failure (14:50:57-14:51:23)¶

14:50:57.828 TX: [01 3F 00 64] - SABM attempt #1
14:50:59.238 TX: [01 3F 00 64] - SABM attempt #2 (1.4s later)
14:51:00.642 TX: [01 3F 00 64] - SABM attempt #3 (1.4s later)
14:51:02.016 TX: [01 3F 00 64] - SABM attempt #4 (1.4s later)
14:51:03.401 TX: [01 3F 00 64] - SABM attempt #5 (1.4s later)
...continuing until...
14:51:22.248 TX: [01 3F 00 64] - Final SABM attempt (~25 total attempts)

Critical Finding: NO X.25 RESPONSES RECEIVED AT ALL - 25+ SABM frames transmitted over 24+ seconds - Zero UA responses from node 100 - Connection completely fails at X.25 layer - XFDCT disconnect called at 14:51:21.863

Comparison: Success vs Failure Patterns¶

First Connection (100→102) - SUCCESS:¶

PAD Layer:     5 requests  → NO response  → TIMEOUT
X.25 Layer:    SABM sent   → UA received  → SUCCESS  
Connection:    ESTABLISHED through fallback

Second Connection (102→100) - FAILURE:¶

PAD Layer:     Negotiation → Partial success → INCOMPLETE
X.25 Layer:    25+ SABMs   → NO responses   → TIMEOUT
Connection:    COMPLETE FAILURE - disconnected

Root Cause Analysis¶

Why 100→102 Succeeds:¶

Node 102 supports X.25 - Responds to SABM with UA
Graceful fallback - PAD fails, X.25 succeeds
Full bidirectional handshake - SABM/UA exchange completes
Connection established - Both nodes confirm ready state

Why 102→100 Fails:¶

Node 100 lacks X.25 support - Never responds to SABM
No fallback mechanism - PAD partial, X.25 complete failure
Asymmetric protocol support - 100 can connect TO X.25, but cannot PROVIDE X.25 services
Hard timeout - System gives up after 25+ attempts

Protocol Architecture Revealed¶

Node Capabilities Matrix:¶

                 Node 100    Node 102
PAD Services:    NO          YES (partial)
X.25 Client:     YES         YES  
X.25 Server:     NO          YES

Communication Patterns:¶

100→102: PAD fails → X.25 client→server succeeds
102→100: PAD partial → X.25 server→client fails (100 cannot be X.25 server)

Timing Analysis - Response Patterns:¶

Successful X.25 (102 responding to 100):¶

SABM response time: 459ms average
UA response time: 656ms average
Connection confirm: 520ms average

Failed X.25 (100 not responding to 102):¶

SABM timeout: 1.4s retransmission interval
No responses: 0ms (never responds)
Total attempts: 25+ over 24+ seconds before giving up

Critical Insights¶

1. Asymmetric Network Architecture:¶

Node 102 = Server node - Provides services to others
Node 100 = Client node - Can only consume services

2. Multi-Layer Fallback Strategy:¶

PAD preferred - Try high-level services first
X.25 fallback - Drop to connection-oriented protocol
Graceful degradation - Maintain connectivity at available level

3. Protocol State Machines:¶

Successful connection requires bidirectional protocol support
Client-server asymmetry prevents reverse connections
Timeout/retry logic differs between PAD (5 attempts) and X.25 (25+ attempts)

4. Connection Success Criteria:¶

First trace: SUCCESS (X.25 fallback works)
Second trace: FAILURE (no X.25 server capability on node 100)

This analysis completely overturns the initial assumption that both connections failed. In reality, one succeeds through protocol fallback while the other fails due to asymmetric capabilities.