Snort package on 64 doesn't work
-
@Ibor:
@Ibor:
I am running 2.0rc3 64bit
i'll have to start a vm for 2.0rc3… I tried 2.1 Dev last weekend and it worked for me
Running 2.0-RC3 (amd64) built on Sat Aug 6 23:18:46 EDT 2011. Checked "Send alerts to main System logs". I'm getting alerts within the Alerts tab as well as the main system logs.
So it is working on 2.0RC3..Good to know
BUT only after entering/executing the following code!! Without it, Snort will not work!
ln -s /usr/lib/libpcap.so /usr/lib/libpcap.so.1I wonder if its because of all the packages i have install, maybe one of them ran that command for me…
-
So basically snort on amd64 is still broken.
-
So basically snort on amd64 is still broken.
well if it runs after running a command or two, it wouldn't be broken then! Any why not just run i386? Unless your pumping heavy traffic thru the box and need a lot of memory, I see no benefit running AMD64.
I hate to say this but if your so bent out of shape for snort, then go install another fw distro and deal with their bloatware instead of whining on every snort thread that its not working. There are tickets opened on the issue and the dev's will get to them when they can. You can always donate money to help push it along if you like.
-
Big props to the "C" man on this. For the first time since starting to experiment with replacing our Draytek boxes/smartmonitor with pfsense, I have a working SNORT (2.8.6.1 pkg v. 2.0) interface.
Running the command from an SSH shell worked:```
ln -s /usr/lib/libpcap.so /usr/lib/libpcap.so.1I'm on a fresh install of 2.0-RC3 (amd64) built on Fri Aug 12 14:47:46 EDT 2011\. With SNORT running on both WAN interfaces and a pile of rules selectd, The Atom 330@1.6GHz is showing 15 to 20% usage, and the 2GB of RAM is 72% utilized So the next step is to get it working so that having "Block Offenders" enabled works. Right now, the service will not start with that box checked…which in my rookie understanding of SNORT means it's not really doing anything for me yet. I have two WAN connections, RE1 (DHCP) and RE2 (PPPOE), so would be happy to provide error logs. With "Block Offenders" checked, the system log returns: snort[37235]: FATAL ERROR: /usr/local/etc/snort/snort_32334_re1/snort.conf(351) Unknown output plugin: "alert_pf" -
Does "Block Offenders" in snort with with pfsense i386?
-
Does "Block Offenders" in snort with with pfsense i386?
it works on i386, just not on amd64
-
So basically snort on amd64 is still broken.
well if it runs after running a command or two, it wouldn't be broken then! Any why not just run i386? Unless your pumping heavy traffic thru the box and need a lot of memory, I see no benefit running AMD64.
I have i386 on one of the boxes. For the box I want Snort on.. i386 is of no use as it can detect about 3.5GB. It made sense earlier when I started with 2GB RAM. I have 4GB RAM now and will be bumping it to 8GB this week. Traffic is extremely heavy, non-stop 24/7.. serving over 30 users on 4 different VLANs. Current bandwidth is 30/4. Will be switching to FTTH 50/25 (or more) soon.
-
Is the code for the 64 bit build available somewhere? I've got a few quiet days this week and would like to see if I can sort the "block offenders" problem on that package.
-
With "Block Offenders" checked, the system log returns: snort[37235]: FATAL ERROR: /usr/local/etc/snort/snort_32334_re1/snort.conf(351) Unknown output plugin: "alert_pf"
Seeing this error myself on amd64 with "block offenders" checked.
snort[22035]: FATAL ERROR: /usr/local/etc/snort/snort_44446_re1/snort.conf(343) Unknown output plugin: "alert_pf"
-
I would have guessed that would have been easier for you guys to have someone else implement the solutions with your help :)
But its interesting to see what people go to when they have either pay or do the work themselves :)
Please, put the patches(if any) into the tickets on redmine. -
I'm trying to get my lot to buy some maintenance time but it's had work atm due to all the emergency services cut backs :(
-
So basically snort on amd64 is still broken.
well if it runs after running a command or two, it wouldn't be broken then! Any why not just run i386? Unless your pumping heavy traffic thru the box and need a lot of memory, I see no benefit running AMD64.
I have i386 on one of the boxes. For the box I want Snort on.. i386 is of no use as it can detect about 3.5GB. It made sense earlier when I started with 2GB RAM. I have 4GB RAM now and will be bumping it to 8GB this week. Traffic is extremely heavy, non-stop 24/7.. serving over 30 users on 4 different VLANs. Current bandwidth is 30/4. Will be switching to FTTH 50/25 (or more) soon.
What are your avg States and avg CPU? I'm running a Atom D510 with 4gigs of memory(3g is usable) 4 NICs, 2 VLANs and a couple of interfaces… I don't have a lot of users but I can can generated a lot of traffic to fill up my 50/5 pipe. I've been up to about 16000+ states out of 299000 available states and my memory still wasn't at 50%..
I take it these 30 users are doing a lot of P2P traffic?
-
The snort package for multiple interface would need some 'love' to work correctly in multi interfaces and not consume that many amounts of RAM.
The optimization would be to make snort memory usage constant and not be multiplied by the number of interfaces it is enabled on.But that is so far in the pipe of the snort package today since there are other things to fix today that…..
-
The weird part about this was that I had always felt that the push was a move to the amd64 platform, and the i386 would eventually get pushed aside (not now but later). I got this just from reading many of the posts from developers, but I guess I read it wrong. I had thought it made sense as in the future, the 386 limitations would stop it (4gb ram 10 years from now will seem very small).
Based on that reason alone, I have stuck with amd64 on 2.0. I was thinking all the packages would get ported to x64, but it seems snort is stuck right now on 386 and nobody is working on fixing amd64. So the decision will be to abandon amd64 and get snort or live without snort…
Decisions decisions... -
Same here. A common home network would be fine on i386 for years to come .. even on now the latest dual core atom CPU. But that's just common home network. For networks serving 10+ users on a constant bandwidth hog spree requiring the extra protection amd64 is the way to go. I know a lot would debate on the RAM usage for snort but RAM being so cheap these days .. it's a no brainer.
-
Those assumptions are fairly flawed, to be honest. i386 is the most stable, well-tested, and widely-used architecture. amd64 is new (to pfSense). Given that the i386 version works fine on amd64 hardware, there are some issues that haven't been addressed (and likely won't be for 2.0) just yet since the architecture is new. amd64 can address more memory but it also uses more kernel memory for the same tasks. It has its advantages, but also its drawbacks.
I highly doubt i386 will be going away or falling by the wayside any time soon. There are numerous platforms out there that still do not support amd64, such as embedded units like ALIX, and even if they did, wouldn't have enough RAM to really justify going that route.
In the case of snort, what it needs to move forward on amd64 is funding. There are lots of people talking about it not working, but few if any offering up resources to make it work.
-
Upgrading to snort package 2.9.0.5 does not resolve too. :-[
it fixes libexec error but still missing alert_pf.
Is this a missing compile arg?
Is there a 'wiki' or 'how to' or forum topic for building tgz packages for pfsense?
-
marcelloc,
The pfSense builder instructions on the dev wiki include a pre-made VM for VirtualBOX/ESX that has all you'd need.
-
In the case of snort, what it needs to move forward on amd64 is funding. There are lots of people talking about it not working, but few if any offering up resources to make it work.
To give the users an idea. How much funding/hours would be needed to get amd64 working again? I've donated in the past to both the pfSense project and to the original maintainer of Snort but I probably will again in the near future.
-
Not sure at the moment. The developer who has been working on it recently (Ermal) is going to be away for a bit, but he'd be the one to ask.
