07/23/08
IPCop 1.4.21 came out right on the heels of 1.4.20. Since it is a minor update,
the IPCop 1.4.21 update will work just fine in Raqcop 1.4.20. Of course, if you
are doing a fresh install, the flash images, install cdrom and vmdk image are
1.4.21. 

07/22/08
Raqcop 1.4.20 is here. It refines the lcd verbosity during boot and has better
fsck management as far as being more automated and not needing user
intervention. Also we now have CF install images that are gzipped in the
raqcop-flash-image-install folder. Same credentials. Kernel cleanups in addition
to the IPCop 1.4.20 kernel update to 2.4.36 is here as well, we only need to
support two ide drivers embedded in the kernel between the Gen III (3000 series)
and Raq 550 which is one of the two Gen V (5000 series) units. Removed the
keyboard and floppy drivers since we don't have these to load drivers for
anyway. This in no way affects your ability to use usb floppy drives. Tom
'wintermute' Eichstaedt's Sysinfo245 is part of this now as it is very useful.
This release will also support and run on the extremely noisy Raq550 with
limited LCD support thus far. I deliberately do not support the Raq XTR since it
is huge, noisy, has four hot swap drive bays and should be used to make a server
with, not a firewall appliance. More details are in the respective folders. 



06/11/08
Of course the latest stable 1.4.18 build has quite a few improvements in the
area of lcd usefulness, it displays programs and services as the machine boots
as well as landing on a bandwidth meter. The lcd program is self contained in a
single perl file /usr/local/sbin/lcd and you may want to edit the bandwidth
settings for your connection as well as the device to monitor. I set it at
100mbs and on eth0, you may want to change it to your red device and up and down
speed in kilobits per second of your isp. WinSCP with the built in editor works
great for this as well as the built in nano editor via command line.

02/25/08
The latest CVS build uses a single driverless Perl lcd script as an LCD Program
rather than all the cruft of the dated Cobalt Panel utilities. This needs work
as well but it's all in one file, not 30 files. Had been experimenting with
LCDproc as well but it needs a better character map to keep unicode from
occasionally garbaging the lcd display which is ascii, otherwise LCDproc is a
nice candidate.

12/02/07
IPCop 1.4.18 is stable now so I built a version for us here and uploaded the
appropriate images for either a VMWare install or WinImage direct image ready to
be used and booted from install. Even as the front panel buttons are still
inactive when IPCop is up and running, the LCD displays the hostname and ip
address. The underlying IPCop is the stable version so it can be used full time.
The raqcop-1.4.18-build-tree folder is nothing more than an already modified
build tree to allow one to build their own images and play with or further
improve what I have done so far. Basically, make.sh prefetch, make.sh
gettoolchain and make.sh build and it will build for you no problem. If using a
64 bit build host, simply open a 32 bit terminal and go to the build tree
provided you have some 32 bit compatibility libraries installed. The toolchain,
once in your cache folder that contains all the sources used to build, basically
takes care of stage1 in the build process so you don't rely on the gcc versions
of the build host. Once you have compiled the first go around, the ccache will
speed up further builds. On a Dual Core Athlon 64 3800+ machine running openSuSE
10.3 64 bit, it takes me just over an hour to build now. We have 1.4.18 for
Cobalts before the masses even have the generic 386 version! BTW, do not use the
e100new driver. It really isn't that good on the 2.4 kernel and locks up. This
is not a Cobalt issue necessarily. The e100 that is used when you boot up is the
actual 2.4.34 kernel included version and as such it works with the kernel just
fine.

11/26/07
I have managed to patch the e100 drivers, both the kernel one and the 3.5.17
version which is built as e100new.o.gz by the IPCop dev team for the soon to be
IPCop 1.4.18 so both drivers can coexist. For some reason, when hooking a floppy
to my test Raq4i and doing a backup, it sets the driver for green as e100. To
make life easier for all of us and since the kernel devs keep threatening to
remove the eepro100 driver which is pretty old by now and not included in a
default ipcop compile anyway, I managed to patch both the kernel and the 3.5.17
version of the e100 drivers to ignore the checksum error which is quite normal
for the 82559ER chips used in many devices like the Cobalt so theoretically, if
one installs either to VMWare and uses the floppy image to restore default
settings and passwords I set up or uses Winimage to restore from the dynamically
expanding VMWare image I uploaded, it should boot and have network access on
first boot with ssh enabled. The e100new.o.gz can be edited in to the ethernet
settings file for next boot. Using an addon called sysinfo, the built in
ethernet ports actually show the true status such as full duplex and 100base.
The eepro100 drivers didn't really show much info about itself and the e100
kernel driver, isn't very self telling either. None of this shows on the default
network status page. I only assumed the other two drivers connected at 100base
since my switch showed that. The new e100new.o.gz shows up nicely in the system
information dropdown if added to ipcop.  

I now have the Cobalt-ized ipcop installation cd to be completely self contained
thus eliminating all the extra steps to prepare a 20 gig Seagate standard Cobalt
HD for plugging back into the Cobalt and booting up.

For people who have access to a Windows machine, Winimage which I included in
the WinImage_Install directory, now allows one to restore a dynamically
expanding or fixed image VMware image to a physical disk, last version only did
fixed sizes unless it was in WinImage format. The improvements since the last
version are phenomenal. WinImage will also convert a dynamically expanding disk
image (considerably smaller for an IPCop install) to a fixed sized image and
will convert between a VMWare image (VMDK) and a WinImage VHD image. You now
only need to create a fixed size image if using Linux and the dd command to
write the image to the 20GB hard drive, I'll look for a way to install/expand
the dynamic image in Linux, I'm sure there is a way by a single command line. I
have included a default dynamic VMWare HD image which also has the default
passwords I set up, turns out that the VMWare dynamic image is much smaller than
a dynamic WinImage image and the program can image from both types, this makes
it less painful to upload here. It's all in the VMWare_Install folder.
 
I now put the extra fluff in the extras folder, mainly lcd sources and binaries
from various places that I used in the learning process thus far.


Dave Studeman