Subject: FW: debugging pasv ports usage

From: Roger Hanke <[email-masked]>
Date: Mon, 25 Jan 1999 18:32:49 -0500

Gregory and Bernhard,
 Finally got to the bottom of this by following Gregory's 
advice to add my own debug statement. While doing this
I compared my WUFTPD patched with Pedro Melo's pasv
port patch with the Beroftpd 1.2.3 I was trying to debug.

 Forgive me, if I get the players wrong at times, but here 
is my best guess on how the quite useful lines have all
dissappeared. Pedro had the 3 statements below in his
patch which all showed what passive port was being used:
  if (log_commands) syslog(LOG_DEBUG, "PASV trying %d",
pasv_addr.sin_port);
  if (log_commands) syslog(LOG_DEBUG, "PASV got %d",
pasv_addr.sin_port);
  reply(227, "entering Passive Mode (%d,%d,%d,%d,%d,%d)", 
UC(a[0]), UC(a[1]), UC(a[2]), UC(a[3]), UC(p[0]), UC(p[1]));

Apparently Gregory did not bother putting in the first two, figuring
the third was sufficient, when incorporating Pedros patch into
his code base. Next Bernhard did a lot of cleanup on -lLdv log/debug
options and took the debug statement out of the reply routine
that used to echo out each reply to the syslog when debugging was
turned on. So now with Beroftpd 1.2.3 even when -lLdv options
are all turned on I dont get any of the above statements written to
the syslog and therefore can get no info on what passive port the
daemon grabbed to satisfy the current client request. I just added
a statement similar to the first two lines just above where the 
3rd line call is made in order to get this debug capability back.
But was hoping I could convince you gentlemen that this is a
worthwhile piece of debugging information that you could add
back into your official versions so that I do not have to add this
line everytime I take a new release ;-)
	IMHO,
	Roger Hanke 

>-----Original Message-----
>From:	Roger Hanke 
>Sent:	Thursday, January 14, 1999 8:13 PM
>To:	'Gregory A. Lundberg'
>Cc:	'WUFTPD List'
>Subject:	debugging pasv ports usage
>
>Gregory,
> Thank you for your help with the new passive ports
>directive. So now I believe I have the correct range of
>ports specified to be used for pasv client commands.
>
> But with WUFTPD Beta 13 I had been using debug 
>mode and looking for the pasv command in the syslog
>to verify what port was actually being returned and that
>it really was in the valid range expected.
>Using the same exact system, and debug settings
>I can not get those debug statements showing up in
>the syslog using BeroFTPD 1.2.3.
>For instance below I show just a short sequence from 
>the syslog first showing just a logon to Beta 13 then a
>logon to BeroFTPD 1.2.3. Both of them are using the
>same command line options, just running on different
>ports on the same box: -adlLu007
>Even tried turning d to v option on command line for 
>BeroFTPD but still no debug statements.
>Finally added log commands to my ftpaccess files and
>this again produced more statements for both versions
>but the BeroFTPD just said PASV and did not show the
>port number like the Beta 13 did:
>
>Jan 14 20:09:44 hdpst01 ftpd[12370]: PASV
>Jan 14 20:09:44 hdpst01 ftpd[12370]: PASV
>Jan 14 20:09:44 hdpst01 ftpd[12370]: PASV trying 27828
>Jan 14 20:09:44 hdpst01 ftpd[12370]: PASV got 27828
>Jan 14 20:09:44 hdpst01 ftpd[12370]: <--- 227
>Jan 14 20:09:44 hdpst01 ftpd[12370]: Entering Passive Mode
>(135,25,216,12,108,180)
>                            
>
> So has anything changed in this area, in terms of
>getting debug statements out?
>	Thanx,
>	Roger Hanke
>
>Jan 14 19:55:18 hdpst01 ftpd[11882]: <--- 331
>Jan 14 19:55:18 hdpst01 ftpd[11882]: Password required for ew3ftp.
>Jan 14 19:55:21 hdpst01 ftpd[11882]: command: PASS password
>Jan 14 19:55:21 hdpst01 ftpd[11882]: <--- 230
>Jan 14 19:55:21 hdpst01 ftpd[11882]: User ew3ftp logged in.  Access
>restrictions apply.
>Jan 14 19:55:21 hdpst01 ftpd[11882]: FTP LOGIN FROM lynxhub
>[135.25.204.10], ew3ftp
>Jan 14 19:55:21 hdpst01 ftpd[11882]: FTP LOGIN FROM lynxhub
>[135.25.204.10], ew3ftp
>Jan 14 19:55:59 hdpst01 ftpd[11882]: command: QUIT
>Jan 14 19:55:59 hdpst01 ftpd[11882]: <--- 221
>Jan 14 19:55:59 hdpst01 ftpd[11882]: Goodbye.
>Jan 14 19:55:59 hdpst01 ftpd[11882]: FTP session closed
>Jan 14 19:55:59 hdpst01 ftpd[11882]: FTP session closed
>Jan 14 19:56:22 hdpst01 ftpd[11920]: VirtualFTP Connect to:
>135.25.216.12
>Jan 14 19:56:22 hdpst01 ftpd[11920]: VirtualFTP Connect to:
>135.25.216.12
>Jan 14 19:56:22 hdpst01 ftpd[11920]: VirtualFTP Connect to:
>135.25.216.12
>Jan 14 19:56:31 hdpst01 ftpd[11920]: FTP LOGIN FROM lynxhub
>[135.25.204.10], ew3ftp
>Jan 14 19:56:31 hdpst01 ftpd[11920]: FTP LOGIN FROM lynxhub
>[135.25.204.10], ew3ftp 
>---------------------------------------------------------------
> Roger A. Hanke         AT&T Web Site Services
> (732)576-5738          [email-masked]
> FAX (732)576-6041      http://lynxhub.att.com/~rah/
>---------------------------------------------------------------
>

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 25 Jan 1999 20:21:37 -0500 (EST)

On Mon, 25 Jan 1999, Roger Hanke wrote:

> Finally got to the bottom of this by following Gregory's advice to add
> my own debug statement. While doing this I compared my WUFTPD patched
> with Pedro Melo's pasv port patch with the Beroftpd 1.2.3 I was trying
> to debug.
> 
> Forgive me, if I get the players wrong at times, but here is my best
> guess on how the quite useful lines have all dissappeared. Pedro had
> the 3 statements below in his patch which all showed what passive port
> was being used:
> the third was sufficient, when incorporating Pedros patch into his
> code base. Next Bernhard did a lot of cleanup on -lLdv log/debug
> options and took the debug statement out of the reply routine that
> used to echo out each reply to the syslog when debugging was turned
> on. So now with Beroftpd 1.2.3 even when -lLdv options are all turned
> on I dont get any of the above statements written to the syslog and
> therefore can get no info on what passive port the daemon grabbed to
> satisfy the current client request. I just added a statement similar
> to the first two lines just above where the 3rd line call is made in
> order to get this debug capability back. But was hoping I could
> convince you gentlemen that this is a worthwhile piece of debugging
> information that you could add back into your official versions so
> that I do not have to add this line everytime I take a new release ;-)

Sounds like you got the morphology 'bout right.  There was one other
player involved but his work was directed solely getting the patches into
the VR version.  He needed the PASV stuff as badly as you do and prolly
just missed the debug stuff since the patches were quite old and had to be
hand-applied.  Plus he had a lot of other things which needed adding to
get the daemon to work with NAT as well.

If you can send over some diff's against either daemon, I'll take a look
at rolling you debugging messages back into the VR version.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195