Siemens HMI VNC server freeze

asked 2021-03-16 21:10:25 +0000

k96hkh gravatar image

Hi

I've been chasing a strange problem for months and I suspect now that it is a network issue. We have a Siemens TP1500 HMI (think it is based on a Windows CE platform) and included in the siemens project that it put on the HMI there is a VNC server that several people connect to (a few times every day). Every now and then the VNC server freeze and no one can connect to it. The HMI panel it self works fine so it is only the VNC server that bugs out. It can happen with a few days interval and sometime more than a week pass between freezes.

A few days ago I recorded a pcap file when it happened, unfortunately I don't have enough points to attach the whole file but I have tried to include relevant data at the end. Wireguard marks the "Reset: Set" as warning and I'm wondering if our problems could have something to with this.

Does anyone know if it is plausible and if not any idea of what could be causing the the problem and where I should be looking?

Cheers!

6891    102.195380926   172.16.90.100   172.16.90.113   VNC 64  Client framebuffer update request
6892    102.396127677   172.16.90.113   172.16.90.100   TCP 60  5900 → 53911 [ACK] Seq=1022652 Ack=11953 Win=65280 Len=0
6893    103.205012312   172.16.90.113   172.16.90.100   TCP 60  5900 → 53911 [PSH, ACK] Seq=1022652 Ack=11953 Win=65280 Len=4 [TCP segment of a reassembled PDU]
6894    103.205104722   172.16.90.113   172.16.90.100   TCP 71  Server framebuffer update [TCP segment of a reassembled PDU]
6895    103.205355881   172.16.90.100   172.16.90.113   TCP 60  53911 → 5900 [ACK] Seq=11953 Ack=1022673 Win=130304 Len=0
6896    103.216612487   172.16.90.100   172.16.90.113   TCP 60  53911 → 5900 [RST, ACK] Seq=11953 Ack=1022673 Win=0 Len=0

Frame 6896: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface enp3s0, id 0
Ethernet II, Src: Dell_c0:ab:07 (00:4e:01:c0:ab:07), Dst: Siemens_a6:47:2d (ac:64:17:a6:47:2d)
Internet Protocol Version 4, Src: 172.16.90.100, Dst: 172.16.90.113
Transmission Control Protocol, Src Port: 53911, Dst Port: 5900, Seq: 11953, Ack: 1022673, Len: 0
    Source Port: 53911
    Destination Port: 5900
    [Stream index: 0]
    [TCP Segment Len: 0]
    Sequence Number: 11953    (relative sequence number)
    Sequence Number (raw): 3423961345
    [Next Sequence Number: 11953    (relative sequence number)]
    Acknowledgment Number: 1022673    (relative ack number)
    Acknowledgment number (raw): 2827668974
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x014 (RST, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 0... = Push: Not set
        .... .... .1.. = Reset: Set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······A·R ...
(more)
edit retag flag offensive close merge delete

Comments

Hard to give any advice without more data/information.

The excerpt shows that the connection was terminated by the client with a reset (not by the server). It is not obvious why this happens. For further analysis it would help to have the complete pcap. You can use other file hosters (like Dropbox for example) to share the capture.

Uli gravatar imageUli ( 2021-03-22 21:00:28 +0000 )edit

Hi Uli and everyone else of course,

Now I've posted that perticular pcap-file here: pcap-file

I have one pcap-file for every hour since almost two weeks back but as always it is like looking for something in a haystack. Very difficult but not impossible if I knew what to look for.

Cheers!

k96hkh gravatar imagek96hkh ( 2021-03-23 20:26:10 +0000 )edit