Azure / iot-edge-opc-proxy

OPC Proxy Module
34 stars 19 forks source link

Exception thrown while Test client connecting to UA Server via Proxy #74

Closed JayeshThamke closed 6 years ago

JayeshThamke commented 7 years ago

1) I attempted to connect test client and NetCoreConsoleServer app via OPC Prroxy module on Windows 10 (VS 2017). Following the procedure: a) Started NetCoreConsoleServer app b) Started Proxy c) Started test client from VS 2017. After debugging test client I found during Endpoint Discovery process it is throwing 'ServiceResultException - BadNotConnected', it is thrown from OPC UA .NET Standard (Client dll) library side.

exception thrown_getendpoints

I then have tried to connect NetCoreConsoleServer with NetCoreConsoleClient app, their connection works fine.

Is it possible because of difference between RuntimeFramework versions?

from Client.csproj <RuntimeFrameworkVersion Condition=" '$(TargetFramework)' == 'netcoreapp1.1' ">1.1.2</RuntimeFrameworkVersion>

from .NETCoreConsoleServer <RuntimeFrameworkVersion>1.0.4</RuntimeFrameworkVersion>

Console output: Test Client

.Net Core OPC UA Console Client Wants to Connect server @: opc.tcp://desktop-hilrmkb:51210/UA/SampleServer 1 - Create an Application Configuration. 2 - Discover endpoints of opc.tcp://desktop-hilrmkb:51210/UA/SampleServer. Selected endpoint uses: Basic256Sha256 3 - Create session with OPC UA server. One or more error(s) occurred: -> Error establishing a connection: BadNotConnected Press any key to exit

Console Output: Proxy

=== Azure iot-edge-reverse-proxy 1.0.3.develop ===

OPC_Proxy_Module_01 installed 18:14:58.057 [0x4cec] INFO Proxy host created! 18:14:58.065 [0x4cec] INFO Proxy module created in GW Host! 18:14:58.071 [0x4cec] NOTICE Host server started! 18:14:58.073 [0x48b4] NOTICE Resolving IoT-Hub-CW-01.azure-devices.net:8883 (family: 0)... 18:14:58.074 [0x48b4] INFO ... IoT-Hub-CW-01.azure-devices.net:8883 -> 13.79.172.43:8883 (ihsu-prod-db-003.cloudapp.net) 18:14:58.156 [0x5714] INFO Socket connected asynchronously! 18:14:58.198 [0x3304] NOTICE Connected to Bonjour 333.10 service... 18:14:58.505 [0x3304] NOTICE Connection established (IoT-Hub-CW-01.azure-devices.net:8883)! 18:14:58.598 [0x3304] INFO Subscribed to $iothub/methods/POST/#! 18:15:18.247 [0x3304] NOTICE Connection alive... 18:15:38.248 [0x3304] NOTICE Connection alive... 18:15:58.251 [0x3304] NOTICE Connection alive... 18:16:18.259 [0x3304] NOTICE Connection alive... 18:16:38.261 [0x3304] NOTICE Connection alive... 18:16:58.272 [0x3304] NOTICE Connection alive... 18:17:13.638 [0x3304] NOTICE IN: [PING#2] 18:17:13.639 [0x3304] NOTICE Resolving desktop-hilrmkb:51210 (family: 0)... 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> [80fe:0:0:0:4b9d:ec0f:b823:c6b9]:51210 (DESKTOP-HILRMKB) 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> [80fe:0:0:0:61f1:6240:31b:1ba3]:51210 () 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> [80fe:0:0:0:6210:4766:d1b2:b759]:51210 () 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> 169.254.163.27:51210 () 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> 192.168.99.1:51210 () 18:17:13.640 [0x3304] INFO ... desktop-hilrmkb:51210 -> 192.168.1.30:51210 () 18:17:13.651 [0x3304] NOTICE OUT: [PING#2] 18:17:14.678 [0x3304] NOTICE IN: [LINK#4] 18:17:14.679 [0x48b4] NOTICE Resolving desktop-hilrmkb:51210 (family: 2)... 18:17:14.680 [0x48b4] INFO ... desktop-hilrmkb:51210 -> 169.254.163.27:51210 (DESKTOP-HILRMKB) 18:17:14.680 [0x48b4] INFO ... desktop-hilrmkb:51210 -> 192.168.99.1:51210 () 18:17:14.683 [0x48b4] INFO ... desktop-hilrmkb:51210 -> 192.168.1.30:51210 () 18:17:14.685 [0x4504] INFO Socket connected asynchronously! 18:17:14.700 [0x3304] NOTICE OUT: [LINK#4] 18:17:15.221 [0x3304] NOTICE IN: [OPEN#5] 18:17:15.223 [0x3304] NOTICE Socket open! 18:17:15.233 [0x3304] NOTICE OUT: [OPEN#5] 18:17:15.900 [0x3304] INFO IN: [POLL#6] 18:17:16.080 [0x3304] INFO IN: [DATA#7] 18:17:16.109 [0x3304] INFO OUT: [POLL#7] 18:17:16.142 [0x3304] INFO OUT: [DATA#1] 18:17:16.402 [0x3304] INFO IN: [POLL#8] 18:17:16.553 [0x3304] INFO IN: [DATA#9] 18:17:16.581 [0x3304] INFO OUT: [POLL#9] 18:17:16.660 [0x3304] INFO OUT: [DATA#2] 18:17:16.924 [0x3304] INFO IN: [POLL#10] 18:17:16.965 [0x3304] INFO IN: [DATA#11] 18:17:16.981 [0x3304] INFO OUT: [POLL#11] 18:17:17.024 [0x3304] INFO OUT: [DATA#3] 18:17:17.450 [0x3304] INFO IN: [POLL#12] 18:17:17.466 [0x3304] INFO OUT: [DATA#4] 18:17:17.886 [0x3304] INFO IN: [POLL#13] 18:17:17.898 [0x3304] INFO OUT: [DATA#5] 18:17:18.260 [0x3304] INFO IN: [POLL#14] 18:17:18.292 [0x3304] INFO IN: [DATA#15] 18:17:18.313 [0x3304] INFO OUT: [DATA#6] 18:17:18.325 [0x3304] INFO OUT: [DATA#7] 18:17:18.828 [0x3304] NOTICE IN: [CLOSE#16] 18:17:18.838 [0x3304] NOTICE OUT: [CLOSE#16] 18:17:38.274 [0x3304] NOTICE Connection alive... 18:17:48.845 [0x3304] INFO Worker closing socket 0000019137DF0720... 18:17:50.856 [0x3304] NOTICE Server socket 0000019137DF0720 destroyed! 18:17:58.273 [0x3304] NOTICE Connection alive... 18:18:18.808 [0x3304] NOTICE Connection alive...

  1. While building test client application using dotnetcore command line interface

<cd ...test/Client> dotnet build

proxy_opc_client_build_warnings.txt

I got warning messages related to "MSB3277: dependent assembly version conflicts"below and I cannot run the project using

<cd ...test/Client> dotnet run

proxy_opc_client_run_error.txt

Thanks for your answers, Jayesh

marcschier commented 7 years ago

This appears to be the same as #73. Investigating.

marcschier commented 7 years ago

Rather than using HEAD, could you try tag 1.0.3? This could be a regression in the OPC stack introduced when switching to the official nuget. But that's just a hunch.

JayeshThamke commented 7 years ago

Thanks for reply @marcschier This appears to be the same as #73. Investigating. RE: Probably yes, however the difference is in #73 the proxy worked correctly on one machine and issues running with separate machines.

marcschier commented 7 years ago

Yes, and it seems that while the outcome was the same, #73 seemed to be a DNS issue.

JayeshThamke commented 7 years ago

@marcschier could you try tag 1.0.3? RE: I am using tag 1.0.3

marcschier commented 7 years ago

Good, then we can exclude the upgrade to 0.4.1 of the stack assemblies having caused a regression. Seeing that there is quite some data exchanged with the .net Core server it could also be a certificate issue. The server will close the client socket if it does not trust the client. For the netcoreconsoleserver to trust the test client app, you need to copy the generated public cert from the client "own cert" to the trustedcerts of the server. If you have not done that, please try this. Btw., the Reference Server that uses WPF has a handy dialog that allows you to trust the client regardless of the presented cert, so you could use that server application as well if you are not familiar with the PKI folder structures used by the OPC stack.

And item 2 should not cause issues, it is due to Relay assembly referencing an old assembly and the proxy needing a newer one. There must be a way to suppress or redirect this, but I have not found it with .net Core tooling. Maybe you know a way, I would love to get rid of the warning ...

JayeshThamke commented 7 years ago

Thanks for reply

  1. I am aware of rejected client certificate in server and copying it from Netcoreconsoleserver's RejectedCert to TrustedCerts folder. There is no rejected certificate from test client in Netcoreconsoleserver.
marcschier commented 7 years ago

Update: I have just tried this on master (using the OPC-UA sample from the new .net API and samples repo) against the .net Standard master branch WPF based server sample and it worked fine.

JayeshThamke commented 7 years ago

hello @marcschier

I have tried to connect test client (from azure-iot-edge-proxy module) with netcoreconsoleserver as well as with WPF Reference server app. (both time without proxy) I did not find any rejected client certificates in servers' cert>RejectedCertificates folder and client console output was

Console output: Test Client

.Net Core OPC UA Console Client
1 - Create an Application Configuration.
2 - Discover endpoints of opc.tcp://desktop-hilrmkb:51210/UA/SampleServer.
Selected endpoint uses: Basic256Sha256
3 - Create session with OPC UA server.
One or more error(s) occurred:
-> Error establishing a connection: BadNotConnected
Press any key to exit 

Now I have no clue why it is throwing exception during session creation. var session = await Session.Create(config, endpoint, true, _clientName, 60000, null, null);

marcschier commented 7 years ago

Does the simple.dll test work? Run it on the same machine where the proxy runs. Supply it only the -p option to simple.dll. If there is activity, we can isolate your issue to OPC.

marcschier commented 7 years ago

Also, to confirm, the OPC console client from the stack repo works for you fine?

JayeshThamke commented 7 years ago

Hi @marcschier RE 2: OPC Console client from stack repo: NetCoreConsoleServer works fine with NetCoreConsoleClient, UA SampleClient, UA QuickStart Reference Client, UaExpert from Unified Automation GmbH (attached images below)

netcoreconsoleserver_netcoreconsoleclient netcoreconsoleserver_quickstartreferenceclient netcoreconsoleserver_ua sampleclient

RE 1: Running "Simple" .\csharp\samples\simple\tcp with -p (performance): It transacted messages to IoTHub and logged messages on proxyd console. Simple console updated the speed of the data transaction. Quick questions> Is the bufferSize = 60000 equivalent to number of messages transmitted to IoTHub ? Because it has filled my IoTHub messages quota. Oops! Also do you have any idea if I can store these messages to blob storage using stream analytics job? I have already started stream job but did not store any .json file.

JayeshThamke commented 7 years ago

Hi @marcschier

  1. Server <-> Client via Proxy worked : The NetCoreConsoleServer and WPF based Sample Server from opc stack repo can now connect to proxy api - opc ua test client via proxy module. I have observed that record.Id is converted to lower case during checking connection of record.

IoTHubServices.cs > internal async Task IsConnectedAsync(INameRecod, CancellationToken) following line of code: record.Id.ToLowerInvariant()

Running Proxy module (build>cmake>x64>bin>Debug>proxyd.exe) extracts the host name and installs a proxy device in IotHub e.g. DESKTOP-0456 (no case change). As it is converted in lower case the proxy api opc ua test client application does not recognize installed proxy device in IoTHub. This is not case when proxy module is ran with docker container, it by default generates alpha(lower case)-numeric id. Workaround for my case is always run proxy with proxyd.exe --name "<lower-case letters>" and then I can run tests.

  1. Remote close received, Server socket destroyed messages in proxy and SocketException in OPC test cliient: When OPC client wants to connect to server through proxy it always displays above messages in proxy and throws SocketException. I still wonder why it is disconnecting or is it an expected behaviour?

socketexception_remotesideclosed

  1. a. IoTHub message count increments even though only proxy module is started and acknowledging connection without connection of server and client app. Is it expected? How can I store those messages in blob storage using stream analytics job?

b. IoTHub message counter increments for OPC UA Server - Client communication and Browse operation, How can I store send receive transactions in blob storage?

  1. Need more info request fro OPC client app: Test>Client> Program.cs> WcfChannelBase.g_CustomTransportChannel = new ProxyTransportChannelFactory what is significance of it? is there documentation for more information ?

Thanks, Jay

marcschier commented 6 years ago

Re 1, see #83 - we will track this there. Re 2, expected behavior. OPC server hangs up on SessionClose message and then we notify the client side through the exception as per Socket API behavior. Re 3. Expected due to status updates being sent while device connected. See IoT hub docs on docs.microsoft.com for how to route messages to blob storage. Re 4. It's a hook mechanism to replace the tcp transport channel factory with one that uses the proxy assembly. Unfortunately doc for this can at this point only be found in the OPC reference stack code itself as this is not a Microsoft Product, but OSS.