SPE Debug Messages
This following list of debug messages is pretty much correct at time of writing but is very much subject to change as we see fit. The purpose of these debug messages to primarily provide us with the information that we need to track down and correct problems with the SPE firmware. As an end user you can find these debug messages useful since they can tell you when something is wrong and hopefully point you in the right direction to fix it.
Often we add messages to debug a new feature but as time progresses and the feature becomes proven and the message is no longer providing any useful information the messages may be removed. Similarly new messages may be added or expanded on to provide more useful information where it was lacking before. If you would like to see any changes to the debug messages feel free to contact us with you suggestions. There are a lot of factors that have to be considered when deciding which messages to leave in and which to take out so we may not follow your suggestions but we will give them consideration. Please tell us why you want the changes in case we are able to meet you needs in a better way.
- The SPE has detected either that it's non-volatile parameter table has not been initialized or the factory reset link has installed.
- Waiting for DSR...
- The SPE is waiting for the g18 module to assert DSR. The SPE has to wait for this before it is able to communicate with the module.
- Sending initialization...
- The SPE is sending it's initialization string to the g18 module.
- SPE Ready (baud_rate bps)
- The SPE has completed power on initialization and is ready to talk to the connected DTE at the specified speed. The down side of having a fixed interface speed is that it makes it very hard to talk to if you forget the speed you have set it to.
- Waiting for DTR...
- The SPE is in it's idle state and waiting for DTR to be asserted.
- Reading identification
- The SPE has seen DTR asserted and is reading the selected identification field from the g18 module. These are the +Cxxx fields selected by the ^HAFS command.
- Looking for Escape...
- The SPE is waiting for the user to enter the escape sequence (AT^HESC). The SPE will respond with one of "Timed out", "Mismatch" or "Got Escape".
- Timed out
- The escape timeout expired.
- A character was received that did not match the escape sequence.
- Got Escape
- The escape sequence was received correctly.
- A parameter setting command has been processed. These are commands of the form AT^Hxxx=parameter(s).
- A parameter reading command has been processed. These are commands of the form AT^Hxxx?.
- A help command has been processed. These are commands of the form AT^Hxxx=?.
- A simple (execute only) command has been processed.
- The parameter table in flash memory has been updated. Because the parameter table is stored in page based flash memory it is necessary to copy the whole table excluding the parameter being changed each time a parameter is changed. The new parameter is then inserted into it's (now blank) position in the table.
LCP (Link Control Protocol) Messages
Refer to RFC 1661. LCP forms part of the Point to Point Protocol (PPP) and is used to negotiate and manage the data link. The LCP negotiation consists of two separate and simultaneous negotiations: one for each direction of data transfer.
"Tx LCP:" messages indicate a packet send from the SPE's micro to the g18 module. "Rx LCP:" messages indicate a packet from the g18 module to the SPE's micro.
- Tx LCP: Config Req
- Rx LCP: Config Req
- An LCP configuration request has been sent or received.
- Tx LCP: Config Rej
- Rx LCP: Config Rej
- An LCP configuration reject has been sent or received. A config reject is used to indicate to the other party parameters that are not supported. It is normal for there to be up to one reject in each direction as part of the negotiation.
- Tx LCP: Config Nak
- Rx LCP: Config Nak
- An LCP configuration negative acknowledge has been sent or received. A config nak is used to indicate parameters whose values are unacceptable. This packet is used to indicate values that would be acceptable. It is normal for there to be up to one nak in each direction.
- Tx LCP: Config Ack
- Rx LCP: Config Ack
- An LCP configuration acknowledge has been sent or received. This indicates that the matching configuration request (sent in the opposite direction) was entirely acceptable.
- Tx LCP: Terminate Req
- Rx LCP: Terminate Req
- An LCP terminate request has been sent or received. This should normally be found as part of the clear down procedure but may occur at the start of negotiation if a previous LCP session has not yet been fully cleared.
- Tx LCP: Terminate Ack
- Rx LCP: Terminate Ack
- The LCP terminate acknowledge is sent as a response to the terminate request.
- Rx LCP: Code Reject
- A code reject packet is sent in response to an LCP packet of unknown type (code).
- Rx LCP: Protocol Rej
- A protocol reject packet is send in response to a PPP packet of unknown protocol.
PAP (Password Authentication Protocol) Messages
Refer to RFC 1334. LCP allows negotiation of an authentication protocol. The usual options are PAP, CHAP or none. Password Authentication Protocol (PAP) is a simple plain text type authentication protocol and is fine over secure links. Challenge Handshake Authentication Protocol (CHAP) is an encrypted protocol designed for use on unsecure links. The g18 module supports only PAP however this is somewhat unnecessary since the authentication is only between the SPE micro and the g18 module. The g18 will in fact accept any user name and password. Originally we went through the PAP authentication but once we realized that we could save time by negotiating to have no authentication we skipped this altogether. If you have up to date firmware in your SPE you won't see any of these messages.
- Tx PAP: Authenticate Req
- An authenticate request has been sent to the g18 module.
- Rx PAP: Authenticate Req
- An authenticate request has been received from the g18. This doesn't happen but if it ever did you'll get this message.
- Rx PAP: Authenticate Nak
- The g18 has rejected our authentication. Again this doesn't actually happen but then you never know what they might do in a future version of g18 firmware.
- Rx PAP: Authenticate Ack
- The g18 has accepted our authentication request.
IPCP (Internet Protocol Control Protocol) Messages
Refer to RFC 1332. IPCP works very much like LCP in that they have the same packet types which have the same relationships to each other. IPCP facilitates negotiation of the IP address and compression. Like the LCP negotiation the IPCP negotiation consists of separate negotiations for each direction.
Unlike the LCP negotiation which is simply between the SPE's micro and the g18 module the IPCP negotiation goes all the way through the GPRS network. This means that there can be some delay in the negotiation at this point.
- Tx IPCP: Config Req
- Rx IPCP: Config Req
- An IPCP configuration request has been sent or received.
- Rx IPCP: Config Rej
- An IPCP configuration reject has been received. A config reject is used to indicate to the other party parameters that are not supported. It is normal for there to be up to one reject in each direction as part of the negotiation however this won't normally be seen with an SPE.
- Rx IPCP: Config Nak
- An IPCP configuration negative acknowledge has been received. A config nak is used to indicate parameters whose values are unacceptable and to suggest values that would be acceptable. It is normal for there to be up to one nak in each direction. This is normally seen with the SPE as the network tells the SPE the IP address it should use.
- Tx IPCP: Config Ack
- Rx IPCP: Config Ack
- An IPCP configuration acknowledge has been sent or received. This indicates that the matching configuration request (sent in the opposite direction) was entirely acceptable.
- Rx IPCP: Terminate Req
- An IPCP terminate request has been received. This doesn't normally happen with the SPE since the g18 will instead send an LCP terminate request which implicitly terminates the IPCP session.
- Rx IPCP: Terminate Ack
- An IPCP terminate acknowledge has been received. We don't normally see this with the SPE since the SPE will skip directly to sending an LCP terminate request.
- Rx IPCP: Code Rej
- An IPCP code reject has been received. We don't normally see this either since we only send things to the g18 that we already know it's going to be happy with.
Other PDP Setup Messages
- PAD mode started
- This messages confirms the completion of the PDP setup and tells us the SPE is ready to transfer user data. This should correspond to the green light going on and the DCD signal being asserted.
Data Transfer Phase
ICMP (Internet Control Message Protocol) Messages
Refer to RFC 792. ICMP is used for various operation functions of the internet. A couple of the functions most familiar to users will probably be the ping function and the "Destination Unreachable" message.
The ICMP echo function is what we commonly know as a ping. The SPE supports both originating and replying to echo requests.
- Tx ICMP: Echo Req
- The SPE has just sent a ping (ICMP echo request).
- Rx ICMP: Echo Req
- The SPE has just received a ping (ICMP echo request) to which it will respond.
- Tx ICMP: Echo Reply
- The SPE has just replied to a ping.
- Rx ICMP: Echo Reply
- The SPE has just received a reply to a ping it originated.
UDP (User Datagram Protocol) Messages
Refer to RFC 768. The user datagram protocol is the mechanism that the SPE uses to transport user data over IP.
- Tx UDP
- The SPE has just sent a data packet.
- Tx UDP (Cmd resp port_number)
- The SPE has just sent a response to a command to the specified port number. The command might have been issued via the control port or via the data port using the escaped prefix. The response will be returned via the same port as the command was issued from.
- Tx UDP (Announcement)
- An announcement message has just been sent.
- Rx UDP: Data
- A data packet has just been received.
- Rx UDP: Ctrl
- A control packet has just been received.
- Rx UDP: Bad IP (source_ip_addr)
- A UDP packet has been received but the source IP address does not match any of the acceptable IP address ranges as specified by the AT^HAIP command.
- Rx UDP: Bad port (port_number)
- A UDP packet has been received that passed the acceptable IP address test but was not address to either the data or control ports.
- Rx TCP: Discarded
- A TCP packet was received.
- PAD mode stopped
- The PAD mode of operation has stopped. The PDP context is being terminated. This normally happens when DTR is dropped.
- HDLC: Invalid frame
- An invalid HDLC frame has been received. This would indicate a communication error between the g18 module and the SPE micro.
- HDLC: Bad FCS
- A HDLC frame has been received with an invalid frame check sequence. This represents a communication error between the g18 module and the SPE micro.
- Rx inter-character timeout
- A timeout has occurred between successive characters within a PPP frame. The timeout is used to help regain frame synchronization in the event of a communication error between the g18 module and the SPE micro.
- The SPE has issued a hangup command to the g18 module. This is not always necessary but helps to ensure that the g18 module is back in the command state ready to accept further commands.