Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Unable to connect to server. Get Bad_CertificateUseNotAllowed exception.
July 6, 2020
18:37, EEST
Avatar
bibhudatta.sahu@honeywell.com
Member
Members
Forum Posts: 19
Member Since:
May 15, 2020
sp_UserOfflineSmall 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

July 7, 2020
11:58, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 775
Member Since:
April 3, 2012
sp_UserOfflineSmall 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.

July 28, 2020
10:50, EEST
Avatar
bibhudatta.sahu@honeywell.com
Member
Members
Forum Posts: 19
Member Since:
May 15, 2020
sp_UserOfflineSmall 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

July 28, 2020
13:01, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 775
Member Since:
April 3, 2012
sp_UserOfflineSmall 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.

July 31, 2020
13:47, EEST
Avatar
bibhudatta.sahu@honeywell.com
Member
Members
Forum Posts: 19
Member Since:
May 15, 2020
sp_UserOfflineSmall 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

August 7, 2020
9:49, EEST
Avatar
Jimmy Ni
Moderator
Members

Moderators
Forum Posts: 25
Member Since:
February 1, 2019
sp_UserOfflineSmall 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.

December 14, 2021
12:58, EET
Avatar
rocket science
Member
Members
Forum Posts: 65
Member Since:
March 16, 2017
sp_UserOfflineSmall 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…

[2]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
clientAuth
serverAuth
]

[3]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
]

No permission to create posts
Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
14 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 120

pramanj: 86

ibrahim: 74

rocket science: 65

kapsl: 57

gjevremovic: 49

Xavier: 42

fred: 41

TimK: 41

Fransua33: 39

Member Stats:

Guest Posters: 0

Members: 2891

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1261

Posts: 5369

Newest Members:

allisontz18, Elmer1493vok, AspectMontageAtrox, miloparris0, josettegrenier, berniceiy1, Sylviaser, gilbertstonge93, waldomarriott43, madgeroque72

Moderators: Jouni Aro: 930, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 775, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 39, Niklas Nurminen: 0, Matti Siponen: 207, Lusetti: 0

Administrators: admin: 1