XPost: comp.os.vms   
   From: bqt@softjar.se   
      
   On 2011-04-07 05:27, glen herrmannsfeldt wrote:   
   > Jeffrey H. Coffield  wrote:   
   >> We had a customer complain that one of their customers could only ftp 3   
   >> files at a time as the fourth would fail. Even if they sent the files   
   >> one at a time, the fourth would generally, but not always fail. Turning   
   >> on the FTP debugging showed a 425 duplicate name error on port 5004.   
   >> They asked me to see if there was some firewall settings that was   
   >> blocking that port.   
   >   
   >> After quite a bit of digging, I saw that when the ftp session started,   
   >> it always used port 5001 first, then 5002, 5003 and fail on 5004.   
   >> Finally a "TPCIP show device" showed there was a bg device open on port   
   >> 5004.   
   >   
   > I presume the is not passive-ftp, which is more usual these days,   
   > especially as it gets through firewalls easier.   
      
   Could be either. Depends on which side this happens on. I'm not clear on   
   that from the description above.   
      
   > I am cross-posting to comp.protocols.tcp-ip.  In general, a TCP   
   > connection is identified by the quad of source address, source port,   
   > destination address, destination port.  If even one is different,   
   > a new connection can be made.  When non-passive ftp opens the port   
   > for the transfer, I would expect (and those in comp.protocols.tcp-ip   
   > will note if I am wrong) that it should set all four, such that it   
   > would not fail if another connection was open on 5004.   
      
   With the exception that if you open a port for listening, you only have   
   the local address and port. And so, no other local uses of that port can   
   be allowed, no matter what remote end.   
      
   > It seems like a VMS bug to me, though.   
      
   Sounds like a bug in ftp. Either on the client side, if this is active   
   mode, or the server side, if this is passive mode.   
   In a way, I'd primarily suspect the server side and passive mode, since   
   you normally give a range of port numbers for the ftpd to use in passive   
   mode, while clients more or less always use more random port numbers   
   from the range of "free" ports for this use.   
      
   But whatever, the code should handle if a port is already in use and   
   can't be set up to listen to, and in that case try to grab another port.   
   This would seem to be the bug, in my eyes. Of course, I could be totally   
   up the tree here. :-)   
      
   	Johnny   
      
   --   
   Johnny Billquist                  || "I'm on a bus   
                                      ||  on a psychedelic trip   
   email: bqt@softjar.se             ||  Reading murder books   
   pdp is alive!                     ||  tryin' to stay hip" - B. Idol   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)