Snort on Linksys WRT54G Wireless Router Help

Void Main · Post by **Void Main** » Sun Dec 07, 2003 10:47 am

As you may know from another thread I have a Linksys WRT54G wireless access point. It runs Linux and Linksys has put up the source code to the firmware. I was able to build my own firmware and install it on the AP with no problem. I also hacked it slightly to allow the upload of programs to it. Jim Buzbee has created a little page about running Snort on this device:
http://www.batbox.org/wrt54g.html

Only problem with his compile of Snort is it only does local logging. I want it to be able to log to a MySQL server just like I do with Snort on my other IDS systems. So I followed the instructions on Jim's page and got the cross compiler tools downloaded, built and installed (the LinkSys uses a MIPS processor). I downloaded the latest libpcap and snort source and successfully built Snort for the MIPS. I uploaded it and verified that it runs. Now I have pretty much what Jim offers, except I have the latest version.

Now I decided to try and get MySQL logging support built in so I downloaded the latest MySQL source but I can not get the configure script to generate a Makefile. I give it the appropriate --host=mips parameter and it knows it is supposed to cross compile targeting the MIPS but it errors out with this error message:

Code: Select all

checking "return type of sprintf"... configure: error: cannot run test program while cross compiling
make: *** No targets specified and no makefile found.  Stop.

I have created a script to build libpcap, mysql, and snort and here is a copy:
http://voidmain.is-a-geek.net/files/scr ... snort.mips

The script assumes you have the source tarballs for libpcap, mysql, and snort extracted under the /usr/src/wrt54g base directory. It also assumes you have the cross compiler tools installed in their default location of /opt/crosstool/mipsel-unknown-linux-gnu (I just built the mips tools following the directions on the page Jim links to for the cross compiler script).

If anyone has any help, ideas, or is interested in helping in this little project I would certainly appreciate it. If I am successful I would like to write a detailed HOWTO page for building a WIRELESS IDS system using this device and Snort. In fact I would like to build a custom firmware package and add to the LinkSys web interface configuration for Snort (rules, MySQL server, etc). I am reasonably sure it can be done and I believe I am very close. Just don't have a lot of cross compiling experience. Of course all of this depends on being able to build a snort binary small enough with MySQL support to not use up the limited resources available on the Linksys unit.

It appears to want to compile a piece of code to check how a return code is handled. Well, of course it can't run MIPS compiled code on an x86 so it fails. But I would think it should know this since it knows it is cross compiling. I'm sure if I keep digging I should be able to figure it out but it doesn't look like an easy one. I'm hoping I can just solve the problem with proper configure arguments or cache settings.

The full output of the MySQL ./configure:

Code: Select all

$ ./buildsnort.mips
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... ./config.guess: line 891: ./dummy-25506: cannot execute binary file
i686-pc-linux
checking host system type... mips-mips-elf
checking target system type... mips-mips-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for gawk... (cached) gawk
checking for mips-gcc... /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc --static
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc --static accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc --static... gcc3
checking for mips-g++... no
checking for mips-c++... no
checking for mips-gpp... no
checking for mips-aCC... no
checking for mips-CC... no
checking for mips-cxx... no
checking for mips-cc++... no
checking for mips-cl... no
checking for mips-FCC... no
checking for mips-KCC... no
checking for mips-RCC... no
checking for mips-xlC_r... no
checking for mips-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc --static -E
checking "C Compiler version"... "/opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc --static mipsel-unknown-linux-gnu-gcc (GCC) 3.2.3"
checking "C++ compiler version"... "g++ g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)"
checking for mips-ranlib... no
checking for ranlib... ranlib
checking for ld used by GCC... /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-ld -static
checking if the linker (/opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-ld -static) is GNU ld... yes
checking for /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-ld -static option to reload object files... -r
checking for BSD-compatible nm... nm
checking whether ln -s works... yes
checking how to recognise dependant libraries... unknown
checking command to parse nm output... ok
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for mips-ranlib... ranlib
checking for mips-strip... no
checking for strip... strip
checking for objdir... .libs
checking for /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc option to produce PIC... -fPIC
checking if /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc PIC flag -fPIC works... yes
checking if /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc static flag -static works... yes
checking if /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc supports -c -o file.o... yes
checking if /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc supports -c -o file.lo... yes
checking if /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-ld -static) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
creating libtool
checking for a BSD-compatible install... /usr/bin/install -c
checking for bison... bison -y
checking for pdftex... no
checking for tex... no
checking "return type of sprintf"... configure: error: cannot run test program while cross compiling
make: *** No targets specified and no makefile found.  Stop.

agent007 · Post by **agent007** » Mon Dec 08, 2003 1:26 pm

VoidMain,

Did u install the linux kernel on the AP? how much of space does that thing have? and whats the storage type?

Tux · Post by **Tux** » Mon Dec 08, 2003 2:22 pm

agent007 wrote:VoidMain,

Did u install the linux kernel on the AP? how much of space does that thing have? and whats the storage type?

Already runs linux, about 16mb?, of flash ram.

Void Main · Post by **Void Main** » Mon Dec 08, 2003 2:58 pm

Yeah, it comes out of the box running Linux (a stripped down kernel with only necessary modules). Tux is right that it has 16MB (total) memory. So when you upload a file not only does it take up x amount of that memory to run it, it also takes up y amount of memory to store the file. I believe the firmware itself is stored in another memory location though so once I get everything tested and working by the upload method I will just create a new firmware with the files included and the necessary changes to the startup scripts and web configuration pages.

I sent a message to Jim Buzbee yesterday about my problem and he actually replied right away (gotta love open source) stating he had similar problems with other source packages he was trying to cross compile. It comes down to hacking the configure script to make it pass all the tests. That is, hard code in the correct answers and comment out the actual tests. In the MySQL case I believe this is only part of the problem. Not only must you hack the configure script but you have to also cross compile any other library that MySQL normally includes in it's build process (cross compile the entire dependency tree). Ultimately I should have enough to compile and statically link a single snort binary, and hopefully that binary after stripping will be 2MB or less.

Void Main · Post by **Void Main** » Sat Dec 13, 2003 7:16 am

Well, I pulled a stupid and fried my WRT54G. I had been hacking and uploading firmware to it via the web interface and I finailly uploaded one that caused it not to boot up any longer. There is an nvram setting that you can set to cause a slight delay at boot time that listens for a firmware upload via tftp but I had never enabled it because I had seen posts that even if this nvram setting was not set you could still tftp the firmware to the box, just in a shorter time window.

Well, apparently that is only true for the WRT54G v1.0, I have v1.1 and I can't get the known good firmware uploaded to it via tftp. I haven't called LinkSys yet but there is another person who seems to be in the same boat I am (see bickford's post):

http://www.dslreports.com/forum/remark, ... 9~start=29

I am contemplating just purchasing another one but I was hoping to get more details about getting the one I have repaired.

Tux · Post by **Tux** » Sat Dec 13, 2003 10:38 am

Soory void, i've got no ideas. The best I can do is say i feel for you.

I did do some searching around but the WRT54G does not seem to have a proper hardware reset function (or hack) so I guess you're out of luck.

What are Linksys like for support?

Void Main · Post by **Void Main** » Sat Dec 13, 2003 10:47 am

Don't really know as I've never called them (I usually don't call for support for anything though). I figure I have 3 options. Option 1: I could be evil and tell them I was upgrading to their latest firmware and the power went off and now I can't boot in hopes they'll take it back and re-flash it. Option 2: I could tell them the truth and say I have been hacking the firmware and killed it and send me a bill for whatever it costs to reflash it. Option 3: Or I could just run down to Best Buy and pick up another one.

I'll probably go for option 3 immediately and then probably try for option 2 after a little more research. I actually have a second good one that I am using now (just for the weekend). We purchased one for security testing for work so I borrowed it for the weekend. They're less than 100 bucks so it's certainly not the end of the world. I've lost more than that in 10 minutes at the Black Jack table. :)

shuiend · Post by **shuiend** » Sat Dec 13, 2003 10:08 pm

How long have you had the router? You could just take it back to the store and say Linksys told you to take it back because it dosent work. I did that with my wireless bridge and compusa didnt ask any questions. Mentioned tech support at linksys said to and they were like ok.

Void Main · Post by **Void Main** » Sun Dec 14, 2003 8:28 am

I bought it mail order. I know a lot of people do that but I can't/won't.

gultig · Post by **gultig** » Sat Jan 31, 2004 3:31 am

Sorry to hear about your wrt54g. If your router is still a brick, you may get some help here: http://www.sveasoft.com/postt26.html
I have a v1.1 and bricked it a couple of times, but I've been able to recover both times now with the methods suggested.

good luck,

gultig

Void Main · Post by **Void Main** » Sat Jan 31, 2004 6:26 am

Hmmm, thank for the tip. I did buy a new one for $60 (a v2.0 model) but still can't seem to revive the old one (v1.1). I looked at the link you provided and tried everything I saw to try with no luck. If you could post step by step the incarnations you went through to get yours working that would be greatly appreciated!

Right now what I am getting when I power on my unit is a flashing power light. I also get a green light on "1" which indicates I have a link between my laptop and the linksys. I tried several things with and without setting a static route (arp -s *) including the regular Linux tftp client, the hacked tftp client that allows you to also send a password. Just a little while ago I downloaded the latest firmware with the autoinstaller (which of course made me boot into Win2k eeeewwwww) and nothing seems to work.

I think I have tried everything I have seen anywhere. I also just tried setting my ethernet interface to half duplex 10Mbps and that didn't help. The link to the LinkSys support document indicates that you should be able to ping the 192.168.1.1 address and I have *never* been able to do that since initially having the problem. Again, I would certainly appreciate if you could give me a step by step on how you did it. Thanks!

Jim · Post by **Jim** » Mon Apr 05, 2004 7:20 pm

Void Main wrote:Hmmm, thank for the tip. I did buy a new one for $60 (a v2.0 model) but still can't seem to revive the old one (v1.1). I looked at the link you provided and tried everything I saw to try with no luck. If you could post step by step the incarnations you went through to get yours working that would be greatly appreciated!

If you still have a brick, you can try what I did in the same situation. It's dangerous, but you don't have much to lose. Basically, you short out some flash pins while powering on the unit. This causes the initial CRC check to fail and the unit goes into a tftp wait state where you can then send a new flash. Only try this as a last resort. It can easily completly destroy the unit but it worked for me. For details, check out my post here :

http://seattlewireless.net/index.cgi/Li ... 99598609bd

Jim

Void Main · Post by **Void Main** » Mon Apr 05, 2004 7:35 pm

Wow! Thanks Jim, I will try it right now. Yep, it's still a brick, would be nice to have two working models so I can play again. :)

Jim · Post by **Jim** » Mon Apr 05, 2004 8:21 pm

Void Main wrote:Wow! Thanks Jim, I will try it right now. Yep, it's still a brick, would be nice to have two working models so I can play again.

Yep, that was the same thing I did. I bricked one unit, bought another and then several months later revived my dead unit. Now I can play without having to shut down my main Internet access.

Jim

Void Main · Post by **Void Main** » Mon Apr 05, 2004 8:26 pm

Did you happen to have a v1.1 router? They refer only to the v2 units. I'll still try it because I have nothing to lose but I am a little confused about which pins to cross. They say pin 15-16 near the LED end of the board. I don't see any pins labeled. Would it be possible to show me roughly the area in this picture?

http://seattlewireless.net/~mattw/photo ... _3425.html

What's odd is that picture is supposed to be a 1.1 board but mine is slightly different and it's a 1.1.

EDIT: There is a white painted box next to the BCM4306 chip that has two rows of pins (1-34, and 35-68). I'm thinking I need to short 15 and 16 on this one. I don't see this box in the picture but the picture shows what looks like a riser board with the BCM4306 chip on it just about where mine would be but the riser board is covering where the rows of pins are on mine. Mine does not have that riser board, the chip is right on the main board. The 2 rows of pins would be below the chip (half way between the chip and the edge of the board). Think I'm on the right track?