🚀 go-pugleaf

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fbd697@newsgroups.borland.com...

> from the outside - I am able to log in to the ftp server - but
> I can't get the directory to list - it simply times out.

The firewall is likely still blocking the data transfer.  Which version of 
Indy are you using?  Is the client using Active or Passive mode transfers?


Gambit 

Passive mode
Indy 10.2.3

Any prog. you can recommend to watch what ports are actually used ?

thanks,

Roland

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fc0c8a@newsgroups.borland.com...

> Passive mode
> Indy 10.2.3

When was the last time you updated your copy of 10.2.3?  I remember fixing 
bugs related to Passive ports not too long ago.  I'll have to double-check 
if those changed have been checked in or not yet.

> Any prog. you can recommend to watch what ports are actually used ?

Windows has a command-line "netstat" program for that.  The "netstat -a" 
command will display all of the listening ports.


Gambit 

I updated indy last time march 3rd

Roland

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:47fc0dc4$1@newsgroups.borland.com...
>
> "roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
> news:47fc0c8a@newsgroups.borland.com...
>
>> Passive mode
>> Indy 10.2.3
>
> When was the last time you updated your copy of 10.2.3?  I remember fixing 
> bugs related to Passive ports not too long ago.  I'll have to double-check 
> if those changed have been checked in or not yet.
>
>> Any prog. you can recommend to watch what ports are actually used ?
>
> Windows has a command-line "netstat" program for that.  The "netstat -a" 
> command will display all of the listening ports.
>
>
> Gambit
> 

I found the problem - and it works now:
in:
IdFTPServer1PASVReply(TIdFTPServerContext *ASender,  AnsiString &VIP, WORD 
&VPort, const TIdIPVersion AIPVer)
 {
 VIP = "65.94.66.176";  // my public IP
 }

VIP seems to be set to the local IP.

So - the question is - where in the FTPServer component is the best place to 
get the public IP from.
- it is already known - because the client already connected on port 21

thanks,

Roland 

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fc471d$1@newsgroups.borland.com...

> IdFTPServer1PASVReply(TIdFTPServerContext *ASender,  AnsiString &VIP, WORD 
> &VPort, const TIdIPVersion AIPVer)
> {
> VIP = "65.94.66.176";  // my public IP
> }
>
> VIP seems to be set to the local IP.

Yes, it is the local IP by default.  That is be design.  TIdFTPServer has no 
way of knowing that it is running behind a router or not.  If TIdFTPServer 
were running on a machine that is directly connected to the Internet, then 
the default IP works fine.  Otherwise, the OnPASVReply exists so you can 
override the default yourself when needed.

> where in the FTPServer component is the best place to get the public IP 
> from.

TIdFTPServer does not know the public IP when running behind a router.  It 
is your responsibility to provide that to it when requested by the 
OnPASVReply event.

> - it is already known - because the client already connected on port 21

The client knows the IP.  TIdFTPServer does not.  It only knows the local 
IP(s) that it is directly listening on.  When TIdFTPServer is running behind 
a router, then the IP(s) are completely different than the IP that the 
client connects to.


Gambit 

thanks for all your help!

now in:
IdFTPServer1PASVReply(TIdFTPServerContext *ASender,  AnsiString &VIP, WORD
> &VPort, const TIdIPVersion AIPVer)
> {

VPort is always set to 210   (the DefaultPort)
should it not be set to inbetween PASVBoundPortMax and
PASVBoundPortMin ?

thanks,

Roland 

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fcd43b$1@newsgroups.borland.com...

> VPort is always set to 210   (the DefaultPort)
> should it not be set to inbetween PASVBoundPortMax
> and PASVBoundPortMin ?

That is a bug that I already started addressing a few weeks ago in the 
Tiburon branch (and need to finish), but not in the main release yet.


Gambit 

Here is what I did in PASVReply - and it does work now:

void __fastcall TForm1::IdFTPServer1PASVReply(TIdFTPServerContext *ASender, 
AnsiString &VIP, WORD &VPort, const TIdIPVersion AIPVer)
 {
 Memo1->Lines->Add("PASV command");
 Memo1->Lines->Add("Connected from: " + ASender->Binding()->PeerIP);

 if ((ASender->Binding()->PeerIP == ASender->Binding()->IP) || 
(ASender->Binding()->PeerIP == IdIPWatch1->CurrentIP))
  {
  Memo1->Lines->Add("Connected from local computer");
  return;
  }
 if 
(ASender->Binding()->PeerIP.SubString(0,ASender->Binding()->PeerIP.LastDelimiter(".")) 
== 
IdIPWatch1->CurrentIP.SubString(0,IdIPWatch1->CurrentIP.LastDelimiter(".")))
  {
  Memo1->Lines->Add("Connected from local network");
  return;
  }
 Memo1->Lines->Add("Connected from remote network");
 PublicIP = GetPublicIP(PublicIPName);
 Memo1->Lines->Add("VIP changed from " + VIP + " to " + PublicIP);
 VIP = PublicIP;
 }

____________________________________________________________________
GetPublicIP function, pDomainName is my own DDNS name:

AnsiString __fastcall TForm1::GetPublicIP(AnsiString pDomainName)
 {
 IdDNSResolver1->Resolve(pDomainName);
 for (int n = 0; n < IdDNSResolver1->QueryResult->Count; n++)
  {
  switch (IdDNSResolver1->QueryResult->Items[n]->RecType)
   {//  TARecord, TCNRecord, THINFORecord, TMINFORecord, TMXRecord, 
TNAMERecord, TNSRecord, TPTRRecord, TRDATARecord, TSOARecord, TTextRecord, 
and TWKSRecord.
   case qtA:
    return ((TARecord*)IdDNSResolver1->QueryResult->Items[n])->IPAddress;
    break;
   }
  }
 return "";
 }


Roland 

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fcf224$1@newsgroups.borland.com...

> Memo1->Lines->Add("PASV command");

That code is not thread-safe.  Any event handler that provides access to a 
TIdContext object is fired in the context of the thread that owns that 
object.  You cannot safely access UI component from outside the context of 
the main thread.  You need to use the TIdSync class for that, or any other 
synchronization technique of your choosing.

> if 
> (ASender->Binding()->PeerIP.SubString(0,ASender->Binding()->PeerIP.LastDelimiter("."))

0 is an invalid string index.  VCL Strings are 1-indexed, not 0-indexed.

> AnsiString __fastcall TForm1::GetPublicIP(AnsiString pDomainName)
> {
> IdDNSResolver1->Resolve(pDomainName);

There is an easier way to do that - use an HTTP query instead, such as to 
http://iplookup.flashfxp.com, to get the exact IP that your server machine 
is accessible from publically.  You don't need to perform your own DNS 
lookups, ie:

    AnsiString __fastcall TForm1::GetPublicIP()
    {
        return IdHTTP->Get("http://iplookup.flashfxp.com");
    }


Gambit 

I just wanted to make sure that what I am doing is right (I havn't used 
TIdSync before):

in the Main form .h file rigth after the line " extern PACKAGE TForm1 
*Form1;"
I added:
_________________________________________________
class TUpdateMemo : public TIdSync
 {
  protected:
    AnsiString txt;
  public:
    __fastcall TUpdateMemo(AnsiString s){txt = s;}
    void __fastcall DoSynchronize(void)
    {
    Form1->Memo1->Lines->Add(txt);
    }
 };
_________________________________________________

then - in   IdFTPServer1PASVReply(TIdFTPServerContext.......)
I changed the code to:
___________________________________________________
TUpdateMemo *um = new TUpdateMemo("PASV command");
um->Synchronize();
delete um;
___________________________________________________


thanks,

Roland 

On or about Wed, 9 Apr 2008 12:43:18 -0400 did "roladdon"
<roladdon@PutMyServerHere.ca> dribble thusly:

>____________________________________________________________________
>GetPublicIP function, pDomainName is my own DDNS name:
>
>AnsiString __fastcall TForm1::GetPublicIP(AnsiString pDomainName)
> {
> IdDNSResolver1->Resolve(pDomainName);

You're better off making the public IP a configuration option for your server
software.  You can't count on local hostname resolution to return the correct
IP, and you shouldn't rely on an outside web site.

"roladdon" <roladdon@PutMyServerHere.ca> wrote in message 
news:47fd80d1$1@newsgroups.borland.com...

> I just wanted to make sure that what I am doing is right (I
> havn't used TIdSync before):

That will work fine.  I tend to add a static method to my TIdSync classes as 
well to hide the 'new' and 'delete' calls and streamline the code that uses 
TIdSync, ie:

    class TUpdateMemo : public TIdSync
    {
    private:
        AnsiString txt;

        __fastcall TUpdateMemo(const AnsiString &s) : TIdSync() { txt = s; }

    protected:
        void __fastcall DoSynchronize(void)
        {
            Form1->Memo1->Lines->Add(txt);
        }

    public:
        static void __fastcall Add(const AnsiString &s)
        {
            TUpdateMemo *um = new TUpdateMemo(s);
            try {
                um->Synchronize();
            } __finally {
                delete um;
            }
        }
    };


    {
        //...
        TUpdateMemo::Add("PASV command");

        //...
    }


Gambit