In RMI the server opens the registry on some port and then the clients connects to the server. Is there any way knowing on which port the connection is made between the server and the client?
I know the default port for RMI is 1099 but what is the port number on the client side? Does the client even opens a port?
The client does have a local port, as in any TCP connection, but there is no way for the server to discover it short of a custom socket factory.
There's also no reason for the server to need it. It's not a useful piece of information. It's not a listening port, so you can't connect to it; it changes from time to time; and it doesn't uniquely identify the client, because of client-side connection pooling and server-side idle connection timeouts.
Related
I have an Azure Container App running and is listening on a public TCP port 8000 (via the load balancer) for incoming connections. When incoming connections are arriving, I serve them with data and everything goes as expected.
My problem is when I stop the server listening on that port. In that case, a client application trying to connect to my public IP address at port 8000 would expect to get an error like 'Could not connect' but this is not happening. What is in fact happening is that the Container Apps environment seem to be forwarding the data no mater what to that port (even if there is no server listening). As such, the client connecting to that port can't understand that the server that should be listening to that port is really stopped (in order to resend the data at a later time).
Example:
Open a TCP client (eg. PacketSender) and try to send some data to port 6000 on your localhost. You should receive a 'Could not connect' error message.
Now, in docker run the following:
docker run -p 6000:6000 nginxdemos/hello:plain-text
Try again to send some data to port 6000 via a TCP client. This time the data will be sent even though the nginxdemos container doesn't listen to port 6000 (but probably on 80).
Is it any way that I can somehow solve that issue on the server side and ensure that the clients can't connect if the server is stopped? I have devices sending thousands of data on a Container App but because they do not expect any kind of an ACK, they think that the data have been transmitted (even though they haven't) and they don't try to resend them.
Not sure about the docker example, it probably depends on how docker on that system implements port forwarding.
In Azure ContainerApps: no, this is not possible. There is always some component listening on the port, even if your application is not running or is restarting, provisioning, scaling, etc. The connection will be buffered until the app starts listening on the port or it times out.
I try to build mobile application which use firebird database. I need to open port 3050 for that service.
I have add rule to ZTE router both incoming and outgoing for port 3050 and also to bitdefender firewall. I have forward rule to specific ip, where firebird listen 3050 port.
When I use open port checker, it shows that 3050 port is open. But when I try to connect to firebird service with FlameRobin using my ip-adress, error message: unable to complete network request to host "86.115.60.xx"
WinShark screenshot shows something but I can't understand all information.
I'm trying to establish a connection with a diameter server. That server has a restriction parameter of "peer port"
Which means source port of my outgoing traffic should be restricted to a specific port.
Since I'm using an erlang diameter client, I didn't find any parameter to specify the outgoing port. It will initiate the connection with a random port to the destination ip:port.
Is there a way to translate my outgoing traffic to that ip locally to a specific port from linux?, so that the external server will see my source port as the allowed port.
You should apply a NAT at the sender side. Read this thread, it explains how to do it with iptables.
Due to a virus in the system, one of our clients have made access to internet restricted in their server. We use two web services data on this server (both use a SOAP API).
The client company is asking me for the ports on the firewall they should leave open so we could be able to use those web services only. I'm not good at networks. So how can I get those information?
I need the port or any address from my two services so that they let them pass through the firewall.
I'm not sure I understand the question, but most web services receive connections on one of:
80 (http)
443 (https)
8080 (http)
Most firewalls client should be configured to allow outbound connections to these.
Server firewall MUST be configured to allow inbound connections on one of these (or some other pre-arranged non-standard port).
To work out what ports your existing web server is actually using:
how to investigate ports opened by a certain process in linux?
Its most likely, 80, 443, or 8080.
I am currently using Ubuntu 10.04 for some rails development. It is installed as a guest machine using VirtualBox on a Windows 7 x64 host.
Within Ubuntu, I am trying to port tunnel several ports from a remote server directly to the Guest OS in order to avoid having to download a remote database.
Let's say I want to forward port 5000 on the remote server to port 5000 on the guest os.
I have set up a forwarder for the port on the Windows side, using VBoxManage.exe. This forwards HostPort 5000 to GuestPort 5000.
Then within ubuntu I run, ssh -L5000:127.0.0.1:5000. However, whenever I try to access "127.0.0.1:5000", I receive the message "channel 7: open failed: connect failed: Connection refused"
Am I missing something?
Thanks for the help!
connect failed: Connection refused
This means that you'r not able to connect to 5000 on the remote end.
If you'r only using this connection from within your guest through your SSH tunnel then you don't need the forward from VBoxManager, as this will open op so that outside computers can connect directly to your guest, it won't help your guest connect to the outside.
Are you sure the server you connect (SSH) to is the same server that runs your database? And is the database running on that server?
When you've connected (SSH) to the server, you can try to list what ports are listening for connections or you could try to connect to the database with telnet. To list listeners you can run "netstat -lnt" (-l shows listening, -n is numeric (show IP and port number) and -t is tcp). You should have a line like "tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN" if you have a service listening for TCP on port 5000. To try and connect you can simply do "telnet 127.0.0.1 5000", if you can't connect with telnet from the server then the database ain't listening/allowing your connection, or the server is running on another port or server.
SSH uses TCP traffic by default, right?
Just to verify, NAT in VirtualBox does have these limitations (per the User Manual):
There are four limitations of NAT mode which users should be aware of:
ICMP protocol limitations: Some frequently used network debugging tools (e.g. ping or tracerouting) rely on the ICMP protocol for sending/receiving messages. While ICMP support has been improved with VirtualBox 2.1 (ping should now work), some other tools may not work reliably.
Receiving of UDP broadcasts is not reliable: The guest does not reliably receive broadcasts, since, in order to save resources, it only listens for a certain amount of time after the guest has sent UDP data on a particular port. As a consequence, NetBios name resolution based on broadcasts does not always work (but WINS always works). As a workaround, you can use the numeric IP of the desired server in the \server\share notation.
Protocols such as GRE are unsupported: Protocols other than TCP and UDP are not supported. This means some VPN products (e.g. PPTP from Microsoft) cannot be used. There are other VPN products which use simply TCP and UDP.
Forwarding host ports lower than 1024 impossible: On Unix-based hosts (e.g. Linux, Solaris, Mac OS X) it is not possible to bind to ports below 1024 from applications that are not run by root. As a result, if you try to configure such a port forwarding, the VM will refuse to start.
Try ssh -L5000:0.0.0.0:5000 instead of ssh -L5000:127.0.0.1:5000
There is something called a "loopback" that is tangled up with 127.0.0.1 that will cause you grief if trying to access ports from a different machine. I.e. your host machine.