Applies To:
  • CitectSCADA
  • CitectHMI
  • CitectFacilities

Summary:
Why do I see newlixconfig, tpcsrvr, tsrmagt, newlixengine, infowave etc in Wireshark when viewing captures of CitectSCADA traffic? 

Solution:

These names are due to "transport name resolution" which in this case is converting TCP/UDP port names into a service name (such as port 80 = http)

The information comes from the "services" file located in the Wireshark program directory .\Program Files\Wireshark\services

Note: This is simlar to how windows will resolve service names (in NETSTAT for example) using the services file in C:\Windows\System32\drivers\etc\

The attached services file includes the CitectSCADA services instead of the ones in the standard services file from IANA. You can copy and replace the existing one.

Here is the CitectSCADA specific content for reference:

################### CitectSCADA / VijeoCitect ############################
citect-ctapi 2073/tcp #CTAPI
citect-cicode-dbg 2074/tcp #Remote Cicode Debugger
citect-report 2075/tcp #Report Server
citect-alarm 2076/tcp #Alarm Server
citect-trend 2077/tcp #Trend Server
citect-io 2078/tcp #I/O Server (<=V6.10, >=V7 I/O server peer port)
citect-idc 2079/tcp #IDC Server (Internet Display Client)
citect-alarm-ds 2080/tcp #Datasource for alarm properties (>=V7.0)
citect-timesrv 2081/tcp #Citect time server
citect-psi-io 2082/tcp #PSI I/O Server (Publisher Subscriber Interface, >=V7.0)
citect-odbc 20222/tcp #Citect ODBC interface
############################################################################

It should be noted that the transport name resolution in Wireshark (as at version 1.0.4) can be a little confusing. This is because Wireshark does not differentiate the server side service port from the originating ephemeral port numbers. This combines with the way Windows uses low port numbers for the ephemeral ports rather than the more conventional much higher number ranges (well above the well known services) which normally make it clear whats going on.

As an example:

A web browser connecting to a web server might look like this

192.168.0.20    74.125.6.78    TCP    mloadd > http [SYN]

with the first response looking like this

74.125.6.78    192.168.0.20    TCP    http > mloadd [SYN,ACK]

In this case the ephemeral port used is 1427 (which the services file translates as mloadd). The source port is not normaly specified by the client process and so is randomly chosen by the operating system. It has no meaning except that it is unique amongst any other connections to the same server. As such it has no permanent meaning or name. Names only makes sense for the server side service as this is consistent.

so it would make more sense if things look like this

192.168.0.20    74.125.6.78    TCP    1427 > http [SYN]
74.125.6.78    192.168.0.20    TCP    http > 1427 [SYN,ACK]

However wireshark has no algorithims to reliably work this out, so it doesn't

Because of this, some may find it clearer to just switch transport name resolution off.

192.168.0.20    74.125.6.78    TCP    1427 > 80 [SYN]
74.125.6.78    192.168.0.20    TCP    80 > 1427 [SYN,ACK]

Preferences -> Name Resolution -> Enable transport name resolution 


Keywords: