the mobus (watlow F4T) allows for connection, my pc use a static IP and watlow F4T is also using a static IP(192.168.0.222), it works well on another laptop or pc, but it could not work on one windows 7 laptop.
The modbus use a 502 port and I checked firewall, and using telnet 192.168.0.222 502 there is no error message, if I use a different port the telnet returns a connection failure, so I assume port 502 is open.
I use ModbusTcpTest130 to test, same setting, when I try to read something from watlow F4T, it always mentions "unable to do modbus read, please check the port setting", as different laptop would work, so I assume there is something special on this laptop, anybody has clue?
update: I tried another pc, it works when I only use modbusTCP130, however, when I tried modbus poll (I forgot to close modbusTCP130 connection), it fails, then after close both modbus poll and modbustcp130, whatever I use modbusTCP130 or modbuspoll, both fail, so looks port not released?
How you are closing the port?. Just closing down the terminal?
When you are not sure that your port is closed, I would suggest rebout devices on both ends. Also make sure there are only one instance of terminal is running.
It wort to try change communication port on device to different one, to make sure that, on PC that port is not being use with diff applications.
Related
I installed postgreSQL server on a raspberry pi 4 with raspbian buster. When I try to connect from local network i have no problems about idle time. When i try to connect from my static public ip I can send command but if I didn't send anything for more than 3 minutes, it appears this message "Connection to the server has been lost".
I tried to install ufw and disable it, I used DMZ, I tried to change keepalive_idle, but i have always the same problem. Please help me.
sometimes the error is
"ERROR: SSL SYSCALL error: Operation timed out"
(Note: always if I am connected from public IP)
If you don't have the same issue from within your local network I assume the connection is being terminated by a network device sitting between the client and the server (a router most likely).
There are routers with small TCP timeout settings (such as 300 seconds) which is close to what you're experiencing.
Try to check (and increase if needed) the TCP timeout settings on your router (and any other devices you might have in between).
Edit:
I tried to find some info on that device (seems to be Sercomm VD625) and it does not seem you can easily change TCP timeout settings (maybe via telnet/ssh if it supports it).
However, a simpler solution might be to avoid keeping an open connection to PostgreSQL if you will have large idle intervals; just connect when you need to and close the connection afterwards.
I have an application with a server written in F# and serve web files using suave. I remote login using powershell into another machine in the network to run the application (The application is also in one of the network drives). I do that because that machine have access to third party APIs needed for the server. Now when I do [IPAddress_Of_Remote_Machine]/[html_file] or [name_of_pc]/[html_file] then chrome is waiting forever and doesn't ever return the webpage. This wasn't happening before and I ran into this problem recently. I opened a different port and used it instead of the default one 80. This made things work but the problem keeps showing up after a couple of days. I don't think it's a firewall issue but I'm clueless to why this is happening.
When running netstat -an, this is what I get (I hid the IP address):
As you can see all of the connections are either in CLOSE_WAIT or ESTABLISHED but not LISTENING. All of these TCP connections is probably because I have PhantomJS and two other APIs running in the application as well. However the loop back address is also open on the same port 5959:
I'm not sure what is difference between these two but when using PortQryUI to query the remote server it returns a success!
I have already made an inbound rule for port 5959 on the server so it should be allowed. The web page is stuck at Waiting for [name_of_pc]. Also, sometimes this problem disappears and everything works fine.
What is the potential problem behind this? Why would this happen all of a sudden?
UPDATE:
I re-ran the application today and it's working correctly. It could be that something is dynamically set within the firewall? Not really sure what is going on. The machine I'm running the server on has a bunch of applications running on it as well so maybe there is an external process that is affecting it?
I made a hello world app with Suave and deployed it on the network drive to test if it's going to work. I opened inbound rule for port 6001
Then I ran the app:
However, it's still not working and this time it says the site cannot be reached when I do: http://[name_of_pc]:6001.
Moving this to an answer so that it can be closed:
Could you post the bindings section of your suave cfg? I'm guessing you know where that is since you are using a non-standard port but if you need don't, search for HttpBinding. I suspect you will find it pointing to 127.0.0.1 which is not good enough for remote access. You could try changing it to 0.0.0.0 or to the server's actual IP address. I would try 0.0.0.0 first for the flexibility it provides
I'm developing a C/S program using Delphi 7, TServerSocket and TClientSocket controls. One problem is now I can only use my PC as server, and my PC is using virtual dialer, so ISP keeps changing my IP, about once in one or two days.
Because I'm using a router, the ServerSocket is opened directly in my local IP (192.168.1.x), just mapped to my public IP, so I suppose the ServerSocket itself shouldn't crash when my public IP changes. What I suppose should be: when my IP changes, all connecting sockets become unavailable, and when my application doesn't know it and still using the socket, ServerSocket should receive some event like OnClientError.
But I found a weird problem - when my IP changed, the server application automatically shut down. I don't know exactly what happened because the shut-down time is afternoon, I was in my office, but I noticed another result: even I used heartbeat in my application layer protocol, the server didn't catch the keep-alive failure - because I recorded everything in a log file on my server, and didn't find it. So my server must be shut down instantly when my IP changed, which even didn't reach the keep-alive logic.
This seems very weird, how can a socket error(due to IP change) directly lead to the whole application shut down? Please if someone have any explanations, and how to deal with this problem, thanks
Once the socket is opened, its bound IP address will never change. This can not be 'fixed' on the server side. I would recommend to work on the servers stability, also the clients should detect that the server no longer exists at the given IP address, and re-connect. (This is independent of why the server became unavailable - a restarting server is normal.)
Already, I've checked at least 20 resources and am out of ideas:
I have a clean, remote Ubuntu EC2 instance, fresh from the AMI, having stopped only to install LAMP, phpmyadmin, and xdebug on it. Yes, I have configured my remote EC2 instance's php.ini file as follows:
Meanwhile, back on my laptop I have Netbeans & Eclipse installed. While I can get either to seamlessly upload and Run my php web app on my EC2 site (via SSH/SFTP) as soon as I hit "Debug" from either, index.php gets uploaded, a browser window opens, and then NOTHING HAPPENS. The page doesn't load, the Debug perspective doesn't open, breakpoints don't get triggered, nothing. Netbeans just hangs out saying "waiting for connection" whereas Eclipse just sits at the notorious 57% level (& yes, I toggled the xdebug.idekey before testing with Eclipse)).
So I tested xdebug's functionality on my server according to the instructions found here and here (both passed). I tried changing to port 9001 (in remote php.ini as well as in local Netbeans/Eclipse), I even tried launching this brand spanking-new EC2 instance with pretty much open Security group settings (SSH=0.0.0.0/0), but nothing seems to be working. I am out & out flummoxed, a self-confessed noob, and appreciative of any insight seasoned professionals in the community may have to offer.
Thanks,
Debbie
This feels like a networking issue to me. Port 9000 may not be accessible. The quickest way to test is to telnet to port 9000 on the remote system (if you have a telnet client installed that allows you to specify which port to telnet to). If the telnet attempt times out or is closed by the remote system you will see the error and this verifies that there is a networking issue.
I would check /etc/services to make sure that port 9000 is not reserved for use of something else. If port 9000 exists and is uncommented then something else is using the port and that services does not know how to respond to your request so it hangs.
I would do a netstat (lookup params to see "all" listening ports) and make sure the remote system is listening on port 9000. If you don't see port 9000 then the remote system is not configured to establish the connection.
If you are on a WIFI network then port 9000 may need to be port forwarded to the remote system using the internal cable modem configuration menu/utility. This is the scenerio I favor because I've wasted so much time solving this kind of problem with different software.
Good luck, you have more troubleshooting ahead of you and different questions to ask to resolve your problem.
Here's what I've done:
I wrote a minimal web server (using Qt, but I don't think it's relevant here).
I'm running it on a legal Windows 7 32-bit.
The problem:
If I make a request with Firefox, IE, Chrome or Safari it takes takes about one second before my server sees that there is a new connection to be accepted.
Clues:
Using other clients (wget, own test client that just opens a socket) than Firefox, IE, Chrome, Safari seeing the new connection is matter of milliseconds.
I installed Apache and tried the clients mentioned above. Serving the request takes ~50ms as expected.
The problem isn't reproducible when running Windows XP (or compiling and running the same code under Linux)
The problem seems to present itself only when connecting to localhost. A friend connected over the Internet and serving the connection was a matter of milliseconds.
Running the server in different ports has no effect on the 1 second latency
Here's what I've tried without luck:
Stopped the Windows Defender service
Stopped the Windows Firewall service
Any ideas? Is this some clever 'security feature' in Windows 7? Why isn't Apache affected? Why are only the browsers affected?
If you're saying "localhost" instead of "127.0.0.1", you're forcing a name lookup before the actual connection attempt, adding delay.
In addition, some browsers, like Firefox 3.5+, don't use the operating system's DNS lookup mechanism, which is why it can have different performance than, say, wget.
You may be running into some automatic proxy discovery problem. In Firefox, you can disable this in Options | Advanced | Network | Settings; select either "No proxy" or give it explicit values. There's also the Internet Properties control panel, which is IE's network settings, but other browsers on Windows may obey settings here, too. Again, disable auto-proxy discovery. This can speed connections outside localhost, too.
For some reason Windows 7 takes 1 second to resolve address localhost regardless of it being in hosts file.
Adding localhost1 to hosts file and using that works around the problem.
When connecting to localhost on a IPv4/IPv6 dual stack host:
A DNS lookup is performed for localhost.
The DNS server (whether IPv6 enabled or not - this doesn't matter) returns both the AAAA record ::1, and the A record 127.0.0.1.
The client first attempts to connect to ::1.
We assume your server program is not IPv6-capable, which is a common case - due to historical reasons, many servers bind their socket to 0.0.0.0 by default rather than [::].
Here an ECONNREFUSED error would be raised for the client. This happens immediately on most platforms; on Windows however, a single call to connect() would try 3 times in 500ms intervals before giving up, hence taking a bit more than one second (See http://stackoverflow.com/q/19440364 for more details).
The client then creates a connection to 127.0.0.1 instead.
This would explain all your clues above:
If you make a request with Firefox, IE, Chrome, Safari or any other IPv6-capable clients, it takes takes about one second trying for ::1 before connecting to 127.0.0.1.
Your own test client just opens a INET socket, so it won't try ::1 at all.
Using a dual-stack server such as Apache, the clients will connect to ::1 happily.
The problem isn't reproducible on Windows XP, of which IPv6 support is not enabled by default.
The problem seems to present itself only when connecting to localhost, as your friend connected with an IPv4-only network.
Running the server in different ports has no effect on the 1 second latency.