I am trying to connect WinTECH OPC Client to MaxDNA V6.0.7 server in local PC and LAN network also. The connection was successfully established but it was showed
Tag Quality bad" and "Value Unspecified Error
How to solve this issue?
Related
using a Windows server, I created a pptp vpn connection, but when connecting, for example, to YouTube, it displays an error that the waiting time was exceeded, to create a vpnk connection, I used this guide https://www.snel.com/support/how-to-set-up-a-vpn-with-windows-server/
Getting an error stating An established connection was aborted by the software in your host machine. When connecting to SMTP server.
Mail is getting triggered properly on development environment but it does not get triggered on Production.
That error means that your SMTP server is aborting your TCP/IP network connection.
There's nothing you can do about that in your program.
This is a problem with your network configuration.
I recently made a very basic TCP server application in C++ and Python using the very basic socket API. The client server connection happens flawlessly within the localhost as well as inside my LAN (within the same Wi-fi). But If I connect my client to an internet service (WAN) and try to connect to my server application behind my wifi (using the Wi-fi's public IP (provided by its ISP) and the port on which my server will be listening to) , I'm unable to get a connection. The server sits idle waiting for a connection ! I have enabled port forwarding on my Wi-fi, but still the results are all vain...
**EDIT: **
I managed to connect them over WAN, but now the ISP have to be the same... This is what I did: I made the server run on my Android device, bound it to the IP of my device that uses mobile data... The client sits behind a WiFi and connects to the Server using the previously mentioned IP and everything works fine ! But however if the client becomes an android app in another device with mobile data provided by different ISP everything fails !!! * So long as client runs behind a WiFi, but server connected to WAN (same ISP) the system works. *
Apparently there is no way to get requested data back to the OPC DA client from the server when using OPC DA over a VPN connection. This is because OPC DA is designed using Microsoft's Component Object Model (COM) and uses Distributed COM (DCOM) for remote connectivity. When a connection is established to a remote server, and data requests are made by the client, the server will send callbacks to the IP address that made the connection. When connected to a VPN, it will broker a local IP address on that network. In conclusion a machine running a OPC DA client using a VPN tunnel to connect to a remote OPC DA server is able to discover the server but not to run it.
My question is: there is a way to use a different tunneling mechanism compatible with the OPC DA protocol?
Alternatively there is a way to route all callbacks to the client from the server to the IP of the PC with the OPC DA server instead of the brokered IP?
I think you'd be better off putting an OPC-UA tunneler on the machine with the DA server and then connecting over the VPN using OPC-UA.
Are you sure that the VPN is the problem? If you are able to "discover" the server, but can't launch it that means your dcom settings are incorrect.
Create a new local user account on the client and the server (same name and password). On the server change the dcom settings for the opc server:
Run dcomcnfg
Find you opc server, select properties.
On the security tab add the new account everywhere (you may try to skip this, sometimes not needed)
On the identity tab, select "this user", fill the new account
On the client, log in with the new account, connect the VPN.
The above dcom settings is the easiest to maintain/set up/debug for remote connections. Any other combination (interactive user/launching user/domain account etc.) is a pain and in 99% time won't work. If you need to use domain users (not recommended at all!), you need to connect the VPN before login in the client (good luck with this)
This is a few years later, but in case anyone unearths this:
Use a tap-interface VPN, rather than a tunnel. In other words, use a layer-2 VPN which behaves like an Ethernet interface on the remote LAN. You (the VPN client) are given an IP address on the remote network that is connected directly to your machine. It behaves exactly as though there is a very long Ethernet cable from your machine to the site. For all practical purposes, you become local to the OPC server.
or...
As suggested by #KevinHeron above, use an OPC Gateway. Prosys OPC make one and have a diagram of your situation on their product page: https://www.prosysopc.com/products/opc-ua-gateway/
I am having some trouble allowing my 2wire router (provided by AT&T to forward certain ports.
I have a raspberry pi running subsonic (a music server) and I would like to access it from the outside internet. I have configured the pi with a static LAN IP address and have opened the specified ports (4040 and 80) on both TCP and UDP. I have also confirmed the service is active and is listening on the specified ports via netstat.
When I attempt to connect, however, from my WAN IP I am confronted with a connection refused dialog. Checking the firewall logs on my router, I see this message
IN=br1 MAC=--:--:--:--:--:-- SRC=(my computer IP) DST=(My WAN IP) LEN=40 TTL=240 PROTO=TCP DPT=5060 Unknown inbound session stopped
It appears that my firewall is still blocking the external connection. What strikes me as odd is, although I am unable to connect I can still see that the port is open from an outside port scanner. Using the service provided from http://www.yougetsignal.com/tools/open-ports/ I have confirmed that my IP has port 4040 to be open.
Once again, I have confirmed that the service is indeed listening on the raspberry pi, setup a static LAN address and created the protocol for both TCP and UDP....
Any help on this matter would be greatly appreciated.
Thanks in advance!
Ok so for whatever reason it was working all along. Apparently it was just getting confused by me trying to connect to my own router. I confirmed this by connecting to the server via 4G on my phone.
Dumb mistake by me.