Change FTPClient port in order to send a command - java

I'm connecting and logging in to a server on port 21. What I want to do next is to send a command string, however I have been instructed to send this command through port 50.
How do I change the port to 50 whilst connected on port 21?
I have tried connecting to the server on port 50 intially, and the onnection is refused. I have tried sending the command whilst connected on port 21 using ftpClient.sendCommand and I get a reply code 500 Unknown command

You should go back to the one who told you this requirement and ask about specifics because - to be blunt - the whole thing doesn't make real sense:
FTP works with two connections, control and data. The control channel is the one you open on port 21 and there is only this one, you can't change it back to another port afterwards. So "send a command on port 50 but connect on port 21" is not a thing with FTP.
A data connection on a port < 1024 is not usual, so it's hard to believe that the one with that requirement meant that, either. For one that would require active FTP connections that everybody nowadays tries to avoid because they are a pain to configure. Opening a listener on a port < 1024 would require root-privileges on Unix-systems which is unlikely you will get just for doing FTP-transfers.
You also said that the command you actually try to send to the server is confidential. I find that hard to believe but if it really is that would mean that we're talking about a non-standard FTP-server working with its own set of FTP-commands, i.e. regular FTP-clients might not be able to do what you need at all.
So go back to the one who gave you this requirement and ask, what the heck he's talking about, ideally with an example how to do it, let's say using the FTP-client that comes with the Windows Command-Shell.

Typically when you connect, the server controls the port assignment. So when you issue a pasv command (passive mode), it typically sends you back an IP / Port to connect to for the data connection. I'm not aware of anything that will allow you to do what you want. The server can restrict the port range for these types of things. Here's a nice explanation that goes over this.
Active vs Passive FTP
You may be able to send a PORT command to connect to port 50 specifically, but it's really unusual to do something like this.
** Edit **
There's two things you can try, I've never used either, so YMMV.
In Active mode, the client gives the server a port to connect to.
Try setting the default port to 50 and turn on Active mode. Hopefully this is on your internal networks, because this would never get past security for a firewall request.
client.setDefaultPort(50);
client.enterLocalActiveMode(); // Apache FTPClient
For Passive mode, you can try to set the active port range.
client.setActivePortRange(50, 50)
client.enterLocalPassiveMode();
You should ask what mode the server is expecting.

Related

Port absolutely refuses to open, despite best efforts

So, I am trying to build a simple java chat application.
The application is supposed to establish a connection on port 5000. When I tried to give the jar to my girlfriend so she could test the client, she gets a connection refused, so I first though to check my ports. Port 5000 absolutely refuses to open.
I have tried everything I can think of (although I am definitely not IT savvy so I could've missed something);
Here are steps I have taken:
In command prompt (while the server is running) I have used netstat -an and found port 5000 is listed as listening. When the server is not running, this port is not listed.
I have disabled any and all antivirus software /firewalls on my rig, and in my router settings.
I have set up a static IP for my rig.
I have port forwarded port 5000 on my router and checked and double checked that I have done it correctly.
I even contacted my ISP, who swears up and down that they don't block ports.
I have tried other ports, not just 5000.
After the above steps, I have used several different sources to check whether port 5000 is open. That thing is more blocked than Michael Moore's arteries.
My question: Why does the internet hate me?
EDIT: over endless hours of chat we (myself and user roelofs) were able to get it working on port 21, (the ftp port), which isn't a problem because there wont be any conflicts, but it isn't right. If anyone can point me in the right direction, I'd much appreciate it. It seems to be some kind of windows specific problem? Maybe? Can confirm ports are correctly forwarded and any kind of security that I can think of is off.
'Connection refused' means that there was nothing listening at the IP:port you tried to connect to. So, either the IP or port was incorrect or your server wasn't running. If the IP and port were correct it also means your firewall is forwarding the port correctly.
'Connect timeout' to a current Ip:port on the other hand indicates that your firewall isn't set up correctly.
After some testing, it appears that windows might have problems with listening sockets above 1024. Running the code on a port lower than that (and setting up all port forwarding correctly) should get you to the point where you can debug.

can an isp block incoming connections?

First of all, i am a newbie in network programming. Few days ago, i wanted to test a simple java server(simple java echo server). I first tried running it in a university computer and then tried connecting through my laptop which is in a different network without any success. I assumed the network(private university network) didn't allow the connection. Next, i ran the server in my laptop expecting it to be public. I ran the server. I ran it in port 5000. Since the connection was through wifi i also did port forwarding so that my router would know where to forward the incoming requests. I even disabled the firewall just to test. Then there is a tool in the internet which i obtained from some other user in stackoverflow http://www.yougetsignal.com/tools/open-ports/ which can check if a port is open in a machine. I put my ipaddress and port number to see if it is reachable. It continued saying the port is closed. Although i don't have a good idea about networks, i called the ISP and asked if the issue was with the network being a private network and if it is possible to host server in my laptop, she concurred saying it was private network and what i am trying to do is not possible. I wanted to try it in some other computer. I met one good guy in stackoverflow who allowed me to run the server in his computer in taiwan. He disabled his firewall or added an exception, then ran the server. I then ran my client and it could successfully connect to his server. I was ecstatic.
So, my question and curiosity is how does isp blocking incoming connection work? Did the ISP really block the incoming connection to my server or could the problem be with some other things? Is it ever possible to host server in my laptop which is accessible to the world. I am still not content with the answer i got from the ISP which was it was private network so it was blocking..isn't internet basically the collection of private networks connected to each other so isn't everyone in one way or other part of a private network? Please help me with these dilemmas. Appreciate your effort and help a lot! :)
Your house probably has one global external IP assigned to you by your ISP. They will normally block commonly used ports incoming, such as 80 (HTTP), 22 (SSH), 23 (Telnet), 25 (SMTP), and 443 (HTTPS). The majority of the remaining ports should be open for you to use.
As you have one global IP, and multiple devices on your network, you need to tell your router which computer the incoming traffic on a given port needs to go to. This is called Port Forwarding. As you don't control the routers upstream from you at your university, you can't change anything while there. At home you can.
Port Forwarding is explained in depth here.
I suppose it depends on the ISP. I have been able to open ports before with mine, using port forwarding from my router.
As a technician who works for an ISP, I can also say that the tech support generally doesn't have a clue whenbit comes to port blocking or networking in general, they mostly follow a script and ask you if you have turned it off and on again. Maybe check that you are forwarding the port correctly?

Finding Open Port TCP Communication

I'm writing a Java application like AIM where I want a lookup server to help two clients connect to each other with the ServerSocket class. Unfortunately a serversocket needs an open port or it will be blocked by your firewall. Without having the clients manually change their firewall settings is there a way I can either find an open port, open a port (it's okay if it asks for permission) I just don't want every client to manually have to change firewall settings. Thanks!
Creating a ServerSocket is what opens the port on the server end (assuming the port is NOT also blocked on the firewall). On many systems, port numbers <1024 are not blocked by the firewall, and therefore often don't require custom configuration. However, since many ISPs have been more and more stringent with what ports they block within their network, many pieces of software have moved to operating over port 80. Why port 80? It's the port used for HTTP, and therefore pretty much open (at firewalls) 100% of the time for any service that operates on the web.
To answer the question of how to find an open port, port scanners perform this function. Basically all they do is try to establish a connection on a range of ports (say port 1-1024). When a connection is successful (in Java you would see this as a good connection over a Socket), you can consider that port "open". You don't need to exchange any data in order to make the connection, you just need to establish the connection, and then close it.
Also, if there is no server software of any kind running on the server, it won't appear "open", even if it isn't blocked. Without a successful Socket (TCP) connection, you won't know what ports are not blocked by user's firewall.
To reiterate, I'm switching back and forth between two related, but separate concepts. Firewalls can block/open ports, or have port forwarding. That's not the same as a port being "open" for connections on a given machine. In order for a machine to accept connections on a given port, there must be a piece of software listening for a connection on that port, otherwise no connection can be made.
I would suggest to look at a couple of alternative solutions that are less cumbersome - scanning for open ports can take quite some time, can cause panicky reactions from firewalls that feel attacked, and so on. There are a couple of techniques that are in active use and have been developed exactly to solve the problem of servers behind firewalls.
UDP Hole Punching, zero user side configuration needed. Simple explanation on how Skype uses this technique can be found here
UPnP / IGD could be used as an alternative, though less devices support it out of the box nowadays due to security problems.
STUN with a Java implementation of client and serverside called JSTUN
Whatever solution you choose, test it thoroughly with different internet service providers, there's a plethora of limitations you can expect wrt blocked ports.

BACNet plugin for Building Management System

I'm trying to get a BACNet scanner up on an Seimens server running the Apogee system with a BACNet interface. I've tried using BACNet4j put i get a port bind error on the LocalDevice object for test/Scan.java.
Does anyone know of any other libraries I could use or a reference to instructions for setting up a BACNet plugin to a building management system?
I have had the same problem before, i.e. the BACnet client needs to both send and receive from UDP port 47808. Since the BACnet server already uses that port to listen (and reply) my solution was to use a virtual IP (a bridge) so that my client runs on the same Ethernet card but with a different IP address. A bit convoluted, I know, but it works.
Whether or not the Apogee system supports virtual (or simply additional) network drivers is another question altogether. On my Linux and Windows machines I can run as many servers and clients as I need (I actually don't know what is the limit, I have run up to 5 servers and 3 clients without any problems).
Concerning the port bind error, you may have to configure your firewall because:
BACnet/IP is using UDP
the default port number is 47808 (0xBAC0)
Your issue might be the use of a (BACnet port #) socket that is already in-use; you have to ensure that it's not in exclusive-use - before binding to the socket, but also (slightly more) important, also ensure it's marked for reuse.
But unless you're listening for Who-Is broadcasts, I'd recommend listening for the (unicast) responses upon a different port #, e.g. 0xBAC1/47809, but still send upon the standard port # 0xBAC0/47808.

FTP Timeout on NLST when directory is empty

EDIT: Learned that Webmethods actually uses NLST, not LIST, if that matters
Our business uses the WebMethods integration server to handle most of our outbound communications, and its FTP functionality leaves something to be desired. We are having a problem that may be specific to WebMethods, but if anyone can point me in a direction of what kinds of things might cause this I'd appreciate it.
When polling two of our partners' FTP servers, we connect without issue but, when doing a NLST on a directory that is empty (no files and no subdirectories) it's timing out. The actual error is:
com.wm.net.ftpCException: [ISC.0064.9010] java.net.SocketTimeoutException: Accept timed out
It's being thrown during the invocation of the pub.client.ftp:ls service. I've logged in with a number of FTP clients without a problem to the same sites. I've used whatever the default FTP client is in windows, FileZilla and lftp. All without issue. The servers themselves aren't the same FTP server software from what I can tell. One is Microsoft FTP, the other I'm uncertain on but is definitely not Microsoft.
Any idea what could cause an FTP client to timeout when waiting for a NLST response on an empty directory? The visible responses from the FTP server appear to be the same, but is there a difference in how NLST responds for an empty directory that I'm unaware of?
This problem is consistent on these two servers. Everything functions fine on directories with files or subdirectories within it, but not when empty.
Any thoughts or directions would be appreciated.
Thanks!
Eric Sipple
I tried this in WebMethods IS Version 6.5 Updates WmPRT_6-5-1_SP1, IS_6-5_SP3.
It worked perfectly first time.
I turned on debugging on the FTP server (Debian's default ftpd). WebMethods' NLST honours the active/passive parameter passed to it.
There's nothing special about the NLST command, nor its correct behaviour with an empty directory -- if LIST works, then so should RETR, STOR and NLST. If NLST works with a non-empty directory, it should work with an empty one.
So my guess is that either:
Your version of WM has a bug mine doesn't
Your FTP server has a bug mine doesn't
There's a wacky protocol-aware firewall in your system that doesn't like FTP data sockets with no data in them.
Firewall vendors are a bit wayward when it comes to FTP...
When testing with other clients, make sure it's from the same machine on which WebMethods Integration Server is running.
Just for the record, here's what should happen for an active NLST
client opens a listening socket, and sends a PORT command with that socket's details
client sends NLST command
server connects to client's listening socket (this is the data socket)
server transmits listing over data socket (in this case, zero bytes)
server closes data socket
... and in passive mode
client sends PASV command
server opens a listening socket, and replies with PASV response containing its details
client connects to listening socket (this is the data socket)
client sends NLST command
server transmits listing over data socket (zero bytes again)
server closes data socket
I am not sure if it was the same problem but I had similar symptoms a while ago using another FTP client in Java (commons.net). The problem turned out to be caused by the active/passive mode of the connection.
I am sorry I can't give you more details, that's all I can remember... hope that help.
Guillermo Vasconcelos was correct in his answer. There are two FTP modes, Active and Passive. The default FTP mode is active. Active requires the server to connect back to the client on some TCP/IP port. This does not work with firewalls because chances are that this port would be blocked or if you are behind a Router with NAT, not mapped.
If you use Passive (PASV) mode instead, you should not get the hang.
I'm going to run some new tests with the settings to passive tomorrow when maintenance is done here, but I'm not sure that's the issue. We are able to get a directory listing if there are files or subdirectories in that directory. It only fails when the directory we're NLST-ing on is empty.
Would the active/passive difference only manifest for an empty directory, or is there another possibility?
FTP requires that both the specified port and the one above it be opened through the firewall. When I had problems with webMethods timing out, it was because the firewall did not have the return port open.
Howard

Categories