Windows 10: WNP Transport Layer received command for the Data Connection

Recently i started to view event logs with following content:

WNP Transport Layer received command for the Data Connection with Verb: PNG, Trid: 159, Namespace: CON containing 81 bytes of payload: 0x4D532D43563A204C37693232655A5154556171656D6B6A354D762F4B412E300D0A0D0A3C70696E672D726573706F6E7365 3E3C776169743E34373C2F776169743E3C2F70696E672D726573706F6E73653E.

Converting payload data from HEX to string says following:

MS-CV: L7i22eZQTUaqemkj5Mv/KA.0<ping-response><wait>47</wait></ping-response>

It looks like establishing some connection and potentially data exfiltration.

Event log level = Verbose
Verbose 100 Useful primarily to help developers debug low-level code failures. Not generally useful to anyone who does not have access to source code or symbols. Most event tracing that does not need to be enabled all the time should be set at the Verbose level. Keywords = Developer Debug: Debugging Cloud Connectivity - Is device connected?,Developer Debug: Debugging Cloud Connectivity,WNP Transport Layer

I scanned the system and antivirus (kaspersky) did not find the viruses in the system, does anyone know what could be done in this case?

:)

 

Newest (current) Map Data for Nokia Maps 3.03 and 3.04

From my point of view however, I dont think that the extra transportation data layer would be a problem unless that renders the map data unreadable to 3.03....As a layer only, the Maps 3.03 should still be able to read the underlying road layers. Anyway,
going online would still give you the latest map data if you'd like that.

 

YOU ARE IN KITL MODE

It appears to me that you have somehow entered a debugging mode (sort of like a boot loader I think). If the soft reset does not work then if it were mine, as a last alternative, I would try a hard reset.

I think this is how it is done on that device (but it should be explained in your user manual):

Press the UP button of the navigation key and the reset button at the same time.



As an aside, KITL means Kernel Independent Transport Layer.

Just for some understanding, here is a partial explanation:

The Kernel Independent Transport Layer (KITL) is designed to provide an easy way for you to support any debugging service. KITL separates the protocol of the communication service from the layer that communicates directly with the communication
hardware. This reduces your involvement in creating a hardware transport layer that understands how to pass data to the device's communication hardware.

The hardware transport layer is then layered under KITL to keep KITL from needing to understand different types of communication hardware. For example, you could create both desktop and Windows CE device-side transport mechanisms.

On the desktop, the transport is a separate DLL that exports certain API functions that KITL relies on and is also registered in the system so KITL knows that it is a functional transport.

On the device, the transport is built into the OAL and therefore the kernel.

On the CE device, KITL relies on the transport to support a set of API level calls that are needed to support the debug services.

The kernel independent transport layer (KITL) contains the following two modes of operation:

Active: The device boots the OAL, calls KitlInit(TRUE) to initialize KITL, and initializes all default KITL clients like the kernel debugger. The KITL service then calls OEMKitlInit and registers all default clients that are used by the system.

Passive: KITL is not automatically started when the device boots. In this mode, KITL initializes itself and the default KITL clients. Call KitlInit(FALSE) to initialize in passive mode. OEMKitlInit is then called when a client registers with the KITL servers.

You must determine which mode the device should enter on boot. Platform Builder provides a flag called KTS_PASSIVE_MODE that determines which mode is used. You can set KTS_PASSIVE_MODE in Platform Builder by enabling active or passive KITL.

You must pass the KTS_PASSIVE_MODE flag, if used, to the OAL before KitlInit is called. On the CEPC hardware platform, passing the data through the boot loader in the BootArgs section does this. To view an example, see %_WINCEROOT%\Platform\Cepc\Kernel\Hal\Halkitl.c.

Active KITL is best suited for the development processes so that the debugger can maintain a constant connection. Passive KITL is better suited to a real-world scenario where the debugger is not constantly needed. The benefit of the passive mode is that it
allows you to create a device that does not have to be tethered to the desktop tools. The device can even be mobile and if it enters a state where the desktop tools are needed, it initiates a KITL connection between the device and desktop.



Jack Cook

http://www.experiencemobility.net

http://www.mobilitysite.com