how-to block ads
|
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
Re: Looking for the Common Thread in router problems
hi biker  I'm not familiar with WallWatcher, I'm sure it's fine to use, what's important is that it can show you the pattern of requests, both incoming and outgoing, well before and well after the system hang. Some worms exist solely to create SYN storms on networks by sending a request that will force a response that is directed at another system, different from the originating one, that also attempts to force a response to a fourth party, and so on.... I'm sure the image most people get of an attack is a few computers sending a lot of data, but in reality, it does not go that way... it more like is many computers "saying" no other computers who then say "wasn't me." It actually takes a child-like imagination for this to really make sense, and that's why they work so well. Verizon has long since blocked port 80 requests [that's why my HTTPd runs on such a goofy port], but I fear that by now other ports are in the mix.
With respect to using a broadcast address on your log destination -- you might be surprised to know that when the LinkSys [or any other ethernet device] sends a broadcast every machine on the LAN will see it [it will also be sent over the air via the wireless interface], moreover every machine on your LAN (including the sending LinkSys if it is in full duplex on any port) will generate a hardware interrupt, to move that recieved packet into RAM from the NIC, each machine will also pass the packet up it's protocol stack looking for a LISTENING SNMP-trap port which will fail on every machine except the one running the logviewer app. The time this takes is very small and it's a performance issue solely. Now, if you used a static address and set the LS to send to the single address, the only machine on your LAN that would spend CPU on the log event would be the logviewer PC [assuming our LS boxes have a "real" internal switch [officially called a MAC layer bridge] and not a hub [I'd love to see the MAC address table]].
I'm just a bit anal about performance, that's all. | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
Thanks ChrisDAT. I agree, using .255 (the broadcast address) for my log client's address is wasting some cycles on my other machines. Since my home network is so small, I will probably go to static addresses for the whole thing to eliminate the overhead of DHCP (however small that overhead may be). I'll change the address of my log client at that time.
Here's a URL if you want to look at WallWatcher, a free log utility for Linksys "BEF" series devices [I have no association with WallWatcher].
»www.sonic.net/~sraaii/wallwatcher/Index.html
I'm familiar with SYN attacks. I don't think I am the object of a SYN attack (I'd be receiving a ton of SYNs if I were). I could be one of the many recipients of a packet with a spoofed source address (designed to cause a denial of service attack on the spoofed source address). As I mentioned before, some versions of the BEFW11S4 v4's firmware were vulnerable to the TARGA3 exploit (which is caused by a malformed packet). So it's possible that some script kiddie's packets are causing many Linksys boxes to hang. I would think that Linksys would test their firmware against the known exploits BEFORE releasing their code, but I know that they do not (because I reported a problem to Linksys when TARGA3 was causing my router with 1.45.7 to hang, they acknowledged that 1.45.7 was vulnerable, and recommended that I backlevel to 1.45.3 which they claim was not vulnerable).
We may never know the exact cause(s) of the router hanging problems, but if I may be so bold, I'd say that Linksys' lack of quality in their firmware is probably a major factor. Sigh!
Although totally off topic, I just can't help responding to Think Twice Speak True's post ...
"I'll have your spam. I love it. I'm having spam, spam, spam, spam, ........, baked beans, spam, spam, and spam."
From "The Complete Monty Python's Flying Circus - All the Words", Volume 2, page 27. (yep, a two volume set of ALL the words from ALL Flying Circus performances)! | |
peteWRT54G
join:2003-12-18
Huntsville, TX
| reply to dellsweig
If you want people to post their specs, I'd recommend you also ask them if they are on DSL or cable, and what brand/model DSL/Cable modem they're using. Or, in short, "how are you connecting to the internet? What does the cable plugged into your WAN link go to?" | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
|  reply to dellsweig
Stability...
is what we are all looking for. This is the common "problem" that is causing us to rack our brains here. Stability and Dynamic are not friends. In an environment that is always changing, stability cannot be achieved. You must have consistency to obtain any level of stability.
DHCP (Dynamic host Configuration Protocol): Is designed for an environment where machines are for the most part transient, and do not need a fixed identity. This is good for a novice, but bad for consistent performance. Any machines that recieve their IP via DHCP cannot have ports forwarded to them, and thus they cannot run applications that require open ports. That's a limitation. DHCP is intended for large-scale installations where maintaining hundreds of PC's via IP address can be overwhelming, moreover, the LinkSys DHCP is missing some important features that are used in the "big game" -- one that comes to mind is MAC address mapping, which allows admin to assign IP based on MAC address, a full DHCP implimentation (even the NT server one) creates a database that can actually "configure" the client PCs to some extent to a level that exceeds their IP identity -- This is where DHCP is da'bomb -- The WinNT DHCP can also interface with WINS and DNS to assign DNS names so that a system's full identity can be "set" from a common database. If you have a fixed set of machines, you don't need DHCP. On a side note, the reason why cable users have to "clone" MAC addresses is because cable providers use DHCP this way, this allows you to maintain a consistent IP, thus changing the cloned MAC can cause access to be denied, or a new address to be assigned.
I have a problem with UPnP for a similar reason... most likely because I don't really know how/why a winXP computer can interface with the LS such that it can control the router without being authenticated. On top of that, when you display the status, it appears to update very frequently, possibly interrogating the router to get updated data even when the status display is not being viewed. That appears to me to require some overhead, on the router and every UPnP enabled device on the LAN. The status only shows aggregate information which is totally useless... you need to know the current rate, or errors, or how about LOAD. It is more efficient to query the router dierctly. If you have a Wireless box, keep this in mind, lest a WarDriver can perform a "drive by" on your LS with uPnP enabled without a password.
When you make things "easy" or "convenient" they inherently become less secure... for wireless boxes, simply turning off SSID broadcast is a huge leap. Look at it this way, I configured the router, I assigned the SSID, I set the channel, etc. Is it that hard to tell my laptop to use the settings I created, or to assign an IP to it? When I do these things, I don't forget them, I create an identity for my network that I remember like my phone number... If I suspect foul play, I'll remember to change them on the two machines that it will effect, easy!
All of the "tweaks" that we find here attempt to achieve consistency... by manually setting MTU, TCP_WINDOW, etc... you are taking the "guesswork" out of that usually accompanies "automatic configuration" -- How many people "let windows determine" your swap file settings? -- you get better performance by setting something, like the amount of RAM you have, because then you save Windows from trying to "Guess" what you will do next. Consistent behavior is your goal.
If we suspect that router logic in the firmware is broken, or otherwise buggy, the LS can be configured such that the only function it performs is the routing function... Then we try to make it crash. You'll never find any "problem" if you cannot create the conditions under which the problem will manifest itself.
Someone mentioned on these boards that there may be a problem with the NAT table overflowing -- a table overflow will certainly cause a router to stop performing the NAT function, if not lockup altogether... That does not necessarily mean that the NAT function is buggy, why? Consider this... 4 machines, LS router, DHCP, a long lease, all running and having fun, there are servers on the internet, that are improperly configured, sometimes with long keepalive times, that cause connections to "linger" after data is transferred -- some are rediculous, in days ... so what happens, is you do stuff, all the while, your NAT table in your router is forced to keep these connections "hot" -- with DHCP "ON", the router may maintain these connections even after you tun off your PCs because the DHCP lease will not have expired. That would be a "Bug" in the DHCP logic. When the table gets full, the router will lock up -- when this happens depends on what (where, how long..) you did prior to that... It could happen while you're surfing, it could happen while you're asleep... the only way to clear the entries is by a router reset... we call this the ticking time bomb. If there was a way to mainpulate the NAT, or at least view it, I could say that this is or is not happening. If turn off DHCP and the problem gets better, but takes longer to occur, I could say that DHCP is a factor, but not the solution. I could also say that the LS NAT logic should not allow those kind of lingering connections, but it may be performing to "spec". There are a lot of bad people and bad machines out there, what do you do? Is there a way to "wipe" the NAT quickly... would a daily (or twice a day) "reset" disrupt my network more than a router lockup... you decide.
This is all to say I want consistency... whatever I have to do to acieve it, I will do. I'm also waiting for Cisco to kick in here, I'm sure we will all know when they do. | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
|  reply to dellsweig
Operating Range [Environmental Temp]
From the published docs for the BEFW11S4 and BEFSR41
Operating Temperature: 32F to 104F (same for both) -I read more than 107F outside the unit.
Storage Temp: -4F to 158F (ouch! - maybe backwards?)
BEFSRxx
Power: 9VAC, 1A (don't you rate watts for AC?, rectifier inside?)
BEFW11xx
Power: 5VDC, 2A (more like it!)
"The more you know... the more you know" | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
1 edit | reply to dellsweig
NAT info?
The LS .pdf doc for the BEFSR41 says:
"the user can have 253 unique addresses behind this single address provided by the ISP" (this must be the size of the MAC address table of the LAN Switch) -- this is why the mask can be set no "higher" than 255.255.255.xxx.
and it also says "the Router supports a maximum of 252 IP addresses." (The size of the ARP cache) -- save one for the router itself.
It also says, "Theoretically the router can establish 520 sessions at the same time." Not specific, but this MUST be the size of the NAT table.
more: Router memory Buffer: 512KB
The LS .pdf for the BEFW11S4 adds:
"How big is the memory buffer on the Router: 1Mb and 512KB flash" --- actually, I dont know what this means... (memory or buffer? - bad language)
I wouldn't sell the farm on this info, because it is not presented in the proper way, and vague at best. It's all I could find.
[Sorry for the cross post - How do you "ref" another post?] | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
Re: Looking for the Common Thread in router problems
ChrisDAT: thanks for all the info in your recent posts !!!
After having disabled UPnP, set DHCP lease to 32767, and disabled logging (all of which did not solve the stability problem), next I'll disable DHCP entirely and use static addresses. As you mentioned, eventually I'll work my way down to using the box as a vanilla router, or maybe just a vanilla hub, to achieve stability (but at that point there's a question of "truth in advertising" since Linksys calls the BEFW11S4 a router/switch/AP).
I am also filtering ports 135-139 and mapping 113 to a non-existent address (based upon intrusion tests from sites like Gibson Research and a few others). I could also try removing the filters and mapping, but I sincerely hope that the BEFW11S4 is capable of filtering a few ports without crashing several times per day .
Again, it comes down to "truth in advertising" from Linksys. If the box cannot handle DHCP, port filtering, port mapping, etc without crashing (because it is too underpowered), then perhaps Linksys should change the name of the product to "Wireless Broadband Door-stop". At least we would know what we're buying! Yep, I realize that $70 is cheap for a router/switch/AP, but it's expensive for a "door-stop" | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
on my "41" which works flawlessly,
I don't do DHCP,
no UPnP [until I "discovered" it, it was on],
a few port maps [UPnP forwarding - the name is wrong],
some forwarded ports,
no outbound filter [port or address],
no spoofed {cloned} MAC,
MTU at 1492,
"connect on demand max idle time" 00 min,
and just about all of the advanced switches disabled... the pass throughs, etc..
I use the LS LogViewer...
Router Mode: Gateway...
No AOL parental controls...
I allow pings ["Disable WAN access"]... When I turned it off (enable) I had some problems... Those diagnotsics like tracert and possibly negotiation may require that.
Never any lockups.
If you do turn everything off "for research puropses" and the thing still crashes, where do you go next?... Is the hardware junk? could the same firmware possibly work for some and not for others? The environment is the greatest variable here and how the units are being used. Are you a target of worm attacks? One thing that causes techs to lose their mind is that hardware never just dies... It starts complaining first, and it can complain for a long time before it finally says bye-bye. Replace the unit... believe me they're cheap, compared the their big brethren where you would have to go deeper x1000 on the cash. It is really possible that that the underlying hardware is soft, it can be helped by the firmware, but not fixed, and the electronics are too cheap to service. That's why LinkSys would rather replace a unit than promise you a fixed firmware, cause maybe they know they have a short life span. Getting the software "right" would certainly expose the weaknesses in the hardware. Short of that, I'm looking for a workaround.
hey biker! you are filtering 135-139 outbound... I suppose to prevent your PC from asking remote machines their Windows name [thus exposing your Windows name]... You really don't have to do that because they couldn't get in anyway unless you were forwarding the ports as well -- just a little tip, I don't think it hurts anything. For port 113... I would never let anything IN that doesn't belong, but that shouldn't cause any problem. In the Win services file that service is called #ident(?). One thing I must mention... Your switch will send that request to every port since it will not have a MAC address for the "dummy" IP in it's MAC address table to be recieved, but ignored by your PCs... I would watch the logs for this one and remove it if I didn't see any. | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
Special config?
There is one thing about my setup that is atypical: I have a real old 10BaseT hub between my LinkSys and the DSL router. I use it [wasting 22 ports] because connecting two devices like a router and bridge (DSL/Cable) modem directly to each other violates the 10BaseT spec., and because I have it. It is also not spec. to connect the PC directly to the modem... So, who am I to say?
What the hub does is allow each network interface to establish LINK independently. Without the hub, if you power off the router, the modem will think it has been disconnected from the LAN and do???? the other way around is also true. That's why you are usually instructed to keep the modem on always. I also suspect the collision avoidance cannot work properly without the hub... most modems only run half duplex over the ethernet port. The timing expects an intermediate repeater between two devices.
Does this cause "the" problem, I can't say... But it is why I asked for setups... Cable VS DSL... It's the "other things" that may have something to do with the problems. Even stuff that seems silly may be the key -- I've seen hardware choke when plugged into an improperly grounded or polarized AC outlet, even a two prong! Don't sleep on the simple stuff. In the business and industrial world, you spend the bucks to get these things right or you pay for it.
Ethernet/LAN hardware is far more sensitive to things like cabling, electricity, heat, etc.. than your TV, CD player, and even your PC... It operates with very low voltage, over very thin wires, at an extremely high frequency. It's a beautiful thing when it works right, and a nightmare when it doesn't. | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
Re: Looking for the Common Thread in router problems
Check out this post ...
»[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups
Maybe Linksys will get the firmware right on the more stable BEFW11S4 v3 ..... Naaaa, Linksys will probably just succeed in coming out with new firmware for the v3 that provides WPA but results in the box crashing every day  | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
Truth in Advertising...
That's a tough call biker -- It is "baiting" the general public (and the gurus) a bit to use key words and features that wind up being partially (or poorly) implimented in the firmware.
The things that are missing, both in the documetation/specifications and in the features/implimentation seem to be the result of trying to squeeze 10lbs. of meat into a 5lb. bag...
It's totally possible that LinkSys never intended for one to be able to use ALL of the features of the box concurrently. I actually doubt it can. Note, the same is true of your PC -- A machine that is set up to do one or two things really well [like game], will do so at the expense of other things being marginally functional. It's the nature of the beast.
When a SysAdmin is buying hardware, especially hardware that must integrate into a much larger system, the features and information that are lacking just won't do... It's almost like having a standard shift without a clutch -- the most important "glue" is missing -- I would not be surprised if some combinations of "features" can never be made stable because of limitations in BOTH the hardware and the firmware. This is one reason why an older version of the firmware can work better for some than for others. The squeaky wheel always gets the grease, but sometimes that can cause LinkSys to chase its tail with other issues that may actually make the product better overall. Sometimes fixing one thing, breaks another. When there are too many "issues" being sorted at the same time, it's like putting a pound of hamburger in a meat grinder and expecting to get a cow. Just can't happen. | |
dellsweig
Extreme Aerobatics
Premium,MVM
join:2003-12-10
Campbell Hall, NY
 ·Time Warner VOIP
·Vonage
 ·RoadRunner Cable
3 edits | reply to dellsweig
Re: Looking for the Common Thread in router problems
Check out this thread
Forums » Up and Running » Wireless Networking » Linksys and NetGear wireless routers.
I have also read about Motorola TA's (VoIp) when used as a router - locking up nightly...
I wish my ISP had a clue??
More info - DOES ANYONE KNOW WHAT THIS IS??
»www.linksys.com/support/cox/firmware.asp
I found this in
Forums » US Cable Support » Cox HSI » Linksys Wireless devices Arp Issues
More info from a post from someone representing themselves as an engineer for Cox Cable:
Linksys Wireless devices Arp Issues
We have had arp issues caused by Linksys wireless devices on our network which has affected a lot of the modems on the network. Please upgrade to the latest firmware for these wireless devices especially for the BEFW11S4v4 wireless router by going to the linksys website »www.linksys.com/support/cox/firmware.asp
Thanks. | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
Folks ... RonS is not having the hang problem with his BEFW11S4 v4 running firmware 1.50. He has made a copy of his configuration available. See his post ...
»[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups
Here is a post with a comparison of my config to Ron's ...
»[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups
Any comments would be appreciated. | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
There is one item missing from both the RonS config and your post biker...
I have an "11S4v4" w/FW 1.50, and, in the Internet connection settings I have radio buttons for
(x) Connect on demand: Max Idle Time: [0] min.
(_) Keep Alive: Redial Period: [20] sec.
Somewhere, I read that if you want to stay online all the time, you should use the connect on demand with a max idle time of 0 seconds... Sometimes the keepalive will be rejected by the ISP and cause them to drop the connection with keepalive set. This is also the setting I use on my BEFSR41 that is also bulletproof.
What's strange is, in RonS's hack of the LS config menus, the radio buttons do not appear? My connection type is PPPoE [DSL]. | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
ChrisDAT: I also do not have radio buttons for
( ) Connect on demand: Max Idle Time:
( ) Keep Alive: Redial Period:
But I too am not using PPPoE.
Could be that the above radio buttons only become visible if one enables PPPoE. | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
| reply to dellsweig
Internet connection type? That could be important... I would guess that PPPoE is used for DSL -- Does anyone use/need PPPoE for cable? -- Maybe run this by RonS?
[Obtain IP Autimatically] -- Means DHCP? -- I wonder if there is a way to determine what the lease time would be on that -- a DHCP "client" is supposed to attempt to renew its IP at 50% of the lease time, I also wonder if some ISPs get silly with the lease time, either going really long or really short ... you could figure it out by connecting a PC directly to the modem [or, plug the modem into a LAN port] and checking lease status in the reg. (there are probably other ways, that's the fastest for me).
Maybe not an issue, maybe important. Does anyone think that some ISPs may know about the MAC clone thing and want to do something about it? How much do you save [they lose] per month by connection sharing? | |
big greg
Premium,MVM,Ex-Mod 2005-6
join:2003-10-11
Boston, MA
clubs: 
1 edit | reply to dellsweig
Getting back to the "common thread" theme...
BEFSW11S4 V4 (1.50) Freezes about every 9-12 hours. Other versions froze every 2-3 days.
Clients: 2-3 wireless W2K (wired clients removed due to hangs). One client is running a webcam 24x7, the others are general web/email use.
Connection type: static IP
PnP: off
WEP: on, 128 bit
WPA: off
Log: off
MTU: disable (1500)
NAT: enable
Local DHCP server: enable
Client lease time: 0 (1 day)
SSID: broadcast disabled
Channel: 11
Port Forwarding: No
Filters: none
Block anon wan requests: enabled
Filter multicast: disabled
Location: sits in a cool spot box is never warm when I power cycle it.
While I started out with pretty good results I have more recently found the thing hanging. | |
RonS
Madm0nke
Premium
join:2000-06-19
Dayton, OH
| reply to ChrisDAT
said by ChrisDAT  :
Internet connection type? That could be important... I would guess that PPPoE is used for DSL -- Does anyone use/need PPPoE for cable? -- Maybe run this by RonS?
I am connected using a cable modem and cable doesn't require PPPoE. I switched the router over to PPPoE and the radio buttons show up. Cable doesn't need the keep alive and connection on demand because once the cable modem syncs with the signal it stays that way until I turn the modem off (Or there is a problem) I remember when I had DSL and a BEFSR41 I had to turn both those on and set it to the default times.
My BEFSW11S4 v4 with 1.50 is still up and running (Since Jan 1st) with no problems. This weekend I am hoping to order a wireless card for the laptop. Then I will turn WEP on and run it at 128Bit encryption and filter it so only my MAC address can connect. Hopefully there will still be no problems.
--
3 out of 4 people make up 75% of the population. | |
ChrisDAT
Google Keyword Compsysnyc
join:2002-02-26
Hollis, NY
2 edits |  reply to dellsweig
One thing I'd like to be able to monitor [SNMP] is the rate that worms and other traffic "hits" the router during different times of the day. The LinkSys "log" only displays the initial TCP SYN request that is made upon the router's IP (and hopefully dropped by the firewall), it does not show UDP packets that may arrive at your front door (in a flood, I might add), nor does it give any indication of the rate that outboud data is being sent from inside your LAN.
This may be important, because too many complaints start with
"everything was fine until a couple of days ago"
What I suspect is that worm traffic is increasing in both volume and rate as more people get online and more people upgrade to broadband, increasing both parameters and wreaking havoc on routers that are not capable of handling these extremely sophisticated "denial of service" attacks.
Most internet users do not have a firewall/NAT deal (they do not yet know the beauty that is LinkSys), so the majority of these attacks are "absorbed" and most likely propagated, by the unprotected machines, creating an escalating ping-pong effect that the LinkSys boxes were never designed to handle (how fast can you "drop" data). I would guess their inbound packet buffer is far smaller than their outbound buffer, since it sits on a much narrower "pipe" than the hungry PCs on its LAN side.
Why NOW? Christmas, New Machines, New Users, Military Overseas, etc... Internet traffic always rises after the holidays, and "tapers off" around the end of February, every year. I wonder how many posts we will see on this board about these same issues in March... This thread may be a dead horse by then (I don't think so).
If I'm correct, however, what do you do NOW? How do I prevent random worms from finding my LinkSys, and locking it up? I'm sure that what's happening on the inside is not the issue because I'm sleeping, or making breakfast, or in the head -- but, sometimes, even while I'm trying to download that Paris Hilton video, that darn piece of LS locks up! Everything was fine for 10 years, and it just started happening.
That's a lot of problems, but it is the most common "set" of circumstances I've heard here, and it crosses all LinkSys models, wired and wireless. Also, the problem ALWAYS goes away if the user takes the LS out of the picture, by connecting the PC directly to the Cable/DSL modem. We'll never know if buying another brand is a "fix" unless we followed the "turncoats" to the other brand's thread and found 'em singin' the same tune over there. A Firmware upgrade seems to help and everyone's happy, but alas, they always come back.
Is that a good symptom summary?
What's so different about a LinkSys on the 'net and a bare naked PC on the 'net? The real kicker here is that some of us (me included) have NEVER seen these symptoms. This was my first Christmas "rush," I've owned a LS since Feb. 2003 and its performance has been everything I expect it to be. Am I lucky? Is it my ISP (who found it necessary to block all incoming port 80 requests, not to prevent me from running a web server, but to possibly save its internal network from being overwhelmed by the forementioned worms)?
The worms keep coming up in my mind, because before Verizon took such drastic measures, my exposed, always on, pre LinkSys protected, WinNT4sp4, WinPoEt-running PC server, would lose its connection far more frequently than it does today... I've been using DSL since 2000, and the "service" has certainly improved over time.
I would be interested in knowing how many of us (especially those with "the problem") have port 80 blocked on the ISP level, how many don't, and If you don't, how many port 80 "hits" your LinkSys is fending off.
I guarantee, if your ISP is not blocking port 80, you'll certainly know it by simply looking at the log. Hint - Use the LogViewer app, because it is seriously tedious refreshing the windows on the LS console and the logviewer adds important information like the time. Just leave the PC, the "log", and the light on, and go to bed, work, school....
Let's see what happens... We can get to the bottom of this if everyone steps up -- don't sleep on this issue, if nothing else it can be ruled out (and I'll slither away to Alaska somewhere).:)
edit:
I just have to add this -- If you think this sounds far-fetched, you probably wouldn't believe that me and several other gurus spent two days working this issue with a user on the Verizon "group therapy" board here at DSLR who had his phone line (before the splitter) plugged into one of those surge protectors with a phone jack. After tweaking and reinstalling everything under the sun, when he 86'd the surge box, a new day dawned. Strangely, he got this brilliant "tech tip" from a Verizon rep. over the phone. Go figure [I'm kinda ashamed to show my Avatar there now!] | |
biker45
join:2003-10-18
Erie, CO
| reply to dellsweig
I cannot believe it ... I just finished writing a post, clicked spell check, and my LS hung ... the post was lost. I think the box has become conscious ... it knows when I am talking about it.
Here's the data that ChrisDAT asked for ...
In the last four days (24 hr periods), my BEFW11S4 v4 running 1.50 has hung four times. 13:02, 10:40, 02:39, and 01:09 (no real consistency in the times of the hangs). I had between 17 and 23 unsolicited packets for 80 during each of the 24 hr periods (not a large number for a 24 hour period).
When running 1.45.7, and doing intrusion tests from pcflank, I found that the TARGA3 exploit would always hang the router. I reported this to LS. They stated that it was a known problem and for me to go back to 1.45.3. Instead, I waited for 1.50 and tried TARGA3 again. In my case, TARGA3 did not hang my router (running 1.50), but others have reported that TARGA3 does hang their router with 1.50. It does not take a lot of packets to cause the a hang, one malformed packet (such as the TARGA3 exploit) can do it. With so few unsolicited packets for port 80, I just cannot say that I am seeing evidence of an attack just before my router hangs.
As a software developer, I know how I'd solve this problem. I'd write a debug version of the firmware that traced every significant event and write the trace data to the log. Then, I'd ask for volunteers (with plenty of space on their hard drives) to run the debug version til their router hangs, and send me the log. It would only take a few logs, cold pizza, and some coffee to work through the logs and find the bug (er I mean cause of the hang).
But as someone has previously mentioned, Linksys will not do this because it would be costly (i.e., take staff time). They already have market share and a parent firm (Cisco) with deep pockets, so good support is not as important as it used to be. If I wasn't so stubborn and wanted to see this problem through to the end, I'd become one of those "turncoats" and replace my Linksys with a DLink (or some other router that is more stable). I just do not think Linksys is going to solve this problem. They are going to put their resources into the 802.11g product line, and the old BEFW11S4 will die a slow (and unsupported) death. I am thankful (and very surprised) that they actually provided firmware for the BEFW11S4 that supports WPA (but when I enabled WPA on my BEFW11S4, I found out that my wireless adapter (WUSB11 v2.8) does not support WPA, even though Linksys says it does).
Sorry for the digression, the topic is common router problems. I have tried just about every configuration change I can think of to stop the random hangs. My log does not show any evidence of an attack (but the log does not show all events). I think ChrisDAT is correct, the problem may not be in the router's configuration, but may be caused by a flaw in the firmware (that results in a hang when a specific packet is received). Without tracing all events in the router, I'm just not sure how we can find the true cause of this problem. | |
|
