This isn't a pcap file, it's just the text output of your tshark command. Did you use -w
to write to a capture file like I suggested?
I'm leaving for the weekend, so you've got some time to figure this out.
This isn't a pcap file, it's just the text output of your tshark command. Did you use -w
to write to a capture file like I suggested?
I'm leaving for the weekend, so you've got some time to figure this out.
ugh, another one coming in like 5 minutes
File is too big, what's your email address.
I sent you a DM with a dropbox link to upload to.
done, thx
Hope you had a good weekend:).
Do you have logs from Ignition during the time period you ran this test / got this capture?
What happens to the Ignition Gateway? Nothing? It crashes and restarts?
This can't be it, I can see the encrypted OPC UA traffic I assume is from the loopback connection before, during, and after the traffic from your client.
I don't know what's happening from just the Wireshark. The first time your client connects it does its reading and browsing and then eventually it looks like the server closes the connection abruptly.
It then reconnects, does some browsing and reading, and then this time the client just closes the connection suddenly.
All of this time the server remains online and the encrypted loopback connection remains operational.
I'll get logs. Ignition still runs. Let me setup another capture with logs to go with it.
Just added more logs to that dropbox. It has the server logs and wireshark.bin is the wireshark logs.Thx
Nothing interesting in the logs. Not sure I was looking for anything specific, but after filtering out all the Modbus logging there was nothing that stood out.
It's interesting that this capture shows the same pattern - first connection the close comes from server, second connection the close comes from the client.
I wonder if it's neither and there's something about this environment
The script running the app will immediately attempt again if there is a failure, I'm just killing it to grab logs and send to you.
Try turning these loggers to DEBUG level and running it again:
I can't find anywhere in the server where we'd close the channel without there being an error that caused it, so still thinking it's environment right now.
will do, I'll send logs when done
When I want to put tags into a database regularly, I use a transaction group.
Transaction groups can target specific rows to overwrite.
Recursion implies using loops of loops.
Iteratively might speed up the process even if you did one loop for finding the bound first.
You could do it in groups rather than all at once.
Ok, I solved this one...
Your client opens the secure channel with a lifetime of 8640000ms.
Then, ~145 seconds later, it renews that secure channel for some reason, and changes the lifetime to 120000ms.
Then, 2 minutes later, having not received another secure channel renewal, the secure channel expires and the Ignition OPC UA server closes the connection.
Attached is a capture with just the relevant packets.
securechannel.pcapng (1.7 KB)
I do see some 120000 hard coded in the lib. I'll hack the appropriate ones.
Thanks,