Hi!

We are using -current at work as a general gateway/firewall machine.
Yesterday morning (08/21 around 08-10 EEST local time) I got the latest
source tree from anoncvs.netbsd.org and made a new kernel+build. Seemed
to be running OK for 7 hours or so. Then it crashed, someone rebooted it,
and pretty soon it went down again. Another reboot this morning, and
another crash after two hours. This time I got the following trace:
(copied from screen to paper, and from there into here; may include typos)

panic: m_copydata
Stopped at      cpu_Debugger+0x4:       leave
db> tr
cpu_Debugger (30,0,8,cb34492c,c0158fba) at cpu_Debugger+0x4
panic (c0317880,38,c0855218,c0855220,cb344978) at panic+0xa
m_copydata (c06fc700,124,38,c0855250,c0824680) at m_copydata+0x56
ippr_ftp_process (cb344a54,ca475010,c083ac00,c0855200,0) at ippr_ftp_process+0x154
ippr_ftp_out (cb344a54,ca475010,c0824680,c083ac00,b980) at ippr_ftp_out+0x1e
ippr_check (ca475010,cb344a54,c083ac00,0,ca475010) at ippr_check+0xcf
ip_natout (ca475010,cb344a54,ca475010,cb344af4,14) at ip_natout+0x4c4
fr_check (ca475010,14,c06aa030,1,cb344af4) at fr_check+0x672
fr_check_wrapper (0,cb344af4,c06aa030,2,c039015c) at fr_check_wrapper+0x69
pfil_run_hooks (c039f4c0,cb344b68,c06aa030,2,c06fc700) at pfil_run_hooks+0x45
ip_output (c06fc700,0,c039f4e4,1,0,c06fc700,0) at ip_output+0x682
ip_forward (c06fc700,0,c06fc700,c0101c10,4) at ip_forward+0x1f6
ip_input (c06fc700) at ip_input+0x3e0
ipintr (c0720010,cb340010,c0150010,c0390010,cb345008) at ipintr+0x64
Bad frame pointer: 0xcb344d7c


Here are some (possibly) relevant entries from the kernel config:

maxusers        32              # estimated number of users
options         I686_CPU
options         VM86            # virtual 8086 emulation
options         INSECURE        # disable kernel security levels
options         KTRACE          # system call tracing via ktrace(1)
options         LKM             # loadable kernel modules
options         DDB             # in-kernel debugger
options         GATEWAY         # packet forwarding
options         INET            # IP + ICMP + TCP + UDP

As it was, these options were off since they were marked expensive:

#options        DIAGNOSTIC      # expensive kernel consistency checks
#options        DEBUG           # expensive debugging checks/support

I guess I need to turn them on, though I'm not really sure what
to do with them...

As I mentioned, the machine has both ipfilter & ipnat running, with
the following lines in /etc/ipnat.conf:

#
# FTP Proxy
#
map ex0 0/0 -> a.b.c.d/32 proxy port ftp ftp/tcp
map ex1 0/0 -> 0/0 proxy port ftp ftp/tcp

ex0 is the external/outside interface, and ex1 is connected to the
internal network. The latter line is for our public ftp server.

I haven't been able to find any evidence suggesting that this could be
caused by some outside ftp client accessing our ftp server. Instead,
it probably is a broken ftp client inside our network. So far, we haven't
been able to reproduce this at will, but I'm confident we can provide
more similar events if anybody is willing to help analyze/fix this.

I am open to any suggestions on how to proceed with finding the exact
cause of this crash, and getting it fixed. Any help would be appreciated.

(Off oucrse, this could be a sign telling me to finally get rid of
FTP altogether ;-) After all, it should take more than a broken
(linux?) ftp client to put a NetBSD machine on its knees).


Arto Selonen

#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.