--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=us-ascii

On Tue, Jun 22, 1999 at 11:07:29AM +0200, bouyer@asim.lip6.fr wrote:
> >Description:
> 	
> 	This box is my router. It does some NAT + ftp proxy.
> 	Tonigth it paniced with "panic: m_copydata". The stack trace
> 	is:
> (gdb) where
> #0  0xf012a4c5 in m_copypacket (m=0xf6a52c3c, how=-156947408)
>     at ../../../../kern/uipc_mbuf.c:401
> 	#1  0xf017dae7 in cpu_reboot (howto=256, bootstr=0x0)
>     at ../../../../arch/i386/i386/machdep.c:1350
> #2  0xf011e8b8 in log (can not access 0xfffffffc, invalid translation (invalid PDE)
> can not access 0xfffffffc, invalid translation (invalid PDE)
> can not access 0xfffffffc, invalid translation (invalid PDE)
> can not access 0xfffffffc, invalid translation (invalid PDE)
> level=-267213627, 
>     fmt=0xfffffffc <Address 0xfffffffc out of bounds>)
>     at ../../../../kern/subr_prf.c:212
> #3  0xf012a502 in m_copydata (m=0xf0401328, off=60, len=52, cp=0xf6a52cfc "")
>     at ../../../../kern/uipc_mbuf.c:420
> #4  0xf015ad05 in ippr_ftp_pasvmsg (fin=0xf6a52de4, ip=0xf61bc810, 
>     tcp=0xf61bc824, nat=0xf043f800) at ../../../../netinet/ip_ftp_pxy.c:282
> #5  0xf015ad59 in ippr_ftp_in (fin=0xf6a52de4, ip=0xf61bc810, aps=0xf043d200, 
>     nat=0xf043f800) at ../../../../netinet/ip_ftp_pxy.c:423
> #6  0xf015afa4 in ap_check (ip=0xf61bc810, fin=0xf6a52de4, nat=0xf043f800)
>     at ../../../../netinet/ip_proxy.c:227
> #7  0xf0159a04 in ip_natin (ip=0xf61bc810, hlen=20, fin=0xf6a52de4)
>     at ../../../../netinet/ip_nat.c:1230
> #8  0xf0157b7b in fr_check (ip=0xf61bc810, hlen=20, ifp=0xf038c030, out=0, 
>     mp=0xf6a52e64) at ../../../../netinet/fil.c:672
> #9  0xf01499ba in ipintr () at ../../../../netinet/ip_input.c:399
> 
> 	Note the "invalid translation (invalid PDE)" messages.
> 
> (gdb) up
> #3  0xf012a502 in m_copydata (m=0xf0401328, off=60, len=52, cp=0xf6a52cfc "")
>     at ../../../../kern/uipc_mbuf.c:420
> 420                             panic("m_copydata");

Ok, I have some more news about this. I spent some time examinig a core
dump. Here's what happens:
The incoming packet comes from the outside. It is really an icmp paquet,
it's a message "host unreachable".
From what I can see someone from the inside did an ftp to
204.200.128.39 and 129.250.16.30 (probably a filtering
router, traceroute stops here too) anserwed with 'host unreachable'.
Then bad things start happening: it seems that this packet is mapped back
as being part of an active ftp proxy session and is forwarded to ippr_ftp_in,
where it his handled as a TCP message !
My guess is that at this point ippr_ftp_in should check for this, and
just forward the icmp message if this is and icmp message.

If I understood things properly, ippr_ftp_in() is supposed to return
the difference of size between the old and new mbuf - is this true ?

What do competent persons think of the patch below ?
I can't test it rigth now, but I will ASAP :)

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--

--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ipnat.diff"

Index: ip_ftp_pxy.c
===================================================================
RCS file: /cvsroot/syssrc/sys/netinet/ip_ftp_pxy.c,v
retrieving revision 1.11
diff -u -r1.11 ip_ftp_pxy.c
--- ip_ftp_pxy.c	1998/11/22 23:30:36	1.11
+++ ip_ftp_pxy.c	1999/08/04 17:51:04
@@ -420,5 +420,10 @@
 {
 	tcphdr_t *tcp = (tcphdr_t *)fin->fin_dp;
 
-	return ippr_ftp_pasvmsg(fin, ip, tcp, nat);
+	if (ip->ip_p == IPPROTO_ICMP) {
+		/* nothing to do, ip_natin() will do the job */
+		return 0;
+	} else {
+		return ippr_ftp_pasvmsg(fin, ip, tcp, nat);
+	}
 }

--xHFwDpU9dbj6ez1V--