Hi, setting up an active mode FTP session from the built-in command line FTP client on Windows 2008 R2 towards a Windows 2003 or Unix FTP server fails at the port command. Taking a network trace shows the following: No. Time Source Src Port Destination Dst Port Protocol Seq Next Seq Ack In Flight Window Len Info 87 2.350570 172.16.12.16 54287 172.25.64.93 21 FTP 74 116 481 42 130816 42 Request: PORT fe80::81e0:acf6:64b7:296%14,104,104 Frame 87: 96 bytes on wire (768 bits), 96 bytes captured (768 bits) Ethernet II, Src: Vmware_a4:00:10 (00:50:56:a4:00:10), Dst: Cisco_d0:96:7f (00:19:06:d0:96:7f) Internet Protocol Version 4, Src: 172.16.12.16 (172.16.12.16), Dst: 172.25.64.93 (172.25.64.93) Transmission Control Protocol, Src Port: 54287 (54287), Dst Port: ftp (21), Seq: 74, Ack: 481, Len: 42 File Transfer Protocol (FTP) PORT fe80::81e0:acf6:64b7:296%14,104,104\r\n Request command: PORT Request arg: fe80::81e0:acf6:64b7:296%14,104,104 Although this is an IPv4 TCP connection the FTP client on Windows 2008 R2 send his link local IPv6 address as argument. Of course the FTP server doesn't understand that and reset the TCP connection. We have tried it on different Windows 2008 R2 servers and get always the same result. Running the FTP client on Windows 7 doesn't show any problem. Is this a known issue? Best Regards, Stefaan

Hi Stefaan, Thanks for posting here. How did establish the connection by using FTP command ? have also included any parameter ? Could share your commands with us? http://technet.microsoft.com/en-us/library/ff687787(WS.10).aspx Regards, Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Tiger, I tried to repro the problem myself and was able to narrowdown the problem a lot. It's *not* the built-in command line FTP client that causes the problem but a custom FTP client program based on a dotNET library. They assumed it was the same problem with the built-in command line FTP client because it didn't work either. However, for the latter the Windows Firewall was definitely not correctly configured. That said, because there is a workaround for the custom FTP client by using passive mode FTP, the developer has no longer any interest in further investigating the problem. So, case closed. Thanks for listening... Regards, Stefaan