<x-flowed> This bug should have already fixed within ftp.proxy 1.1.6beta5. Do you have tested this release ?
At 10:10 11.12.2002 +0100, you wrote: >De : Miguel A. Argaqaraz2 . [mailto:[EMAIL PROTECTED] > > I think is a Bug, because I only get this error in only one case. > > > > What I have different from each network/configuration is that > > this special > > case has a Firewall-1 as a firewall. When he tries to connect > > I see "-ERR: received signal #13" in the log, and the > > connection is refused. > > > > I have tried the ftp.proxy with an public ip address in the > > client host, > > and trought a linux doing masquerading, using an active ftp > > session, and everything > > works flawlesly. > > > > What else do you need in order me to help you? > > > > Regards, > > Miguel. > >So, I strongly agree with you: it's a bug. >In fact it's both a ftp.proxy and a firewall-1 bug. >Firewall-1 can't do statefull ftp firewalling with ftp queries or replies >that cross the ip packets bounds (for instance, if the ftp client says "STOR >" in a packet and "/tmp/foo.bar" in the next one), in that case Firewall-1 >closes the connection in a way that send SIGPIPEs (#13) to ftp.proxy. >Ftp.proxy send some ftp queries and replies across ip packets bounds, >sending the while query but the final end of line sequence ("\r\n") in a >packet, and the eol sequence in the next packet. >As far as I know, this bug may not appear even with firewall-1, depending on >the operating system, of its ip options and of routers between the ftp.proxy >and the firewall-1 machines, since ip packets can be defragmented in a way >that fix the bug. > >This patch should help you: > >diff -Nur ../ftpproxy-1.1.5/src/ftp.c ./src/ftp.c >--- ../ftpproxy-1.1.5/src/ftp.c Mon Feb 4 18:11:21 2002 >+++ ./src/ftp.c Tue Aug 21 10:21:00 2001 >@@ -477,11 +477,20 @@ > > int cfputs(ftp_t *x, char *line) > { >+ char *buf; >+ int n; >+ > if (debug) > fprintf (stderr, ">>> CLI: %s\n", line); >- >- write(1, line, strlen(line)); >- write(1, "\r\n", 2); >+ >+ n = strlen(line); >+ buf = malloc(n+3); >+ strcpy(buf, line); >+ strcat(buf, "\r\n"); >+ write(1, buf, n+2); /* call write() once only, because some >firewalls >+ don't allow queries to continue accross >network >+ packets */ >+ free(buf); > > return (0); > } > > >Please tell us if ftp.proxy still doesn't work properly with this patch. > >-- >Greg. </x-flowed> From [EMAIL PROTECTED] Wed Dec 11 16:08:02 2002 X-Persona: <ftp.pproxy> Return-path: <[EMAIL PROTECTED]> Received: from mail.mitch.com.ar ((customer192-217.iplannetworks.net) [200.69.192.217]) by compucation.de ([213.185.64.44]) with SMTP (MDaemon.PRO.v6.5.2.R) for <[email protected]>; Wed, 11 Dec 2002 14:15:00 +0100 Message-ID: <[EMAIL PROTECTED]> From: "Miguel A. Argañaraz² ®" <[EMAIL PROTECTED]> To: "ftp.proxy" <[email protected]> Cc: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Subject: [general-l] -ERR: received signal #13 {04} Date: Wed, 11 Dec 2002 10:15:09 -0300 Organization: http://mitch.com.ar MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: found to be clean (Processed in 3.499245 secs) X-Lookup-Warning: SMTP connection lookup on 200.69.192.217 does not match 200.69.192.217 X-MDRcpt-To: [EMAIL PROTECTED] X-MDRemoteIP: 200.69.192.217 Sender: [EMAIL PROTECTED] X-Return-Path: [EMAIL PROTECTED] Precedence: bulk List-Unsubscribe: <mailto:[EMAIL PROTECTED]> X-MDMailing-List: [EMAIL PROTECTED] X-MDSend-Notifications-To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-MDaemon-Deliver-To: [email protected] X-Eudora2Unix: 3905-11-05T08:39:35Z converted I have tested this realease and it works successfully!! OK, I'll go 1.1.6beta5 Thanks for all, Regards, Mitch²® ----- Original Message ----- From: "Andreas Schoenberg" <[EMAIL PROTECTED]> > This bug should have already fixed within ftp.proxy 1.1.6beta5. Do you have > tested this release ? > > At 10:10 11.12.2002 +0100, you wrote: > >De : Miguel A. Argaqaraz2 . [mailto:[EMAIL PROTECTED] > > > I think is a Bug, because I only get this error in only one case. > > > > > > What I have different from each network/configuration is that > > > this special > > > case has a Firewall-1 as a firewall. When he tries to connect > > > I see "-ERR: received signal #13" in the log, and the > > > connection is refused. > > > > > > I have tried the ftp.proxy with an public ip address in the > > > client host, > > > and trought a linux doing masquerading, using an active ftp > > > session, and everything > > > works flawlesly. > > > > > > What else do you need in order me to help you? > > > > > > Regards, > > > Miguel. > > > >So, I strongly agree with you: it's a bug. > >In fact it's both a ftp.proxy and a firewall-1 bug. > >Firewall-1 can't do statefull ftp firewalling with ftp queries or replies > >that cross the ip packets bounds (for instance, if the ftp client says "STOR > >" in a packet and "/tmp/foo.bar" in the next one), in that case Firewall-1 > >closes the connection in a way that send SIGPIPEs (#13) to ftp.proxy. > >Ftp.proxy send some ftp queries and replies across ip packets bounds, > >sending the while query but the final end of line sequence ("\r\n") in a > >packet, and the eol sequence in the next packet. > >As far as I know, this bug may not appear even with firewall-1, depending on > >the operating system, of its ip options and of routers between the ftp.proxy > >and the firewall-1 machines, since ip packets can be defragmented in a way > >that fix the bug. > > > >This patch should help you: > > > >diff -Nur ../ftpproxy-1.1.5/src/ftp.c ./src/ftp.c > >--- ../ftpproxy-1.1.5/src/ftp.c Mon Feb 4 18:11:21 2002 > >+++ ./src/ftp.c Tue Aug 21 10:21:00 2001 > >@@ -477,11 +477,20 @@ > > > > int cfputs(ftp_t *x, char *line) > > { > >+ char *buf; > >+ int n; > >+ > > if (debug) > > fprintf (stderr, ">>> CLI: %s\n", line); > >- > >- write(1, line, strlen(line)); > >- write(1, "\r\n", 2); > >+ > >+ n = strlen(line); > >+ buf = malloc(n+3); > >+ strcpy(buf, line); > >+ strcat(buf, "\r\n"); > >+ write(1, buf, n+2); /* call write() once only, because some > >firewalls > >+ don't allow queries to continue accross > >network > >+ packets */ > >+ free(buf); > > > > return (0); > > } > > > > > >Please tell us if ftp.proxy still doesn't work properly with this patch. > > > >-- > >Greg. > >
