Differences in TcpServerChannel behavior under Linux and Windows .NET 8 builds

[galigula2]

Type of issue

• [X] Bug
• [ ] Enhancement
• [ ] Compliance
• [ ] Question
• [ ] Help wanted

Current Behavior

I'm building a OPC UA Server application using .NET 8 and which I plan to run inside a docker (linux) container. Some of the developers work with Windows-based machines and some work with Linux-based machines. The difference appears when I try to connect to my application using a third party OPC UA Client with Basic256Sha256/Sign&Encrypt and my application DOES NOT yet trust the Application Certificate of the client.

The following combinations were tested

• Linux UA Expert to LinuxMyApp -> DOES NOT WORK
• Windows UA Expert to LinuxMyApp -> WORKS
• Windows UA Expert to WindowsMyApp -> WORKS
• Linux Prosys Browser to LinuxMyApp -> WORKS

In the faulty case, UA Expert tries to connect but receives Bad_SecurityChecksFailed and then the connection is not terminated until 5 minutes has passed (meaning e.g. that I cannot try to re-connect using UA Expert before the connection has closed).

The problem only appears when both Linux version of UA Expert and Linux version of my application are involved. I tracked to problem down to TcpServerChannel.ProcessOpenSecureChannelRequest() which checks the client's Application Certificate which fails due to not being trusted. The function then calls TcpListenerChannel.ForceChannelFault() which check whether the connection state is "Connecting" or not.

• In Windows it seems to be in "Connecting" since the "ForceChannelFault"-error text is not printed and the connection closes immediately.
• In Linux it seems to NOT be in "Connecting" state since the "ForceChannelFault"-error is printed and the connection is closed by the CleanupTimer after 5 minutes (TransportQuotas.ChannelLifetime).

I tried to check what might have caused the TcpServerChannel.State to become something other than "Connecting" but could not find it.

Expected Behavior

I would expect both Windows and Linux versions to behave identically.

Strange part is that it also seems to have something to do with UA Expert's Linux build since Windows version of UA Expert AND Linux version of Prosys Browser works.

Steps To Reproduce

1. Compile a simple OPC UA Server project for .NET 8 in Linux (can provide a sample if needed since the reference implementations target .NET Framework)
2. Launch the Server
3. Try to connect using Linux-version of UA Expert client with Anonymous/Basis256Sha256/Sign&Encrypt
4. Observe that the connection does not close immediately but remains open until TransportQuotas.ChannelLifetime has passed

Environment

- OS: Ubuntu
- Environment: Visual Studio Code
- Runtime: .NET 8
- Nuget Version: 1.5.374.27
- Component: TcpServerChannel
- Server: Simple OPC UA Server application
- Client: UA Expert (Linux build)

Anything else?

No response

[mregen]

Hi @galigula2, based on your test matrix I would suspect the UA Expert Linux behaves differently. Could you test the connection of UA Expert Linux --> WindowsMyApp to see if the problem persists? If yes UA Expert Linux behaves different, otherwise not. Then comparing wireshark traces may give some hint.

[EthanChangAED]

Closing for now. Please reactivate if there is further update.