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

Alas, I am but a contractor:(

Answer 2

On 2nd thought, I believe I will.

Done.

REF# 7518837

Answer 3

Now you buggers are REALLY in for a hard time.

FTP.EXE, the DOS version, uses ACTIVE mode.
My newly purchased software can use both PASV & ACTIVE.
Assuming I use ACTIVE, why would FTP.EXE make it though the firewall every time but EDTFTP have issue, even in ACTIVE mode?

I believe it a proxy issue but have no logs to show:(
However, I did use a SNIFFER @ the house and I suppose I could compare the EDTFTP log to the FTP.EXE log!

Answer 4

Thank you very much!

FYI, we are currently doing an extensive rewrite of edtFTPnet and there should be a much enhanced release available in a couple of weeks.

On 2nd thought, I believe I will.

Done.

REF# 7518837

Answer 5

Comparing the logs is the best option to start with. Then we can see exactly what FTP commands are being sent back and forth, and what the differences are.

FTP.EXE, the DOS version, uses ACTIVE mode.
My newly purchased software can use both PASV & ACTIVE.
Assuming I use ACTIVE, why would FTP.EXE make it though the firewall every time but EDTFTP have issue, even in ACTIVE mode?

I believe it a proxy issue but have no logs to show:(
However, I did use a SNIFFER @ the house and I suppose I could compare the EDTFTP log to the FTP.EXE log!

Answer 6

I know it's moving backwards and all but would REALLY appreciate the code being compatible (and of course tested) with Framework 1.0

Large corporations are not so quick to jump to the latest "thing" so expecting them to update the framework can be (and is in my case) a hassle.

Answer 7

By the way, why is there a re-write in progress?

Answer 8

I just tried comparing the way that FTP.EXE and edtFTPnet select ports when in ACTIVE mode. I found that they use them in very similar (identical?) ways. Both will open ports with incrementing numbers (e.g. 1952, 1952, 1953) for each data transfer. And in both cases the server (ProFTPD on Linux) would connect to the opened port from the default data channel, i.e. port 20. So there's no apparent difference between them in that regard. I have no access to a MS Proxy Server so I can't see what happens when it's involved.

The fact that ACTIVE mode is working through the firewall at all for FTP.EXE indicates that there's some sort of "magic" going on. You might like to have a look at Proxy Server's Structural Design on the MS website. The section "Socks Proxy Service" says that FTP will utilize the SOCKS Proxy Service, but it mentions it in passing and I'm not sure if I've understood it correctly. There's also some mention of some specialized comms going on between WinSock and the proxy server, which could also be a factor.

FYI, we're currently developing SOCKS support for edtFTPnet. Experimental versions should be ready within a few days.

- Hans (EDT Support)

Answer 9

We've added a huge number of features to edtFTPj, our Java client, in the last 18 months. So we're porting them all over to edtFTPnet.

By the way, why is there a re-write in progress?

Answer 10

It should be compatible with 1.0 - just need to recompile.

I know it's moving backwards and all but would REALLY appreciate the code being compatible (and of course tested) with Framework 1.0

Large corporations are not so quick to jump to the latest "thing" so expecting them to update the framework can be (and is in my case) a hassle.