As you mention JNOS I presume you are not using the NET/ROM code built into the Linux kernel, but run JNOS as a user program on some tun/tap device. This means, this problem has very little to do with Linux. It is just a bug in the code, maybe combined with a property of the compiler. It sometimes happens that when you compile C code with a newer (or another) compiler than the original developer used, bugs surface that have always been present under the carpet. What happens when it crashes? Segmentation violation? That would indicate a corrupted pointer or -memory. When you type "ulimit -c unlimited" before you start the program you will get a core file (memory dump), and you can find out what is happening using gdb. Of course you need some insight in programming, but it could already help when you just print the stack backtrace (bt) and post it here. I have no personal experience with JNOS under Linux but it kind of surprises me that nowhere in the makefile or compile document there is mention of "64 bits". I would compile a program this age in 32-bit mode (my NETCHL also requires this), and that would be done by adding -m32 to the CFLAGS and installing the 32-bit development libraries first. But I leave it to others to comment if this is required. Unclean code could fail in the way you describe when compiled in 64-bit mode and work perfectly in 32-bit mode. Rob