In depth look @ code in Action by the PROXY group.

Question

Hello,

Seems everytime, both ACTIVE and PASV, code generates a seemingly random port for which to do LS or GET/PUT.
As our firewall is locked down, using arbitrary ports in the mannor won't fly.
Looking @ the code, seems the port is determined by the remote server?

Can the code be forced to use a set of ports WITHOUT resorting to hardcoding? (BTW, tried to force code to use ports 20 and 21 for LS and it failed.)

Our shop is using Microsoft Proxy 2.0
My proxy group has a few questions regards protocol layers.

Layer 7: Application
Layer 6: Presentation
Layer 5: Session
Layer 4: Transport
Layer 3: Network
Layer 2: Data Link
Layer 1: Physical

I supplied the PROXY team with this line:
"Socket sock = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);"
however they said they needed more information

Being new to this, not sure which are mine and which are used by the library. I suppose it goes without saying that layers 6 and 7 is my wrapper code.

If you can full in the gaps for the other layers, I'd be appreciative.
I'm using WINDOWS NT (4.00.1381)

Thanks!

Answer 1

Fair enough that PASV requests of the remote server a PORT for transmission.

However, what determines the PORT the client wishes to communicate data transfers through when using an ACTIVE connection mode?
Far as I can tell by stepping though the code, each port supplied to the remote server is random, or at least random looking. I tried hardcoding the standard port of 20 but code still bombed.

Answer 2

http://www.ncftp.com/ncftpd/doc/misc/ft ... walls.html is worth reading.

Many proxies support using the proxy address as the remote hostname, and remoteuser@remotehost as the username to login with.

Fair enough that PASV requests of the remote server a PORT for transmission.

However, what determines the PORT the client wishes to communicate data transfers through when using an ACTIVE connection mode?
Far as I can tell by stepping though the code, each port supplied to the remote server is random, or at least random looking. I tried hardcoding the standard port of 20 but code still bombed.

Answer 3

Thanks for the info.

DOS based FTP.EXE, however unmanaged still seems to do a good of getting data from one place to another and seems to use a minimal amount of ports which appear to be "the norm".

There are issues however that need to be addressed; for example, that the application is console based and does not lend itself well to automation beyond scripting and shelling to DOS.

So I suppose a solution would be to rewrite the core of FTP.EXE into a service easily managed by C#/JAVA (I seen some code that professes to to but have yet to see a viable implementation).

No, not a knock against your product. In fact, its beautiful.

I work for a BIG company that has restrictions in place regards ports.
How does one approach the company and say, to the effect, "for FTP to work smoothly you will most likely need to expend considerable effort on configuration or considerable cash on hardware that is FTP aware."

Because of the difficulties faced during implementation, I'll be forced to turn back the clock to FTP.EXE.

My company is big, REALLY big.
For you and for me, being an implementor, making this work is good.

The company is using MICROSOFT PROXY 2.0.
Does this PROXY service have the potential to be flexible, yet secure, in implementing your code?

And, I'm not sure what this means:

Many proxies support using the proxy address as the remote hostname, and remoteuser@remotehost as the username to login with.

Answer 4

DOS based FTP.EXE is probably using PORT where the FTP server is supplying the port numbers.

The below means:

Try connecting to your remote host by doing this:

ftp = new FTPClient("proxyhost");
ftp.login("remoteuser@remotehost","remotepassword");

Many proxies support this.

Thanks for the info.

DOS based FTP.EXE, however unmanaged still seems to do a good of getting data from one place to another and seems to use a minimal amount of ports which appear to be "the norm".

And, I'm not sure what this means:

Many proxies support using the proxy address as the remote hostname, and remoteuser@remotehost as the username to login with.

Answer 5

If so, FTP.EXE is using PASV and could be literally using the entire ephemeral port range.

If so, PROXY/FIREWALL would be wide open to the range.
If so, EDTFTP would NOT fail.

Makes more sense that FTP.EXE is using ACTIVE mode and perhaps instructing REMOTE SERVER to use either port 20 or, heavens forbid, port 21, for which to transmit data.

When in ACTIVE mode, how does the code determine the port to instruct the REMOTE server to communicate on?

Answer 6

Ok - let's find out for sure.

If you start up FTP.EXE, connect to the site, and type 'debug'

This will display the commands and replies being sent back & forth.

Is it sending PORT or PASV?

If so, FTP.EXE is using PASV and could be literally using the entire ephemeral port range.

If so, PROXY/FIREWALL would be wide open to the range.
If so, EDTFTP would NOT fail.

Makes more sense that FTP.EXE is using ACTIVE mode and perhaps instructing REMOTE SERVER to use either port 20 or, heavens forbid, port 21, for which to transmit data.

When in ACTIVE mode, how does the code determine the port to instruct the REMOTE server to communicate on?

Answer 7

Layer 5: Session = edtFTPnet
Layer 4: Transport=TCP
Layer 3: Network=IP

Answer 8

Too cool.

The commands are PORT and therefore, ACTIVE.
Far as I'm aware, FTP.EXE, being a product perhaps 10 years old (still using NT @ work), is not capable of

I had the FIREWALL tech monitor the transactions from NT based FTP.EXE and found the following:
1) Contol Port 21
2) Data Port (Client: seemingly random, Server: 20)
3) Connection Active

I'm going to try using ACTIVE @ the house.
Am assuming PASV is the default and have already successfully made that happen @ home.

Assuming the above, what would prevent edtFTPnet from using ACTIVE transmission? On every test, the ACTIVE connection mode failed.

Answer 9

We don't know. What error message are you getting?

Assuming the above, what would prevent edtFTPnet from using ACTIVE transmission? On every test, the ACTIVE connection mode failed.

Answer 10

We're pretty small. So if you'd like to purchase a perpertual source license to help us keep developing, we'd appreciate it :)

http://www.enterprisedt.com/products/ed ... chase.html

My company is big, REALLY big.
For you and for me, being an implementor, making this work is good.