Log In
Register
Forum
Topic RSS
18:37, EEST
May 15, 2020
Offline
Hello,
I set up the host name in device and after that I ran the server on device. I was able to get the actual host name in log as below
—ApplicationIdentity.getActualHostName()—>bibhu
But while trying to connect client from laptop to server which is running in device. Still I am getting the “A low level communication error occurred.” exception in client log and I am unable to connect to server. The exception is as below:
exception: Failed to create secure channel to server: : opc.tcp://bibhu:52520/OPCUA/N4OpcUaServer [http://opcfoundation.org/UA/SecurityPolicy#None,None]
com.prosysopc.ua.client.ConnectException: Failed to create secure channel to server: : opc.tcp://bibhu:52520/OPCUA/N4OpcUaServer [http://opcfoundation.org/UA/SecurityPolicy#None,None] ServiceResult=Bad_CommunicationError (0x80050000) “A low level communication error occurred.”
at com.prosysopc.ua.client.UaClient.E(SourceFile:5255)
at com.prosysopc.ua.client.UaClient.connect(SourceFile:901)
//Calling UaClient from application
at java.lang.Thread.run(Thread.java:748)
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_CommunicationError (code=0x80050000, description=”2147811328, Read timed out”)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.open(SourceFile:1281)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.open(SourceFile:749)
at com.prosysopc.ua.stack.application.Client.createSecureChannel(SourceFile:370)
at com.prosysopc.ua.client.UaClient.E(SourceFile:5251)
… 20 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.net.SocketInputStream.read(SocketInputStream.java:224)
at com.prosysopc.ua.stack.utils.bytebuffer.InputStreamReadable.atN(SourceFile:185)
at com.prosysopc.ua.stack.utils.bytebuffer.InputStreamReadable.getInt(SourceFile:110)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.open(SourceFile:1178)
… 23 more
This time I also tried to run both server and client in device. But still I got the same exception.
Prior to Prosys sdk 4.3 version, we were using prosys sdk version 2.2.J633-721. So I was tried with the old Prosys sdk as well. While running the application
with old Prosys sdk, I was able to connect to server (while server is running in device and client in laptop). So I compared netstat log of old sdk and new sdk while running the application.
Running the application with old Prosys sdk(2.2.J633-721), below is the netstat log.(52520 is the port where server is running)
================================================================================================
$ netstat -an | grep 52520
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
$ netstat -an | grep 52520
tcp6 0 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.60575 ESTABLISHED
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
$ netstat -an | grep 52520
tcp6 0 96 ::ffff:192.168.1.52520 ::ffff:192.168.1.60576 ESTABLISHED
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
Running the application with new Prosys sdk 4.3, below is the netstat log. (52520 is the port where server is running)
==========================================================================================
$ netstat -an | grep 52520
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55179 ESTABLISHED
tcp6 0 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55178 TIME_WAIT
tcp6 0 0 fe80::f65e:abff:.52520 *.* LISTEN
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
tcp6 0 0 ::1.52520 *.* LISTEN
tcp6 0 0 fe80::1%lo0.52520 *.* LISTEN
$ netstat -an | grep 52520
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55195 ESTABLISHED
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55179 CLOSE_WAIT
tcp6 0 0 fe80::f65e:abff:.52520 *.* LISTEN
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
tcp6 0 0 ::1.52520 *.* LISTEN
tcp6 0 0 fe80::1%lo0.52520 *.* LISTEN
$ netstat -an | grep 52520
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55212 ESTABLISHED
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55195 CLOSE_WAIT
tcp6 73 0 ::ffff:192.168.1.52520 ::ffff:192.168.1.55179 CLOSE_WAIT
tcp6 0 0 fe80::f65e:abff:.52520 *.* LISTEN
tcp6 0 0 ::ffff:192.168.1.52520 *.* LISTEN
tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN
tcp6 0 0 ::1.52520 *.* LISTEN
tcp6 0 0 fe80::1%lo0.52520 *.* LISTEN
$
It looks like in new sdk server decides to bind to each port independently rather than listening on the address. It would make login difficult.
Also while running the application with old Prosys sdk, I didn’t do any hostname change in device. But I was able to connect to server while running
the server in device. Could you please provide your thought.
Thanks,
Bibhudatta Sahu
11:58, EEST
April 3, 2012
Offline
I’m assuming you use the same java version for both. Basically I’m trying to rule out possible causes for the problem in hope to find it.
This is maybe an odd request, but could you try replacing the 2.2.J633-721 with 2.3.2 (remember to update both stack and SDK jars) and see if it still works.
The 2.2.J633-721 was sort of special build, since it was back then to contain fixes for issues. Release-wise it is something inbetween 2.2.6 and 2.3.0. In 2.3.2 based on old release notes we did some fixing for CLOSE_WAIT on the socket (https://downloads.prosysopc.com/opcua/release_notes2.3.2-781.html and also for 2.3.0). I would not completely rule out some problem that would only affect your device setup as a side-effect. IF it fails with 2.3.2, then that would be an indication of that (thus making the search for the problem easier as it would mean 2.x->4.x upgrade is not the cause).
Additionally, I have never personally seen netstat to use format like “tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN”, meaning specifically the “::ffff:” prefix. Per https://en.wikipedia.org/wiki/IPv6_address#Special_addresses they are IPv4 mapped or translated addresses (though for ::ffff:192.168.1.52520 it misses the last IPv4 address “number” as there should be 4, but now the port number is sort of the 4th, which should not be; but it might be something specific to the mapping/translation, I know too little yet about this). It is possible that this is relevant.
Anyway, in general a ServerSocket listens on an IP + port number combo. Unless the IP is a wildcard address, such as https://en.wikipedia.org/wiki/0.0.0.0 it will listen only on that combination. And with the wildcard it still is only to that port number, i.e. it is impossible to “just listen on the address”, or alternatively I did misunderstand that comment.
A Socket connection will always have 2 IPs and 2 ports, server side has the IP+port it listens to, the client side will also open a socket for IP+port combo (usually from https://en.wikipedia.org/wiki/Ephemeral_port range, thus e.g. in the log 60575, 60576, 55179, 55178 etc., the OS handles these when the connection is opened).
To my knowledge we have always being binding to each IP separately (and all of them by default), that is to say, we do not bind (as the default) on a wildcard address (which we probably should, but not the point here). The only change in 2.x vs 4.x in this area should be that IPv6 is by default on in 4.x, thus a lot more addresses to bind on.
However other than those CLOSE_WAIT fixes in 2.3.0 and 2.3.2 I do not recall at least direct changes (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_Java_SDK_3_Release_Notes.html, https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html). 4.0.0 added support for ReverseHello, so at least some changes were needed for that, but it shouldn’t at least have affected this.
At this point I really would need a local test setup where this can be reproduced. Otherwise I think it will be more “please try this” ideas. Can you reproduce this situation in any linux distro etc. that we could setup in a virtual environment to debug ourselves? That would be a lot faster. Basically something like Ubuntu would be best, though given that that is the one we’ll mostly use for testing linux-wise and we have not run into this problem ourselves it probably wont be the correct choise here (but I might try to get similar IPv4 mapping/translation to see if that is the problem). Note that you should use SampleConsoleServer and SampleConsoleClient for reproducing then so I can match that.
Alternatively I guess the other thing to try is that you’ll turn the logging on TRACE level for the entire SDK, output that to a file and zip and send via email to us. Note that preferably the log files should be roll on 50 or 100MB to multiple files. And there will be lots of it, since loading the standard model for the address space generates a ton of logs. But the error would at least seem to be quite low-level, so it might not be visible in the logs.
10:50, EEST
May 15, 2020
Offline
Bjarne Boström said
I’m assuming you use the same java version for both. Basically I’m trying to rule out possible causes for the problem in hope to find it.This is maybe an odd request, but could you try replacing the 2.2.J633-721 with 2.3.2 (remember to update both stack and SDK jars) and see if it still works.
The 2.2.J633-721 was sort of special build, since it was back then to contain fixes for issues. Release-wise it is something inbetween 2.2.6 and 2.3.0. In 2.3.2 based on old release notes we did some fixing for CLOSE_WAIT on the socket (https://downloads.prosysopc.com/opcua/release_notes2.3.2-781.html and also for 2.3.0). I would not completely rule out some problem that would only affect your device setup as a side-effect. IF it fails with 2.3.2, then that would be an indication of that (thus making the search for the problem easier as it would mean 2.x->4.x upgrade is not the cause).
Additionally, I have never personally seen netstat to use format like “tcp6 0 0 ::ffff:127.0.0.1.52520 *.* LISTEN”, meaning specifically the “::ffff:” prefix. Per https://en.wikipedia.org/wiki/IPv6_address#Special_addresses they are IPv4 mapped or translated addresses (though for ::ffff:192.168.1.52520 it misses the last IPv4 address “number” as there should be 4, but now the port number is sort of the 4th, which should not be; but it might be something specific to the mapping/translation, I know too little yet about this). It is possible that this is relevant.
Anyway, in general a ServerSocket listens on an IP + port number combo. Unless the IP is a wildcard address, such as https://en.wikipedia.org/wiki/0.0.0.0 it will listen only on that combination. And with the wildcard it still is only to that port number, i.e. it is impossible to “just listen on the address”, or alternatively I did misunderstand that comment.
A Socket connection will always have 2 IPs and 2 ports, server side has the IP+port it listens to, the client side will also open a socket for IP+port combo (usually from https://en.wikipedia.org/wiki/Ephemeral_port range, thus e.g. in the log 60575, 60576, 55179, 55178 etc., the OS handles these when the connection is opened).
To my knowledge we have always being binding to each IP separately (and all of them by default), that is to say, we do not bind (as the default) on a wildcard address (which we probably should, but not the point here). The only change in 2.x vs 4.x in this area should be that IPv6 is by default on in 4.x, thus a lot more addresses to bind on.
However other than those CLOSE_WAIT fixes in 2.3.0 and 2.3.2 I do not recall at least direct changes (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_Java_SDK_3_Release_Notes.html, https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html). 4.0.0 added support for ReverseHello, so at least some changes were needed for that, but it shouldn’t at least have affected this.
At this point I really would need a local test setup where this can be reproduced. Otherwise I think it will be more “please try this” ideas. Can you reproduce this situation in any linux distro etc. that we could setup in a virtual environment to debug ourselves? That would be a lot faster. Basically something like Ubuntu would be best, though given that that is the one we’ll mostly use for testing linux-wise and we have not run into this problem ourselves it probably wont be the correct choise here (but I might try to get similar IPv4 mapping/translation to see if that is the problem). Note that you should use SampleConsoleServer and SampleConsoleClient for reproducing then so I can match that.
Alternatively I guess the other thing to try is that you’ll turn the logging on TRACE level for the entire SDK, output that to a file and zip and send via email to us. Note that preferably the log files should be roll on 50 or 100MB to multiple files. And there will be lots of it, since loading the standard model for the address space generates a ton of logs. But the error would at least seem to be quite low-level, so it might not be visible in the logs.
Hello,
We also tried with SampleConsoleServer running in device and tried to connect from SampleConsoleClient to server. Still we are facing the same issue. We would like to arrange a remote session to discuss the issue. Probably through “Microsoft Teams” meeting. Could you please suggest feasible time to have discussion.
Thanks,
Bibhudatta Sahu
13:01, EEST
April 3, 2012
Offline
You can discuss with sales@prosysopc.com, see https://www.prosysopc.com/services/ for our paid services. Note that the SDK support only includes forum + email (for people that have non-eval license). And it is basically only fixing issues shown to be incorrect vs. the specification. That is all, and anything else we do is goodwill from our part (sometimes we have extra time, sometimes of personal interest, sometimes something might be in general good for the SDK even if it would technically be outside of support).
Also note that regardless of anything, I do not do in practice do live communications (would generally speaking be waste of time for everybody, since it could take hours to come up with proper answers, thus async communication channels are the way to go). Also it is vacation season here in Finland (usually from start of June to the end of August), thus it might take a while for a suitable person to be available. But in general sales will answer rest if you send mail to them.
13:47, EEST
May 15, 2020
Offline
Hello,
I would like to know whether this Prosys SDK – 4.3 tested on QNX operating system environment. Is client able to connect to server running in QNX operating system.
Thanks,
Bibhudatta Sahu
9:49, EEST
Moderators
February 1, 2019
Offline
bibhudatta.sahu@honeywell.com said
Hello,
I would like to know whether this Prosys SDK – 4.3 tested on QNX operating system environment. Is client able to connect to server running in QNX operating system.Thanks,
Bibhudatta Sahu
Hello,
Prosys OPC UA SDK for Java – 4.3 has NOT been tested on QNX. We think that it works on QNX, as it works on normal OSes, i.e. win/linux/osx, which would in general show that it works on a normal Java SE JVM. But to be sure, we are now setting up a test environment and confirm the compatibility.
By the way, as a commercial user, you can always send requests to our SDK support, which is quicker in response.
12:58, EET
March 16, 2017
Offline
bibhudatta.sahu@honeywell.com said
com.prosysopc.ua.stack.common.ServiceResultException: Bad_CertificateUseNotAllowed (code=0x80180000, description=”Bad_CertificateUseNotAllowed (code=0x80180000, description=”The certificate may not be used for the requested operation.”)”)
Hi, I came across this error message when I used a certificate which was missing the extensions ‘Key Usage’ and ‘Extended Key Usage’. Certificates which were missing this extensions were working in older versions of several OpcUa servers, but when using such a certificate with newer versions of OpcUa Servers it might happen that the OpcUa Server rejects this certificate with the error message ‘Bad_CertificateUseNotAllowed ‘
Please make sure that your certificate contains the follwoing extensions and have at least this values set…
ExtendedKeyUsages [
clientAuth
serverAuth
]
[3]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
]
Most Users Ever Online: 1919
Currently Online:
59 Guest(s)
Currently Browsing this Page:
2 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 734
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16, edgardo3518Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
