![[Top]](../images/home.jpg){kind=small}
![[Contents]](../images/contents.jpg){kind=small}
![[Prev]](../images/previous.jpg){kind=small}
![[Next]](../images/next.jpg){kind=small}
![[Last]](../images/index.jpg){kind=small}
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.
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.)
Esc [ Esc =
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.
|
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 18The 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]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: free local pool address [208.147.145.141]
ADDRPOOL: Deleting addrPoolThe following message appeared when the Pool #1 Count parameter for an existing pool was changed from 4 to 3:
ADDRPOOL: New Addr pool rc = 0
addrPool index 1 ip [192.168.8.8] count 4
ADDRPOOL: Deleting addrPoolIn 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: New Addr pool rc = 0
addrPool index 1 ip [192.168.8.8] count 3
ADDRPOOL: Deleting addrPoolThe second pool is then deleted:
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
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.
MAX> arptableThe ARP table displays the following information:
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
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.
dir parameter indicates the direction of the last call into each modem. It can have the following settings:
2-Call was outgoing.
3-Call was incoming.
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> avmLooking 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:
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
ffdffbfc = 11111111110111111111101111111100The 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.bridisplay n
where n is the number of octets to display per frame. Specifying a value of zero disables the logging of the messages.
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.
callback at the command prompt.
Example: Following are several examples of output displayed by the Callback command.
MAX> callbackThe following message appears as the MAX prepares to call back the remote end:
CALLBACK debug is now ON
CALLBACK: processing entry topekaThe MAX then dials the remote end:
CALLBACK: initiate call to topekaWhen the call has been made and is being negotiated:
CALLBACK: new state WAITINGIf callback failed and will be retried:
CALLBACK: new state FAILEDIf callback is never successful, the call is marked for removal from the callback list and the following message appears:
CALLBACK-FAILED: topeka marked as failedAfter 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 topekaTo terminate the display:
MAX> callback
CALLBACK debug is now OFF
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.
MAX> fatal-historyThe log is now empty:
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
MAX> fatal-historySee Also: Fatal-History
MAX>
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.
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.
coredump [enable] [disable] [now] ip address
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.
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. port 0-# n
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. 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.
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 = 1The following reset results from an out-of-memory condition, sometimes termed a memory leak:
FATAL_POOLS_NO_BUFFER = 2Other resets include:
FATAL_PROFILE_BAD = 3The preceding reset is caused by a processor exception error.
FATAL_SWITCH_TYPE_BAD = 4
FATAL_LIF_FATAL = 5
FATAL_LCD_ERROR = 6
FATAL_ISAC_TIMEOUT = 7
FATAL_SCC_SPURIOUS_INT = 8
FATAL_EXEC_INVALID_SWITCH = 9The 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_DESC = 10
FATAL_EXEC_NO_MAIL_POOL = 11The preceding reset is caused by a software loop.
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
FATAL_MEMCPY_TOO_LARGE = 30The 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.
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
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 = 100As 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.
ERROR_BUFFER_IN_USE 101Warning 104 can be logged under different conditions (for example, double freeing memory or a low-memory condition).
ERROR_BUFFER_WRONG_POOL 102
ERROR_BUFFER_WRONG_HEAP 103
ERROR_BUFFER_NOT_MEMALLOC 104
ERROR_BUFFER_BAD_MEMALLOC 105Memory 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_BOGUS_POOL 106
ERROR_BUFFER_BOGUS_HEAP 107
ERROR_BUFFER_NEG_MEMALLOC 108Warning 108 is logged when a negative length request is made to the memory allocation code.
ERROR_BUFFER_ZERO_MEMALLOC 109Warning 109 is similar to Warning 108, except that the a zero length request is made to the memory allocation code.
ERROR_BUFFER_BOUNDARY 110Warning 111occurs when a software routine has tried to allocate a block of memory greater than 64KB.
ERROR_BUFFER_TOO_BIG 111
ERROR_BUFFER_NULL 112Warning 145 occurs when a memory-copy routine was called but the source buffer was much larger than expected.
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
ERROR_MEMCPY_TOO_LARGE 150Warning 154 is caused by an error in the WAN driver.
ERROR_MEMCPY_NO_MAGIC 151
ERROR_MEMCPY_WRONG_MAGIC 152
ERROR_MEMCPY_BAD_START 153
ERROR_WAN_BUFFER_LEAK 154
ERROR_TERMSRV_STATE 160Warning 175 occurs because the kernel temporarily does not have available memory to spawn a task.
ERROR_TERMSRV_SEMA4 161
ERROR_STAC_TIMEOUT 170
ERROR_EXEC_FAILURE 175
ERROR_EXEC_RESTRICTED 176Warning 180 is caused by a missing channel on a T1/PRI line.
ERROR_EXEC_NO_MAILBOX 177
ERROR_EXEC_NO_RESOURCES 178
ERROR_CHAN_MAP_STUCK 180
ERROR_CHAN_DISPLAY_STUCK 181Warning 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_REQ 182
ERROR_NEW_CALL_NO_DISC_RESP 183Usage: Enter
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
fatal-history at the command prompt.
MAX> fatal-historySee Also: Clr-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
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.
MAX> fclearSee Also: FSave
.
FRestore
Description: Restores a configuration from Flash memory and loads it into DRAM on the
MAX.
Usage: Enter frestore at the command prompt.
FSave
Description: Stores the current configuration into Flash memory.
Usage: Enter fsave at the command prompt.
MAX> fsave
.........................................
.
MAX>
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.
|
MAX> helpSee Also: ?
? -> 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)
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.
MAX> ipxripdebug
IPX-RIP state display is ONThe 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.
Following are the two default strings for the MAX:
AT&F0&C1V0W1X4
AT%C3\N3S2=255S95=44S91=10+MS=11,1,300,33600A
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
mdbstr 2 AT%C3\N3S2=255S95=44S91=10+MS=11,1,300,14400A
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:
modemdiag at the command prompt.
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.
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.
0 - OKUsage: Enter
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)
modemdrvstate at the command prompt.
Example: A modem call comes into the MAX, and a modem call is cleared from the MAX.
MAX> modemdrvstateModem 1 on the modem card in slot 3 has been assigned to answer an incoming modem call:
MODEMDRV debug display is ON
MODEMDRV-3/1: modemOpen modemHandle B04E3898, hdlcHandle B026809C, orig 0The modem is idle, so it is available to answer the call:
MODEMDRV-3/1: _processOpen/IDLEThe 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&F0E0Buffers are allocated for data being received from the WAN:
MODEMDRV-3/1: _hdlcBufSentFnc: buffer = 2E12EAE0, status = SENT
MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13ADF0, len=8, parseState[n,v]=[0,0], status= RCVDThe MAX modem receives OK from the calling modem:
MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13BA20, len=5, parseState[n,v]=[0,0], status= RCVD
MODEMDRV-3/1: data =OKThe same process is repeated for strings 2 and 3:
MODEMDRV-3/1: _processTimeout/DIAL_STR2Now, 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: 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
MODEMDRV-3/1: _hdlcBufSentFnc: buffer = 2E12EAE0, status = SENTResult codes 77 and 67 indicate that V.42 error correction and V.42bis error compression, respectively, have been successfully negotiated.
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
MODEMDRV-3/1: _hdlcBufRcvdFnc: data=2E13B408, len=1, parseState[n,v]=[2,0], status= RCVDAt 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: 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
MODEMDRV-3/1: _processRcodeEvent/AWAITING RLSD, mType=5, RLSD=0Following 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-3/1: _processRlsdChange/AWAITING RLSD = 1
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
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.
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.pppdump n
where n is the number of octets to display per frame. Specifying a value of 0 (zero) disables the logging of data.
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 7ETo 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.
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
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 7ESee Also: WANDisplay, WANNext, WANOpen
FF 03 C0 21 01 01 00 23 00 24 00 00 02 7E
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.pppfsm at the command prompt.
Example: The following display shows the complete establishment of a PPP session.
MAX>pppfsmPPPFSM 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 troubleshooting PPP
issues, you might want to use PPPIF in conjunction with PPPDump.
Usage: Enter pppif at the command prompt.
MAX> pppifThe following message indicates a modem call:
PPPIF debug is ON
PPPIF: open: routeid 285, incoming YES
PPPIF-110: ASYNC modeLink Compression Protocol (LCP) is negotiated:
VJ Header compression is enabled.PAP authentication is configured on the MAX and required for access:
PPPIF-110: vj comp on
PPPIF-110: _initAuthenticationLCP has been successfully negotiated and established. Authentication is next:
PPPIF-110: auth mode 1
PPPIF-110: PAP auth, incoming
PPPIF-110: bypassing async layer
PPPIF-110: Link Is up.PAP Authentication was successful. Compression Control Protocol (CCP) is negotiated next, along with IP Network Control Protocol (IPNCP):
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'
PPPIF-110: opening CCPThe user is given the address 1.1.1.1 from pool 0:
PPPIF-110: pppMpSendNeg Pkt
PPPIF-110: pppMpNegTimeout layer 6
PPPIF-110: using address from pool 0IPNCP and CCP have been successfully negotiated. The PPP session has been completely established.
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
PPPInfo
Description: Displays information about established PPP sessions. Has little practical use
other than as a tool for developmental engineering.
Usage: ppinfo index [all]
Syntax element |
Description |
|---|---|
index
|
Selects a particular PPP information table.
|
all
|
Displays information about embedded structures.
|
MAX>pppinfo 1Ncp[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]In the following message,
PPTPCM-[1.1.1.1]: Event = Local-Start-Request
PPTPCM-[1.1.1.1]: Starting local session
status = 0 indicates that this was a successful connection:
PPTPCM-[1.1.1.1]: Started local session; status = 0Following are messages from an unsuccessful connection:
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
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 acknowledgment from the NT server:
PPTPDATA-[1.1.1.1]: Received GRE ACKAlso, the MAX received data from the NT server that needs to be forwarded out the WAN port:
PPTPDATA-[1.1.1.1]: _dataFromLanThe 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 peerThe 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.
PPTPEC-[1.1.1.1]: pptpECSend calledUnsuccessful attempt:
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
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
MAX> pptpsend 1.1.1.1
PPTPCM: Sending Echo Request to host [1.1.1.1]
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.
(For troubleshooting RADIUS-related issues, the RADIF command displays more detailed information.)
radacct at the command prompt.
MAX> radacctA user hangs up and a stop record is generated:
RADACCT debug display is ON
RADACCT-147:stopRadAcctThe 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.
radif at the command prompt.
Example: Following are messages you might see for a successful RADIUS authentication:
RADIF: authenticating <8:my_name> with PAPThe RADIUS Daemon IP address and authentication port appear:
RADIF: _radiusRequest: id 41, user name <9:my_name>
RADIF: _radiusRequest: challenge len = <0>
RADIF: _radiusRequest: socket 5 len 89 ipaddr 01010101 port 65534->1645The response is sent back from RADIUS. In this case, the user
RADIF: _radCallback
RADIF: _radCallback, buf = B05BBFA0
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 = 2After 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: Authentication Ack
RADIF: attribute 6, len 6, 00 00 00 02A RADIUS Accounting Start packet is sent to the RADIUS Accounting Server (using port 1646):
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
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.
MAX> radstatsIn the following message,
RADIUS authen stats:
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=602In 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 1The next message indicates that the MAX sent 1557 Accounting packets and received 1555 responses (
RADIUS accounting stats:
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=0In 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 1The 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.
Local Rad Acct Stats:
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> resetSee 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
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.
telnetdebug at the command prompt.
Example: The following session shows the MAX terminal server establishing a successful Telnet connection with another UNIX host.
MAX> telnetdebugThe far-end UNIX host has been contacted:
TELNET debug is now ON
TELNET-4: TCP connectFor 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 24The UNIX host will support option 1:
TELNET-4: recv WILL 1
TELNET-4: repl DO 1The MAX receives a request to support option 3:
TELNET-4: recv WILL 3The MAX will support option 3:
TELNET-4: repl DO 3The UNIX host will support option 3:
TELNET-4: recv DO 3The UNIX host will not support option 24:
TELNET-4: recv DONT 24The MAX will not support option 24:
TELNET-4: repl WONT 24The 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.
Usage: tloadcode name_or_ip_address_of_tftp_server filename
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
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
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.update [text_string]
MAX>updateHost 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 12321312312312321The following two messages indicate that the text strings were entered incorrectly:
update command: invalid arg 3!The following message indicates that the MAX accepted the update string:
update command: disallowed
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.wandisplay number_of_octets_to display_from_each_packet
Enter
wandisplay 0 to disable the logging of this information.
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 0See Also: WANDSess, WANOpen, WANNext
WAN message display terminated
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.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.
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.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.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.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: wanOpenAnswerThe 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: 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
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.
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.
FF 03 which indicates a PPP frame
Following are the packet formats:
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
XMIT-3:: 29 octets @ 2C2E94Following 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:
[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
XMIT-3:: 29 octets @ 2C2E94LCP Configure Request-CHAP authentication, Magic number
[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
RECV-3:: 19 octets @ 2BEB8CLCP Configure Acknowledgment-The device in the following trace will be authenticated with CHAP. The Magic number is also acknowledged:
[0000]: ff 03 c0 21 01 60 00 0f 03 05 c2 23 05 05 06 4e
[0010]: 36 c9 05
XMIT-3:: 19 octets @ 2C2E94LCP 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.
[0000]: ff 03 c0 21 02 60 00 0f 03 05 c2 23 05 05 06 4e
[0010]: 36 c9 05
After the trace, the device will need to transmit another LCP Configure Request, removing all the rejected options:
RECV-3:: 29 octets @ 2BF1A4LCP Configure Request-Note that all values that were previously rejected are no longer in the packet:
[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
XMIT-3:: 8 octets @ 2C2E94LCP Configure Acknowledgment:
[0000]: ff 03 c0 21 01 04 00 04
RECV-3:: 8 octets @ 2BF7BCAt 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:
[0000]: ff 03 c0 21 02 04 00 04
RECV-3:: 21 octets @ 2BFDD4The device transmits its encrypted user name and password:
[0000]: ff 03 c2 23 01 01 00 11 04 4e 36 c9 5e 63 6c 63
[0010]: 72 34 30 30 30
XMIT-3:: 36 octets @ 2C2E94The remote device sends a CHAP Acknowledgment:
[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
RECV-3:: 8 octets @ 2C03ECAt this point, the negotiation moves from authentication to negotiation of Network Control Protocols (NCPs). Ascend supports Bridging Control Protocol (BCP), IPCP, IPXCP, and ATCP.
[0000]: ff 03 c2 23 03 01 00 04
IPCP Configure Request-Van Jacobsen Header Compression, IP address of 1.1.1.1:
RECV-3:: 20 octets @ 2C0A04BCP Configure Request:
[0000]: ff 03 80 21 01 e3 00 10 02 06 00 2d 0f 00 03 06
[0010]: 01 01 01 01
RECV-3:: 8 octets @ 2C101CIPCP Configure Request-IP address of 2.2.2.2:
[0000]: ff 03 80 31 01 55 00 04
XMIT-3:: 14 octets @ 2C2E94IPCP Configure Reject-Van Jacobsen Header Compression. The remote device should send another IPCP Configure Request and remove the request to perform VJ Header Compression:
[0000]: ff 03 80 21 01 01 00 0a 03 06 02 02 02 02
XMIT-3:: 14 octets @ 2C2E94BCP - Protocol Reject. The local device is not configured to support bridging:
[0000]: ff 03 80 21 04 e3 00 0a 02 06 00 2d 0f 00
XMIT-3:: 8 octets @ 2C2E94IPCP Configure Acknowledgment:
[0000]: ff 03 80 31 08 55 00 04
RECV-3:: 14 octets @ 2C1634IPCP Configure Request-Note that VJ Header Compression is not requested this time:
[0000]: ff 03 80 21 02 01 00 0a 03 06 01 01 01 01
RECV-3:: 14 octets @ 2C1C4CIPCP Configure Acknowledgment:
[0000]: ff 03 80 21 01 e4 00 0a 03 06 02 02 02 02
XMIT-3:: 14 octets @ 2C2E94At 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.
[0000]: ff 03 80 21 02 e4 00 0a 03 06 01 01 01 01
Following are two packets used in determining link quality:
LCP Echo Request packet:
RECV-3:: 16 octets @ 2BEB8CLCP Echo Response:
[0000]: ff 03 c0 21 09 01 00 0c 4e 36 c9 05 00 00 00 00
XMIT-3:: 16 octets @ 2C2E94
[0000]: ff 03 c0 21 0a 01 00 0c 00 00 00 00 00 00 00 00
XMIT-31:: 29 octets @ D803CLCP Configure Request-MP+, MRU of 1524, PAP authentication is required. MRRU of 1524, End Point Discriminator using the device's MAC address:
[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
RECV-31:: 33 octets @ D4FBCLCP Configuration Acknowledgment:
[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
RECV-31:: 29 octets @ D55CCLCP Configuration Acknowledgment:
[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
XMIT-31:: 33 octets @ D803CAt 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.
[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
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 @ D803CPAP Authentication Acknowledgment:
[0000]: ff 03 c0 23 01 01 00 10 06 6a 73 6d 69 74 68 03 72
[0010]: 65 64
RECV-31:: 9 octets @ D5BDCAuthentication is successful. Final negotiation determines protocols to be supported over the link.
[0000]: ff 03 c0 23 02 01 00 05 00
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.
RECV-31:: 20 octets @ D61ECBCP Configure Request sent from this device:
[0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03
[0010]: 01 07 03 00
XMIT-31:: 20 octets @ D803CBCP Configure Acknowledgment:
[0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03
[0010]: 01 07 03 00
XMIT-31:: 20 octets @ D864CBCP Configure Acknowledgment:
[0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03
[0010]: 01 07 03 00
RECV-31:: 20 octets @ D67FCBCP is up and the session begins sending bridged traffic. No routed protocols were negotiated.
[0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03
[0010]: 01 07 03 00
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
Copyright © 1998, Ascend Communications, Inc. All rights reserved.