Beta 2.0build and addons

[Westlin]

Hey guys,

I came across a Symantec Velociraptor 1100 on eBay a couple weeks back and couldn't resist having a new firewall to tinker with.  I came across the Raqcop project and then a full blown project came about.   

Glad to see first that Dave is working on this project.  Great work!  That said I got comfortable with the stable build first and the tinker in me just couldn't help wanting to test out the 2.0 builds. 

I have it installed already and have the basic configs on it now on my bench.  Now I want to try and get snort and dansguardian on to this install.

I'm a old Penguin from 92 so I know my way around linux no question but I would like some pointers where to start with both of these addons as I've not really explored the .conf files to much yet.

Also wanted to know how much pain in the end is trying to get Snort and Dansguardian up and running on the beta.

Thanks,

MLA

PS: Oh btw guys I'm more than happy to help in the project if you got a need for me.

[Davesworld]

Any IPCop 2 addons that exist will work here. Most of them are listed on the German IPCop forum. There is a good reason why Snort was dropped from 2.0 and I do not run it at all with 1.4.21 since it is a waste of memory at 100MB per monitored interface, tons of false positives and no rule updates in two years for THAT version of Snort. 1.4.23 CVS has an updated version of Snort that will indeed download current rules and all but it was considered to drop it from the 1.4 branch as well. The pattern with Snort has always been:

False positives due to bogus rules. Bogus rules removed in the next update and new rules added, many of the new rules turn out to be bogus which will then be fixed in the next update and new rules added again, many of which will turn out to be bogus. The best thing you can do in IPCop is monitor your log summary for the previous day and notice that anything that was headed for the red (wan) interface never made it to your green (lan) interface meaning it was dropped. Snort as it exists in 1.4 is also not inline (thank God) but rather just informational only.

As far as DansGuardian, I'm sure there is or will be a version for IPCop 2. Keep in mind that some addons for 1.4 are a part of 2.0 such as System Information and Advanced Proxy and so forth.

The Cobalt friendlyIPCop 2 Beta builds are currently and unofficially maintained by me as it is yet to be determined if and how there will be an official Cobalt build in IPCop itself. I stick as closely as possible to the svn trunk but upload my diffs. The release manager for IPCop 2 has an interest in this and has added some Cobalt specific mods to the svn trunk where they do not interfere with normal PC versions such as the Cobalt section of System Information and moving the raid detection to NOT look in /proc for mdstat since the md driver has to be in the kernel image to be able to boot to raid from a Cobalt and mdstat will ALWAYS show in /proc, it was moved to /etc to look for a file that will ONLY exist in a raid install.

Nobody on the devel list has openly responded to the release manager's post regarding having a Cobalt build and whether to make a separate branch or not. I purposefully have not been calling the 2.0 Beta builds as Raqcop 2 beta until I know what will or will not take place. There WILL be a method to run IPCop 2 when it is released, on Cobalt hardware. The gui for 2.0 is very nice and has no rendering problems with anything khtml related such as Webkit. Interestingly, when opening 1.4 with IE8, it has the exact same rendering issues as anything khtml based. My personal opinion is that the 2.0 gui when running on a Cobalt, should be Cobalt blue, grey and white rather than black grey and white with IPCop for cobalts shown in the left part of the top bar where IPCop shows now. Just a thought.

[Westlin]

Good then.  I have been tinkering a little and did a few rewrites of the harddrive (my CF - IDE units are not here yet) and haven't had any luck with Snort.  I guess I'll drop the Snort part of my project for now.  I have come to this realization though that I really should get to  know the guts of the system better before tinkering with addons yet.  I want to try and make it as stable a config first before muckin' with it.  I've broken my install a couple times already as expected and just did rewrites of the image to the drive to start over.

Got a interesting new problem now though.  My internal interfaces stopped working on the latest image writes.  Haven't had time to really work on it but it's brought me to a grinding halt. 

[Davesworld]

They just stopped working out of the blue while the system was running?

[Westlin]

Upon writing the img file to the disk and booting the unit for the first time the interface doesn't respond to pings or will allow a management pc to open the web interface. Odd really considering I haven't changed my test ench setup at all. I'm going to try another write and see what happens.

[Westlin]

Just a note all. In my 3rd write of the image and same result. No internal interface available. Weird. Dave you know of anything that has this effect?  I'm a little dumbfounded at the moment. 

[Davesworld]

We're still talking about 2.0 Beta? If so, after a reimage, you must log in via the serial console and run depmod -a BEFORE running setup and setting up networking.

The only current way to avoid this in the future is to use a usb backup and use vmware or a donor pc to install directly to flash or hard drive. Actually any Virtual environment will work as long as the Virtual session can read either an iso image or a cd and boot from it as well as be able to use a usb flash drive to read from and restore. IPCop 2 beta uses strict udev settings to assign mac addresses to the proper interfaces and also name them exactly how you set them up. The udev files are saved when you back up to usb. Note that by backup we mean system settings only. The udev settings are the very reason I removed networking from initial setup during install. You really need to have it running on the actual machine in order to get networking to work properly. Setup will NOT detect the nics properly until you depmod the kernel modules.

With 1.4, networking only set the interfaces by driver module and address, not mac addresses so a premade image would install and work on bootup right away.

Having said all this, do your interfaces all work on 1.4?

[Westlin]

Yes we are still talking about the 2.0beta and yes I run depmod -a before running setup.  I am able to assign the interfaces and have tried both changing the IP address to something else and leaving it at the new default of 192.168.1.1.  Neither work oddly enough.

I did try going back to 1.4 again last night and the interfaces worked but I had the same lcd line 2 scrolling cursor issue that someone on here had.

I'm going to work with it a little more and see what I can figure out.

[Davesworld]

Is your green assigned to the nic you actually have connected to your lan and is it on the same subnet?

As far as 1.4.21, I'll take a look at the -3 build. The kernel config I used does not even have the lcd driver in it much less have "lcd twiddle" feature enabled. Only the rom kernel can be doing that. The "twiddle" is the knight rider effect on line 2. If you boot up and you have the twiddle, you cannot be running the os kernel (stage II in a Cobalt, rom kernel is stage I) as I mentioned the Stage II kernel has no lcd support since I do not use the old Cobalt lcd utilities.

[Westlin]

Well. Never got past the twiddle issue but was able to get past the beta2.0 and no activitating nic issue. I had an extra dual port 100 mb nic laying around and in an act of desperation I slapped that in and replaced the old card. Low and behold it finally gripped about the old card being gone. Had to assign the new card info and poof up it came this time. So I'm summising that it was a failed nic causing me all my grief.  Now back to work again.

Now I just have to wait for the CF card to IDE parts yo come in and I can put that part in and I'm ready to Rick and roll with this unit leading my home network.

Thanks for all the suggestions and pointers Dave.

[Westlin]

Ack. Sorry for the misspellings.  Blasted iPhone preemptive typing.   

[Davesworld]

Do all nics show on the System Information screen? They do not have to even have a driver loaded to show in the first section. I just can't imagine two failed 82559er chips in the same system. Common failures in Cobalts are due to leaky bulging capacitors and sometimes a bad flashrom chip. I have had instances where I did a complete cmos reset by holding the E button down while powering on and after reconfiguration (only needed for Raqcop 1.4.x), it worked fine after and still up to now. Fortunately, IPCop 2.0 uses hda1 for both so a cmos reset will default boot and root to hda1 on every Cobalt except the 550 which defaults to md0 and the non 550 units will boot with no configuration if using a single drive install. In Raid it's the reverse, a 550 defaults to md0 and console intervention is absolutely necessary to run a single drive on a 550. 

[Westlin]

Good tip.  Maybe I reset the CMOS by accident.  I have held the E down instead of S before just trying to get anything.  I need to remember that trick though just in case.

On a different note is there a fan speed control?  I'd like to keep this router in my home office with me but the fans are going to annoy me unless I can lower the RPMs a little.  

Got any ideas Dave?

Thanks again.

[Davesworld]

The fans were likely replaced at some point with 9500 rpm fans as those were the closest thing available to the originals at one time. This is no longer true. I know auto speed control would only be possible with a fan containing a thermistor on the 3000 series as the fans are on the back and pull warmed air through them. They are also only two wire. I have one test Raq4i running with a failed cpu fan that is running around 40 degrees C in about a 70 degree F room but the cover is off. There is discussion elsewhere in this forum with specific part numbers and such. The 550 is by far the biggest challenge to trade noise for heat.

Sadly the 550 is the most difficult to monitor the temp as well. It uses a different sensor chip than any of the 3000 series and even the sister XTR of the 5000 series has the same chip as the 3000 series only they use more channels of it. With the 2.10.3 rom in the 550, the sensors don't even work while in the rom kernel. I'm not entirely sure if the 550 ever had temp monitor working. Incidentally, the same chip monitiors core voltage and fan rpm in the 550 and those DO work. The 5000 series both have three wire tach fans. The temp part of the driver got broken a long time ago but only in the subsection for the 550's sensor chip. These are Cobalt drivers. It might make sense to use an in kernel thermal sensor driver for the 550 only or try to use the one in the Pentium III Coppermine.

[Westlin]

Dave,

Hope your holidays are going well.  I've been wrapped up in family matters and put my project on hold till then.  That said thanks for the info on the devices and fans.  I was the one that replaced the fans with the models you had here onsite.  I installed both new fans myself based on the sunon fans you have onsite here.  They are just still much louder than I would like for sitting less than 8 feet from me in my home office.  So I'd like to rev them down a few rpms to see if I can't find a good balance between fan noise and temperature control.

This is where my newbieness shows in that I believe when your referring to a Raq550 that is equivalant to my Velicoraptor 1100 unit?  I always thought it was closer to a Raq4  (at least at the guts level of the unit)  Outside of the ugly yellow faceplate on this unit I can't find any major difference between it and it's blue shielded breathern.