When enabled, this feature will capture packets sent and received on the IR1800 series CANBUS. Once captured, the data will be exported as a packet capture (PCAP) file to allow for further examination. The feature is configured in exec mode and is only temporary, meaning it is not permanent across a reboot/reload.

A file name is required for the capture. The default location for the capture file is at bootflash:/canbus_dumplogs. If the capture is started without specifying the file initially, or after the router is reloaded, you will get the following message when you check the status:

canbus packetdump file pcapfile path bootflash:/canbus_dumplogs/pcapfile didn't start

After stopping the capture, if you want to start the capture again without specifying the file name, the old specified name will be overwritten.

Use the following command to specify the name of the capture file:

Router#monitor canbus packetdump file <filename>

Note	You do not need to specify the path, the only supported path is the default path bootflash:/canbus_dumplogs

Use the following command to start the capture using the specified <filename> from the command above:

Router#monitor canbus packetdump start

Use the following command to stop the capture:

Router#monitor canbus packetdump stop

Use the following command to check the status of the monitoring:

Router#show canbus packetdump

Router#monitor canbus packetdump ?
file CAN Bus interface packet capture destination file
start CAN Bus interface packet capture start
stop CAN Bus interface packet capture stop

Router#monitor canbus packetdump file canbusfile
Router#show canbus packetdump
canbus packetdump file canbusfile path bootflash:/canbus_dumplogs/canbusfile didn't start

Router#monitor canbus packetdump start
Router#show canbus packetdump
canbus packetdump file canbusfile path bootflash:/canbus_dumplogs/canbusfile started

Router#monitor canbus packetdump stop
Router#show canbus packetdump
canbus packetdump file canbusfile path bootflash:/canbus_dumplogs/canbusfile didn't start

Automotive Dead-Reckoning (DR) refers to the capability of a GNSS receiver to continue to navigate on an automotive platform when there are an insufficient number of GNSS satellite signals available. To do this, the receiver uses information provided by external sensors concerning the state of the vehicle in order to propagate the navigation solution.

Automotive DR requires information regarding the change in directional heading of the vehicle, which is provided by a three-axis digital gyroscope. Automotive DR also requires information about speed and direction of the vehicle. Speed is provided by an odometer (wheel tick) count, which is input into the IRM-GNSS-ADR pluggable module.

The automotive DR feature also accepts data from a three-axis digital accelerometer, which provides information that can be used to determine the orientation of the gyro when it is installed at a tilt angle. This information is also used to estimate elevation. The accelerometer is integrated within the sensor included inside the pluggable module.

Prior to the 17.9.1 release, only mode obdii was available. In 17.9.1, mode j1939 is added with the existing default mode obdii.

The J1939 connector is supported on heavy duty trucks, which provides speed and reverse status data to be fed into the GPS/DR module using J1939 protocol. It is configured through the command line interface under the controller.

Router(config-controller)#dead-reckoning ?
enable enable GPS feature
mode DR mode configuration
nmea NMEA Configuration

Router(config)#controller Gps-Dr
Router(config-controller)#dead-reckoning mode j1939

Router#show platform hardware gps dead-reckoning
=============================
DR Vehicle interface mode: J1939
GPS/DR Vendor Info: TELIT
GPS/DR module FW Version: V33-1.0.5-CLDR-4.7.10-N115R115-003291-3
DR Calibration Status:
DR is not calibrated
Odometer is not calibrated
Gain is not calibrated
Offset is not calibrated

CAN Bus Status:
CAN Bus Tx Count: 1874
CAN Bus Tx error Count: 0

CAN Bus Rx Count: 571
CAN NULL packet Bus RX Count: 0
CAN Bus Rx unsupported packet Count: 448

CAN Bus TX to DR Count: 123
CAN Bus TX to DR error Count: 0

DR data:
DR Sample TimeStamp in usec: 0
DR odometer count received from module: 0
DR odometer count sent to module: 1353
DR odometer is not valid from module
DR odometer delta count from module: 0
DR reverse status: 0

DR in use for location fix: No
time duration for loss of line of sight:
travel distance for loss of line of sight:
travel heading error at exit:
travel yaw error at exit:
travel gyro gain error at exit:
position error at exit:
position error ratio at exit:
position noise error at exit:
Raw Accel Data in X: 0
Raw Accel Data in Y: 0
Raw Accel Data in Z: 0
Raw Gyro Data in X: 0
Raw Gyro Data in Y: 0
Raw Gyro Data in Z: 0

When the ntp refclock GPS is configured, and there is a GPS signal with a valid time lock, the WPAN time sync will be done using the 1PPS output of the GPS receiver. When the ntp refclock GPS is not configured, or there is no GPS signal with time lock available, WPAN will sync the time by GPIO.

The feature is configured using the following CLI:

enable gps-based time sync
ntp refclock gps

The following CLI can be used to get information about the state of the pulse-based time sync:

show wpan 0/X/0 hardware time-stats

The following output shows an example of when the GPS signal is working:

Router#show wpan 0/1/0 hardware time-stats
Current pulse source: PPS
Last sync pulse trigger time: 1653442579.000000 (2022:05:25-09:36:19-CST)
Last sync pulse receive time: 1653442578.990649 (2022:05:25-09:36:18-CST)
Total pulses triggered: 4116324
Total pulses received: 4116324
Sync pulses: 34312
Pending offset before last sync: 0.008130
Pending offset after last sync: 0.009342
Current pending offset: 0.008688
Router#

The following output shows an example of when the GPS signal is not working, and the time sync is through the GPIO:

Router#show wpan 0/1/0 hardware time-stats
Current pulse source: SW
Last sync pulse trigger time: 1653443059.000000 (2022:05:25-09:44:19-CST)
Last sync pulse receive time: 1653443058.990649 (2022:05:25-09:44:18-CST)
Total pulses triggered: 4116806
Total pulses received: 4116806
Sync pulses: 34316
Pending offset before last sync: 0.008130
Pending offset after last sync: 0.009342
Current pending offset: 0.008562
Router#

This feature adds support for logging certain information that can be useful to diagnose any issues concerning time drift between IOS XE and the WPAN module.

The feature is disabled by default. Use the following CLI to enable the feature:

interface wpan 0/x/0
time-sync-stats

Then dump the data to a file:

wpan 0/x/0 tss-dump

The following information will be logged whenever IOS XE sends a time sync update to the WPAN module:

• Current IOS XE time

• Difference between IOS and bridge right before sync

• Response time for the BRIDGE_KEY_GLOBAL_TIME command

• Difference between IOS XE and bridge right after sync

• IOS XE local time

When the system clock changes, the following information will be logged:

• Current IOS time (after the clock change)

• IOS XE local time

• Whether or not the change is applied by NTP

Note	Gradual adjustments during normal NTP operation are not considered clock changes. Only larger changes applied by NTP, and changes as a result of the clock set command are logged.

Data is stored in a compact binary form in files time_stat<seq>_slot_<slot>. The data is stored in the directory bootflash:/wpan_sys_info/ where <seq> is the sequence number of the log file and <slot> is the slot number of the WPAN interface.

The latest data always gets written to the file with sequence 1. The file rotation/rollover logic is:

1. When the file with sequence 1 reaches 1MB, it gets renamed to sequence 2.

2. If there was previously a file with sequence 2, it gets renamed to 3.

3. If there was previously one with sequence 3 it gets deleted.

For example, time_stat1_slot_<slot> always has the latest data, and time_stat3_slot_<slot> always has the oldest data.

Since there can be a large amount of data, which is intended to be processed externally, there is no CLI to show the data. Instead, an external script is used that can parse the time_stat files and can be used to analyze the data according to the specific problem being debugged. Data is buffered in memory for up to 15 minutes before being written to the file. The following exec command can be used to force all data to be written to the file immediately:

wpan 0/X/0 tss-dump 

In IOS XE releases prior to 17.9.1, the BBU firmware was bundled into the IOS XE image. The only way to upgrade the BBU firmware was to upgrade the image.

This feature will add a new CLI which will upgrade the BBU firmware from an image stored in a local file. The firmware images will be signed and the signature will be verified prior to installation. The BBU firmware images will be posted to CCO together with IR1840 images.

In order to limit permissions granted to the BBU process, it will only be allowed to access a directory called "bbu_fw" on the bootflash. Therefore, the firmware files need to be in that directory. The CLI to perform the firmware upgrade is:

request platform hardware battery firmware-update install bootflash:bbu_fw/<file name>

This new feature applies to the ESR6300 Router.

PPPoE is a session/connection-oriented protocol, which extends the point-to-point radio frequency (RF) link from an external radio to an IOS router. Router communication with the radio is represented by virtual access interface (connectivity to a radio neighbor).

VMI operates in the Bypass mode where each Virtual Access Interface (VAI) represents a radio neighbor. The VMI layer re-directs unicast routing protocol traffic to the appropriate P2P link (Virtual-Access interface) and replicates any Multicast traffic that needs to flow.

For IPV6 multicast over PPPoE to function properly, the following must be configured:

• PPPoE (Virtual-template, VMI and physical interface)

• IPV6 unicast and multicast routing

• IPv6 PIM BSR

• IPv6 MLD

Note	This feature requires the Network Advantage License.

For additional information, see the IPv6 Multicast over PPPoE chapter.

The following table describes the differences between Bundle mode and Install mode:

Cisco IOS XE running on IoT routers has typically made use of the Bundle boot mode. Bundle boot mode is also known as Consolidated boot, and uses a single compressed image. The typical naming convention is <product>-universalk9.<release>.SPA.bin.

This mode provides a consolidated boot process, using local (hard disk, flash) or remote (TFTP) .bin image. Booting via a .bin image means that the router would first have to uncompress the image before booting from it. This led to a longer period of time for the router to boot.

To upgrade the router to a new version of IOS XE, you would point the "boot system" to a new software image. This method is well known and details are available in your products configuration guide.

Starting with IOS XE release 17.9.1, a new boot mode called Install mode has been added to the IoT routers. Install mode uses packages loaded into bootflash, which are read by a packages.conf file. This method provides more control over the software installation process.

Note	SMU installation was supported in both bundle boot and install mode. From Cisco IOS XE Release 17.9.x, SMU installation will be stopped if the router is booted up in bundle mode. If the router is booted up in install mode, SMU installation will keep working as it is in previous releases.

Router(config)#boot system bootflash:<filename>

#install add file bootflash: [activate commit]

For additional information, please see Cisco IOS XE Installation Methods.

Numerous improvements have been made in the Cellular link up-time with IOS-XE release 17.9.1. In previous releases, the cellular interface was taking approximately two and a half minutes to come up and pass traffic after the router booted up. The Cellular link up-time has been improved by approximately 20% in this release.

This feature will present a warning when issuing a boot system flash command followed by a file name of an image which has a version number lower than the one of the running image. The downgrade operation will still be possible by ignoring the warning message presented to the user. Booting an image with the same or higher version of the running image is allowed without warning. The feature is only intended for images already loaded on the bootflash of the router, this means only for the boot system flash <file_name> CLI (excluding other sources/devices like ftp, mop, rpc, tftp, rom).

The following are examples of how the system compares versions:

When comparing two version numbers as follows:

• 17.7.1

• 17.7.1c

The version with the letter (17.7.1c) will be considered the most updated one.

When comparing two version numbers as follows:

• 17.7.3a

• 17.7.3f

The comparison will be made taking into consideration the alphabetical order. In the case above 17.7.3f will be considered the most updated one.

Support has been added for SNMP MIB to be able to return values from temperature sensors. The output should look similar to the show environment CLI.

The output of a show environment on an IR1101:

IR1101#show environment

Number of Critical alarms:  0
Number of Major alarms:     0
Number of Minor alarms:     0

 Slot        Sensor          Current State   Reading        Threshold(Minor,Major,Critical,Shutdown)
 ----------  --------------  --------------- ------------   ---------------------------------------
 R0          Temp: TS1       Normal          42    Celsius      (75 ,80 ,90 ,na )(Celsius)
 R0          Temp: TS2       Normal          37    Celsius      (75 ,80 ,90 ,na )(Celsius)

The output from an snmpwalk would look similar to this:

[root@sg-centos-hv ~]# snmpwalk -v 2c -c public 33.33.33.204 1.3.6.1.4.1.9.9.13.1.3.1
SNMPv2-SMI::enterprises.9.9.13.1.3.1.2.1 = STRING: "Sensor 1"
SNMPv2-SMI::enterprises.9.9.13.1.3.1.3.1 = Gauge32: 48
SNMPv2-SMI::enterprises.9.9.13.1.3.1.4.1 = INTEGER: 93
SNMPv2-SMI::enterprises.9.9.13.1.3.1.5.1 = INTEGER: 0
SNMPv2-SMI::enterprises.9.9.13.1.3.1.6.1 = INTEGER: 1
SNMPv2-SMI::enterprises.9.9.13.1.3.1.7.1 = INTEGER: 0

The ciscoEnvMonTemperatureStatusEntry oid is 1.3.6.1.4.1.9.9.13.1.3.1:

• ciscoEnvMonTemperatureStatusIndex (.1)

• ciscoEnvMonTemperatureStatusDescr (.2)

• ciscoEnvMonTemperatureStatusValue (.3)

• ciscoEnvMonTemperatureThreshold (.4)

• ciscoEnvMonTemperatureLastShutdown (.5)

• ciscoEnvMonTemperatureStatus (.6)

In IOS XE versions prior to 17.9.1, GPS was enabled by defaut, however, GPS Mode was disabled by default. This required that the user perform an additional modem power-cycle after the router came up in order to use GPS.

Starting with IOS XE 17.9.1, GPS Mode will be enabled by default, and will be set to standalone mode. This will help reduce the cellular link up time.

Note	This only applies to the cellular based GPS. This does not apply to the GPS/GNSS module in IR1800 (DR module), IR8140 (native GPS) and IR8340 (Timing module).

Use the following command to check cellular GPS status:

Router# show cellular <slot> gps
auto-reset Enable reset modem automatically after configuring GPS enable or mode

IOS XE 17.9.1 added the ability to add, edit, or delete the APN from the Cisco WebUI Interface. The following provides an overview of how to perform this function.

Note	This section only describes new functionality and is not a complete overview of the WebUI.

Adding the APN

From the WebUI, navigate to Configuration > Interface > Cellular. Double click on the cellular interface based upon your platform.

On the Cellular window, click on the Profiles tab.

From the Profiles tab, you can Add, Delete, or Edit the APN. Once the profile is modified, click on Update & Apply to Device at the bottom of the window.

Changing the SIM Slot

By default, the APN is attached to SIM slot 0. You can change the APN to SIM slot 1 by using the WebUI.

From the WebUI, navigate to Configuration > Interface > Cellular. Click on the Advanced radio button on the top of the window.

Click on the Controller tab at the top of the window.

Click on the Primary SIM Slot pull-down and select slot 1. Click on Update & Apply to Device on the bottom of the window.

HTTPS supports secure TLS version TLSv1.3 in Cisco IOS XE 17.9.1 and later.