#

# MAX Diagnostic Command Reference

This guide provides all available information about the MAX diagnostic commands. The information is organized for quick reference, and does not include tutorials. All commands are listed alphabetically.

Under most circumstances, diagnostic commands are not required for correct operation of the MAX, and in some circumstances might produce undesirable results. Please use the following information with caution. Contact Ascend Technical Support with any questions or concerns.

Note: Every attempt has been made to confirm that this chapter correctly describes the functionality and output of the MAX diagnostic commands. But while diagnostic mode can be a very valuable troubleshooting tool for anyone, its primary focus is on the requirements of Ascend's development engineers. For this reason, Ascend does not guarantee the completeness of the list of commands or of the cataloging of functionality from release to release.

## Using MAX diagnostic commands

To be allowed access to diagnostic mode, you must set the Field Service privilege to Yes in the active Security profile. (If you have any questions about how to activate Security profiles, see the MAX Security Supplement.)

Use one of the following two methods to access diagnostic mode:

- From the MAX VT100 interface, display the DO menu by pressing Ctrl-D. Then press D or select D=Diagnostics.

- From the MAX VT100 interface, type the following key sequence in rapid succession:

      Esc [ Esc =

  (Press the Escape key, followed by the Left Bracket key, then the Escape key again, followed by the Equals key.)

  You must press all four keys within one second for the MAX to recognize the escape sequence.

To display an abbreviated list of the most commonly used commands in diagnostic mode, enter a question mark:

    MAX>?

To display a complete listing, append ascend to the question mark:

    MAX>? ascend

To exit diagnostic mode, enter `quit`.

Because most diagnostic commands are designed to give a developer information about specific aspects of MAX functionality, you might find it helpful to use commands in combination to troubleshoot different problems.

For example, when troubleshooting modem-related issues, you might want to use ModemDrvState, ModemDiag, and MDialout (if modem dial-out is supported on your MAX) to get all modem-related information for your calls.

Using several commands simultaneously not only gives you a clearer picture of what is happening, but also shows you a chronological timeline of the events.

## Command reference

Following are the MAX diagnostic commands in alphabetic order:

## ?

Description: Displays an abbreviated list of the most commonly used diagnostic commands and a brief description of each command. Append the `ascend` modifier to display the complete list of commands.

Usage: ?`[` ascend `]`

#### Syntax element | #### Description
--- | ---
`ascend` | List all commands.

Example:

    MAX> ?

    ? -> List all monitor commands

    clr-history -> Clear history log

    ConnList -> Display connection list information

    ether-display -> ether-display <port #> <n>

    fatal-history -> List history log

    fclear -> clear configuration from flash

    FiltUpdate -> Request update of a connection

    frestore -> restore configuration from flash

    fsave -> save configuration to flash

    help -> List all monitor commands

    nslookup -> Perform DNS Lookup

    priDisplay -> priDisplay <n>

    quit -> Exit from monitor to menus

    reset -> Reset unit

    tloadcode -> load code from tftp host

    trestore -> restore configuration from tftp host

    tsave -> save configuration to tftp host

    wanDisplay -> wanDisplay <n>

    wanDSess -> wandsess <sess <n>> (display per session)

    wanNext -> wanNext <n>

    wanOpening -> wanOpening <n> (displays packets during
    opening/negotiation)

## AddrPool

Description: Displays messages related to dynamic address pooling. The command is a toggle that alternately enables and disables the debug display.

Usage: Enter addrpool at the MAX prompt.

Example: Following are several examples of output displayed from `addrpool`.

With 18 addresses currently allocated from a pool:

    ADDRPOOL: lanAllocate index 0 inuse 18

The address 208.147.145.155 was just allocated:

    ADDRPOOL: allocate local pool address [208.147.145.155]

The following message appeared when the address 208.147.145.141 was to be freed because the user of that address had hung up. The MAX must find the pool to which the pool address belonged, then free the address so it is available for another user:

    ADDRPOOL: found entry by base [208.147.145.141] entry
    [208.147.145.129]

    ADDRPOOL: free local pool address [208.147.145.141]

The following messages shows that a new pool is created. Under Ethernet > Mod Config > WAN Options, Pool #1 Start is set to 192.168.8.8, and Pool #1 Count is set to 4:

    ADDRPOOL: Deleting addrPool

    ADDRPOOL: New Addr pool rc = 0

    addrPool index 1 ip [192.168.8.8] count 4

The following message appeared when the Pool #1 Count parameter for an existing pool was changed from 4 to 3:

    ADDRPOOL: Deleting addrPool

    ADDRPOOL: New Addr pool rc = 0

    addrPool index 1 ip [192.168.8.8] count 3

In the events reported by the following display, a second pool is created. Under Ethernet > Mod Config > WAN Options, Pool #2 Start is set to 192.168.10.8, and Pool #2 Count is set to 10:

    ADDRPOOL: Deleting addrPool

    ADDRPOOL: New Addr pool rc = 0

    addrPool index 1 ip [192.168.8.8] count 4

    ADDRPOOL: New Addr pool rc = 0

    addrPool index 1 ip [192.168.8.8] count 4

    addrPool index 2 ip [192.168.10.1] count 10

The second pool is then deleted:

    ADDRPOOL: Deleting addrPool

    ADDRPOOL: New Addr pool rc = 0

    addrPool index 1 ip [192.168.8.8] count 4

## ARPTable

Description: Displays the MAX unit's Address Resolution Protocol (ARP) table. The MAX uses the ARP table to associate known IP addresses with physical hardware addresses.

Usage: Enter `arptable` at the command prompt.

Example:

    MAX> arptable

                      ip address   ether addr  if rts pkt   ref  insert

    DYN    206.30.33.11 00A0244CCE04   0   0   0     1   281379

    DYN   206.30.33.254 00605C4CA220   0   0   0     1   281303

    DYN    206.30.33.21 00059A403B47   0   0   0     1   281179

    DYN    206.30.33.15 00A0247C2A72   0   0   0     1   281178

The ARP table displays the following information:

#### Column | #### Description
--- | ---
| Unnamed first column indicates how the address was learned, dynamically (DYN) or by specification of a Bridge Address (STA).
ip address | Network address contained in ARP requests.
ether addr | Media Access Control (MAC) address of the host identified by `ip` `address`. Also referred to as the hardware address.
if | Interface on which the MAX received the ARP request.
rts | Routes pointing to the address.
pkt | Number of packets queued.
ref | Number of times that the address was used.
insert | Time at which this entry was inserted into the ARP table.

## Avm

Description: Displays a report on the status of the availability of modems in the MAX. Each time you enter `avm`, you get a snapshot of current modem states and the recent history for each modem. The command is particularly helpful in troubleshooting modem connection problems, for which you must focus on the ability of individual modems to successfully connect with dial-in users.

A call is noted as successful if modem handshaking (training) and authentication are successful.

A call is noted as bad if modem handshaking fails at any point in the initial call set-up, or if the dial-in user does not successfully log in.

The `dir` parameter indicates the direction of the last call into each modem. It can have the following settings:

1-Call direction unknown.
2-Call was outgoing.
3-Call was incoming.

A modem is moved to the suspect list if its first four calls are bad, or if it experiences eight bad calls in a row. Modems on the suspect list may still be used if all free modems are in use. Any subsequent successful call to a suspect modem places that modem back on the free list.

Note: A call that has been categorized as bad does not necessarily indicate a modem problem with the MAX. Poor line quality, software problems with the calling modem, wrong numbers, and forgotten passwords all can generate calls that appear as bad calls but that have nothing to do with modems on the MAX.

Usage: Enter `avm` at the command prompt.

Example: In the following display, an 8-mod modem card is located in slot 8 of the MAX. Modems 8:5 and 8:6 are in use. Modems 8:2, 8:3, 8:4, 8:7, and 8:8 are idle and available to accept calls. Modem 1 has been disabled by the V.34 Modem > Modem Diag > Modem #1 parameter.

    MAX> avm

    Modems on free list:

    Modem 8:4, 70 calls, 6 bad, last 32 calls = ffdffbfc dir=3

    Modem 8:8, 54 calls, 1 bad, last 32 calls = ffffffff dir=3

    Modem 8:3, 63 calls, 1 bad, last 32 calls = fffbffff dir=3

    Modem 8:2, 74 calls, 1 bad, last 32 calls = ffffffff dir=3

    Modem 8:7, 64 calls, 2 bad, last 32 calls = ffbfffbf dir=3

    Modems on suspect list:

    Modem 8:1, 57 calls, 0 bad, last 32 calls = ffffff00 dir=3

    Modems on disabled list:

    Modems on dead list:

    Modems on busy list:

    Modem 8:5, 65 calls, 2 bad, last 32 calls = fffffffd dir=3

    Modem 8:6, 58 calls, 1 bad, last 32 calls = ffffffff dir=3

Looking at modem 4 on slot 8 (designated 8:4 ), the eight-digit hexadecimal number has to be converted to binary to indicate how many of the last 32 calls were successful:

`ffdffbfc = 11111111110111111111101111111100`

The zeroes show that modem 8:4 has had four unsuccessful calls, including the last two calls. After the hexadecimal number, `dir=3` indicates that the last call was an incoming call.

## BRIDisplay

Description: Displays messages related to the D-channel signaling for any BRI slot cards installed on the MAX. The command is available only if you have loaded a version of MAX software that supports BRI slot cards.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the BRIDisplay command during a period of low throughput.

Usage: `bridisplay` `n`

where `n` is the number of octets to display per frame. Specifying a value of zero disables the logging of the messages.

Example:

    MAX> bridisplay 4

    BRI-XMIT-7:  : 4 octets @ B04EE520

    [0000]: 00 B3 01 01

    BRI-RCV-7:  : 4 octets @ B0539A80

    [0000]: 02 B3 01 01

    BRI-XMIT-7:  : 4 octets @ B0529560

    [0000]: 02 B3 01 01

    BRI-RCV-7:  : 4 octets @ B05608A0

    [0000]: 00 B3 01 01

## Callback

Description: Displays messages related to the callback functionality of the MAX. You can use the command to display, for example, sessions queued for callback. The command is a toggle that alternately enables and disables the debug display.

With the callback feature enabled, the MAX hangs up after receiving an incoming call that matches the specifications in the Connection profile. The MAX then uses the Dial # specified in the Connection profile to call back the device at the remote end of the link.

You can use the callback command to tighten security by ensuring that the MAX connection to known destinations only. The command can also help you troubleshoot detailed areas of the callback process.

Usage: Enter `callback` at the command prompt.

Example: Following are several examples of output displayed by the Callback command.

    MAX> callback

    CALLBACK debug is now ON

The following message appears as the MAX prepares to call back the remote end:

    CALLBACK: processing entry topeka

The MAX then dials the remote end:

    CALLBACK: initiate call to topeka

When the call has been made and is being negotiated:

    CALLBACK: new state WAITING

If callback failed and will be retried:

    CALLBACK: new state FAILED

If callback is never successful, the call is marked for removal from the callback list and the following message appears:

    CALLBACK-FAILED: topeka marked as failed

After the remote end is called back, its entry is removed from the Callback list so that the MAX can reallocate and use the resources. The following message appears:

    CALLBACK: deleting entry topeka

To terminate the display:

    MAX> callback

    CALLBACK debug is now OFF

## ClockSource

Description: Displays the source of clocking for the MAX. Clock slips can cause connectivity problems, particularly for analog users. If you use the Net/T1 > Line Config > Line # > Clock Source parameter to move the clock source, you can use this diagnostic command to validate your changes.

Note: You need to reboot the MAX to enable any changes to the Clock Source parameter. Also, if more than one line has Clock Source set to Yes, remember that the clock source will be derived from the first line that syncs. If you want to ensure that a particular line is the source, make sure it has Clock Source set to Yes and that all other lines have Clock Source set to No.

Usage: Enter `clocksource` at the command prompt.

Example: In the following example, the clock source is taken from the first T1/PRI line, designated `dsl 0`. ```Dsl#` indicates the maximum number of possible sources for the clock. The source can be on Net/T1 slot cards or Net/BRI slot cards. This MAX has three T1/PRI lines configured, so there are three possible external sources for the clock. `LstSel` is further validation that the clock is being derived from `Dsl#0`. After `Now`, a 2 indicates that layer 2 is up for that line and is available as the clock source.

    MAX> clocksource
    Clock source is dsl 0
    Dsl#    01234567890123456789012345678901234567890123456789
    LstSel  a?????????????????????????????????????????????????
    Now     222-----------------------------------------------

## Clr-History

Description: Clears the fatal-error history log.

Usage: Enter `clr-history` at the command prompt. To display the log before clearing it, enter the fatal-history command.

Example:

    MAX> fatal-history

    OPERATOR RESET:  Index: 99  Load: ti.m40 Revision: 5.0A

    Date: 02/13/1997.       Time: 04:22:47

    DEBUG Reset from unknown in security profile 1.

    SYSTEM IS UP:  Index: 100  Load: ti.m40 Revision: 5.0A

    Date: 02/13/1997.       Time: 04:23:50

    MAX> clr-history

The log is now empty:

    MAX> fatal-history

    MAX>

See Also: Fatal-History

## CoreDump

Description: Enables or disables the ability of the MAX to send the contents of its memory (core) to a specified UNIX host. When you use the function, the core file created can be several megabytes in size. Also, the UNIX host must be running the `ascendump` daemon, which is available by contacting Ascend Technical Support.

The CoreDump command is a particularly useful tool for Ascend's development engineering, and Technical Support occasionally requests its use to help troubleshoot specific issues.

You can include the `now` option to instruct the MAX to dump its core immediately. You can include the `enable` option to direct the MAX to dump its core when it has logged an entry to the fatal error log.

Caution: This command causes active connections to be disconnected and the MAX to reboot after its memory (core) has been dumped. Do not use the command unless specifically requested to do so by an Ascend representative.

Usage: `coredump [enable] [disable] [now]` `ip address`

where:

- `enable` instructs the MAX to dump its core to the specified IP address when an entry is logged to the fatal-error log.

- `disable` cancels the command if it has been enabled.

- `now` instructs the MAX to dump its core immediately to the specified IP address.

Example: Following are examples of entering the CoreDump command, and possible response messages:

    MAX> coredump enable 1.1.1.1

    coredump over UDP is enabled locally only with server 1.1.1.1

    MAX> coredump disable 1.1.1.1

    coredump over UDP is disabled locally only with server 1.1.1.1

    MAX> coredump

    coredump over UDP is disabled locally only with server 1.1.1.1

    MAX> coredump enable 200.200.28.193

    coreDump: Sending arp request...

    coreDump: Sending arp request...

    coreDump: Sending arp request...

    coreDump aborted: Can't find ether address for first hop to
    200.200.28.193

## Ether-Display

Description: Displays the contents of Ethernet packets.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the Ether-Display command during a period of low throughput.

Usage: ether-display`` `port 0-#` n

#### Syntax element | #### Description
--- | ---
`port 0-#` | The range of Ethernet ports on which received or transmitted packets should be displayed. Use zero only to indicate that Ethernet packets for all ports should be displayed.
`n` | The number of octets to display from each Ethernet packet.

Example: To display the first 12 octets of each Ethernet packet for all ports:

    MAX> ether-display 0 12

    Display the first 12 bytes of ETHER messages

    ETHER XMIT: 105 octets @ B07BE920

    [0000]: 00 40 C7 5A 64 6C 00 C0 7B 0C 01 59

    ETHER RECV: 64 octets @ B077EE70

    [0000]: 00 C0 7B 0C 01 59 00 40 C7 5A 64 6C

    ETHER XMIT: 219 octets @ B07BE920

    [0000]: 00 40 C7 5A 64 6C 00 C0 7B 0C 01 59

    ETHER RECV: 64 octets @ B077F4C0

    [0000]: 00 C0 7B 0C 01 59 00 40 C7 5A 64 6C

    MAX> ether-display 0 0

    ETHER message display terminated

## Fatal-History

Description: Displays the MAX fatal-error log. Each time the MAX reboots, it logs a fatal-error message to the fatal-error history log. The fatal-error log also includes Warnings, for which the MAX did not reset. Development engineers use Warnings for troubleshooting purposes. A Warning indicates that the MAX detected an error condition but recovered from it. The number of entries in this log is limited by available flash space, and the errors rotate on a First-In, First-Out (FIFO) basis. You can use the Clr-History command to clear the log.

Note: If your MAX experiences a fatal-error reset or Warning, contact Ascend Technical Support immediately.

##### Definitions of fatal errors:

The following reset is the result of an Assert. This problem can be either hardware or software related. Contact Ascend Technical Support if you experience an FE1 reset.

    FATAL_ASSERT =              1

The following reset results from an out-of-memory condition, sometimes termed a memory leak:

    FATAL_POOLS_NO_BUFFER =     2

Other resets include:

    FATAL_PROFILE_BAD =         3

    FATAL_SWITCH_TYPE_BAD =     4

    FATAL_LIF_FATAL =           5

    FATAL_LCD_ERROR =           6

    FATAL_ISAC_TIMEOUT =        7

    FATAL_SCC_SPURIOUS_INT =    8

The preceding reset is caused by a processor exception error.

    FATAL_EXEC_INVALID_SWITCH = 9

    FATAL_EXEC_NO_MAIL_DESC =   10

The preceding reset occurs if the MAX tries to allocate a mail message and there are none left. A reset of this type is usually due to a memory leak.

    FATAL_EXEC_NO_MAIL_POOL =   11

    FATAL_EXEC_NO_TASK =        12

    FATAL_EXEC_NO_TIMER =       13

    FATAL_EXEC_NO_TIMER_POOL =  14

    FATAL_EXEC_WAIT_IN_CS =     15

    FATAL_DSP_DEAD =            16

    FATAL_DSP_PROTOCOL_ERROR =  17

    FATAL_DSP_INTERNAL_ERROR =  18

    FATAL_DSP_LOSS_OF_SYNC =    19

    FATAL_DSP_UNUSED =          20

    FATAL_DDD_DEAD =            21

    FATAL_DDD_PROTOCOL_ERROR =  22

    FATAL_X25_BUFFERS =         23

    FATAL_X25_INIT =            24

    FATAL_X25_STACK =           25

    FATAL_ZERO_MEMALLOC =       27

    FATAL_NEG_MEMALLOC =        28

    FATAL_TASK_LOOP =           29

The preceding reset is caused by a software loop.

    FATAL_MEMCPY_TOO_LARGE =    30

    FATAL_MEMCPY_NO_MAGIC =     31

    FATAL_MEMCPY_WRONG_MAGIC =  32

    FATAL_MEMCPY_BAD_START =    33

    FATAL_IDEC_TIMEOUT =        34

    FATAL_EXEC_RESTRICTED =     35

    FATAL_STACK_OVERFLOW =      36

    FATAL_OPERATOR_RESET =      99

The preceding entry is logged to the fatal-error table when the MAX has been manually reset, either in diagnostic mode (with the Reset or NVRAMclear commands), through the user interface, or through MIF.

Instead of a standard stack backtrace, the message includes the active Security profile index. On the MAX the Default profile is number 1, and the Full Access profile is number 9. 0 indicates an unknown security profile.

The reset is logged immediately before the MAX goes down.

    FATAL_SYSTEM_UP =           100

As a complement to entry 99, the preceding entry is logged as the MAX is coming up. For a normal, manual reset, a fatal error 99 should appear, followed by a fatal error 100.

##### Warning messages

Warnings are not the result of reset conditions. The MAX logs Warnings when it detects a problem and recovers. Following are the Warnings, in numeric order:

    ERROR_BUFFER_IN_USE             101

    ERROR_BUFFER_WRONG_POOL         102

    ERROR_BUFFER_WRONG_HEAP         103

    ERROR_BUFFER_NOT_MEMALLOC       104

Warning 104 can be logged under different conditions (for example, double freeing memory or a low-memory condition).

    ERROR_BUFFER_BAD_MEMALLOC       105

    ERROR_BUFFER_BOGUS_POOL         106

    ERROR_BUFFER_BOGUS_HEAP         107

Memory management code (or other modules) detected that the buffer header of what should have been a free buffer had been corrupted by the previous overwrite.

    ERROR_BUFFER_NEG_MEMALLOC       108

Warning 108 is logged when a negative length request is made to the memory allocation code.

    ERROR_BUFFER_ZERO_MEMALLOC      109

Warning 109 is similar to Warning 108, except that the a zero length request is made to the memory allocation code.

    ERROR_BUFFER_BOUNDARY           110

    ERROR_BUFFER_TOO_BIG            111

Warning 111occurs when a software routine has tried to allocate a block of memory greater than 64KB.

    ERROR_BUFFER_NULL               112

    ERROR_BUFFER_SEGCOUNT_ZERO      113

    ERROR_BUFFER_TRAILER_MAGIC      114

    ERROR_BUFFER_TRAILER_BUFFER     115

    ERROR_BUFFER_TRAILER_LENGTH     116

    ERROR_BUFFER_TRAILER_USER_MAGIC 117

    ERROR_BUFFER_WRITE_AFTER_FREE   118

    ERROR_BUFFER_NOT_IN_USE         119

    ERROR_BUFFER_MEMCPY_MAGIC       120

    ERROR_BUFFER_MEMCPY_MAGIC_NEXT  121

    ERROR_BUFFER_MIN                101

    ERROR_BUFFER_MAX                121

    ERROR_LCD_ALLOC_FAILURE         145

Warning 145 occurs when a memory-copy routine was called but the source buffer was much larger than expected.

    ERROR_MEMCPY_TOO_LARGE          150

    ERROR_MEMCPY_NO_MAGIC           151

    ERROR_MEMCPY_WRONG_MAGIC        152

    ERROR_MEMCPY_BAD_START          153

    ERROR_WAN_BUFFER_LEAK           154

Warning 154 is caused by an error in the WAN driver.

    ERROR_TERMSRV_STATE             160

    ERROR_TERMSRV_SEMA4             161

    ERROR_STAC_TIMEOUT              170

    ERROR_EXEC_FAILURE              175

Warning 175 occurs because the kernel temporarily does not have available memory to spawn a task.

    ERROR_EXEC_RESTRICTED                      176

    ERROR_EXEC_NO_MAILBOX                      177

    ERROR_EXEC_NO_RESOURCES                  178

    ERROR_CHAN_MAP_STUCK            180

Warning 180 is caused by a missing channel on a T1/PRI line.

    ERROR_CHAN_DISPLAY_STUCK        181

    ERROR_NEW_CALL_NO_DISC_REQ      182

Warning 182 indicates that a Disconnect message to the Central Office (CO) was not sent. The problem can be caused by conditions on the MAX or at the CO. When the MAX encounters the condition, it assumes the CO is correct, and answers the call.

    ERROR_NEW_CALL_NO_DISC_RESP     183

    ERROR_DISC_REQ_DROPPED          184

    ERROR_SPYDER_BUFFER             185

    ERROR_SPYDER_DESC               186

    ERROR_TCP_SBCONT_TOO_BIG        190

    ERROR_TCP_SEQUENCE_GAP          191

    ERROR_TCP_TOO_MUCH_DATA         192

    ERROR_TCP_TOO_MUCH_WRITE        193

    ERROR_TCP_BAD_OPTIONS           194

    ERROR_OSPF_BASE                 200

Usage: Enter `fatal-history``` at the command prompt.

Example:

    MAX> fatal-history

    OPERATOR RESET:  Index: 99  Load: mhpe1bip Revision: 4.6Cp22

    Date: 02/24/1997.       Time: 16:08:43

    DEBUG Reset from unknown in security profile 1.

    OPERATOR RESET:  Index: 99  Load: ebiom.m40 Revision: 5.0A

    Date: 02/24/1997.       Time: 16:09:35

    NVRAM was rebuilt

    SYSTEM IS UP:  Index: 100  Load: ebiom.m40 Revision: 5.0A

    Date: 02/24/1997.       Time: 16:10:04

See Also: Clr-History

## FClear

Description: Clears Flash memory on the MAX. When the MAX boots, it loads the code and configuration from Flash memory into Dynamic Random Access Memory (DRAM). If you want to return your MAX to its factory-set defaults, you need to perform an FClear.

Usage: Enter `fclear` at the command prompt.

Example:

    MAX> fclear

    .

See Also: FSave

## FRestore

Description: Restores a configuration from Flash memory and loads it into DRAM on the MAX.

Note: The MAX performs an FRestore when it boots. You need to execute the command if you have made changes to the current configuration and want to restore the configuration stored in Flash memory.

Usage: Enter `frestore` at the command prompt.

## FSave

Description: Stores the current configuration into Flash memory.

Note: When you load code with the TloadCode command, an FSave is performed automatically before the code is uploaded. When the box boots after the upload, the MAX will load the configuration stored in Flash rather than be reset to factory default settings.

Usage: Enter `fsave` at the command prompt.

Example:

    MAX> fsave

    .........................................

    .

    MAX>

## Heartbeat

Description: Displays information related to multicast heartbeat functionality. The command is a toggle that alternately enables and disables the debug display.

Usage: Enter `heartbeat` at the command prompt.

Example: Following are several examples of output displayed by the Heartbeat command.

    HB: Sending SNMP Alarm count

    HB: Checking Number of HeartBeats received

    HB: HeartBeats received x

    HB: Changing to Alarm Mode, HeartBeats Received x Expected y

    HB: HeartBeat group address changed

    HB: Heart beat received with invalid UDP port

    HB: Heart beat received from invalid source

    HB: Received HeartBeat packet

## Help

Description: Displays a list of the most commonly used diagnostic commands and a brief description of each command. You can append the `ascend``` modifier to display the complete list of commands.

Usage: help`[`ascend`]`

#### Syntax element | #### Description
--- | ---
`ascend` | List all commands.

Example:

    MAX> help

    ? -> List all monitor commands

    clr-history -> Clear history log

    ConnList -> Display connection list information

    ether-display -> ether-display <port #> <n>

    fatal-history -> List history log

    fclear -> clear configuration from flash

    FiltUpdate -> Request update of a connection

    frestore -> restore configuration from flash

    fsave -> save configuration to flash

    help -> List all monitor commands

    nslookup -> Perform DNS Lookup

    priDisplay -> priDisplay <n>

    quit -> Exit from monitor to menus

    reset -> Reset unit

    tloadcode -> load code from tftp host

    trestore -> restore configuration from tftp host

    tsave -> save configuration to tftp host

    wanDisplay -> wanDisplay <n>

    wanDSess -> wandsess <sess <n>> (display per session)

    wanNext -> wanNext <n>

    wanOpening -> wanOpening <n> (displays packets during
    opening/negotiation)

See Also: ?

## IPXripDebug

Description: Displays incoming and outgoing IPX RIP traffic. The command is a toggle that alternately enables and disables the debug display.

Usage: Enter `ipxripdebug` at the command prompt.

Example:

    MAX> ipxripdebug

    IPX-RIP state display is ON

The following message appears as the MAX sends an IPX RIP packet announcing its route:

    IPXRIP: 10000a17 announced 0 routes on interface 1000:

Next, a Pipeline 50 has dialed the MAX. The MAX receives a RIP route from the Pipeline:

    IPXRIP: received response from ac1b0001:00c07b5e04c0 (1 nets).

The following message indicates that the MAX is delaying sending a RIP packet in order to prevent the interpacket arrival time from being closer than busy/slow routers can handle. An IPX router should never violate the minimum broadcast delay.

    IPX-RIP: too soon to send on interface 1000.

The following messages indicate received and sent RIP updates:

    IPXRIP: 10000a81 announced 0 routes on interface 1000:

    IPXRIP: received response from ac1b0001:00c07b6204c0 (1 nets).

    IPXRIP: 10000aa6 announced 0 routes on interface 1000:

    IPXRIP: received response from ac1b0001:00c07b5504c0 (1 nets).

    IPXRIP: 10000abc announced 0 routes on interface 1000:

## MdbStr

Description: Modfies the default modem AT command strings used by the modems on the MAX for both incoming and for outgoing calls. WIth older software, you could not modify the AT command for modems on the MAX. You could affect the string in minor ways by modifying the V42/MNP, Max Baud, and MDM Trn Lvl parameters located in Ethernet > Mod Config > TServe Options.

The MdbStr command also allows you to return the string to its factory default settings.

The modem chip in the MAX supports AT commands of up to 56 characters in length. To fully support all possible functionality, each AT command is sent as two separate strings. You can modify one or both strings.

Note: The AT command string initializes the modems it affects. When you change the AT command string, you are changing the functionality of the modems. Please use the MdbStr command carefully.

Following are the two default strings for the MAX:

- `AT&F0&C1V0W1X4`

- `AT%C3\N3S2=255S95=44S91=10+MS=11,1,300,33600A`

Usage: `mdbstr [0] [1] [2] [``AT command string``]`

Example: You can modify each portion of the AT command string as follows:

Override the existing first string with a new string:

    mdbstr 1 AT&F0&C1V1W1

Override the second portion of the AT command string:

    mdbstr 2 AT%C3\N3S2=255S95=44S91=10+MS=11,1,300,14400A

Return both strings to their factory default settings:

    mdbstr 0

## ModemDiag

Description: Displays diagnostic information about each modem as the modem's call is cleared. The command is a toggle that alternately enables and disables the diagnostic display.

With ModemDiag enabled, at the end of each modem call the command initiates an AT&V1 call and displays the following variables with their current values:

Usage: Enter `modemdiag` at the command prompt.

#### Variable | #### Description
--- | ---
TERMINATION REASON | LINK DISCONNECT-The remote side disconnected the call. LOCAL REQUEST-The MAX initiated a disconnect because of poor line quality. CARRIER LOSS GSTN CLEARDOWN-Global Switched telephone network (GSTN) initiated the disconnect. NO ERROR CORRECTION INCOMPATIBLE PROTOCOL EXCESSIVE RETRANSMISSIONS DTR LOSS INACTIVITY TIMEOUT INCOMPATIBLE SPEEDS BREAK DISCONNECT KEY ABORT
LAST TX data rate | Last data rate at which the modem on the MAX was transmitting.
HIGHEST TX data rate | Highest data rate at which the modem on the MAX was transmitting.
LAST RX data rate | Last data rate at which the modem on the MAX was receiving.
HIGHEST RX data rate | Highest data rate at which the modem on the MAX was receiving.
Error correction PROTOCOL | Negotiated error correction protocol.
Data COMPRESSION | Negotiated data compression protocol.
Line QUALITY | Probes are sent by each modem to determine the quality of the line and the connection. The range for this variable is 0 to 128. The lower the number, the better the perceived line quality.
Receive LEVEL | Representation of the attenuation (weakening) of the modem signal, which is measured in decibels. The decibel rating is translated into a number between 0 and 128 for inclusion in this report. The lower the number, the lower the attenuation of the modem signal.
Highest SPX Receive State | Number relating to an internal DSP state machine in the modem code. Has no practical use for most users.
Highest SPX Transmit State | Number relating to an internal DSP state machine in the modem code. Has no practical use for most users.

Example:

    MAX> modemdiag

    TERMINATION REASON.......... LINK DISCONNECT

    LAST TX data rate........... 26400 BPS

    HIGHEST TX data rate........ 26400 BPS

    LAST RX data rate........... 24000 BPS

    HIGHEST RX data rate........ 24000 BPS

    Error correction PROTOCOL... LAPM

    Data COMPRESSION............ V42Bis

    Line QUALITY................ 032

    Receive LEVEL............... 017

    Highest SPX Receive State... 67

    Highest SPX Transmit State.. 67

    TERMINATION REASON.......... LINK DISCONNECT

    LAST TX data rate........... 28800 BPS

    HIGHEST TX data rate........ 31200 BPS

    LAST RX data rate........... 28800 BPS

    HIGHEST RX data rate........ 28800 BPS

    Error correction PROTOCOL... LAPM

    Data COMPRESSION............ V42Bis

    Line QUALITY................ 032

    Receive LEVEL............... 017

    Highest SPX Receive State... 85

    Highest SPX Transmit State.. 87

## MDialout

Description: Displays messages related to modem dialout. You can use the command in conjunction with the diagnostic command ModemDrvState to get detailed information about outbound modem calls.

The command is a toggle that alternately enables and disables the debug display.

Usage: Enter `mdialout` at the command prompt.

Example: A modem on the MAX prepares to make an outbound modem call, but never receives a dialtone:

    MAX> mdialout

    MDIALOUT-2/4: >> CURR state=Await_Off_Hook, NEW event=Event_Off_Hook

    MDIALOUT-2/4: connected to DSP!

    MDIALOUT-2/4: rqst tone (14) via channelIndex 0

    MDIALOUT-2/4: tone generation started.

    MDIALOUT-2/4: >> CURR state=Await_Dial_Tone, NEW
    event=Event_Dialtone_On

    MDIALOUT-2/4: decode timer started.

    MDIALOUT-2/4: << NEW state=Await_1st_Digit

    MDIALOUT-2/4: enabling tone search, channel index=0, timeslot=0

    MDIALOUT-2/4: << NEW state=Await_1st_Digit

    MDIALOUT-2/4: >> CURR state=Await_1st_Digit, NEW event=Event_On_Hook

    MDIALOUT-2/4: stopping decode timer.

    MDIALOUT-2/4: rqst tone (15) via channelIndex 0

    MDIALOUT-2/4: disabling tone search, channel index=0

    MDIALOUT-2/4: disconnected from DSP.

    MDIALOUT-2/4: << NEW state=Await_Off_Hook

    MDIALOUT-2/4: >> CURR state=Await_Off_Hook, NEW event=Event_Close_Rqst

    MDIALOUT-?/?: << NEW state= <DELETED>

## ModemDrvDump

Description: Displays information about the status of each modem.

Usage: Enter modemdrvdump at the command prompt.

Example: Following is a message about modem 0 (the first modem) in the modem card in slot 3 on the MAX. The numbers in brackets indicate number of calls with unexpected open requests, unexpected Rcode events, unexpected release events and unexpected timeouts:

    MODEMDRV-3/0: Unexp Open/Rcode/Rlsd/TimOut=[0,0,0,0]

## ModemDrvState

Description: Displays communication to and from the modem driver on the MAX. You can see which buffers are allocated and which AT command strings are being used to establish modem connections.

You can also determine whether data is received from the modem in an understandable format. If line quality is poor, the modem driver attempts to parse incoming data from the modem, but it might not be successful.

The command is a toggle that alternately enables and disables the diagnostic display.

Note: Once a connection is negotiated, the modems exchange a series of numerical result codes. You can see and decipher these result codes to determine the negotiated connection rate and error correction/compression protocols. Following is a list of several result codes and their meanings:

    0 - OK

    1 - CONNECT (300 bps)

    2 - RING

    3 - NO CARRIER

    4 - ERROR

    5 - CONNECT 1200

    6 - NO DIALTONE

    7 - BUSY

    8 - NO ANSWER

    9 - CONNECT 0600

    10 - CONNECT 2400

    11 - ONNECT 4800

    12 - CONNECT 9600

    13 - CONNECT 7200

    14 - CONNECT 12000

    15 - CONNECT 14400

    16 - CONNECT 19200

    17 - CONNECT 38400

    18 - CONNECT 57600

    22 - CONNECT 1200/75 (Models with v.23 support only)

    23 - CONNECT 75/1200 (Models with v.23 support only

    24 - DELAYED

    25 - CONNECT 14400

    32 - BLACKLISTED

    33 - FAX

    34 - FCERROR

    35 - DATA

    40 - CARRIER 300

    43 - CONNECT 16800 (V.34 ONLY)

    44 - CARRIER 1200/75 (Models with v.23 support only)

    45 - CARRIER 75/1200 (Models with v.23 support only)

    46 - CARRIER 1200

    47 - CARRIER 2400

    48 - CARRIER 4800

    49 - CARRIER 7200

    50 - CARRIER 9600

    51 - CARRIER 12000

    52 - CARRIER 14400

    66 - COMPRESSION: CLASS 5 (MNP 5)

    67 - COMPRESSION: V.42BIS (BTLZ)

    69 - COMPRESSION: NONE

    70 - PROTOCOL: NONE

    77 - PROTOCOL: LAP-M (V.42)

    80 - PROTOCOL: ALT (MNP)

    81 - PROTOCOL: ALT - CELLULAR (MNP 10) +FC +FCERROR

    85 - CONNECT 19200 (V.34 ONLY)

    91 - CONNECT 21600 (V.34 ONLY)

    99 - CONNECT 24000 (V.34 ONLY)

    103 - CONNECT 26400 (V.34 ONLY)

    107 - CONNECT 28800 (V.34 ONLY)

    151 - CONNECT 31200 (V.34 ONLY)

    155* - CONNECT 33600 (V.34 ONLY)

Usage: Enter `modemdrvstate` at the command prompt.

Example: A modem call comes into the MAX, and a modem call is cleared from the MAX.

    MAX> modemdrvstate

    MODEMDRV debug display is ON

Modem 1 on the modem card in slot 3 has been assigned to answer an incoming modem call:

    MODEMDRV-3/1: modemOpen modemHandle B04E3898, hdlcHandle
    B026809C, orig 0

The modem is idle, so it is available to answer the call:

    MODEMDRV-3/1: _processOpen/IDLE

The next two lines show the MAX modem sending the first string. The second line shows that a buffer needs to be allocated for sending the command out the WAN.

    MODEMDRV: Answer String, Part 1 - AT&F0E0

    MODEMDRV-3/1: _hdlcBufSentFnc: buffer = 2E12EAE0, status = SENT

Buffers are allocated for data being received from the WAN:

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13ADF0, len=8,
    parseState[n,v]=[0,0], status= RCVD

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13BA20, len=5,
    parseState[n,v]=[0,0], status= RCVD

The MAX modem receives OK from the calling modem:

    MODEMDRV-3/1: data =OK

The same process is repeated for strings 2 and 3:

    MODEMDRV-3/1: _processTimeout/DIAL_STR2

    MODEMDRV: Answer String, Part 2 - AT&C1V0W1X4

    MODEMDRV-3/1: _hdlcBufSentFnc: buffer = 2E12EAE0, status = SENT

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13C038, len=2,
    parseState[n,v]=[0,0], status= RCVD

    MODEMDRV-3/1: data = 0

    MODEMDRV-3/1: _processTimeout/DIAL_STR3

    MODEMDRV: Answer String, Part 3 -
    AT%C3\N3S2=255S95=44S91=10+MS=11,1,300,33600A

Now, result codes are processed to clarify the characteristics of the connection. The MAX modem sends a result code of 52, or CARRIER 14400, and the MAX modem receives the same speed from the calling modem:

    MODEMDRV-3/1: _hdlcBufSentFnc: buffer = 2E12EAE0, status = SENT

    MODEMDRV-3/1: data = 5

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13ADF0, len=2, parseState[n,v]=[5,0],
    status= RCVD

    MODEMDRV-3/1: data = 2

    MODEMDRV-3/1: decode= 52

Result codes 77 and 67 indicate that V.42 error correction and V.42bis error compression, respectively, have been successfully negotiated.

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13B408, len=1,
    parseState[n,v]=[2,0], status= RCVD

    MODEMDRV-3/1: data = 7

    MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13BA20, len=8,
    parseState[n,v]=[5,0], status= RCVD

    19DEMDRV-3/1: data = 7

    MODEMDRV-3/1: decode= 77

    MODEMDRV-3/1: decode= 67

At this point the modem call is up, and the modem driver has completed its task. From here, the call will be passed to Ethernet resources:

    MODEMDRV-3/1: _processRcodeEvent/AWAITING RLSD, mType=5, RLSD=0

    MODEMDRV-3/1: _processRlsdChange/AWAITING RLSD = 1

Following is the normal sequence of steps for a modem call that is cleared (by either modem). Modem 5 on the modem card in slot 7 of the MAX is freed from the previous call and is reinitialized (so it is available for the next call).

    MODEMDRV-7/5: modemClose modemHandle B04E6F38

    MODEMDRV-7/5: _closeConnection:ONLINE, event=3

    MODEMDRV-7/5: _processTimeout/INIT

## NSLookup

Description: Similar to the UNIX `nslookup` command. When you specify a host name, a DNS request is forwarded. If the host is found, the corresponding IP address is displayed.

Usage: `nslookup``` `host_name`

Example:

    MAX> nslookup host1

    Resolving host host1.

    IP address for host drawbridge is 1.1.1.1.

    MAX> nslookup 198.4.92.1

    Resolving host 198.4.92.1.

    MAX> nslookup

    Missing host name.

    MAX> nslookup nohost

    Resolving host nohost.

    Unable to resolve nohost!

## NVRAMClear

Description: Clears Nonvolatile Random Access Memory (NVRAM). The current system configuration is stored in NVRAM.

Note: A copy of the configuration may also be stored in Flash memory. If you clear NVRAM, the MAX resets and initializes itself with the configuration it detects in Flash memory. To return your MAX to its factory default settings, you must first use the FClear command to clear the configuration in Flash then use NVRAMClear.

Usage: Enter `nvramclear` at the command prompt.

See Also: FClear

## PPPDump

Description: Very similar to the WANDisplay diagnostic command. But `PPPDump` strips out escape characters that are present for asynchronous PPP users (who are dialing in with modems). The escape characters are necessary because of the asynchronous nature of the data stream. Stripping them out simply clarifies the presentation of the data.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the PPPDump command during a period of low throughput.

Usage: `pppdump` `n`

where `n` is the number of octets to display per frame. Specifying a value of 0 (zero) disables the logging of data.

Example:

Consider the following frames, which were logged by the WANDisplay 64 command:

    7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 37 7D 22 7D 26 7D 20 7D
    2A 7D 20 7D 20 2D 7D 23 7D 26 3A AA 7E

    7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 23 7D 20 7D 24 7D 20 7D 20
    7D 22 7D 7E

To get the data stream without escape characters, the 0x7D bytes need to be stripped, and the byte following each 0x7D byte needs to be decremented by 0x20.

With PPPDump, the MAX automatically convert and displays the data as follows:

    7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 2D 03 06 3A AA 7E 7E

    FF 03 C0 21 01 01 00 23 00 24 00 00 02 7E

See Also: WANDisplay, WANNext, WANOpen

## PPPFSM

Displays changes to the PPP state machine as PPP users connect. The command is a toggle that alternately enables and disables the diagnostics display.

Usage: Enter `pppfsm` at the command prompt.

Example: The following display shows the complete establishment of a PPP session.

    MAX> pppfsm

    PPPFSM state display is ON

    PPPFSM-97: Layer 0   State INITIAL     Event OPEN...

    PPPFSM-97: ...New State STARTING

    PPPFSM-97: Layer 0   State STARTING    Event UP...

    PPPFSM-97: ...New State REQSENT

    PPPFSM-97: Layer 1   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 2   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 3   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 4   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 5   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 6   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 7   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 8   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 9   State INITIAL     Event UP...

    PPPFSM-97: ...New State CLOSED

    PPPFSM-97: Layer 0   State REQSENT     Event RCONFREJ...

    PPPFSM: irc_new scr 4

    PPPFSM-97: ...New State REQSENT

    PPPFSM-97: Layer 0   State REQSENT     Event RCONFACK...

    PPPFSM-97: ...New State ACKRECD

    PPPFSM-97: Layer 0   State ACKRECD     Event RCONFREQ...

    PPPFSM-97: ...New State ACKRECD

    PPPFSM-97: Layer 0   State ACKRECD     Event RCONFREQ...

    PPPFSM-97: Layer 1   State CLOSED      Event OPEN...

    PPPFSM-97: ...New State REQSENT

    PPPFSM-97: ...New State OPENED

    PPPFSM: PAP Packet

    PPPFSM-97: Layer 6   State CLOSED      Event OPEN...

    PPPFSM-97: ...New State REQSENT

    PPPFSM-97: Layer 4   State CLOSED      Event OPEN...

    PPPFSM-97: ...New State REQSENT

    PPPFSM-97: Layer 4   State REQSENT     Event RCONFREQ...

    PPPFSM-97: ...New State REQSENT

    PPPFSM: ccp Packet code 1

    PPPFSM-97: Layer 6   State REQSENT     Event RCONFREQ...

    PPPFSM-97: ...New State REQSENT

    PPPFSM: ccp Packet code 2

    PPPFSM-97: Layer 6   State REQSENT     Event RCONFACK...

    PPPFSM-97: ...New State ACKRECD

    PPPFSM-97: Layer 4   State REQSENT     Event RCONFACK...

    PPPFSM-97: ...New State ACKRECD

## PPPIF

Description: Displays messages relating to each PPP connection. This command is particularly useful in troubleshooting negotiation failures. To help in troublshooting PPP issues, you might want to use PPPIF in conjunction with PPPDump.

Usage: Enter `pppif` at the command prompt.

Example:

    MAX> pppif

    PPPIF debug is ON

    PPPIF: open: routeid 285, incoming YES

The following message indicates a modem call:

    PPPIF-110: ASYNC mode

Link Compression Protocol (LCP) is negotiated:

    VJ Header compression is enabled.

    PPPIF-110: vj comp on

PAP authentication is configured on the MAX and required for access:

    PPPIF-110: _initAuthentication

    PPPIF-110: auth mode 1

    PPPIF-110: PAP auth, incoming

    PPPIF-110: bypassing async layer

LCP has been successfully negotiated and established. Authentication is next:

    PPPIF-110: Link Is up.

    PPPIF-110: pppMpNegUntimeout last 0 layer 0

    PPPIF-110: pppMpNegUntimeout last 0 layer 0

    PPPIF-110: LCP Opened, local 'Answer', remote ''

    PPPIF-110: _openAuthentication

    PPPIF-110: pppMpNegUntimeout last 0 layer 1

    PPPIF-110: Auth Opened

    PPPIF-110: Remote hostName is 'my_name'

PAP Authentication was successful. Compression Control Protocol (CCP) is negotiated next, along with IP Network Control Protocol (IPNCP):

    PPPIF-110: opening CCP

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpNegTimeout layer 6

The user is given the address 1.1.1.1 from pool 0:

    PPPIF-110: using address from pool 0

    PPPIF-110: Allocated address [1.1.1.1]

    PPPIF-110: opening IPNCP:

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpNegTimeout layer 4

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpNegUntimeout last 0 layer 6

    PPPIF-110: pppMpNegUntimeout last 0 layer 4

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpNegUntimeout last 0 layer 4

    PPPIF-110: IPNCP Opened to

    PPPIF-110: pppMpSendNeg Pkt

    PPPIF-110: pppMpNegUntimeout last 0 layer 6

    PPPIF-110: CCP Opened

IPNCP and CCP have been successfully negotiated. The PPP session has been completely established.

## PPPInfo

Description: Displays information about established PPP sessions. Has little practical use other than as a tool for developmental engineering.

Usage: `ppinfo` `index``[all]`

Example:

#### Syntax element | #### Description
--- | ---
`index` | Selects a particular PPP information table.
`all` | Displays information about embedded structures.

Example:

    MAX> pppinfo 1

    Ncp[LCP]        = B02B396C

    Ncp[AUTH]       = B02B39BC

    Ncp[CHAP]       = B02B3A0C

    Ncp[LQM]        = B02B3A5C

    Ncp[IPNCP]      = B02B3AAC

    Ncp[BNCP]       = B02B3AFC

    Ncp[CCP]        = B02B3B4C

    Ncp[IPXNCP]     = B02B3B9C

    Ncp[ATNCP]      = B02B3BEC

    Ncp[UNKNOWN]    = B02B3C3C

    Mode            = async

    nOpen pending   = 0

    LocalAsyncMap   = 0

    RemoteAsyncMap  = 0

    Peer Name       = N/A

    Rmt Auth State  = RMT_NONE

    aibuf           = 0

    ipcp            = B03E502C

    vJinfo          = 0

    localVjInfo     = 0

    bncpInfo        = B03E559C

    ipxInfo         = B03E55DC

    remote          = no

    Bad FCS         = a

## PPTPCM

Description: Displays messages relating to the call management layer of PPTP. Messages appear as calls are routed to the PPTP server by the MAX. The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `pptpcm` at the command prompt.

Example: Following are messages from a successful connection:

    PPTPCM: Connecting to host [1.1.1.1]

    PPTPCM-[1.1.1.1]: Event = Local-Start-Request

    PPTPCM-[1.1.1.1]: Starting local session

In the following message, `status = 0` indicates that this was a successful connection:

    PPTPCM-[1.1.1.1]: Started local session; status = 0

    PPTPCM-[1.1.1.1]: _receiveFunc called

    PPTPCM-[1.1.1.1]: Event = Remote-Start-Reply

    PPTPCM-[1.1.1.1]: Session state changed from Local-Start to Up

Following are messages from an unsuccessful connection:

    PPTPCM-[2.2.2.2]: Event = Local-Start-Request

    PPTPCM-[2.2.2.2]: Starting local session

    PPTPCM-[0.0.0.0]: Started local session; status = -4

    PPTPCM-[0.0.0.0]: EC Start failed

## PPTPData

Description: Displays the data flowing between the PPTP client and the PPTP server. The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `pptpdata` at the command prompt.

Example: The first of the following messages indicates that the MAX received a positive acknowledgement from the NT server:

    PPTPDATA-[1.1.1.1]: Received GRE ACK

Also, the MAX received data from the NT server that needs to be forwarded out the WAN port:

    PPTPDATA-[1.1.1.1]: _dataFromLan

The MAX receives a packet from the WAN with a good Frame Check Sequence, and sends it to the PPTP server to be processed:

    PPTPDATA-[1.1.1.1]: Good FCS.  Sending packet to peer

The following message is a result of an unsuccessful attempt to connect to an NT PPTP server.

    PPTPDATA-[2.2.2.2]: pptpDataSessionDown, Session not found

## PPTPEC

Description: Displays control link messages between the PPTP client and the PPTP server. The command is a toggle that alternately enables and disables the diagnostics display.

Usage: Enter `pptpec` at the command prompt.

Example: Following are messages from a successful connection and from an unsuccessful attempt.

Successsful connection:

    PPTPEC-[1.1.1.1]: pptpECSend called

    PPTPEC-[1.1.1.1]: New state = Running

    PPTPEC-[1.1.1.1]: Event = Send, current state = Running

    PPTPEC-[1.1.1.1]: New state = Running

    PPTPEC-[1.1.1.1]: Receive callback called

    PPTPEC-[1.1.1.1]: Event = Receive, current state = Running

    PPTPEC-[1.1.1.1]: New state = Running

Unsuccessful attempt:

    PPTPEC-[2.2.2.2]: pptpECStart called\x7f

    PPTPEC-[2.2.2.2]: Event = Start, current state = Stopped

## PPTPSend

Description: Sends an Echo Request to the specified NT PPTP server.

Usage: `pptpsend` `ip_address_of_PPTP_server`

Example:

    MAX> pptpsend 1.1.1.1

    PPTPCM: Sending Echo Request to host [1.1.1.1]

## PRIDisplay

Description: Displays the contents of WAN packets.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the PRIDisplay command during a period of low throughput.

Usage: `pridisplay` `n`

where `n` is the number of octets to display from each WAN packet.

Example: The output from the following PRIDisplay command shows the first 64 bytes from each packet sent to or received from the WAN:

    MAX> pridisplay 64

    Display the first 64 bytes of PRI messages

    PRI-RCV-0(task: B0479C00, time: 83251.39) 4 octets @ B0539620

    [0000]: 02 01 01 61

    PRI-XMIT-0(task: B04B3A40, time: 83251.39) 4 octets @ B050C340

    [0000]: 02 01 01 49

    PRI-RCV-0(task: B0479C00, time: 83261.64) 4 octets @ B052AF60

    [0000]: 02 01 01 61

    PRI-XMIT-0(task: B04B3A40, time: 83261.65) 4 octets @ B051EFA0

    [0000]: 02 01 01 49

    PRI-RCV-0(task: B0479C00, time: 83269.98) 27 octets @ B0539620

    [0000]: 02 01 48 60 08 02 1A 7B 05 04 03 80 90 A2 18 04

    [0010]: E9 82 83 88 70 05 C1 34 39 39 30

    pridisplay 0

    PRI message display terminated

## Quit

Description: Exits diagnostic mode.

Usage: Enter `quit` at the command prompt.

## RadAcct

Description: Displays RADIUS accounting information. The RadAcct command displays very few messages if RADIUS Accounting is functioning correctly. The command is a toggle that alternately enables and disables the diagnostic display.

`(F`or troubleshooting RADIUS-related issues, the RADIF command displays more detailed information.)

Usage: Enter `radacct` at the command prompt.

Example:

    MAX> radacct

    RADACCT debug display is ON

A user hangs up and a stop record is generated:

    RADACCT-147:stopRadAcct

The following message indicates that there is some load on the network and the sending of a stop record is delayed. This does not necessarily indicate a problem:

    RADACCT-147:_endRadAcct: STOP was delayed

## RadIF

Description: Displays RADIUS-related messages. RadIF is a powerful diagnostic command, because it displays RADIUS messages the MAX receives as well as messages that it sends. Output from RadIF, in conjunction with running your RADIUS daemon in diagnostic mode (using the `-x` option), gives you virtually all the information you need to clarify issues relating to user authentication.

You can also validate the IP port that you have configured (or think you have configured), and the user name that is being sent by the client.

The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `radif` at the command prompt.

Example: Following are messages you might see for a successful RADIUS authentication:

    RADIF: authenticating <8:my_name> with PAP

    RADIF: _radiusRequest: id 41, user name <9:my_name>

    RADIF: _radiusRequest: challenge len = <0>

The RADIUS Daemon IP address and authentication port appear:

    RADIF: _radiusRequest: socket 5 len 89 ipaddr 01010101 port
    65534->1645

    RADIF: _radCallback

    RADIF: _radCallback, buf = B05BBFA0

The response is sent back from RADIUS. In this case, the user `my_name` has passed authentication. Following is a list of the most common responses:

    1 - Authentication Request
    2 - Positive Acknowledgement
    3 - Rejection
    4 - Accounting Request
    5 - Accounting Response
    7 - Password Change Request
    8 - Password Change Positive Acknowledgement
    9 - Password Change Rejection
    11 - Access Challenge
    29 - Password - next code
    30 - Password New PIN
    31 - Password Terminate Session
    32 - Password Expired

    RADIF: _radCallback, authcode = 2

    RADIF: Authentication Ack

After authenticating a user, the RADIUS daemon sends the attributes from the user profile to the MAX. The MAX creates the user's Connection profile from these attributes, and RadIF displays them. For a complete list of attribute numbers, see the MAX RADIUS Configuration Guide.

    RADIF: attribute 6, len 6, 00 00 00 02

    RADIF: attribute 7, len 6, 00 00 00 01

    RADIF: attribute 8, len 6, ff ff ff fe

    RADIF: attribute 9, len 6, ff ff ff 00

    RADIF: attribute 11, len 12, 73 74 64 2e

    RADIF: attribute 12, len 6, 00 00 05 dc

    RADIF: attribute 10, len 6, 00 00 00 00

    RADIF: attribute 13, len 6, 00 00 00 01

    RADIF: attribute 244, len 6, 00 00 11 94

    RADIF: attribute 169, len 6, 00 00 11 94

    RADIF: attribute 170, len 6, 00 00 00 02

    RADIF: attribute 245, len 6, 00 00 00 00

    RADIF: attribute 235, len 6, 00 00 00 01

A RADIUS Accounting Start packet is sent to the RADIUS Accounting Server (using port 1646):

    RADIF: _radiusAcctRequest: id 42, user name <9:my_name>

    RADIF: _radiusAcctRequest: socket 6 len 82 IP cf9e400b port
    1646, ID=42

    RADIF: _radCallback

    RADIF: _radCallback, buf = B05433C0

    RADIF: _radProcAcctRsp: user:<9:my_name>, ID=42

## RadStats

Description: Displays a compilation of RADIUS Authentication and Accounting statistics.

Usage: Enter `radstats` at the command prompt.

Example:

    MAX> radstats

    RADIUS authen stats:

In the following message,`A` denotes authentication and `O` denotes other. There were 612 authentication requests sent and 612 authentication responses received.

    0  sent[A,O]=[612,15], rcv[A,O]=[612,8]

602 were authenticated successfully, and 18 were not:

    timout[A,O]=[0,6], unexp=0, bad=18, authOK=602

In the next message, the IP address of the RADIUS server is 1.1.1.1, and the `curServerFlag` indicates whether or not this RADIUS server is the current authentication server. (You can have several configured RADIUS servers, but only one is current at any one time.) `0` (zeor) indicates no. A `1` indicates yes.

    IpAddress 1.1.1.1, curServerFlag 1

    RADIUS accounting stats:

The next message indicates that the MAX sent 1557 Accounting packets and received 1555 responses (`ACKs` from the Accounting server). Therefore, the `unexp` value is `2`. This does not necessarily indicate a problem, but might be the result of the MAX timing out a particular session before receiving an `ACK` from the RADIUS server. Momentary traffic load might cause this condition. The value of `bad` is the number of packets that were formatted incorrectly by either the MAX or the RADIUS server.

    0  sent=1557, rcv=1555, timout=0, unexp=2, bad=0

In the next message, note that the Accounting server is different from the Authentication server. The Accounting and Authentication servers do not need to be running on the same host, although they can be.

    IpAddress 2.2.2.2, curServerFlag 1

    Local Rad Acct Stats:

The next two messages can be used to look for traffic congestion problems or badly formatted Accounting packets. Under typical conditions, you might see a few packets whose acknowledgments fail.

The first message indicates whether any RADIUS requests have been dropped by the MAX. With this particular message, no requests were dropped. 1557 were sent successfully:

    nSent[OK,fail]=[1557,0], nRcv=1557, nDrop[QFull,Other]=[0,0]

The next message indicates whether any session timeouts resulted from failure to receive a RADIUS responses were not received, causing a session timeout. The message also indicates responses that are received by the MAX but that do not match any expected responses. The MAX keeps a list of sent requests, and expects a response for each request. In the following message, one response received from the RADIUS server did not match any of the requests that the MAX had sent out. This might be caused by a corrupted response packet, or by the MAX timing out the session before the response was received.

    nRsp[TimOut,NoMatch]=[0,1], nBackoff[new,norsp]=[0,0]

The following messages display a summarized list of RADIUS server statistics:

    Local Rad Serv Stats:

    unkClient=0

    index 0 #Sent = 0, #SendFail=0 badAuthRcv = 0, badPktRcv = 0

## Reset

Description: Resets the MAX, which terminates all active connections and restarts. All users are logged out and the default security level is reactivated. All active WAN lines are temporarily shut down because of the loss of signaling or framing information. As the MAX boots, it runs its Power-On Self Tests (POST).

Usage: Enter `reset` at the command prompt.

Example: To reset the unit:

    MAX> reset

See Also: NVRAM

## Revision

Description: Displays the serial number of the box.

Usage: Enter `revision` at the command prompt.

Example: In the following message, the MAX has a serial number of `6363077`.

    MAX> revision

    revision = 0 1 10 6363077

## SNTP

Description: Displays messages related to Simple Network Time Protocol (SNTP). The command is a toggle that alternately enables and disables the diagnostics display.

Usage: Enter `sntp` at the command prompt.

Example: Following are sample messages displayed with SNTP enabled.

The MAX accepts time from a configured NTP server. The following message appears if the MAX does not accept a supplied time:

    Reject:li= x stratum= y tx= z

The following message indicates that the MAX accepts the time from a specified NTP server:

    Server= 0 Time is b6dd82ed d94128e

Because the stored time is off by more than one second, it is adjusted:

    SNTP: x Diff1= y Diff2= z

## TelnetDebug

Description: Displays messages as Telnet connections are attempted or established. The Telnet protocol negotiates several options as sessions are established, and TelnetDebug displays the Telnet option negotiations.

The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `telnetdebug` at the command prompt.

Example: The following session shows the MAX terminal server establishing a successful Telnet connection with another UNIX host.

    MAX> telnetdebug

    TELNET debug is now ON

The far-end UNIX host has been contacted:

    TELNET-4: TCP connect

For this Telnet session, the MAX will support options 24 and 1. The UNIX host should respond with either `DO` or `WONT`:

    TELNET-4: send WILL 24

    TELNET-4: recv WILL 1

The UNIX host will support option 1:

    TELNET-4: repl DO 1

The MAX receives a request to support option 3:

    TELNET-4: recv WILL 3

The MAX will support option 3:

    TELNET-4: repl DO 3

The UNIX host will support option 3:

    TELNET-4: recv DO 3

The UNIX host will not support option 24:

    TELNET-4: recv DONT 24

The MAX will not support option 24:

    TELNET-4: repl WONT 24

The UNIX host will support options 1 and 3:

    TELNET-4: recv WILL 1

    TELNET-4: recv WILL 3

## TLoadCode

Description: Uses Trivial File Transfer Protocol (TFTP) to load software from a UNIX host into the MAX unit's flash memory. The TFTP host can be accessed from the Ethernet interface or across the WAN. The MAX needs to be reset to load the the uploaded code, since the MAX must load the code from Flash memory into DRAM.

Although the MAX might experience a small performance degradation during the file transfer, it will be fully functional during the file download process.

When you use the TLoadCode command, the current configuration of the MAX is saved to flash memory . Therefore, manual reconfiguration, which is required when loading software through the serial connection, should not be necessary.

When you execute the command, a sequence of dots appears on the screen, indicating the progress of the transfer. Each dot represents the transfer of approximately 512 bytes.

Note: If the TFTP transfer is interrupted or the checksum of the uploaded file is incorrect, the new code does not load when the MAX is rebooted. The MAX reloads its previous version of code. Also, if the new code is uploaded at boot time, an FRestore is performed to load the configuration that is stored in flash memory. The MAX reboots again to properly initialize the configuration.

Usage: `tloadcode` `name_or_ip_address_of_tftp_server filename`

Example:

    MAX> tloadcode

    usage: loadcode host file

    > tloadcode 1.1.1.1 mhpt1.bin

    saving config to flash

    .................................

    .

    loading code from 1.1.1.1

    file mhpt1.bin...

    ...............................................................
    ..........

    .......................................................

    .............................

## TRestore

Description: Restores a saved configuration from a TFTP host to Flash memory on the MAX. You need to manually reboot the MAX to load the restored configuration from Flash memory into dynamic RAM.

Usage: `trestore` `name_or_ip_address_of_tftp_server filename`

Example:

    MAX> trestore 1.1.1.1 config.txt

    restoring configuration from 1.1.1.1:69

    file config.txt...

## TSave

Description: Saves the MAX configuration that is stored in flash memory to a TFTP server. You need to perform the FSave command if you want to save your currently running configuration. FSave saves the currently running configuration to flash memory.

Usage: `tsave` `name_or_ip_address_of_tftp_server filename`

Example:

    MAX> tsave 1.1.1.1 config.txt

    saving configuration to 1.1.1.1:69

    file config.txt...

## Update

Description: Modifies optional functionality of the MAX. To enable some options, you must obtain a set of hash codes (supplied by an Ascend representative) that will enable the functionality in your MAX. After each string is entered, the word complete appears, indicating that the MAX accepted the hash code.

If you enter `update` without a text string modifier, the MAX displays a list of current configuration information.

Usage: `update [``text_string``]`

Example:

    MAX> update

    Host interfaces: 4

    Net interfaces: 4

    Port 1 channels: 255

    Port 2 channels: 255

    Port 3 channels: 255

    Port 4 channels: 255

    Field features 1: 182

    Field features 2: 33

    Field features 3: 54

    Protocols: 1

    MAX> update 5 1023 12321312312312321

The following two messages indicate that the text strings were entered incorrectly:

    update command: invalid arg 3!

    update command: disallowed

The following message indicates that the MAX accepted the update string:

    update command: command complete.

## WANDisplay

Description: Displays all packets received from or sent to any of the WAN interfaces. Because WANDisplay ouput shows the raw data the MAX is receiving from and sending to the remote device, the information can be very helpful in PPP negotiation problems.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen.

You might prefer to use the WANDisplay command during a period of low throughput. Alternatively, depending on the types of information you need to gather, you might use WANDSess, WANOpen, or WANNext to focus the display.

Usage: `wandisplay` `number_of_octets_to display_from_each_packet`

Enter `wandisplay 0` to disable the logging of this information.

Example: Following are several examples of WANDisplay output. Note that the bytes are displayed in hexadecimal format.

    MAX> wandisplay 24

    Display the first 24 bytes of WAN messages

    > RECV-272:: 1 octets @ 5E138F74

    [0000]: 0D

    RECV-272:: 13 octets @ 5E13958C

    [0000]: 0A 41 63 63 65 70 74 3A 20 69 6D 61 67

    XMIT-276:: 1011 octets @ 2E12D8A4

    [0000]: 7E 21 45 00 03 EE 54 2B 40 00 37 06 BA 09 CF 2B

    [0010]: 00 86 D0 93 91 90 1A 0A

    MAX> wandisplay 0

    WAN message display terminated

See Also: WANDSess, WANOpen, WANNext

## WANDSess

Description: Similar to WANDisplay, but WANDSess displays only incoming and outgoing packets for a specific user. WANDSess is particularly helpful for troubleshooting a MAX with several simultaneous active connections. The volume of output from commands such as WANDisplay make them not as effective for troubleshooting issues for particular users. WANDSess is a filter to let you focus your troubleshooting.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the WANDSess command during a period of low throughput.

Usage: `wandsess` `user_name_or_profile_name number_of octets_to_display_from each_packet`

Enter `wandsess` `user_name_or_profile_name` `0` to disable the logging of this information.

Example:

    MAX> wandsess gzoller 24

    RECV-gzoller:300:: 1 octets @ 3E13403C

    [0000]: 7E 21 45 00 00 3E 15 00 00 00 20 7D 31 C2 D2

    RECV-gzoller:300:: 15 octets @ 3E133A24

    [0000]: D0 7D B3 7D B1 B3 D0 7D B3 90 02 04 03 00 35

    XMIT-gzoller:300:: 84 octets @ 3E12D28C

    [0000]: 7E 21 45 00 00 4E C4 63 00 00 1C 7D 31 17 5F D0

    [0010]: 93 90 02 D0 93 91 B3 00

    Notice that the only difference in output between WANDSess and WANDisplay is that with
    WANDSess, the name of the user is displayed in a message. The data is identical in content,
    but WANDSess displays no data from any other sessions.

    MAX> wandsess gzoller 0

    MAX>

## WANNext

Description: Similar to WANDisplay, but WANNext displays only incoming and outgoing packets for the next successfully authenticated user. As with WANDSess, the output is the same as for WANDisplay but is filtered to include only data from a single user.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the WANNext command during a period of low throughput.

Usage: `wannext` `number_of_octets_to_display_from_each_packet`

Enter `WANNext 0` to disable the logging of this information.

## WANOpening

Description: Similar to WANDisplay, but WANOpening displays only the opening incoming and outgoing packets for all users during the establishment of their PPP sessions. This command is particularly helpful if you are troubleshooting connection problems in which users seem to connect to the MAX, but are disconnected within a few seconds. Again, the output from WANOpening is very similar to WANDisplay, but displays packets for sessions only until the connection has been completely negotiated.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the WANOpening command during a period of low throughput.

Usage: `wanopening` `number_of_octets_to_display_from_each_packet`

Enter `WANOpening 0` to disable the logging of this information.

## WANToggle

Description: Displays messages from the WAN drivers on the MAX, including the state of calls that have been processed by the MAX unit's calling routines but not yet sent to the Ethernet drivers.

If you enter the command while traffic through your MAX is heavy, the resulting amount of output can make it tedious to find the information you are looking for. The screen might even display the message `----- data lost -----`, which just means that not all the output can be displayed on the screen. You might prefer to use the WANToggle command during a period of low throughput.

The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `wantoggle` at the command prompt.

Example: Following is typical output produced by a modem call into the MAX. After the incoming call is determined to be an analog call, a modem is directed to answer it.

    WAN-389: wanOpenAnswer

    WAN-389: modem redirected back to wan

    WAN-389: Startup frame received

    WAN-389: Detected unknown message

    WAN-389: Detected ASYNC PPP message

    WAN-389: wanRegisterData, I/F 58

The next two messages appear when the call is cleared. The second message does not indicate a problem. It appears because the modem clears the call a split second before the software releases its resources. The software does a check on the modem, which has already been released.

    WAN-389: wanCloseSession, I/F 58

    WAN-??: no modem assoc w WanInfo

## WDDialout

Description: Displays the specific packet that caused the MAX to dial out. The command is particularly helpful if the MAX is dialing out when it should not. You can use `WDDialout` information to design a filter to keep the MAX from dialing out because of a particular packet.

The command is a toggle that alternately enables and disables the diagnostic display.

Usage: Enter `wddialout` at the command prompt.

Example: The following message includes a date/time stamp, the phone number being dialed, and the packet that caused the MAX to dial out:

    Date: 01/01/1990.     Time: 00:51:56

    Cause an attempt to place call to 18185551234

    WD_DIALOUT_DISP: chunk D7BA6 type OLD-STYLE-PADDED.

    : 60 octets @ F3050

    [0000]: 09 00 07 ff ff ff 00 05 02 e8 14 0d 00 24 aa aa

    [0010]: 03 00 00 00 80 f3 00 01 80 9b 06 04 00 01 00 05

    [0020]: 02 e8 14 0d 00 ff 00 f7 00 00 00 00 00 00 00 ff

    [0030]: 8e 01 00 00 00 00 00 00 00 00 00 00

    MAX> wddialout

    WANDATA dialout display is OFF

## PPP decoding primer

Many of the diagnostic commands display raw data. This section is designed to assist you in decoding PPP, MP, MP+ and BACP negotiations. The negotiations can be logged with the PPPDump, WANDisplay, WANDSess, WANNext, or WANOpen diagnostic commands. For more detailed information than this appendix provides, see specific RFCs. A partial list of pertinent RFCs appears at the end of this appendix.

### Breaking down the raw data

An important concept to keep in mind is that each device negotiates PPP independently, so the options might be identical for each direction of the session.

During PPP negotiation, frame formats in the various protocols are very similar. They share the following characteristics:

- `FF 03` which indicates a PPP frame

- A two-byte Protocol Identifier

- A one-byte Packet Format ID number

- A one-byte ID number

- A two-byte length

- Options for the protocol

#### Identifier | #### Description
--- | ---
C0 21 | Link Control Protocol (LCP)
C0 23 | Password Authentication Protocol (PAP)
C2 23 | Challenge Handshake Authentication Protocol (CHAP)
80 21 | Internet Protocol (IP)
80 29 | Appletalk
80 2B | Novell's Internetwork Packet Exchange (IPX)
80 31 | Bridging PDU
80 FD | Compression Control Protocol (CCP)

Following are the most common protocols you will see in Ascend diagnostic traces:

Following are the packet formats:

#### Packet Format ID | #### Description
--- | ---
`01` | Configure Request
`02` | Configure Acknowledgment
`03` | Configure Non-Acknowledgment
`04` | Configure Reject
`05` | Terminate Request
`06` | Terminate Acknowledgment
`07` | Code Reject
`08` | Protocol Reject
`09` | Echo Request
`0A` | Echo Reply
`0B` | Discard Request

Note: If a packet received from the WAN fails the Cyclic Redundancy Check (CRC), the display is similar to the following, where `RBAD` denotes Received BAD:

    RBAD-27:: 8712 octets @ 26CFE8

    [0000]: fe dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd

    [0010]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd

    [0020]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd

    [0030]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd

### Annotated Traces

Following are sample traces you can use as guides to help you decode other traces.

#### Example of a PPP connection attempt

LCP Configure Request-MP+, MRU of 1524, MRRU of 1524 and End Point Discriminator using the device's MAC address:

    XMIT-3:: 29 octets @ 2C2E94

    [0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4

    [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c

Following is a second LCP Configure Request from the same device. Everything in the packet is identical to the previous packet, except the ID number has incremented from 01 to 02:

    XMIT-3:: 29 octets @ 2C2E94

    [0000]: ff 03 c0 21 01 02 00 19 00 04 00 00 01 04 05 f4

    [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c

LCP Configure Request-CHAP authentication, Magic number

    RECV-3:: 19 octets @ 2BEB8C

    [0000]: ff 03 c0 21 01 60 00 0f 03 05 c2 23 05 05 06 4e

    [0010]: 36 c9 05

LCP Configure Acknowledgment-The device in the following trace will be authenticated with CHAP. The Magic number is also acknowledged:

    XMIT-3:: 19 octets @ 2C2E94

    [0000]: ff 03 c0 21 02 60 00 0f 03 05 c2 23 05 05 06 4e

    [0010]: 36 c9 05

LCP Configure Reject-MP+, MRU of 1524, MRRU of 1524 and End Point Discriminator. This rejection shows two things. First, the remote side does not support MP+ or MP, since MP+ and the MRRU were rejected. This will have to be a PPP connection. Second, since the MRU of 1524 was rejected, the default of 1500 is assumed. There must be an MRU, so a rejection of a given value only calls for use of the default value.

After the trace, the device will need to transmit another LCP Configure Request, removing all the rejected options:

    RECV-3:: 29 octets @ 2BF1A4

    [0000]: ff 03 c0 21 04 02 00 19 00 04 00 00 01 04 05 f4

    [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c

LCP Configure Request-Note that all values that were previously rejected are no longer in the packet:

    XMIT-3:: 8 octets @ 2C2E94

    [0000]: ff 03 c0 21 01 04 00 04

LCP Configure Acknowledgment:

    RECV-3:: 8 octets @ 2BF7BC

    [0000]: ff 03 c0 21 02 04 00 04

At this point, since both sides have transmitted LCP Configure Acknowledgments, LCP is up and the negotiation moves to the authentication phase. The device receives a CHAP challenge from the remote end:

    RECV-3:: 21 octets @ 2BFDD4

    [0000]: ff 03 c2 23 01 01 00 11 04 4e 36 c9 5e 63 6c 63

    [0010]: 72 34 30 30 30

The device transmits its encrypted user name and password:

    XMIT-3:: 36 octets @ 2C2E94

    [0000]: ff 03 c2 23 02 01 00 20 10 49 b8 e8 54 76 3c 4a

    [0010]: 6f 30 16 4e c0 6b 38 ed b9 4c 26 48 5f 53 65 61

    [0020]: 74 74 6c 65

The remote device sends a CHAP Acknowledgment:

    RECV-3:: 8 octets @ 2C03EC

    [0000]: ff 03 c2 23 03 01 00 04

At this point, the negotiation moves from authentication to negotiation of Network Control Protocols (NCPs). Ascend supports Bridging Control Protocol (BCP), IPCP, IPXCP, and ATCP.

IPCP Configure Request-Van Jacobsen Header Compression, IP address of 1.1.1.1:

    RECV-3:: 20 octets @ 2C0A04

    [0000]: ff 03 80 21 01 e3 00 10 02 06 00 2d 0f 00 03 06

    [0010]: 01 01 01 01

BCP Configure Request:

    RECV-3:: 8 octets @ 2C101C

    [0000]: ff 03 80 31 01 55 00 04

IPCP Configure Request-IP address of 2.2.2.2:

    XMIT-3:: 14 octets @ 2C2E94

    [0000]: ff 03 80 21 01 01 00 0a 03 06 02 02 02 02

IPCP Configure Reject-Van Jacobsen Header Compression. The remote device should send another IPCP Configure Request and remove the request to perform VJ Header Compression:

    XMIT-3:: 14 octets @ 2C2E94

    [0000]: ff 03 80 21 04 e3 00 0a 02 06 00 2d 0f 00

BCP - Protocol Reject. The local device is not configured to support bridging:

    XMIT-3:: 8 octets @ 2C2E94

    [0000]: ff 03 80 31 08 55 00 04

IPCP Configure Acknowledgment:

    RECV-3:: 14 octets @ 2C1634

    [0000]: ff 03 80 21 02 01 00 0a 03 06 01 01 01 01

IPCP Configure Request-Note that VJ Header Compression is not requested this time:

    RECV-3:: 14 octets @ 2C1C4C

    [0000]: ff 03 80 21 01 e4 00 0a 03 06 02 02 02 02

IPCP Configure Acknowledgment:

    XMIT-3:: 14 octets @ 2C2E94

    [0000]: ff 03 80 21 02 e4 00 0a 03 06 01 01 01 01

At this point, a PPP connection has been successfully negotiated. The caller was successfully authenticated by means of CHAP, and IPCP was the only successfully configured NCP. IPX, Appletalk, and bridging will not be supported during this session.

Following are two packets used in determining link quality:

LCP Echo Request packet:

    RECV-3:: 16 octets @ 2BEB8C

    [0000]: ff 03 c0 21 09 01 00 0c 4e 36 c9 05 00 00 00 00

LCP Echo Response:

    XMIT-3:: 16 octets @ 2C2E94

    [0000]: ff 03 c0 21 0a 01 00 0c 00 00 00 00 00 00 00 00

#### Example of MP+ call negotiation

LCP Configuration Request-MP+, MRU of 1524, MRRU of 1524, End Point Discriminator using the device's MAC address:

    XMIT-31:: 29 octets @ D803C

    [0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4

    [0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71

LCP Configure Request-MP+, MRU of 1524, PAP authentication is required. MRRU of 1524, End Point Discriminator using the device's MAC address:

    RECV-31:: 33 octets @ D4FBC

    [0000]: ff 03 c0 21 01 01 00 1d 00 04 00 00 01 04 05 f4

    [0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0

    [0020]: 7a

LCP Configuration Acknowledgment:

    RECV-31:: 29 octets @ D55CC

    [0000]: ff 03 c0 21 02 01 00 19 00 04 00 00 01 04 05 f4

    [0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71

LCP Configuration Acknowledgment:

    XMIT-31:: 33 octets @ D803C

    [0000]: ff 03 c0 21 02 01 00 1d 00 04 00 00 01 04 05 f4

    [0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0

    [0020]: 7a

At this point, LCP is up. Next is the authentication phase. The local device agreed to PAP authentication, so it should transmit its user name and password. Note that they are not encrypted and can be decoded very easily.

PAP Authentication Request-User name is shown in hexadecimal and must be converted to ASCII. User name is 0x6a 0x73 0x6d 0x69 0x74 0x68 (jsmith) and password is 0x72 0x65 0x64 (red):

    XMIT-31:: 20 octets @ D803C

    [0000]: ff 03 c0 23 01 01 00 10 06 6a 73 6d 69 74 68 03 72

    [0010]: 65 64

PAP Authentication Acknowledgment:

    RECV-31:: 9 octets @ D5BDC

    [0000]: ff 03 c0 23 02 01 00 05 00

Authentication is successful. Final negotiation determines protocols to be supported over the link.

Note: MP+ was negotiated, and both devices begin sending MP+ packets from this point. The data portion of the packet is identical to PPP, but there is an eight-byte MP+ header instead of the two-byte PPP header:

In the following packet, `00 3d` is the designation for a Multilink packet. The fifth byte designates whether this packet is fragmented. The sixth, seventh, and eighth bytes are the sequence number, which increments by one for each packet sent or received.

Bytes nine through eleven, 80 31 01, designate as a BCP Configure Request received from the remote device:

    RECV-31:: 20 octets @ D61EC

    [0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03

    [0010]: 01 07 03 00

BCP Configure Request sent from this device:

    XMIT-31:: 20 octets @ D803C

    [0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03

    [0010]: 01 07 03 00

BCP Configure Acknowledgment:

    XMIT-31:: 20 octets @ D864C

    [0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03

    [0010]: 01 07 03 00

BCP Configure Acknowledgment:

    RECV-31:: 20 octets @ D67FC

    [0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03

    [0010]: 01 07 03 00

BCP is up and the session begins sending bridged traffic. No routed protocols were negotiated.

The following packets are sent as part of the MP+ protocol. They are sent at one-second intervals. The packets are used by each unit to validate the existence of the link. This validation gives the devices a secure way to determine whether the link is still up, even if there is no data traffic passing between the devices.

    RECV-31:: 8 octets @ D5BDC

    [0000]: ff 03 00 3d c0 00 00 05

    XMIT-31:: 8 octets @ D803C

    [0000]: ff 03 00 3d c0 00 00 04

    RECV-31:: 8 octets @ D61EC

    [0000]: ff 03 00 3d c0 00 00 06

    XMIT-31:: 8 octets @ D803C

    [0000]: ff 03 00 3d c0 00 00 05

#### Relevant RFCs

The following RFCs provide more detail about the protocols used in Ascend diagnostic traces.

#### Identifier | #### Title
--- | ---
`RFC1378` | PPP AppleTalk Control Protocol (ATCP)
RFC1552 | PPP Internetwork Packet Exchange Control Protocol (IPXCP)
RFC1638 | PPP Bridging Control Protocol (BCP)
RFC1661 | Point-to-Point Protocol (PPP)
RFC1934 | Ascend's Multilink Protocol Plus (MP+)
RFC1962 | PPP Compression Control Protocol (CCP)
RFC1974 | PPP Stac LZS Compression Protocol
RFC1989 | PPP Link Quality Monitoring
RFC1990 | PPP Multilink Protocol (MP)
RFC1994 | PPP Challenge Handshake Authentication Protocol

Copyright © 1998, Ascend Communications, Inc. All rights reserved.