Snort on Linksys WRT54G Wireless Router Help

[BillyG]

I've sent you 2 other files with ping, one is tftp attempt during ping and the other is ping, tftp attempt and ping again...
I can't beleive it is dead, it wouldn't ping i suppose but again i'm not an expert ;)
i'll go on trying ! i've decided i wouldn't stop untill i succeed (yes i'm optimistic kind a guy) ;))

[Void Main]

I've sent you 2 other files with ping, one is tftp attempt during ping and the other is ping, tftp attempt and ping again...

Yep, I see the echo requests and responses then 5 tftp write requests and not a peep back, then more echo requests and responses.

I can't beleive it is dead, it wouldn't ping i suppose but again i'm not an expert ;)

I never used the term dead. Screwed was the term I used in #1 in my last post. :) It is possible that when shorted the tcp/ip stack gets loaded but something is preventing the tftp server from loading. This would exhibit the observed behavior. I do believe this scenerio is not as likely as the other 2 though.

If you had a second machine that you could sniff from on a hub with the first machine that would eliminate scenerio #2 (firewall blocking).

Scenerio #3 is very possible if you aren't really getting the pins shorted properly. You might also check very carefully that you haven't damaged the pins so that they are touching each other. Also, you might try just a plain nmap to see if any other ports are open. This might indicate whether it has booted all the way up:

# nmap 192.168.1.1

i'll go on trying ! i've decided i wouldn't stop untill i succeed (yes i'm optimistic kind a guy) ;))

I think if none of this gets you going and you really won't stop until you succeed then your next step would be building a serial console connection so you can actually see the boot messages while you boot it. You could see exactly why the tftp server isn't starting. Another easier option to try first might be to build the JTAG connection. I have never done either of these as I have never bricked a router bad enough to need to so I can't help much beyond this. There are several threads on how to do this on the openwrt.org forums and wiki.

[BillyG]

i've done the nmap it says :

Code: Select all

Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2006-02-05 16:21 CET
All 1672 scanned ports on 192.168.1.1 are: filtered

Nmap finished: 1 IP address (1 host up) scanned in 62.316 seconds


Why doesn't it say "open", sorry but what means "filtered" ?

[Void Main]

The only way a port shows open is if there is a service (program) that is bound to that port. For instance, when the tftpd program is running it binds to and opens UDP port 69. When sshd is running it binds to and opens TCP port 22, etc. "Filtered" means there is a firewall in the way and nmap can't tell whether the port is open or closed. See description here:

http://www.insecure.org/nmap/man/index. ... escription

Give me a minute and I'll short the pins on one of my routers and see if I get the same results.

EDIT: I get the same results:

Code: Select all

# nmap 192.168.1.1

Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2006-02-05 10:01 CST
All 1672 scanned ports on 192.168.1.1 are: filtered
MAC Address: 00:0C:41:xx:xx:xx (The Linksys Group)


So, to recap I can't see anything that you are doing wrong. As long as you are getting pings within a couple of seconds of plugging the power in and they continue without stopping then your router should be in the proper mode. If you are positive you are not filtering (firewall client) on your Mac then the only next step is a cable so you can actually see the console messages.

[BillyG]

So i'll go on trying... The JTAG trick seems a little bit over my knowledge but i may try in a few days...
Anyway, if i have some news, i'll let you know :)

Thx again Void :)

[BillyG]

SUCCESS !
Ok, this is stupid but if you don't know it you can try a long time like i did without result (at least for a European GS v4)

The fact is that every time i was rebooting the router, the first time i was trying to upload something it told me "code pattern incorrect" and then the following times, just the timeout. I searched on the net and found out that "code pattern incorrect" is when you don't have the good firmware. But mine was ok, the only thing was that it was not the original Linksys one !
So i dled it from linksys site and then it f... worked !!!

So again a success story but that was dumb !
;))
A last thx for Void because without the short i discovered on his page, i wouldn't have succeeded :))

[Void Main]

Good news! I even searched for that error but thought it was something specific to your client. I did think of a possible bad firmware, but why when you did the tcpdump did I not see any data transferred? Even if it was a bad firmware it would have had to be sent to the router before it could reject it. I did not see this in the sniff.

[BillyG]

No indeed the transfer never began, i always had the "code pattern incorrect" and then the timeout. Apparently (and i don't know how, maybe a header or something like that) but the router is able to detect something. Maybe does it act like this when the Flash is empty (i guess so otherwise it wouldn't be possible to upload something different than linksys FW).
And the question of the size is not the determinant factor here because i even tried some other small (<3Megs) FW with the same result...

[Void Main]

But there was never a response from the router so the error message had to come from your tftp client, not the router. It just doesn't make sense.

[BillyG]

hehe i'm unable to answer to that, i agree though, it doesn't make sense, but two clients with the same answer (The shell & Mactftp) would indicate it is not the client, but again, i really don't know ;))

[Void Main]

Oh well, you got it working so if anyone else runs into the same problem they'll know how to fix it. Thanks! Actually, now that I think about it. The capture you sent me must have been from the "timeout". That is exactly what I would expect with a timeout. If you had sniffed when you got that error code I probably would have spotted your problem.

[BillyG]

What i don't understand also is why the error was happening only at the first attempt after reboot, all the followings were timeouts !
But anyway, i knew i was close and i'm happy not to have quited :)
And as you say, the important is that we succeeded, and we know (more or less ;) why

[Void Main]

After a firmware is uploaded it automatically reboots. Maybe it does on an unsuccessful upload as well which would explain the behavior.

[Tux]

Original Post

Void, is this issue still open?

I'd be interested in helping. The reason being i'm looking to get an OpenWRT router setup myself (a WRTSL54GS if I can get one imported).
So, there are ulterior motives, but i'm here to help!

I have got Debian Etch (MIPS Little-endian) running under QEMU in preparation for the task.

[Void Main]

Wow, apparently I haven't been keeping up on the latest WRT happenings. How did I miss this little gem?!? I have 3 WRT54G and 1 WRT54GS boxes but a USB port would open up so many more possibilities! Has anyone booted Debian on one of these devices? I use OpenWRT on all my current WRTs. I wonder if it's possible to boot the device directly from USB or do you have to have your kernel and boot image on the internal flash? A thumbdrive with Debian installed would make a pretty cool little firewall box.

I don't currently run Snort on the WRT but it should work:
http://www.linux.com/article.pl?sid=06/03/20/2239256

The problem is Snort can be very resource intensive so I run it on another system to sniff the public side of my WRT firewall. I suppose if you just want minimal rules to sniff the wireless side it should be workable. It looks like people have it working with a remote MySQL database in that article. Maybe I will have to pick up one of these. Why wouldn't they offer these things where you live?