<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">

<channel>
<title>Re: Looking for the Common Thread in router problems in Linksys</title>
<link>http://www.dslreports.com/forum/r8966168</link>
<description></description>
<language>en</language>
<pubDate>Sat, 28 Nov 2009 18:42:20 EDT</pubDate>
<lastBuildDate>Sat, 28 Nov 2009 18:42:20 EDT</lastBuildDate>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9762686</link>
<description><![CDATA[<A HREF="/useremail/u/856446"><b>Scott W</b></A> :  <BLOCKQUOTE><SMALL>said by  dellsweig <A HREF="/useremail/u/911537"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR><br>If there is a home security requirement - use MAC filtering - do't screw around with WPA...<br> <HR></BLOCKQUOTE><br><br>Mac's are easily spoofed. And unencrypted data can still be intercepted, whether the interceptor is on your network or not.  Yes, do use MAC filtering, but WITH, not in place of, encryption.<br><br>So far, I've had no problems using WPA on my WRT54G. I did have one computer that wanted to disconnect upon user logoff, but following the advice in the wrt54g disconnection thread about the "AuthMode" registry edit seems to have taken care of that.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9762686</guid>
<pubDate>Tue, 23 Mar 2004 20:56:47 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9762086</link>
<description><![CDATA[<A HREF="/useremail/u/972324"><b>cgray88</b></A> : Excellent signal... always.  Can't find any competing networks, and the AP is like 7 ft away.  My connection to the AP never drops.<br><br>This prob happens daily.  Net Connections box on my computer tells me I'm connected.  Run around the corner to the Linksys, and I am listed in the clients table.  Run back, ping 192.168.1.1... request timed out.  Look back at the Net Connctions box, and it will say something like "sent : 302 / recieved : 0"<br><br>Then I do a long reset (pwr down AP then modem, wait, pwr up modem, wait, pwr up AP) and all of a sudden, I'm surfing again... <br><br>I'm completely perplexed... I've tried everything to fix it.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9762086</guid>
<pubDate>Tue, 23 Mar 2004 20:03:24 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9760813</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> : I gave up and send my V4 to my girlfriend's apartment, where it has been running without errors for weeks.<br><br>Do you have good signal strength when your connection drops?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9760813</guid>
<pubDate>Tue, 23 Mar 2004 17:53:41 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9758980</link>
<description><![CDATA[<A HREF="/useremail/u/972324"><b>cgray88</b></A> : Looks like the commentary has come to a halt in this thread.  Is there anything to update???<br><br>I'm having nearly identical issues, with my BEFW11S4.  Differences are that mine is the Version 2, as opposed to the Version 4, and that when I lose my internet, it only drops on the those connected wirelessly.  The computers wired in continue to run smoothly.  Mine also does not appear to drop at any particular time, per se... it seems to only drop when my computer shuts down/restarts, or goes to sleep.  Otherwise, this thread is like 6 pages of exactly what I am going through...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9758980</guid>
<pubDate>Tue, 23 Mar 2004 15:01:44 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9482261</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : I, too, had the same lockup problems as mentioned here...  been scratching my head for 3 months (the router is at mom's house, who rarely uses the net but has been instructed to reset the router power plug when internet not found...).<br><br>First problematic router was a BEFW11S4 v4.  Locked up.  Returned it after a few days to Fry's, got a new v4.  Same thing.  Scratched my head.  I have set up five BEFW11S4's over the past 3 years; all are still running, and probably haven't even been rebooted (i realize now that is most likely because they aren't v4's!)<br><br>Back to the v4 in use now: It came loaded with the 1.45.7 firmware.  I upgraded to 1.50.  Still locked up.<br>I upgraded to 1.50.1, hoping that would solve the problem as it did for many...  Still locked up.<br><br>A couple days ago I found this forum and read that one of you had downgraded to 1.45.3.  I tried that last night and--voila!--the router is not locking up (at least not yet)!!  THANK YOU!<br><br>Hopefully this router will stay useable for more than a few hours with this old firmware!  When will the Linksys engineers fix this obvious problem??]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9482261</guid>
<pubDate>Mon, 23 Feb 2004 19:48:24 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9321240</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Get the new version  firmware 1.5.1 and it solved my lockups for good!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9321240</guid>
<pubDate>Sat, 07 Feb 2004 23:42:31 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9208866</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : <B>biker</B> -- I'm sure LinkSys knows which ones were "born to be wild" and which ones have the "right stuff" inside -- I will almost guarantee you, the one you get will make all your dreams come true. <br><br>[...and what's wrong with believing in Santa?:)]]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9208866</guid>
<pubDate>Tue, 27 Jan 2004 20:54:59 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9208544</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : <B>big greg: </B>Linksys did not say which model they will be sending. However, the Warranty Return process specifically asked for what model I had, so my guess is that I'll be receiving a v4.<br><br>I am not optimistic that the new unit will be any more reliable, but I keep reading posts by people who say their BEFW11S4 v4 is rock solid (so along with believing is Santa Claus, I'm believing that Linksys will have fully tested the replacement unit they send me and it will be rock solid). Then, I wake up from my dream :)<br><br><B>Chris DAT: </B>I'd like to think that Linksys will take my old unit and fully test it, but see paragraph above about my also believing in Santa Claus!!<br><br>I read on one of the forums here that it may be less costly to Linksys to replace these devices with no questions asked, than to waste their staff's time trying to talk the customer through diagnostic and debugging procedures (especially if the problem is caused by a hardware flaw or software bug that no amount of configuration changes by the end user could fix). Staff costs are much more expensive than hardware, so Linksys may just be willing to replace every BEFW11S4 v4 with no questions asked. Of course, if the replacement hardware also fails, then it starts to get expensive for Linksys. Maybe they just figure that people with the flawed devices will just give up and go away (after all, once Linksys has made the sale, they really don't care if we go away, and going away is less expensive for them than if we keep calling their Tech Support).<br><br>Based on FedEx tracking number, ETA for my new device is Wed (in the midst of a snow storm here on the East Coast). Maybe I'll see it Thurs or Friday. Wonder if I should collect guesses as to how long it will take for the replacement unit to fail (who me, skeptical)?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9208544</guid>
<pubDate>Tue, 27 Jan 2004 20:27:00 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9201915</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : <B>biker</B> -- it may say something if LinkSys is so willing to replace the unit -- and actually, it's a good idea as it will give LinkSys an opportuninty to examine the unit (if they're smart) -- at least if they care anything at all about improving the "rep" that is spreading fast about LinkSys hardware.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9201915</guid>
<pubDate>Tue, 27 Jan 2004 08:27:40 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router proble</title>
<link>http://www.dslreports.com/forum/remark,9201602</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> :  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> are you getting a V3 or another V4?  I seem to remember other people getting another V4 (the 12 volt version) but it did not solve their problems. <br><br>I couldn't make my V4 run here no matter what I did. Yesterday, I just took my V4/1.50 over to my girlfriend's place (cable modem, 1 wireless, 1 wired). I got her D-Link in return. <br><br>Maybe it will run just fine down there. I know the Dlink runs ok here but doesn't have the signal strength that the V4 had. <br><br>As soon as the V4 hangs, I'll let you know.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9201602</guid>
<pubDate>Tue, 27 Jan 2004 07:04:46 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9200582</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : My BEFW11S4 v4 (1.50 firmware) continued to hang even after I disconnected its cable modem connection, and disabled the wireless feature (eliminating stray incoming packets from the WAN link and stray wireless connections as the source of the problem).<br><br>I had previously reported these problems to Linksys via email to their Tech Support (only response I ever got was: "we're working on it").<br><br>I finally decided to wait on their support line to speak to someone. After being on hold for an hour, I got connected. I figured the technician would first insist that I go through all of the same configuration changes (I previously performed over the past several months) in order to attempt to resolve the problem while on the phone. <br><br>After a brief explanation of the make, model, problem, and the changes I performed while trying to solve the problem, the technician just told me to go to the Support page on the Linksys site, and request a Warranty Return (I bought my BEFW11S4 in October and it is still under warranty). I probably could have gone straight to the Warranty Return page on the Linksys site without first having to wait an hour on hold for Tech Support.<br><br>The Warranty Return process was straight-forward. I had to provide a credit card number, but as long as I return the old device within 5 days of receiving the new one, my card will not be charged. Three day shipping of the new device to me is free. I have to pay to return the old device :(<br><br>Of course, there's no guarantee that the new device will be any more reliable than my current one, but it's worth a try. I'll post here after I get the new device (delivery is scheduled for 1/29).<br><br>Has anyone returned their flawed BEFW11S4, and gotten a new one? If so, was the new one any better (in terms of reliability)?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9200582</guid>
<pubDate>Tue, 27 Jan 2004 01:09:54 EDT</pubDate>
</item>

<item>
<title>Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9197170</link>
<description><![CDATA[<A HREF="/useremail/u/936764"><b>Moody_Blue</b></A> : Being plagued with the 1.50.1 problem, I've decided to reinstall 1.45.3. Router is now working for at least 24h with "equivalent" parametrization. I keep my fingers crossed.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9197170</guid>
<pubDate>Mon, 26 Jan 2004 19:14:11 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9158392</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : What we probably need is for someone like Consumer Reports to "get" about 100 of the questionable LinkSys routers, put them in the same room [at "room temperature"], and just plug them into AC and each other and then "wire in" one PC, no internet, no wireless, no nothing. All this PC has to do is let out a broadcast every now and then -- to keep the network "alive." <br><br>I would not be surprised if "some" of the little blue devils succomb to this "torture test" before 12 hours. In a week there may be more casualties. After a month....?<br><br>You have at least been able to determine <B>big-g</B>, that there must be a hardware problem going on here... The cause may only be known to LinkSys... Maybe the units cannot overheat even once, maybe they cannot tolerate the wrong cable being inserted even once, maybe thay can be damaged by "samsonite" handling on their way to a retailer or to your home, maybe they have cheap flash RAM that "forgets" under certain conditions? -- one thing is certain, the unit you have is bad, and there is probably no flash-ware that can correct the issue. One sure sign is that operating on the switch logic alone appears to be able to crash the unit over time -- a thumbs down for LinkSys.<br><br>If you cannot RMA the box, pop the case, and look for stuff that may appear to be burned or melted inside, or soldered connections that may be loose or broken, or anything loose inside the case -- those are quality control issues and signs of internal trauma to the unit. If you decide to just buy another unit, there may be a real solid state electronics whiz that would perform an autopsy to see what is actually wrong with it. <br><br>Overall as network hardware goes, they can be considered disposable, since their price is almost equal to the price to ship them for service or replacement. Like I said before, this is the Cisco name goin down the tubes here, so I would expect to see changes [possibly evidenced by price increases] in the near future.<br><br>I guess one could say that the hardware is one "thread" that can be tested for and either determined or ruled out as an issue if you are willing to go to the same length as <B>big greg</B> -- I appreciate your effort. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9158392</guid>
<pubDate>Thu, 22 Jan 2004 15:54:54 EDT</pubDate>
</item>

<item>
<title>Re: BEFW11S4 behind firewall/router...</title>
<link>http://www.dslreports.com/forum/remark,9157474</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> :  <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>My BEFW11S4v4 w/FW1.50 is behind the router [BEFSR41], and has no wireless clients most of the time -- basically it acts like a switch and WAP, with one wired PC that's on 24/7. This PC has no problem communicating with the other PCs wired to the BEFSR41 or the internet through the BEFSR41. The BEFW11S4 also has an active DHCP to provide IP config info to the wireless clients. All other IPs are static.<br> <HR></BLOCKQUOTE><br><br>OK I think we eliminated the internet connection as being the problem (cable, DSL, T1, behind router, not behind router, static IP, dynamic IP, PPPoE, and on and on).<br><br>I noticed my unit was crowded around a lot of other equipment that could be bothering this plastic-cased device. <br><br>I have one room that is wired ethernet, so I put the POSW11S4 in that room by itself. No source of RF or any other electronic device within 15 feet of it.  Plus, it's cool... like 60 degrees in that spot.<br><br>It hung like a champ.<br><br>So it doesn't appear to be heat, or proximity to any RF emissions. And we now know that shutting off the wireless doesn't prevent a hang. <br><br>Is Linksys still RMAing V3 units for these V4s?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9157474</guid>
<pubDate>Thu, 22 Jan 2004 14:16:40 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9115619</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : Here's the results of my latest test:<br><br>I disabled wireless on my BEFW11S4 v4 (firmware 1.50), and then disconnected the ethernet cable between the Linksys box and my cable modem.<br><br>The router hung (sometime between 11:33 pm last night and 9:50 am this morning).<br><br>So, both the wireless and WAN interfaces have been eliminated as the source of my problem.<br><br>To say that the BEFW11S4 v4 (and its firmware) are a POS would only be putting it too kindly.<br><br>To attempt to solve this problem, I have previously:<br>* set my MTU from 1500 to 1400.<br>* changed from DHCP to static IP addressing<br>* turned off logging<br>* made sure that UPnP is disabled<br>* did a "long" reset<br>* set the router on 35 mm film containers to improve air flow around it.<br><br>It does not appear to me that any amount of configuration tweaking can or will resolve this problem. It's just plain poor quality on Linksys' part.<br><br>I will (again) be contacting their tech support, this time to demand that they just give me my money back. I'll escalate to the CEO if necessary (Victor Tsao).<br><br>I'm curious if anyone else experiencing the hang problem on their BEFW11S4 v4 has tried disconnecting their cable modem or DSL and disabling wireless (to see if their problem also occurs with both the wireless and WAN interfaces down).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9115619</guid>
<pubDate>Sun, 18 Jan 2004 13:05:01 EDT</pubDate>
</item>

<item>
<title>BEFW11S4 behind firewall/router...</title>
<link>http://www.dslreports.com/forum/remark,9107827</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : My BEFW11S4v4 w/FW1.50 is behind the router [BEFSR41], and has no wireless clients most of the time -- basically it acts like a switch and WAP, with one wired PC that's on 24/7. This PC has no problem communicating with the other PCs wired to the BEFSR41 or the internet through the BEFSR41. The BEFW11S4 also has an active DHCP to provide IP config info to the wireless clients. All other IPs are static.<br><br>I'm intereested in seeing what your setup turns up.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9107827</guid>
<pubDate>Sat, 17 Jan 2004 14:51:42 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9107659</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : I disabled the wireless feature on my BEFW11S4 v4 (firmware 1.50), and as usual (sigh) it hung within 16 hours.<br><br>Like clockwork, my BEFW11S4 v4 has been hanging (randomly) once or twice per 24 hour period (thankfully, I don't have the problem mentioned in the "connection drops every 2 - 3 minutes" thread).<br><br>Since my router hung with wireless disabled, I think I can eliminate packets coming in through the wireless interface as a suspect (i.e., interference from my neighbor's wireless networks, either intentional or otherwise).<br><br>Next, I will disconnect the ethernet cable between my cable modem and BEFW11S4, and wait to see what happens.<br><br>If the router again hangs within 24 hours, then I think I can eliminate any incoming packets as the cause of the hang. Then, it may be time to throw the box down the stairs :)<br><br>I'll post results later.<br><br>Anyone else with a BEFW11S4 v4 (firmware 1.50) who would like to perform similar experiments? It would be interesting to see if others who are experiencing these random hangs have similar results.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9107659</guid>
<pubDate>Sat, 17 Jan 2004 14:30:30 EDT</pubDate>
</item>

<item>
<title>Re: Wireless Drops...</title>
<link>http://www.dslreports.com/forum/remark,9107336</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : You may want to examine this thread regarding wireless "drops" every 3-60 mins:<br><br>&raquo;<A HREF="/forum/remark,8598566~mode=flat">[wireless] Connection drops every 2-3 minutes</A><br><br>it also includes a WinXP wireless "fix" that addresses a known problem. This may or may not influence the box getting hung up, but who knows?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9107336</guid>
<pubDate>Sat, 17 Jan 2004 13:44:44 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9102540</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : <B>big greg: </B>Thanks for your efforts at trying to nail down this problem (random hangs).<br><br>I'm with you, I want to throw my linky down the stairs.<br><br>Here's a suggest test to eliminate wireless from the equation. What if we disabled wireless on the BEFW11S4 and waited to see if it hangs. If it does, then wouldn't that eliminate stray (or otherwise) wireless traffic from the list of usual suspects?<br><br>My guess is that even with wireless disabled, the BEFW11S4 will continue to hang.<br><br>Next test: remove the WAN link (cable modem in my case) then wait and see if the BEFW11S4 will hang (thus totally eliminating incoming packets from WAN as a cause of the problem). I'm not sure on how this test might turn out, but as long as I'm predicting, I'll guess that the linky will still hang (thus implying a serious and hard to find flaw in the firmware).<br><br>I'll give these two tests a try this weekend (and others may want to try the same, so we can compare results).<br><br>On a positive note, I just configured a Cisco Aironet 350 card on my laptop (static WEP) and it works fine with my BEFW11S4. However, there were two paramaters (fragmentation threshold and RTS) that needed to be changed (slightly) on my BEFW11S4. In the case of these two parameters, the max value that the Cisco Aironet 350 allowed was slightly lower than the value I had set in the BEFW11S4 (I had these values set to max allowed by BEFW11S4). So I reduced the values in my BEFW11S4 to match the max values allowed on the Aironet 350 card.<br><br>If anyone is interested, I can provide the details. I don't recall the exact numbers off the top of my head, but the reduction was about 10 or 20 (from values around 2000). These changes did not affect the reliability of my BEFW11S4 (it still hangs about once a day). My laptop with Aironet 350 card works fine (as long as the BEFW11S4 remains up).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9102540</guid>
<pubDate>Fri, 16 Jan 2004 21:56:26 EDT</pubDate>
</item>

<item>
<title>Good news or bad news?</title>
<link>http://www.dslreports.com/forum/remark,9099584</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> : So here are the results of my testing. All I did was set a separate static address and put little Linky behind a NAT router here. There was other traffic on the network, but no traffic from the outside. <br><br>Initial results were inconclusive, as when I moved the wires I rotated it 45&deg; which caused loss of signal. <br><br>After I moved it back to its old spot, I power cycled it and and 24 hours of runtime later it hung 4 times, 3 times today between 10 am and 3:30 pm (light usage by 3 laptops). <br><br>While there was other traffic from 3 other W2K systems on the NATted segment (NATted segment is on a switch, and one switch port was connected to the WAN port of the router), none of it was the sort of port probing garbage I find on the unwashed Internet.<br><br>I could set up a NAT router with *nothing* but the router on the wire, but I suspect it would make any difference.  I could also turn on logging, but again I suspect it wouldn't make any difference.<br><br>This leads me to believe that the type of connection and the activity on the LAN port have little to do with the hangs.<br><br>I have discovered that there are 3 other 802.11b networks in the area (but none of them are on channel 11 with me). <br><br>I'm wondering if the hangs are related to the other wireless equipment in the area.<br><br>I'm also about to throw this thing down the stairs. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9099584</guid>
<pubDate>Fri, 16 Jan 2004 16:43:25 EDT</pubDate>
</item>

<item>
<title>Port SCAN...</title>
<link>http://www.dslreports.com/forum/remark,9086418</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : Hello again <B>biker</B> --- The challenge, yes - and, I don't want to take this BEFW11S4 over to my Auntie's house (where she uses Optimum Online) after "burning in" the box for so long, then, as soon as I walk out the door, the router freezes -- then I don't look too good.<br><br>To "see" the effect of port filtering on the part of Verizon, I posted on the Verizon board -- Port 80 is filtered and "maybe" 25 [SMTP-mail]. To find out for sure, I used the DSLR port scan applet. I also used the LinkSys LogViewer to see what ports were being tested, and what ports were getting in -- I didn't see any port 80 attempts reach the LinkSys, however port 25 attempts were made [and of course absorbed] by the LS. The port scan also tests UDP ports, but as we know, the LS only logs TCP requests -- so my test says alot, but it's not the whole picture.<br><br>So, that narrows it down to a possibly "evil," malformed port 80 TCP [or UDP?] packet that we want to "catch" inside our LAN. Note that not every port 80 packet will be the bad one --- Hmmmmmmmmmmm, I wonder how many people who have DMZ on a PC or an HTTPd on port 80, or whose ISP is VOL have these random but increasingly frequent "lockups?"<br><br>Hey <B>'ster</B> -- I know what you're saying -- that UPnP is "just too natural for me" too -- until I figure out how it can allow any PC on the LAN (wired or wireless) to gain command and control over my LS box <B>without authentication</B>, it stays OFF.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9086418</guid>
<pubDate>Thu, 15 Jan 2004 12:03:24 EDT</pubDate>
</item>

<item>
<title>UPnP causes a lot of problems!</title>
<link>http://www.dslreports.com/forum/remark,9083992</link>
<description><![CDATA[<A HREF="/useremail/u/522717"><b>qworster</b></A> : I find that in many Linksys units UPnP seems to cause a LOT of problems. I've had several Linksys routers (both wired and wireless) that constantly disconnected clients, crashed, etc.  Turning off UPnP in these units seems to make things a LOT more stable! ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9083992</guid>
<pubDate>Thu, 15 Jan 2004 03:04:54 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9083822</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : <B>ChrisDAT: </B>Good idea about forwarding port 80 requests to never-land. Let's wait to hear from <B>big greg's</B> experiment in isolating his LS from the outside world. Thanks <B>big greg</B> for the effort!!<br><br>I think <B>ChrisDAT's</B> observation is right on. Based on the posts in this thread, most of us here are more interested in finding a solution to this problem because of the challenge, rather than trading in our Linksys hardware for something that works. One thing's for certain, when we solve this one, Linksys has many more problems (er I mean challenges) to work on :)<br><br> ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9083822</guid>
<pubDate>Thu, 15 Jan 2004 02:09:59 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9077161</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> :  <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>You see <B>big greg</B>, this is called thinking "outside the box" -- The fact that you get attacks from a T1 takes both the DSL and cable modems out of the picture. Your post also speaks volumes to the fact that the little critters are "out there" and that they MAY have an adverse effect on your LinkSys in particular.<HR></BLOCKQUOTE><br><br>So at least we know it's not settings related to your incoming connection (static, dynamic, pppoe, DSL, cable, T1) so that "rules out" a certain (small) section of the router code, and it "rules in" certain environmental factors encountered on any IP address.<br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>I know you meant to say "For those types of worms that attack neighbors, changing your IP address would [NOT] matter much." <HR></BLOCKQUOTE><br><br>Yeah, I should have re-read that. <br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>However, I would dare to disagree -- while a change in IP would not change the frequency of getting a random attack, it would influence a directed attack.<HR></BLOCKQUOTE><br><br>True. I was referring to the random critter attack, the kind that sprays all my IPs with the same junk. In that case changing your IP address to another in the same subnet would NOT matter that much. <br><br>Certainly a directed attack on a certain live IP is a whole other ball game.<br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>To the "subnet run by idiots" -- that's possibly a group of PCs that are running unprotected/filtered by a firewall. Most of us spend far less time on outbound filtering than we do on inbound forwarding. Outbound filtering can prevent us from becoming part of the problem.<HR></BLOCKQUOTE><br><br>Yeah over there at typhoid mary corporation there a number of unpatched Windows 98 machines, and a bunch of other stuff. At least they shut down the unpatched NT 4.0 machine. :D<br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>On my DSL, I usually get the same address after a router or modem reset via a settings change. After an ISP hiccup, I often get a vastly different IP (network addresss wise), even the PPPoE server can be different [my first hop in an outbound tracert], so I don't know if I can "make" my ISP give me a new address without going "dark" [turning off the DSL modem] for a certain time period. <HR></BLOCKQUOTE><br><br>The DHCP server has remembered your MAC address in its DHCP client table. When the modem comes online it asks for another address and the DHCP server says aha, renewal for this MAC address.<br><br>When the ISP bounces the DHCP server, it doesn't have your MAC address any more. So the cable modem asks for an address and in all likelyhood gets a new one. <br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>You are dead right about cable, any communications by near neighbors will at least be seen by the cable modem, and possibly passed on to to the router. Cable has that vulnerability, especially if the modem forwards broadcasts and multicasts.<HR></BLOCKQUOTE><br><br>Want I meant was if there is traffic between two IPs that are in the same routing subnet, those packets will NOT be passed to core of the cable network. The source and destination is the local subnet. Not only that you have high speed access for brute attacks on other IPs in your subnet. :p<br><br>So the cable network would have no way of seeing this traffic. They can kick the customer off the cable system, but they won't know he's attacking your system.<br><br> <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>I am concerned that sometimes as we suggest/post possible solutions, a person reads them, applies the knowledge, their problem goes away, and they never revisit the site to say "hey, it worked for me!" The <B>feedback</B> is important, even if it is to say "that s**t didn't even work." Please, everyone, respond. <HR></BLOCKQUOTE><br><br>OK, I've got an idea that maybe hasn't been tried. I'm going to put the router behind another NAT server rather than on the unwashed Internet. (I wanted to keep it on the Internet segment in case my WEP was broken... they can do whatever they want out there, but keep them the hell off the internal network at any cost.) <br><br>Yes, little Linky will get a nice quiet relaxing cozy private little network segment. All protected from the outside world. That will tell us if it is the network traffic, or not. I can set it up tonight. I'll let you know the results.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9077161</guid>
<pubDate>Wed, 14 Jan 2004 14:47:44 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9076926</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : You see <B>big greg</B>, this is called thinking "outside the box" -- The fact that you get attacks from a T1 takes both the DSL and cable modems out of the picture. Your post also speaks volumes to the fact that the little critters are "out there" and that they MAY have an adverse effect on your LinkSys in particular.<br><br>I know you meant to say "For those types of worms that attack neighbors, changing your IP address would [NOT] matter much." However, I would dare to disagree -- while a change in IP would not change the frequency of getting a random attack, it would influence a directed attack.<br><br>To the "subnet run by idiots" -- that's possibly a group of PCs that are running unprotected/filtered by a firewall. Most of us spend far less time on outbound filtering than we do on inbound forwarding. Outbound filtering can prevent us from becoming part of the problem.<br><br>On my DSL, I usually get the same address after a router or modem reset via a settings change. After an ISP hiccup, I often get a vastly different IP (network addresss wise), even the PPPoE server can be different [my first hop in an outbound tracert], so I don't know if I can "make" my ISP give me a new address without going "dark" [turning off the DSL modem] for a certain time period. From the LogViewer, 99.9% of the stray requests on unblocked ports (overwhelmingly 137,139 and 445, but there are others) come from remote ISPs.<br><br>You are dead right about cable, any communications by near neighbors will at least be seen by the cable modem, and possibly passed on to to the router. Cable has that vulnerability, especially if the modem forwards broadcasts and multicasts.<br><br>I am concerned that sometimes as we suggest/post possible solutions, a person reads them, applies the knowledge, their problem goes away, and they never revisit the site to say "hey, it worked for me!" The <B>feedback</B> is important, even if it is to say "that s**t didn't even work." Please, everyone, respond.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9076926</guid>
<pubDate>Wed, 14 Jan 2004 14:21:20 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9076233</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> : I run a small ISP and when there are attacks, most often they come all over my IP block from IP addresses close to mine. Example: if my IP block was 4.4.4.0/32 then I would often get attacks on random addresses in my subnet from 4.4.1.0/32 through 4.4.8.0/32.  This makes a lot of sense, cause if you want to find more live hosts to infect, you don't want to pick totally random IPs. You want to pick some that you know are assigned, connected, and friendly to your advances.  <br><br>There's one subnet close to mine that must be run by idiots, as they get infected and stay that way for months. <br><br>Anyway, if you are on a cable system it would seem most natural to attack your neighbors, some of which you would share a network segment with, as not only are they connected but you can get to them quickly, and perhaps without any telltale traffic going to cable system's internet gateway. Same thing with DSL, as everyone connecting to a particular CO most likely gets an address out of the same subnet. <br><br>For those types of worms that like to attack neighbors, changing your IP address would NOT matter much.<br><br>I also use a static IP from a T1 for my W41 and it hangs just as reliably as well as you guys on DSL or cable.<br><br><SMALL>edit: added NOT</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9076233</guid>
<pubDate>Wed, 14 Jan 2004 13:15:52 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9076104</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : I have an idea <B>biker</B>, that If you're game, we could try.<br><br>Let's assume our "Gremlin" is a malformed port 80 [or some other port or service] packet that chokes the LS when it is recieved...<br><br>Your mission, should you choose to accept it, is to tell the router to forward port 80 requests to never-neverland, or better still, a PC, possibly with a running HTTPd, that can properly [and safely] handle this request. <br><br>What this would do is force the router to modify the packet, maybe even "fix" it, such that it encounters the LinkSys in a different context. Having an HTTPd to recieve the request would "expose" the actual HTTP request that is being made by viewing the log of the HTTPd. It could be somewhat "risky" to use the MS IIS, because I know many of the exploits are specifically targeted at the MS web server.<br><br>Would anyone like to pursue this issue?<br><br>Hi <B>Biggie-Gee</B>! You are on the money describing the hardware of the LS -- What we're trying to do here is hot-rod the box a bit so that it can at least meet our expectations that come from knowledge of hardware that costs hundreds of times more than these little boxes. Maybe we will not succeed, but let me put it in context: I have a 1970 Chevrolet Chevelle [red, 396] that has no digital electronics to speak of [ie. no brain] -- when the weather changes more than a little, it needs to be re-tuned or it will not run, if I put cheap gas in it, it will let me know, the paint is so old, it is cracking and appears to fall off as I look at it, and it drinks gasoline like the Exxon Valdiz -- on the other hand, it's an absolute thrill to drive, it gets "thumbs ups" where ever I go, and I can't step out of it without someone asking me "how much." I bought the car for a cool $1000 and have probably put more than 5x that into it since -- will I get rid of it - NEVER. Ultimately, what we want to do is find the limitations of the LinkSys package, so we can work around them, and live with them.<br><br>It is absolutely easy to jump ship on LinkSys, as there is a world of similarly-priced and featured boxes out there, but if the problem is what we're working here, it will do no good -- the LinkSys has the features I want and need, and my LinkSys works, if I'm correct here, the problem is not even the fault of LinkSys, and finding this elusive "silver bullet" will apply across brands.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9076104</guid>
<pubDate>Wed, 14 Jan 2004 13:05:07 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9076046</link>
<description><![CDATA[<A HREF="/useremail/u/166533"><b>RonS</b></A> :  <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>It's important to note that worm attacks are random -- in one hour you could see 100 hits, and for the next day, you may not see any. Some of the attacks are also "smart" enough that when they find a good target IP, they remember and propagate that info about the "soft target," so that an IP change can totally change the nature of the issue -- If you have a static IP, you are probably more succeptible -- keep in mind, these little devils are designed by people who know this stuff, they certainly know that without a dynamic IP [this is usually an ISP-wide setting], you're a "sitting duck" in a way. I also believe that of the "well known" exploits, there are probably twice as many "unknown" exploits because, once again, the bad guys are always one step ahead of the good guys, they also follow the CERTs and the workarounds, and immediately go to work on an attack for the workaround, most likely before you even see it. It may only take ONE bad [malformed] packet (with an invalid MTU or MSS field possibly) to jack the router. I would be interested in hearing from <B>RonS</B> on this issue. <HR></BLOCKQUOTE><br><br>Very interesting and thought inducing post. I read back and some people say that <I>"All the sudden the router just stopped working. It was fine for weeks"</I> People with cable modems keep the same IP address to the MAC address of the device the modem is hooked up to for months. When I put the new router in I got a different IP address. Could it be that the IP address hasn't been used and the worms are ignoring it for now. Maybe eventually they will see the IP in use and send a bad packet to it and start problems for me? <br><br>That wouldn't explain the problems for DSL users who usually get a different IP address each time the have to power cycle their Router. It would be interesting if the people having the problem that are on cable modems would unplug the Network cable from the router and plug the modem into their computer. This would get you a different IP address. Then wait a day or two and plug it back into your router. This should get you a different IP address than you had previously (write down your IP address to verify) Then see if the problem is still there.<br><SMALL>--<br><B><I>3 out of 4 people make up 75% of the population.</I></B></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9076046</guid>
<pubDate>Wed, 14 Jan 2004 12:59:52 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9074885</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> :  <BLOCKQUOTE><SMALL>said by  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>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). <HR></BLOCKQUOTE><br><br>I'm a software developer too, and clearly that's the way to attack this problem. <br><br> <BLOCKQUOTE><SMALL>said by  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>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).<HR></BLOCKQUOTE><br><br>I can give you one reason that the 1.50 code supports WPA: marketing. They can sell more of these crippled boxes if they claim they support WPA. <br><br>Remember we all got a bottom of the line device here. People go to the mall and buy the cheapest wireless router they can find. The V1/2/3 boxes were cheap (but reliable) but the v4 box is most likely far cheaper to make. Cheaper to make results in more profit. <br><br>Linksys could care less that this horrible product is tarnishing their reputation... I'm sure sales of this POS are not hurt one bit by it's flaws. People just buy the cheapest one (I did) or they purchased one based on experience with earlier models (Mom's V3 is rock solid) or because they saw the Cisco logo on the box (marketing ploy).<br><br>If I was in the department where the 1.50 code was produced, I'd be pretty ashamed of myself. Clearly the code has had major changes in the 1.50 release.  Management rushed the code out because they wanted it to claim that it supports WPA. Now that it's out, the engineers have no doubt moved to other products.<br><br>The priority at Linksys is to move hardware at the expense of their reputation. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9074885</guid>
<pubDate>Wed, 14 Jan 2004 10:42:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9074343</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Thanks Chris - good post!!!<br>I will say how suprised I was that setting my MTU back to default - re-introduced the problem!! That was the first time the router had been re-set in weeks. A very helpful tech at my ISP wanted to try it - actually what a concept - a cable ISP tech that would talk to me about a router .<br>Thinking about it - the fact that this problem started after some specific date/event maybe suggests a firmware upgrade in some part of the ISP network.... Now if we could only get that kind of info....<br><br>Hey - you have to try those 5.5 Db antennas from Radioshack - I see about a 20% difference on the Signal graphs and get coverage deep into the corners of my house now!!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9074343</guid>
<pubDate>Wed, 14 Jan 2004 09:18:20 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9074290</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : <B>biker</B> -- You hit the nail on the head about the debug and stuff, and thanks for the info. I also learned long ago, that before I post anything of substance to "copy" to the clipboard, FIRST -- I feel your pain.<br><br>It's important to note that worm attacks are random -- in one hour you could see 100 hits, and for the next day, you may not see any. Some of the attacks are also "smart" enough that when they find a good target IP, they remember and propagate that info about the "soft target," so that an IP change can totally change the nature of the issue -- If you have a static IP, you are probably more succeptible -- keep in mind, these little devils are designed by people who know this stuff, they certainly know that without a dynamic IP [this is usually an ISP-wide setting], you're a "sitting duck" in a way. I also believe that of the "well known" exploits, there are probably twice as many "unknown" exploits because, once again, the bad guys are always one step ahead of the good guys, they also follow the CERTs and the workarounds, and immediately go to work on an attack for the workaround, most likely before you even see it. It may only take ONE bad [malformed] packet (with an invalid MTU or MSS field possibly) to jack the router. I would be interested in hearing from <B>RonS</B> on this issue.<br><br>More people need to report in this....<br><br><B>dells</B>, You are also correct -- We cannot get to the bottom of this issue if our basic settings are "off" from the start -- LinkSys boxes do not do Max Path MTU Discovery [a feature that may solve many issues], while PCs have this turned ON by default, moreover the router's MTU must be less than or equal to the MTU of your ISP [actually, I think it is the modems that are goofy on that one]. The problem still persists for some people regardless of the setting of the MTU -- moreover, the lockups usually become less frequent because the MTU issue is solved when you "get it right." The MTU and MSS are related in that they determine the "fields" of the packet record which in turn tells firewalls and applications how to interpret the packet data. Routers along the way do not examine this info, so it is transparent to them -- that's what makes malformed packets "explosive" only at the end point -- the smart bombs of the worm world, they are usually directed at one specific application.<br><br>I really wish I could "look inside" the LinkSys better, in the absence of realtime information about the operating environment of the router, we can only look at the external conditions and make a best guess based on those observations as to how the router is responding to/effected by them. If we're lucky and look deep enough a "pattern" will emerge.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9074290</guid>
<pubDate>Wed, 14 Jan 2004 09:10:04 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9074023</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Just to goive you guys an update - not want you want to hear either (knock on wood)<br>The router has been fine since the beginning of December. As you know, both this and my old V1 started freezing once a day - sometimes more often. I replaced the V1 with the V4, upgraded software and started playing with settings.<br>The device runs 24/7/365. Speed on Road runner 2800/360 average.<br>UPnP off<br>VPN passsthrough enabled<br>Logging off<br>WEP/WAP off<br>MTU 1400<br>no cloned MAC<br>2 forwarded ports (5060-5062) to valid STATIC addresses<br>Port filtering on 3 ranges<br>WAN access disabled<br>remote upgrade enabled<br>DHCP client lease 32767 (6 dhcp client PC,s 2 hardwire static IP cisco ATA)<br>Filter multicast - disabled<br>SSID enabled - channel 6<br>Obtain IP automatically<br><br>BTW: My ISP does NOT block any of the known service ports (1000 or less) and most likely does not block any ports<br><br>I am not offereing solutions here - just observations. Both Linksys and my ISP said to change the MTU. I did and the problem cleared. I set it back (default) and the problem occurs again. I am sure the combination of other settings help in some way (buffer usage, etc). This experiment is repeatable - tech support at my ISP asked me to repeat it.<br><br>The major chains and ISP's are distributing these boxes. I doubt a profit making organization like Best Buy would continue to sell a problem SKU that flooded their return or service desk.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9074023</guid>
<pubDate>Wed, 14 Jan 2004 08:18:09 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9073117</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : 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.<br><br>Here's the data that ChrisDAT asked for ...<br><br>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).<br><br>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.<br><br>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). <br><br>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).<br><br>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.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9073117</guid>
<pubDate>Wed, 14 Jan 2004 02:03:26 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9071288</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : 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.<br><br>This may be important, because too many complaints start with <br><br><B>"everything was fine until a couple of days ago"</B><br><br>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.<br><br>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.<br><br>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).<br><br>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.<br><br>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.<br><br>Is that a good symptom summary?<br><br>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)?<br><br>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.<br><br>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.<br><br>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....<br><br>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).:)<br><br>edit:<br>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!]]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9071288</guid>
<pubDate>Tue, 13 Jan 2004 22:15:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9070772</link>
<description><![CDATA[<A HREF="/useremail/u/166533"><b>RonS</b></A> :  <BLOCKQUOTE><SMALL>said by  ChrisDAT <A HREF="/useremail/u/591864"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>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?  <HR></BLOCKQUOTE><br><br>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.<br><br>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.<br><SMALL>--<br><B><I>3 out of 4 people make up 75% of the population.</I></B></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9070772</guid>
<pubDate>Tue, 13 Jan 2004 21:34:30 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9070498</link>
<description><![CDATA[<A HREF="/useremail/u/886011"><b>big greg</b></A> : Getting back to the "common thread" theme...<br><br>BEFSW11S4 V4 (1.50) Freezes about every 9-12 hours. Other versions froze every 2-3 days.<br>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.<br><br>Connection type: static IP<br>PnP: off<br>WEP: on, 128 bit<br>WPA: off<br>Log: off<br>MTU: disable (1500)<br>NAT: enable<br>Local DHCP server: enable<br>Client lease time: 0 (1 day)<br>SSID: broadcast disabled<br>Channel: 11<br>Port Forwarding: No<br>Filters: none<br>Block anon wan requests: enabled <br>Filter multicast: disabled<br>Location: sits in a cool spot box is never warm when I power cycle it.<br><br>While I started out with pretty good results I have more recently found the thing hanging.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9070498</guid>
<pubDate>Tue, 13 Jan 2004 21:05:14 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9042159</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : 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? <br><br>[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).<br><br>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?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9042159</guid>
<pubDate>Sat, 10 Jan 2004 22:52:16 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9041830</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : <B>ChrisDAT: </B>I also do not have radio buttons for <br><br>( ) Connect on demand: Max Idle Time: <br>( ) Keep Alive: Redial Period: <br><br>But I too am not using PPPoE.<br><br>Could be that the above radio buttons only become visible if one enables PPPoE.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9041830</guid>
<pubDate>Sat, 10 Jan 2004 22:19:29 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9041702</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : There is one item missing from both the <B>RonS</B> config and your post <B>biker</B>...<br><br>I have an "11S4v4" w/FW 1.50, and, in the Internet connection settings I have radio buttons for <br><br>(x) Connect on demand: Max Idle Time: [0] min.<br>(_) Keep Alive: Redial Period: [20] sec.<br><br>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.<br><br>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].]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9041702</guid>
<pubDate>Sat, 10 Jan 2004 22:08:50 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9041384</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : 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 ...<br><br>&raquo;<A HREF="/forum/remark,8654928~mode=flat~days=9999~start=80#9036112">[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups</A><br><br>Here is a post with a comparison of my config to Ron's ...<br><br>&raquo;<A HREF="/forum/remark,8654928~mode=flat~days=9999~start=80#9041370">[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups</A><br><br>Any comments would be appreciated.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9041384</guid>
<pubDate>Sat, 10 Jan 2004 21:37:46 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9037521</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Check out this thread<br><br>Forums &raquo; Up and Running &raquo; Wireless Networking &raquo; Linksys and NetGear wireless routers. <br><br>I have also read about Motorola TA's (VoIp) when used as a router - locking up nightly...<br><br>I wish my ISP had a clue??<br><br>More info - DOES ANYONE KNOW WHAT THIS IS??<br>&raquo;<A HREF="http://www.linksys.com/support/cox/firmware.asp" >www.linksys.com/support/cox/firmware.asp</A><br>I found this in <br>Forums &raquo; US Cable Support &raquo; Cox HSI &raquo; Linksys Wireless devices Arp Issues<br><br>More info from a post from someone representing themselves as an engineer for Cox Cable:<br><br> Linksys Wireless devices Arp Issues<br>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 &raquo;www.linksys.com/support/cox/firmware.asp<br><br>Thanks.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9037521</guid>
<pubDate>Sat, 10 Jan 2004 14:42:36 EDT</pubDate>
</item>

<item>
<title>Truth in Advertising...</title>
<link>http://www.dslreports.com/forum/remark,9036431</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : That's a tough call <B>biker</B> -- 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.<br><br>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... <br><br>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.<br><br>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. :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9036431</guid>
<pubDate>Sat, 10 Jan 2004 12:36:16 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9033036</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : Check out this post ...<br><br>&raquo;<A HREF="/forum/remark,8654928~mode=flat~days=9999~start=80#9029298">[wireless] BEFW11S4 v4, Firmware 1.5, constant lockups</A><br><br>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 :(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9033036</guid>
<pubDate>Sat, 10 Jan 2004 00:07:49 EDT</pubDate>
</item>

<item>
<title>Special config?</title>
<link>http://www.dslreports.com/forum/remark,9028756</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : 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?<br><br>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.<br><br>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.<br><br>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.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9028756</guid>
<pubDate>Fri, 09 Jan 2004 16:11:31 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9028434</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : on my "41" which works flawlessly, <br><br>I don't do DHCP,<br>no UPnP [until I "discovered" it, it was on],<br>a few port maps [UPnP forwarding - the name is wrong],<br>some forwarded ports,<br>no outbound filter [port or address],<br>no spoofed {cloned} MAC,<br>MTU at 1492,<br>"connect on demand max idle time" 00 min,<br>and just about all of the advanced switches disabled... the pass throughs, etc..<br>I use the LS LogViewer...<br>Router Mode: Gateway...<br>No AOL parental controls...<br>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.<br><br>Never any lockups.<br><br>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.<br><br>hey <B>biker</B>! 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.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9028434</guid>
<pubDate>Fri, 09 Jan 2004 15:40:07 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9027665</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : ChrisDAT: thanks for all the info in your recent posts !!!<br><br>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).<br><br>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 . <br><br>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" :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9027665</guid>
<pubDate>Fri, 09 Jan 2004 14:22:11 EDT</pubDate>
</item>

<item>
<title>NAT info?</title>
<link>http://www.dslreports.com/forum/remark,9026087</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : The LS .pdf doc for the BEFSR41 says:<br><br>"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.<br><br>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.<br><br>It also says, <B>"Theoretically the router can establish 520 sessions at the same time."</B>  Not specific, but this MUST be the size of the NAT table.<br><br>more: Router memory Buffer: 512KB<br><br>The LS .pdf for the BEFW11S4 adds:<br><br>"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)<br><br>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.<br><br>[Sorry for the cross post - How do you "ref" another post?]]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9026087</guid>
<pubDate>Fri, 09 Jan 2004 11:30:28 EDT</pubDate>
</item>

<item>
<title>Operating Range [Environmental Temp]</title>
<link>http://www.dslreports.com/forum/remark,9026017</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : From the published docs for the BEFW11S4 and BEFSR41<br><br>Operating Temperature: 32F to 104F (same for both) -I read more than 107F outside the unit.<br>Storage Temp: -4F to 158F (ouch! - maybe backwards?)<br><br>BEFSRxx<br>Power: 9VAC, 1A (don't you rate watts for AC?, rectifier inside?)<br><br>BEFW11xx<br>Power: 5VDC, 2A (more like it!)<br><br><I>"The more you know... the more you know"</I> :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9026017</guid>
<pubDate>Fri, 09 Jan 2004 11:20:09 EDT</pubDate>
</item>

<item>
<title>Stability...</title>
<link>http://www.dslreports.com/forum/remark,9025472</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : 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.<br><br>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.<br><br>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.<br><br>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!<br><br>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.<br><br>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.<br><br>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.<br><br>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.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9025472</guid>
<pubDate>Fri, 09 Jan 2004 10:15:53 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9025410</link>
<description><![CDATA[<A HREF="/useremail/u/916410"><b>peteWRT54G</b></A> : 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?"]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9025410</guid>
<pubDate>Fri, 09 Jan 2004 10:07:38 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9020766</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : 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.<br><br>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]. <br>&raquo;<A HREF="http://www.sonic.net/~sraaii/wallwatcher/Index.html" >www.sonic.net/~sraaii/wallwatcher/Index.html</A><br><br>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).<br><br>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!<br><br>Although totally off topic, I just can't help responding to Think Twice Speak True's post ...<br>"I'll have your spam. I love it. I'm having spam, spam, spam, spam, ........, baked beans, spam, spam, and spam."<br>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)! ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9020766</guid>
<pubDate>Thu, 08 Jan 2004 20:44:01 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9015899</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : hi <B>biker</B> :) 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.<br><br>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 <I>switch</I> [officially called a MAC layer bridge] and not a hub [I'd love to see the MAC address table]].<br><br>I'm just a bit anal about performance, that's all. :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9015899</guid>
<pubDate>Thu, 08 Jan 2004 12:42:25 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9015520</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : Just to summarize: My BEFW11S4 v4 (firmware 1.50) has been hanging once or twice per day (requiring a power cycle). One possible cause discussed in this Topic was that the router did not have enough processing power or resources to handle the load. In order to reduce the load, I recently disabled logging, have also set my DHCP lease renewal value to 32767, and disabled UPnP. <br><br>Prior to disabling logging (but after setting DHCP lease time to 32767 and disabling UPnP), my router was still hanging every night (between the time I shut my PCs down for the night and the time I booted the next morning).<br><br>After disabling logging, my router did not hang overnight for two nights in a row (router did hang during the day).<br><br>However, last night, my router hung.<br><br>So, I am beginning to think that the router hang problem may be caused by something other than load (or perhaps there are multiple causes). In my case I have done everything I can (configuration wise) to reduce overhead, with the exception of disabling WEP. If I must disable WEP to make this router stable, then I'm ready to jump ship and try another vendor's box. I know that I can (and do) use MAC filtering, but a dedicated hacker can sniff the MAC address and then spoof it. I also know that WEP is hackable. I really want to use WPA, but that's a issue for a different Topic (Linksys claims that the WUSB11 v2.8 supports WPA, but is does not).<br><br><B>ChrisDAT:</B> I am using WallWatcher for my client logging app. Now that I've seen the case where my router hung overnight (with logging disabled), I think I can remove logging from the list of usual suspects. I'll enable logging and leave my PC on overnight (to try and capture status at the time of the hang). If the hang is a result of load, then I should see the load (in the log) leading up to the crash. However, if the crash is the result of a single event (such as a malformed packet similar to the TARGA3 exploit), then this event may not be in the log. Thanks for the offer to use your web pages that will "work the log".<br><br>Also, as dellsweig mentions, the SNMP Trap/logging function may be a contributor to this problem.<br><br>I am using the broadcast address (.255) to specify my log client, and WallWatcher (on my PC) is not having any problems receiving the logs from my router. My DHCP range, defined in the router's config, stops at .200 (well below the broadcast address). I have not had the need to go to a static address for the PC running WallWatcher (if so, I'd use an address above .200 but below .255)<br><br>In addition to scanning my logs for nasty stuff like spyware, adware, viruses, etc, I also use a combination of Zonealarm, Ad-aware, and Spybot.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9015520</guid>
<pubDate>Thu, 08 Jan 2004 11:55:07 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router proble</title>
<link>http://www.dslreports.com/forum/remark,9015486</link>
<description><![CDATA[<A HREF="/useremail/u/720248"><b>Johkal</b></A> : And now for something completely different: "THE LARCH"<br><br>STOP THAT! Thats completely rediculous!<br><br>Eggs - Spam & Eggs But I don't like Spam!<br><SMALL>--<br>Never wrestle a pig. You both get dirty and the pig likes it.</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9015486</guid>
<pubDate>Thu, 08 Jan 2004 11:49:43 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9015190</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : Not really, <B>dells</B>... The trap will not indicate the problem directly, but it could show a pattern or stream of incoming worm attacks and the ports they were directed at; it could show a port scan in progress, just before...; it may even be able to send the "killah" request to the logviewer before it locks up.<br><br>I am assuming that the log is working properly, I am also "reading" the log -- patterns emerge, the logging will stop while the router is hung, it will also stop at a particular time [the logviewer will not]... You cannot view the router-based log at this time, but your PC will not be hung. That is the reason for sending the log away from the router.<br><br>Anyone who uses the log [the incoming log is the most important], should realize that you will get seemingly random "hits" on port 137 (NETBIOS name) 445, and 8080 (the default remote LS admin address), and many other ports all the time -- many of those are worms... If my router fails after a port 8080 request despite having remote admin disabled, I would think that the "feature" [to disable the remote admin] may not work, and the request is handled by the router when it should just ignore it. Moreover, if I found that out, before I tell LinkSys about the issue, I would set a port forward rule to send all 8080 requests to an unused internal ip address [not 127.0.0.1] that is neither in my DHCP range nor my [assigned] static address range. That's a workaround --- people who write these worms know the weaknesses of the firmware, heck, they probably find out by reading these boards.<br><br>What's important here is that I work the problem in small steps, one piece of the puzzle at a time... If you change too many things at a time (like flashing a new firmware) you will never discover which one thing fixes your one problem... The fact that many posters get bombed overnight, indicates that maybe there is a worm that is exploiting a specific, common LinkSys weakness. It is not lost on me that when it is nighttime here, it is daytime in the asian pacific world... worms come from infected, or otherwise compromised PCs that will be more active there while we sleep... In electronics, who is the major competitor for the USA? Think about it, you're talking big bucks here.<br><br>I'm not implying anything, but I don't take anything for granted either. If this offends anyone, TOUGH. :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9015190</guid>
<pubDate>Thu, 08 Jan 2004 11:11:37 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9014886</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Chris<br><br>You are missing the point here..... The SNMP Trap/logging function (in the firmware) may be a contributer to the problem. By the time the router cries for help - its too late. That is assuming there are traps included in the code which would indicate buffer problems.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9014886</guid>
<pubDate>Thu, 08 Jan 2004 10:35:09 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9014818</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : <B>ManRoss</B>, I like your setup... That's the path I will take too. Is that two fans? How do you power them? I was thinking to make a "splitter" on the power cable to power them -- What is it, 5vDC?... You know, once that masking tape glue dries, you'll NEVER be able to get it off :) The idea to shroud the other upper holes says you know what you're doing. Even if heat is not the problem, it certainly cannot hurt, and will certainly extend the useful life of the unit -- electronics can never be "too cool."<br><br><B>biker</B>, Do you use the LinkSys logviewer app? I ask because it seems to respond immediately to router activity. I think the router will send the SNMPtrap message as soon as the log "event" occurs. What this would do for you [and anyone whose router chokes overnight] is give you a good indication of exactly WHEN things stopped working because you would see the last communications with the router before the hang. I have a DNS update client, a public SHOUTcast, and a few other services that talk to the internet at fixed intervals, so I can tell when communications stop by looking at the remote log. The resolution works out to about every three minutes or so. You would have to set something like this up if you don't have such an app, and it has to be at TCP app, not a ping or other ICMP or UDP low-level service. The log option only specifies a fixed address [I have not been able to get a broadcast address to work [ends in .255], actually I wouldn't want to do that anyway, so the PC that runs the logviewer app should [must] have a static IP [I shouldn't have to say this, but do not assign static addresses that are within the DHCP range].<br><br>Using the LogViewer app. has also alerted me to spyware, adware, hijacks and other parasite [background] activity because they produce outbound log entries when the browser is running (they're sneaky like that) but nothing is really going on.<br><br>If you need an app to use to "work" the log you could use a webpage that refreshes frequently. I have some you could use, they are around 1K in size so you won't exceed any quotas by using them. They utilize a META http-refresh tag in the html so you need to have that enabled in your browser. They also change so that your browser shouldn't try to cache them [the HTTPd will send an "expires" header].<br><br>&raquo;<A HREF="http://cjw.servehttp.com:11423/cgi-fx/userdef2?s=DSLR" >cjw.servehttp.com:11423/cgi-fx/u&middot;&middot;&middot;2?s=DSLR</A><br>[1Kb, 2 min. refresh]<br><br>or, if you prefer a non-secular one :)<br><br>&raquo;<A HREF="http://cjw.servehttp.com:11423/ShoutcastStatus.html" >cjw.servehttp.com:11423/ShoutcastStatus.html</A><br>[2Kb, 2 min. refresh]<br><br>note: my dynamic DNS prov. is having a bad hair day today... so if you get a "could not find..." message, be assured that it is only temporary. There go my stats 4 today :(. [I tried to hold the post until it came back... oh well, here they are IP style:<br><br>[:) <I>cjw edit: dns is back, yaaaay!</I> :)]<br><br>...just an example of getting what you pay (or in this case don't pay) for.] <br><br>note2: I got a new IP address last night from Verizon sometime between 10:30p and 11:30p EST... the logviewer shows this in the incoming log [for non-forwarded port requests, the destination IP will be the public IP], and the DNS update client also realized it [it checks every hour], and the router didn't hang.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9014818</guid>
<pubDate>Thu, 08 Jan 2004 10:26:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9013359</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Ok another issue that I ran into some time ago.  A W11S4 V1 that I opened up had all the components on the circuit board inside a Tin Box.  If you wanted to add some heat sinks in that case you had to unsolder the Tin Box first.  Guess the tin box was a good RFI shield, but in the process it would have been a good Heat Shield as well (trapping the heat inside).  Adding a fan in that case would likely have little effect.  Can be useful in some of the other designs though.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9013359</guid>
<pubDate>Thu, 08 Jan 2004 01:32:28 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9013140</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : When I first encountered the "router hang" problem (October), I read one post on DSLReports that mentioned heat. For optimal signal strength to upstairs room where wireless PC sits, I had to place my BEFW11S4 on top of a 6 foot bookcase.<br><br>It gets hot up there on the bookcase near the ceiling. So, after reading the post on heat, I set my router on top of four 35mm film containers. This provides an inch or so of extra clearance under the box, but is certainly not as effective as the fan pictured in manross' post !!!<br><br>Up until a few days ago (when I disabled logging), my router was hanging every night (while I was asleep, lights were out, and thermostat set back .... i.e., less heat around the router than during the day). The router rarely crashed during the day. Heat could be the catalyst in the router hang problem, but I'm not sure that's the case (at least for my setup). If it were heat, I would expect to see my problem repeat itself more than once or twice a day.<br><br>Here's a new fact for everyone's consideration ...<br><br>While on www.pcflank.com running tests against my setup, I found that with older BEFW11S4 v4 firmware versions, the TARGA3 exploit would consistently hang my router. I opened a case with Linksys and they told me that the firmware I was running at the time (1.45.7) was known to be affected by this exploit and suggested that I backlevel to 1.45.3.<br><br>I waited til firmware 1.50 came out and again tried the TARGA3 exploit. This time, my router did not hang (although I have read posts by others who state that TARGA3 did hang their router running 1.50).<br><br>The TARGA3 exploit is a malformed packet. So, I am wondering if firmware 1.50 could have a weakness, and as a result, when a specific packet (malformed or otherwise) is received it causes the firmware to crash. That could happen under either high or low load.<br><br>Prior to turning off logging, I observed that my router was often hit by various probes. I wonder if some script kiddie's probe is causing the "router hang" problem. Unfortunately, the BEFW11S4 buffers its logs, so when it hangs, it takes the most recent log entries down with it.  I was never able to correlate anything in the log (as it appeared on my PC's client app) with the router's hang.<br><br>Any thoughts?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9013140</guid>
<pubDate>Thu, 08 Jan 2004 01:02:36 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9012626</link>
<description><![CDATA[<A HREF="/useremail/u/869940"><b>manross</b></A> : My mistake...I have a WRT54G and there is a good 1/2" clearance from case to board.  Nether-the-less not much venting is needed to create a negative pressure at the bottom of the case.  Of course you can do what I did and never worry about heat.......:D<br><br>PS... Disregard the zip file. I was trying to post a picture.  I'll repost when I figure it out:huh:<br><br><IMG SRC="http://www.martysrcboats.com/tpix/fan.jpg"><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap WIDTH=33%><A HREF="/r0/download/506158~655caf533415248ae0220b70c5b100c4/fan.zip"><IMG  align=absmiddle TITLE="download" SRC="http://i.dslr.net/silk/compress.png" border=0 width=16 height=16><IMG SRC="http://i.dslr.net/1ptrans.gif" WIDTH=10 HEIGHT=1 border=0><big>fan.zip</big></A> <small>146 bytes</small><br><small>(fan.jpg)</small></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9012626</guid>
<pubDate>Wed, 07 Jan 2004 23:53:34 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9012569</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : dellswieg,<br><br>Fact: <br>In a lab envirnonment you can crash any router no matter how well you tune its config.  Very simple, use pageant, smartbits, or agilent route injectors and apply and withdraw thousands of BGP or OSPF or even RIP routes per second and in a few minutes you expensive powerful router is toast! You don't even need a traffic load.(Usually not even that long. But boy is it kinda fun!)<br>Do not forget that even though these routers are small they have fairly respectable specs for the processor speeds, and memory and flash sizes.  Do not forget that a Cisco 2600 router has a 50Mhz 486/Pentium class CPU with between 8-16 MB of RAM, and 4 - 32MB of Flash. And that router costs much more.  I have pounded on all sorts of routers. And with its processor memory specs the Linksys should eat up the 2600 but it doesnt.  For comparison the BEFSX41 has a 162Mhz ARM 9 processor, 16MB of RAM and 4MB of Flash! Linksys has a problem with its firmware developement,optimzation, source code versioning, and physical quality control.  All symptoms of the sub $50 prices for a lot of their gear.<br><br>That was it for you.<br><br>Regarding cable internet architecture.  <br>Cable Internet services piggyback off of traditional cable by being Frequency Division Multiplexed into a higher carrier that is filtered out of traditional devices.  Only devices that listen for that carrier can pick it up. The data signal is encoded with 16-64 QAM and can be upwards of 30Mhz of spectral width.  Because of the nature of legacy cable for each neighborhood or collection of neighborhoods there is a cable "node". A cable node is a router with a tie in into the neighborhood cable run.  That same cable run phsically and electricaly connects to EVERY home that recieves cable, even if they do not subscribe to cable internet service. Thus cable is a hubbed architecture. If the cable were switched every home would not be electircally connected to the other. (This is what ethernet switches do, they segment the physical ethernet collision domain into a collision domain per port instead of per switch.) But the cable companies would have to replicate the analog and/or digital baseband video signal to many different physical segments.  Not only would signal quality suffer due to increased load impedance, but costs would skyrocket due to the vastly increased cost of balancing out the impedance load, and building so many different physically seperate cable segments would simply not be pratical. Remember, why does cable get slower as more users use it?  Because it is a shared architecture.  Switches do not have this penalty.<br><br>Do not confuse the cost of little home switches and hubs with the costs of gear that ISP's have to pay.  Their gear has to be reliable and  the firmware needs to be bulletproof, not to mention that the basic technology of cable service just described, at this time mitigates against using cable "switches".<br>Cable modems are indeed the bridges between the cable wire and the ethernet wire.  But only newer cable modems have the built in MAC-Filtering (L2 Bridging) capabilities.  The data is still there on the wire for all to see.<br><br>Regarding heat, this certainly could not hurt any devices.  Go buy some small aluminum heatsinks and glue them to the switch chip and the CPU chip in the linksys routers.  It will help pull the heat out of the silicon mutch better.<br><br>James]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9012569</guid>
<pubDate>Wed, 07 Jan 2004 23:47:43 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9011115</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Hey Marty, have a look inside the box.  You will find that there is a large circuit board (about the size of the footprint) inside.  It completely covers all the holes in the bottom so hardly anything "Convects" to the top holes.  Remove the circuit board and the airflow would be great,  however......you figure it out.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9011115</guid>
<pubDate>Wed, 07 Jan 2004 21:27:07 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9009210</link>
<description><![CDATA[<A HREF="/useremail/u/869940"><b>manross</b></A> : ChrisDat,<br>In regards to the bottom vent holes in conjuction with the design of the case. It's a cheap way to offer cooling without fans.  The cooler air below the router will be sucked up throught the router as the warm air rises out of the top vent holes, I think it's called convection currents.  It does work somewhat....<br>Marty]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9009210</guid>
<pubDate>Wed, 07 Jan 2004 18:29:52 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9008419</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Hey a 1 star General.  Actually Linksys made several different V2 models that were all called V2.  Some had one kind of problem and others had something different.  Several different chipsets were used inside, you had to peek into the box to find out.  Would not be a surprise to me if they are still doing this.  That spreadsheet just keeps on getting bigger and bigger......]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9008419</guid>
<pubDate>Wed, 07 Jan 2004 17:16:24 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9008259</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : Let's all hope the Cisco team can bring something to the table here and not pull a "Microsoft" by buying out a competitor and then droppping the ball.  When you buy a Cisco product you expect nothing less than bulletproof software... Now the Cisco name is at stake.<br><br>Yep, George, my "41" is a v2... Works great though. It's in free air too. I just stacked the boxes for "research purposes" :) Maybe different hardware?<br><br>:) Did anyone notice, I got my first STAR!!! :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9008259</guid>
<pubDate>Wed, 07 Jan 2004 17:01:22 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9007901</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : I did a little check too: BEFW11S4 above a BEFSR41 -- the BEFSR41 supports the WAN and has two active clients... the "11S4" has no active clients and is only attached to the "41", its wan port is not connected.<br><br>Like yours, MY "11S4" was cool as can be ABOVE, below was a different story -- I used a baby thermo in the space between the two boxes ... it maxed out [went off scale high] at >107.6 deg.F.! Beneath the "41" it was warm too, but not as hot, I would assume "room temp" since the baby-t went offscale low [89.6 deg.F.] just like it would do in the open air.<br><br>Activity must contribute to heat production, as my "41" is always busy because I have two systems that constantly talk to each other and the WAN 24/7 [ShoutCAST/WinAMP DSP and ShoutCast DNAS]...<br><br>Anyone else "see/feel anything?"]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9007901</guid>
<pubDate>Wed, 07 Jan 2004 16:24:37 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9007870</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Hi folks, ah yes HEAT.  I have had a few encounters with this issue as well.  A couple of years ago Linksys made a BEFSR41 V2 design that had a chip which ran hot enough to Fry Eggs....The unit kept crashing too, so I cemented a big aluminum heat sink to the chip and left the cover off.  The unit never crashed since and has worked well.  Recently I purchased another BEFSR41 V3 this time.  The V3 unit runs off the same model of wall wart but is hardly warm at all.  Guess the chip makers have made some real progress in the past couple of years.<br><br>Linksys is still using the same Plastic Box enclosure design that they started with.  Frankly I much prefer the Box design that D-Link is using now.  Their box can be placed on end, which I always do, so there is good airflow across the circuit board inside.  The Box has vent holes in each end so it can be installed flat if necessary and still not get too hot.  I found in that case the units run much cooler though if they are placed on end....More grit for the gears to grind.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9007870</guid>
<pubDate>Wed, 07 Jan 2004 16:21:13 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9007489</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : ChrisDAT<br>All of my stuff is on a shelf I built in the top of a hall closet. No special ventilation, door is always closed. The router (BEFW11S4 V4) sits with no cooling restrictions, next to 2 Cisco ATA 186 boxes (stacked), next to the cable modem. Power supplies are on a lower shelf near the power strip.<br>This setup runs 24x7x365.<br><br>I just climbed up a chair to check out the location - No dirt or dust on the unit, the case is not warm to the touch nor does the air feel any warmer above the unit.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9007489</guid>
<pubDate>Wed, 07 Jan 2004 15:41:21 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9007440</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : I just want to mention that HEAT was mentioned in another thread here the other day -- a user opened up his totally dead box that exhibited the "symptoms" mentioned here for some time just before it went kaput, and found a roasted capacitor... [jpalmer]<br><br>Most CPU boxes have cooling fans, LinkSys "BEF" series "blue" boxes have no fans (typical of modems) -- they have cooling holes above and below... in my house dust tends to settle on any horizontal surface over time, I dust my hardware often to clear the holes in the top because if they become filled with dust the internal case temp will kill the electronics inside... The bottom holes are of no use at this point since heat rises.<br><br>Electronics are extremely heat sensitive -- electrical resistance increases with temperature, most electronics are designed to operate within a temp. range [that should also appear in "specifications"] -- "cheaper" electronics have a smaller range than top-shelf electronics. It's not do-or-die, but when the temperature goes out the high end of the temp range strange things happen... too far out of range and... well, we all know the smell.<br><br>Some things are certain... over time, dust settles -- a brand new router will have less restriction to airflow than an older one -- a WIRELESS router, with RF modulators, will generate more heat than one that does not have the wireless stuff... <br><br>I was thinking also about how to address this -- mounting the unit vertically may not help because placing the holes to the side may only allow heat to accumulate in the new "top" [get out the drill?] -- place CPU Fans on top? -- run the LS with the cover off? I'll try some of these myself - and maybe present a case-mod LinkSys for y'all.<br><br>What does YOUR physical location look like? Is the router sandwiched between alot of other stuff? Is there anything stacked on top of it [like another "Blue" box"]... Put your hand above the unit [about an inch or so], you should feel a LOT of heat, more than you can feel below -- if it is hotter below the unit than above, it's likely that the upper holes are restricted -- I use a soft paint brush [without paint :)] to clear them... Without built-in fans, the unit NEEDS free airflow around it. The LS seems to rely on convection, the hot air must escape the top of the case to draw cooler air in the bottom.<br><br>This is not THE answer to the LS "issue," but it is a piece of the puzzle.<br><br><B>"<I>When the only tool you have is a HAMMER, the whole world looks like a NAIL</I>"</B>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9007440</guid>
<pubDate>Wed, 07 Jan 2004 15:35:44 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9006810</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Hey<br>I have both a version 1 and version 4. My Version 1 had been working fine for years, a couple months ago started with the 'hangs'. I figured it was just an old design and bought a V4 back in November. It did the hang thing. I upgraded to 1.50 - same. Information I culled together from Linksys, the network engineers at work and from this group made me try changing some of my settings (MTU, logging, UPnP, lease - you know the drill). The device has been rock solid now for weeks. I did the same drill on my V1 and it works fine too.<br><br>I assume my ISP - Road Runner made changes - the obvious one was a speed increase (2.8/366) - basically double the speed. Who knows what other under the cover changes were made by the ISP as well. <br><br>It is likely that firmware is a contributing factor - programmers are known to be greedy when it comes to runtime. I would hope future releases will optimize code to perform better with the available hardware (mem, cpu). For now - it 'appears' that turning these new features OFF saves processing resources on an already taxed device.<br><br>Other vendors are plagued by the same type issues - without knowing how much memory or CPU speed a vendors device has - well we a shooting in the dark I guess.. Just like our PC's - memory can make or break a system.<br><br>I would doubt that components are inferior in the linksys boxes as compared to anything else in the same price class.  A component failure would generally not be recoverable (ie: a re-boot might not fix it). What we are seeing is more likely due to internal buffer overflows - running out of memory. Program bugs are alot easier to find by the vendor (and fix).<br><br>Have fun<br><br>Dan]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9006810</guid>
<pubDate>Wed, 07 Jan 2004 14:24:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9006659</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : For the second day in a row, my router (BEFW11S4 v4 with firmware 1.50) did not hang overnight. Last change I made was to disable logging. However, my router did hang while I was using my PC during the day. So I cannot conclude that disabling logging has solved the router hang problem.<br><br>As others have mentioned, the Linksys routers do not have much power nor resources, and they could be getting overwhelmed by traffic (and hang). Or, there could be some kind of bug in Linksys' firmware such that a specific set of events (even under low load) causes the router to hang. The fact that other vendor's routers (including older Linksys models) seem to be more solid (see pooter's recent post about his DLINK box) implies that it is possible to make cheap SOHO routers that do the job (even under load) without hanging multiple times per day.<br><br><B>Dellsweig:</B> I can leave my PCs on overnight to see the effect, but since (during the last two days) my router has not hung overnight, but did hang while my PCs were in use during the day, I'm not sure that leaving my PCs on overnight will shed any additional information on the problem. You mentioned that your setup has been solid. Which version of BEFW11S4 do you have? I have v4. I am just wondering if the router hang problem may (in part) be due to Linksys using more inferior components in their newer models (many people with older BEFW11S4s report that their routers do not experince the hang problem). <br><br><B>George Kidd:</B> regarding your concern about the security of financial transactions on a cable connection which is a shared media where all packets on the LAN can be sniffed ... be sure to enter sensitive data (in your browser) only when you have an SSL (HTTPS) session. That will help to protect your data from easily being observed.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9006659</guid>
<pubDate>Wed, 07 Jan 2004 14:07:50 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9005051</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Well I find it quite interesting how Linksys carefully avoids things like Processor Clock Rate, Amount of Flash storage, Amount of RAM etc. in their Specifications.  We always check this kind of stuff when we purchase a PC/MAC and so on.  With Routers we are left to assume that as the costs of these items drop, then newer models will have faster processors and such.  Over time loads on the Internet will have increased so one would expect routers need to be more robust to handle that.....Also increasing Wireless from 11 Mbps to 54 Mbps etc. must place a significant load on devices that handle the Traffic.<br><br>So the question is, what have the manufacturers done about all this if anything.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9005051</guid>
<pubDate>Wed, 07 Jan 2004 10:46:55 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9004682</link>
<description><![CDATA[<A HREF="/useremail/u/727676"><b>pooter</b></A> : The wireless Linksys I bought froze once a day (4 times in 4 days), any time of day with no discernable pattern (my setup details are in an earlier post.)  <br><br>On Sunday, I ran a couple cable runs and put in a refurbished (wired) DLink DI-604.  No freezes in 3 days (logging is enabled.)<br><br>For comparison's sake, I wish I could snag a new wired Linksys and see if that freezes on me.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9004682</guid>
<pubDate>Wed, 07 Jan 2004 09:59:38 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9003990</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> :  <BLOCKQUOTE><SMALL>said by  ToasterMan78 <A HREF="/useremail/u/904557"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR> <BLOCKQUOTE><SMALL>said by someoneyoudonotknow:</SMALL><HR>...Cable is not switched at this time it is simply repeated like a hub. ...[and you can therefore sniff your neighbors traffic]...I use Comcast cable... <HR></BLOCKQUOTE>My understanding is that switches are about the same price as hubs (at least for home users, I assume it carries through on the business end), and it would seem to be insane for a major ISP to use hubs on their network from a network-congestion point of view. Especially with hundreds of people potentially connected to a single node.<br> <HR></BLOCKQUOTE><br><br>If you think about it - a head end device may be responsible for 250 end user nodes. Of those - how many are actually allocated and in use in your neighborhood?? 20% or less - Total broadband users are only at 20% of households - that includes cable and DSL.<br><br>There is alot of traffic on the local segment of the ISP's LAN. You are using a shared resource. In some home installations,there may only be a few active drops - in some MANY active drops....<br><br>Bottom line - the more traffic present, the more traffic your router will have to handle on it's WAN side. From what I read on the boards, ALL the cheap routers have some type of lock-out problems - most likely under load.<br><br>AT the lab where I work, part of our certification of routers for OUR network is to load test them - crash them!! We make sure our configurations work - and tune config parameters if needed. Just remember the router does not have much of a CPU and memory (no P4 and gigs of mem). Think how easily you could crash a 386 box]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9003990</guid>
<pubDate>Wed, 07 Jan 2004 07:57:16 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9003956</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : RDHW<br>You are correct in saying that items such as logging, lease negotiations, encryption do not add to NETWORK overhead substantially.<br><br>We are talking about processing on a hardware device - all of these items take CPU and some take substantial memory (route tables, lease tables). Higher end routers can priorotize these tasks - for example, SNMP runs at a lower priority to prevent polling from effecting router performance - but it is doubtful these low-end devices have such ability.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9003956</guid>
<pubDate>Wed, 07 Jan 2004 07:48:13 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9003910</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Miker<br><br>When I see that replcaeing devices did not effect the situation - I tend to rule out that device as the culprit.. <br>I think (and my own BEFW11S4's) back it out. That it is a cumulative thing. These devices may be running on the edge n some situations - especially in higher load cable situations.<br><br>Can you try leaving everything (PC's) turned on overnight, turn your logging off, turn your WEP off (create MAC access list if you are worried about unauthorized access), set the long lease interval and see what happenes. You can always work backwords from there.<br><br>My setup has been solid for weeks now since I made those changes..<br><br>Think of this simple analogy - you put bucket in the sink and run the faucet. You take a shot glass and one shot at a time, divert the water down the drain. You might be able to keep up with the water level in the bucket for a while. Eventually, you will have to reach away to do something (send a log trap or renew a lease). The water will rise. Eventually the water will win and the bucket will fill (buffer overflow and router freeze). If you speed the water up (ISP speed increase) or add some new overhead, the bucket fills faster.<br><br>The simple fact that you can set your watch by these failures suggest overhead as an issue]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9003910</guid>
<pubDate>Wed, 07 Jan 2004 07:34:27 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9003684</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : You're both right, kinda:<br><br>Cable is a party line, but it is not really ehternet on the cable side, remember it is designed for cable TV, so it is not designed to be "secure." Your cable modem is the bridge that only forwards data destined for your internal network. That means that you cannot "snoop" packets from your side of the cable modem.<br><br>note: DSL works internally the way you expect because the POTS system is switched by nature -- that's one reason why DSL has a design advantage over cable, and that's the primary physical difference detween the two "under the hood."]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9003684</guid>
<pubDate>Wed, 07 Jan 2004 05:48:46 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9003309</link>
<description><![CDATA[<A HREF="/useremail/u/904557"><b>ToasterMan78</b></A> :  <BLOCKQUOTE><SMALL>said by someoneyoudonotknow:</SMALL><HR>...Cable is not switched at this time it is simply repeated like a hub. ...[and you can therefore sniff your neighbors traffic]...I use Comcast cable... <HR></BLOCKQUOTE>My understanding is that switches are about the same price as hubs (at least for home users, I assume it carries through on the business end), and it would seem to be insane for a major ISP to use hubs on their network from a network-congestion point of view. Especially with hundreds of people potentially connected to a single node.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9003309</guid>
<pubDate>Wed, 07 Jan 2004 02:53:20 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9002477</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : @someone (anybody?)  Hmmm   if I get this right and a cable node is the same as a Hub then you can easily do the equivalent of a "Wiretap" on your neighbours.  That should make it relatively easy to discover things like Passwords, Credit Card Numbers etc.  How come the crooks are not doing a land office business on cable then?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9002477</guid>
<pubDate>Wed, 07 Jan 2004 00:11:54 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9002334</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : rdhw,<br><br>You are not correct.  Cable data networks such as comcast are basically a hubbed architecture.  Any traffic that is put out by ANYONE on your neighborhood cable node can be seen and sniffed by ANYONE else.  Cable is not switched at this time it is simply repeated like a hub.  With a router connected into a cable modem you mitagate this somewhat in that other folks can attack you machines directly but they can still see your packets.  I sniff all of the time and you would not believe the traffic that you can see.  I use comcast cable BTW<br><br>James ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9002334</guid>
<pubDate>Tue, 06 Jan 2004 23:51:39 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,9000628</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : After disabling Logging on my BEFW11S4 v4 (firmware 1,50) last night, I noticed that it did not hang (as usual) over night.<br><br>I was all set to celebrate (hoping to have found a resolution to the hang problem). Unfortunately, my router hung this afternoon. <br><br>So, it appears that disabling logging on the router is not the silver bullet that will kill the "router hang beast".  SIGH.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,9000628</guid>
<pubDate>Tue, 06 Jan 2004 21:19:19 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8999548</link>
<description><![CDATA[<A HREF="/useremail/u/904557"><b>ToasterMan78</b></A> :  <BLOCKQUOTE><SMALL>said by  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>...the "hanging" problem experienced by... routers... may be due to these devices not having enough processing power and/or resources (RAM, etc) to handle the load.... <HR></BLOCKQUOTE>One problem is that  manufacturers of home-class products (AFAIK) do not list the CPU, RAM, etc in the product specifications for their routers, etc. I wonder if there is any independent website(s) that would have this info? I suspect not. But it would probably be an eye-opener.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8999548</guid>
<pubDate>Tue, 06 Jan 2004 19:43:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8995077</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : How about Cable -v- DSL?<br><br>I have DSL and a BEFSR41v2 router w/FW v1.45.7 and the one before that, that has been bulletproof since I got it in FEB 2002 --- No DHCP, no Multicast forwarding -- I don't do VPN, but I host several Apache servers (on different ports) supporting downloads, and TWO ShoutCAST streams that are busy 24/7... all this from a "modest" residential 640/128 Verizon DSL. It gets dead slow under load, but it does not die.<br><br>The modem is a Westell InfoSpeed Bellatlantic branded modem with one Flash upgrade.<br><br>Internally I run MS networking to share disks over IPX [Ethernet_802.3] just because it's faster.<br><br>I wonder if the connection type has anything to do with this puzzle?<br><br>(Just another thought: I wonder, what happens when the LinkSys DHCP expires leases while the clients are shut off? ie: how hard does it try to contact them? and what does it do when it cannot?)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8995077</guid>
<pubDate>Tue, 06 Jan 2004 12:27:40 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8994969</link>
<description><![CDATA[<A HREF="/useremail/u/691919"><b>rdhw</b></A> :  <BLOCKQUOTE><SMALL>said by  dellsweig <A HREF="/useremail/u/911537"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>Our routers 'see' all traffic on the local ISP switch - it has to process all of your neighbors traffic to too.<HR></BLOCKQUOTE>No: on a cable modem system, none of your neighbour's traffic gets through your cable modem (if this were not so, the security implications would be immense).  All that comes through your cable modem is traffic addressed to this particular customer, plus any broadcasts (ARP, DHCP) from the head end that are essential for the correct operation of IP networks.  The bandwidth taken by those head-end broadcasts is trivial and not an issue.<br><br>The other things you mention (logging, UPnP, DHCP leases, etc) are also trivial in terms of network loading.  Whatever is causing the problems you are suffering from, it isn't network loading from having these options active.<br><SMALL>--<br>Robin Walker &raquo;<A HREF="http://homepage.ntlworld.com/robin.d.h.walker/" >homepage.ntlworld.com/robin.d.h.walker/</A> for broadband troubleshooting tips</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8994969</guid>
<pubDate>Tue, 06 Jan 2004 12:16:52 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8992217</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : Most of the recent posts here seem to conclude that the "hanging" problem experienced by the Linksys BEFW11S4 (and/or any other "cheap" routers) may be due to these devices not having enough processing power and/or resources (RAM, etc) to handle the load. Thus, they periodically freeze/hang. Sounds reasonable to me. Although, it seems as though only the more recent models of Linksys hardware are experiencing this problem ... owners of the older models seem to be saying that their routers are solid. Could it be that Linksys has started using inferior components in their more recent models (this is only a conjecture, not an accusation).<br><br>Based upon the configs (of "working" routers) collected by dellsweig, I will disable logging and see if that helps to resolve the router hang problem I'm experiencing. I have already set my DHCP lease interval to 32767 (but that alone did not resolve the problem). If that does not work, I will just disable DHCP and assign static IP addresses. <br><br>I am using WEP, and really do not want to disable it. I live in a high density area where many of my neighbors' wireless APs are visible to me, so my AP must be visible to them. Even with its shortcomings, I'd rather have WEP enabled to stop the curious lurkers and rookie hackers, than just leaving my AP wide open.<br><br>In my case, the hang often (at least 90% of the time) occurs over night (between the time I power off my PCs and go to sleep, and when I reboot in the morning and find that the router has hung). During this time, there could be incoming packets destined for my router's IP address that overwhelm the router's resources and cause it to hang, but there is no traffic to/from the PCs on my LAN (they are powered off at the time). I have "Block Anonymous Internet Requests" and "Filter Multicast" both enabled to help reduce the exposure of my router. As dellsweig mentions, the problem may be caused by other traffic on my cable (not necessarily traffic destined for me, but traffic that my router must process to determine that it can ignore the packets).<br><br>MSNhurts asks whom to be angry at (Linksys or Cisco) for releasing a firmware upgrade that re-introduced a problem that had, at one time, been solved. My guess is: be angry at Linksys. Having been through a corporate "take over" (like Cisco buying Linksys), I believe it takes more than a year for a large parent corporation (Cisco) to impose its culture (and the resulting improvements in quality and reliability) on the newly acquired subsidiary. Cisco only bought Linksys early in 2003. <br><br>Cisco could have set a high objective for Linksys' bottom line, and to achieve their financial objective, Linksys may have found that they needed to use less reliable components in their newer models (and spend less staff resources solving firmware problems reported on their products). Again, this is only my conjecture. It certainly would be nice to get Linksys' side of this issue.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8992217</guid>
<pubDate>Tue, 06 Jan 2004 01:19:39 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8991190</link>
<description><![CDATA[<A HREF="/useremail/u/920917"><b>MSNhurts</b></A> : My router used to hang constantly, and then I upgraded to 1.44 or 1.45 (forget) - and it worked great. Then, in hopes of WPA, I upgraded to 1.5 - now all the convenience of wireless is lost because every 10 minutes (ok, not quiet that often) I have to get up and go reset the router. Is this the first upgrade since Cisco acquired linksys? I want to know who to be pissed at for releasing a firmware upgrade that re-introduced a problem that had, at one time, been solved. At least the firmware reminds me of who I can likely thank - Linksys *A division of Cisco, inc.*]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8991190</guid>
<pubDate>Mon, 05 Jan 2004 23:02:43 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8990667</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : dellsweig,<br><br>I use WPA exclusively and it works just fine.  As far as microsoft not working with vendor xyz you are incorrect.  At this point microsoft XP is the ONLY game in town if you want to use WPA.(I don't feel like paying for the odyssey client.)  Admittedly the wirless client in XP is buggy. I must say I have rolled out a couple of these types of wireless networks for customers and it works perfectly.  Now you must patch the XP wireless client twice for it to work properly.<br>As far as DHPC and UPnP and advanced features using CPU overhead.  I have run NAT, Firewalling ACLs, DHPC server, syslog, SNMP polling and trapping, and quite a bit more but my memory is failing at the moment.  The point is all of these proccesses were run on a platform with a 40 Mhz 386 Equivalent CPU with 4MB of RAM. (Cisco 2500 series)  Now I do realize that these are Cisco boxes, I am just trying to show that yes the processes use CPU and memory it is not as bad as you might think.  These small routers run with 125Mhz to 200Mhz processors in them!  Hell 3 years ago my core router for 140,000 end users only had a 200Mhz processor! (MIPS R5000) The difference is the software running on the platform, and linksys does not spend the appropriate resources in this area to make things work properly.  (Cisco/Juniper spend a large amount of money and software developement)  Linksys boxes are way to cheap to recieve that kind of treatment. <br><br>James]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8990667</guid>
<pubDate>Mon, 05 Jan 2004 22:07:30 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8988962</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Chris<br><br>I have to agree... Logging, encryption, UPnP, lease renewal - all of the 'advanced' features of the linky add overhead. Overhead means CPU and memory resources. Every CPU cycle the CPU spends processing a logging trap is time spent NOT processing IP Packets. Our routers 'see' all traffic on the local ISP switch - it has to process all of your neighbors traffic to too. It may not route it but it has to look at the packet to 'see' if it is important. The more extra tasks you can turn off - the better the odds the router will survive. Alot of people have noticed that their problems started at some point in time - did your ISP's increase your bandwidth about that time? Mine did and thats when the lockups started.<br><br>Of the folks that sent me some of their config parameters - ALL of the 'working' routers had logging off, DHCP set to long intervals and no WEP or WPA<br><br>Just an observation........<br><br>I remember having to re-boot my computer all the time too - I would run too many programs at once.... Growing pains...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8988962</guid>
<pubDate>Mon, 05 Jan 2004 19:22:35 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8988770</link>
<description><![CDATA[<A HREF="/useremail/u/904557"><b>ToasterMan78</b></A> :  <BLOCKQUOTE><SMALL>said by  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>...running wires to the room where my wife's PC is located is not an option ... <HR></BLOCKQUOTE>I suspect you don&#146;t want to damage your house by drilling to run wires. I had a friend who had Comcast cable TV installed, and before he could say &#147;don&#146;t drill through the hardwood floor&#148; the Comcast guy did just that.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8988770</guid>
<pubDate>Mon, 05 Jan 2004 19:02:59 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8988756</link>
<description><![CDATA[<A HREF="/useremail/u/591864"><b>ChrisDAT</b></A> : DHCP seems to be a contributor here... Does anyone have good performance with DHCP off --- You really dont need DHCP with less than 10 or so clients, it's easier and more stable to assign IPs, especially if you expect the machines to communicate with each other...<br><br>To add to that... For a "cheapie" NAT/Router, I would guess that the LinkSys suffers from poor packet buffering, both on the Switch/LAN side, and especially on the NAT/Router/Wan side, where a few, fat 100BaseTX boxes have to squeeze into a 10BaseT cable or DSL modem, which then squeezes into what amounts to a 1Mbit or so broadband connection... Routers hang and drop packets when their input buffer is full. I don't know if any linksys product sends source quench messages (probably not) to protect themselves, and many Windows implimentations have a tendency to free-flow (ignoring them anyway).  The switches do not have (give) the ability to set the Duplex of the individual ports, this is important, because you really have no reason running full duplex (collision avoidance/detection is off here) on a small lan, and that can make the problem far worse since your cable/DSL modem is certainly half-duplex and supports CSMA/CD(sp.).<br><br>Overall the problem may be that the LinkSys may suffer from small buffers (not enough RAM) and trying to act like a big boy so that the little guy can take advantage of what is usually high-buck hardware... My suggestion, only use what you need, DHCP and logging require tables, not using them may free up more packet memory, especially if you're having big problems... Turn off that ZoneAlarm, the UPnP, and let the router concentrate on NAT.<br> ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8988756</guid>
<pubDate>Mon, 05 Jan 2004 19:01:48 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8988556</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : ToasterMan:<br><br>Thanks.<br><br>The PCs that I use at home are wired to the BEFW11S4. When it hangs, my wired connections are down (until I reboot).<br><br>My wife's PC (in another room of the house) connects wirelessly to the BEFW11S4.<br><br>Prior to my wife getting her PC (last Oct), I was in an all wired configuration (and did not have any problems - I used a different vendor's hub to connect my PCs).<br><br>When my wife bought her PC, I installed a BEFW11S4 to serve as a wireless AP and router. That's when I began having reliability problems caused by the BEFW11S4 hanging. I could probably move my wired PCs to a different (non-Linksys) device, but I'd still have the Linksys box to contend with for my wife's wireless connection (running wires to the room where my wife's PC is located is not an option ... I will need some kind of wireless AP in my network ... Linksys or otherwise). ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8988556</guid>
<pubDate>Mon, 05 Jan 2004 18:44:27 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8988380</link>
<description><![CDATA[<A HREF="/useremail/u/904557"><b>ToasterMan78</b></A> :  <BLOCKQUOTE><SMALL>said by  biker45 <A HREF="/useremail/u/888461"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>Any other thoughts/suggestions would be appreciated. <br> <HR></BLOCKQUOTE>Probably others have mentioned this to you, but wired setups are intrinsically more stable than wireless setups. I don't know how long you have had problems (I see you have posted in other threads on your BEFW11), but it may be time to move to a wired setup.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8988380</guid>
<pubDate>Mon, 05 Jan 2004 18:24:20 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8987981</link>
<description><![CDATA[<A HREF="/useremail/u/748241"><b>mikeyuf</b></A> : Well, Im having all the same problems.. But Im trying to to find 1.45.7? anyone have it?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8987981</guid>
<pubDate>Mon, 05 Jan 2004 17:46:48 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8985500</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : Dan:<br><br>Setting DHCP lease interval to 32767 in BEFW11S4 v4, to try and resolve the router hang problem, did not work. <br><br>Router was in a hung state when I booted my PC this morning and attempted to access the net (i.e., pings to the inside IP address, 192.168.1.1, failed). After power cycling the router, the problem cleared as usual.<br><br>I leave my router and cable modem powered on 24x7, but I shut down my PCs at night. Before shutting down last night, I verified that the router was not hung. When I booted my wired PC this morning, I found the router was hung (pings to 192.168.1.1 confirmed the hang). Nothing in the router's log indicated a problem. <br><br>After booting in the morning is typically when I first encounter the router hang problem. The router hang problem occurs regardless of whether I boot my wired or wireless PC. Subsequent boots of either PC do not cause the router to hang (so booting is not causing the problem). Also, on rare occasions, I find that the router is not hung when I first boot my PCs in the morning.<br><br>Often during the day (with my PCs already booted), I will notice that I cannot access a web site. Subsequent pings to 192.168.1.1 fail, indicating that the router has hung again. On rare occasions, I can get through an entire day without a hang, but not often.<br><br>I really hoped that setting the DHCP lease time to 32767 would solve the problem, but I guess I won't be that lucky.<br><br>Since the hang often occurs at night when my PCs are down, I am wondering if the catalyst for the hang is something that my cable company is doing/sending. I guess I could power down my cable modem over night, leave the router powered up, and see if the router hangs (over night). If so, that would eliminate my cable company from the list of usual suspects.<br><br>Any other thoughts/suggestions would be appreciated. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8985500</guid>
<pubDate>Mon, 05 Jan 2004 13:40:55 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router proble</title>
<link>http://www.dslreports.com/forum/remark,8985052</link>
<description><![CDATA[<A HREF="/useremail/u/720248"><b>Johkal</b></A> : Flash back to 1.45.7]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8985052</guid>
<pubDate>Mon, 05 Jan 2004 12:54:42 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8984971</link>
<description><![CDATA[<A HREF="/useremail/u/727676"><b>pooter</b></A> : I bought a new  BEFSW11S4 V4 last week and upgraded it to firmware 1.50 first thing.  It has up to 4 clients and froze once a day. <br><br>UPnP: off<br>WEP: enabled<br>WPA: off<br>Log: enabled<br>MTU: default<br>DHCP:default<br>SSID: broadcast disabled<br>Port Forwarding: Yes - 1 port<br>Filter Ports: none<br><br>Edit: I forgot to mention, I could not detect any patterns regarding the router hanging.  Twice it happened overnight when the router was not in use (all PCs and other Internet devices were turned off.)  Once it happened while I was using XBox Live and the other time it happened while surfing.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8984971</guid>
<pubDate>Mon, 05 Jan 2004 12:46:17 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8982991</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Biker...<br><br>Way back (a whole year ago) when I was setting my Vonage ATA to work with the Linksys, I was having a problem where the ATA would 'lock up' once a day. The techs at Vonage suggested I try increasing the lease time - and guess what - it solved the problem... Maybe there is some obscure handshake the Linky tries which blows some DHCP client implementations out or some message the DHCP server in the linky does not like but it worked..<br><br>Did the change effect your problem?? did the 'problem' interval change?? There really isnt that many things in your linky that are clock driven like the lease interval.<br><br>Dan]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8982991</guid>
<pubDate>Mon, 05 Jan 2004 07:21:09 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8977035</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : dellsweig:<br><br>I received your email with suggestion that I change my DHCP lease interval to 32767.<br><br>You have a good point. The router hang problem could be related to its processing of the DHCP lease renewal. <br><br>I just changed my lease expiration to 32767 and will post results in this thread.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8977035</guid>
<pubDate>Sun, 04 Jan 2004 15:59:12 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8976076</link>
<description><![CDATA[<A HREF="/useremail/u/166306"><b>Jan Janowski</b></A> : My problem is I either mis-interpret the manual, or over-interpret what I read in the manual.... Which gets complicated by things in manual being covered in less detail than what I needed, and an occasional breaking of features in later version firmware.... and me running around trying to determine what I did to kill it.<br><br>I would say that more than 70% of the problems I've encountered are of this type.<br><SMALL>--<br>Looking for 1939 Indian Motocycle</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8976076</guid>
<pubDate>Sun, 04 Jan 2004 14:12:24 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8975861</link>
<description><![CDATA[<A HREF="/useremail/u/888461"><b>biker45</b></A> : dellsweig:<br><br>Thanks for your initiative to try and figure out the cause of the dreaded router hang problem.<br><br>Here's my info...<br><br>Router: BEFSW11S4 V4 (firmware 1.50) Locks/freezes approx twice per day (2 clients). Problem also occurred with older firmware 1.45.7 and 1.45.3<br> <br>UPnP: off<br>WEP: enabled<br>WPA: off<br>Log: enabled<br>MTU: 1500 (previously set to 1400 but problem persisted)<br>DHCP Lease: 0 (label on config setting states that 0 minutes implies one day)<br>SSID: broadcast disabled<br>Port Forwarding: Yes - 1 port<br>Filter Ports: Yes, 4 ports]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8975861</guid>
<pubDate>Sun, 04 Jan 2004 13:49:28 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8974010</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Who-ever Hofbrau is needs to get some sleep....<br><br>Pretty sad when you cant try to share the experience of others out here to help the folks coming here to solve their problems without getting slammed.<br><br>Sounds like a real friendly guy ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8974010</guid>
<pubDate>Sun, 04 Jan 2004 09:23:44 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8971846</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Yup, that about covers the problems.  Does NE1 have some "Good" Working Answers/Solutions that we can all put to good use?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8971846</guid>
<pubDate>Sat, 03 Jan 2004 23:51:54 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8966201</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : JJ<br><br>I agree - look before you leap BUT - many will find that PnP is killing them - add in WPA and well - you see the posts... The specs for PnP allow vendors to do their own things - without concern for inter-operability. I have not read the WPA specs carefully but I am sure Microsofts implementation does not always play with vender 'xyz' implementation....<br><br>Just trying to get folks to see that if you dont need it - turn it off.<br><br>If there are specific port forward requirements - forward them - dont use PnP.... If there is a home security requirement - use MAC filtering - do't screw around with WPA...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8966201</guid>
<pubDate>Sat, 03 Jan 2004 12:41:28 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8966175</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Ok - I will start:<br><br>BEFSW11S4 V4 (1.50) No Locks or freezes (8 clients) <br>PnP: off<br>WEP: off<br>WPA: off<br>Log: off<br>MTU: 1400<br>DHCP Lease: 32767<br>SSID: broadcast enabled<br>Port Forwarding: Yes - 2 port ranges<br>                     <br>BEFW11S4 V1 (1.44.2) No Locks or Freezes (6 clients)<br>PnP: off<br>WEP: off<br>Log: off<br>MTU: 1400<br>DHCP Lease: 32767<br>SSID: broadcast enabled<br>Port Forwarding: no]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8966175</guid>
<pubDate>Sat, 03 Jan 2004 12:37:49 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8966168</link>
<description><![CDATA[<A HREF="/useremail/u/599681"><b>JJ_Mclure</b></A> : i understans the common thread model.  but isn't that like a stitch in time saves nine.  Or, look before you leap.  <br><br>think people that threads come in many varieties.  Clothes, CPU Multitasking,  sewing,  Lines of code Etc. Etc.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8966168</guid>
<pubDate>Sat, 03 Jan 2004 12:36:59 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8965957</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : if you inlude router model, firmware rev with the things like PnP off - I will cut this stuff into a spreadsheet.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965957</guid>
<pubDate>Sat, 03 Jan 2004 12:13:34 EDT</pubDate>
</item>

<item>
<title>Re: Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8965904</link>
<description><![CDATA[<A HREF="/useremail/u/447958"><b>George Kidd</b></A> : Well folks, one approach is, I always leave uPnP turned "Off", and I avoid Wireless stuff.  I am using ADSL and as a result have not had many of the problems mentioned.  For me it "Just Works".....Happyness is...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965904</guid>
<pubDate>Sat, 03 Jan 2004 12:06:46 EDT</pubDate>
</item>

<item>
<title>Re: Common Thread for router problems</title>
<link>http://www.dslreports.com/forum/remark,8965590</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Not a common thread for router problems - well maybe so - <br>It is just here in the Linksys forwum - if you dig down, you will find a few common configuration settings to those who are ready to throw out thier Linkys.... These folks will most likely find similar problems when they bo buy a Dlink, or SMC or Netgear... I bet when they step back and look, PnP, WEP/WPA, MTU and/or Logging will all have some overlap.<br><br>This might just give some folksa push to look at these things before they complain... The UPnP is a big player here - there is a reason Linksys did not rush to embrace the 'standard']]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965590</guid>
<pubDate>Sat, 03 Jan 2004 11:23:22 EDT</pubDate>
</item>

<item>
<title>Re: Common Thread for router problems</title>
<link>http://www.dslreports.com/forum/remark,8965561</link>
<description><![CDATA[<A HREF="/useremail/u/589568"><b>streetwolf</b></A> : Are you sure you really want a common thread for Router Problems?  It would be like me having a common thread why I can't get a date.  Way to long :-)<br><SMALL>--<br></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965561</guid>
<pubDate>Sat, 03 Jan 2004 11:18:30 EDT</pubDate>
</item>

<item>
<title>Re: Common Thread for router problems</title>
<link>http://www.dslreports.com/forum/remark,8965386</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Some more info.... <br><br>90% of you out there dont have a clue as to what PnP is or does and how it effects your network.<br><br>&raquo;<A HREF="http://www.coternet.com/resource/article/upnp/upnp.htm" >www.coternet.com/resource/articl&middot;&middot;&middot;upnp.htm</A><br><br>Many vendors - including Linksys - have not embraced UPnP due to its inherent security and stability issues. The spec allows each individual vendor to make extenstions which dont necessarily play together either!!There is little or no security in UPnP as well - ANY application - web based ort local - can reconfigure your router - turn on or off port forwarding, effect routes, DNS servers, you name it...<br><br>Kind of like leaving the keys in the car and wondering why the gas tank is sometimes empty......]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965386</guid>
<pubDate>Sat, 03 Jan 2004 10:50:03 EDT</pubDate>
</item>

<item>
<title>Looking for the Common Thread in router problems</title>
<link>http://www.dslreports.com/forum/remark,8965318</link>
<description><![CDATA[<A HREF="/useremail/u/911537"><b>dellsweig</b></A> : Ok All<br>Instead of guessign what everyone is trying to do with their home networks (games, browsing, etc,etc,etc) - Why dont yo post the major congifg items that are in place at the time of your router crash/hang. <br><br>Maybe we will all see the common thread<br><br>PnP (on or off)<br>Security (WEP, WPA, None)<br>Logging (on or off)<br>MTU Setting<br>Port FOrwarding <br>DHCP Client lease time<br><br>I bet we find a common thread here - Like PnP <br><br>Logic tells me that with all the complaining going on about the hardware - there is something else we arent talking about which is behind this all]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8965318</guid>
<pubDate>Sat, 03 Jan 2004 10:39:35 EDT</pubDate>
</item>

</channel>
</rss>
