The only way I was able to keep the 675 from requiring a power recycle was to set a filter to disable incoming port 80 altogether. If you're not running a webserver behind the router, disabling the web interface and changing the "webserver" port to something other than 80, both on the 675, will work fine. Unfortunately, anything that listens on port 80 BEHIND the 675 that responds WILL crash the 675, regardless of what you do to the web service on the 675. Apparently, the deny all incoming port 80 filter prevents the router from evaluating the packet(s), preventing the crash. Short of that, it seems we're SOL until Cisco fixes this shit. I tested this by making sure the web interface was disabled, and changed the default port it would listen on to (59059). then turned off filter I'd set to prevent the traffic entirely, allowing it through to my web server on port 80, and within 1/2 hr, I had 6 CR probes (logged on my webserver), and the 675 had crashed. Turning the incoming port 80 denied filter back on once again prevented the crash, and has continued to prevent any crashing. Good thing my webserver isn't critical, though I suspect there are plenty of folks who require their webservers to be alive behind their 675...small business customers, etc... <rant> Cisco: WTF?! How about getting your shit together and fixing this CBOS crapware!!! 2.4.2 is STILL susceptible to this nonsense?!?! </rant> my $0.02, G At 08:46 PM 8/5/01 -0700, you wrote: >On Sun, 5 Aug 2001, terry white wrote: > > > on "8-5-2001" "John Nemeth" writ: > > > > : I have a 3Com CoreBuilder 3500 running software version 2.1.0 that > > : has been falling over a lot over the last few days. > > > > : NOTE: I don't have any proof that it is CodeRed that is causing the > > : CoreBuilder to fall over, but it is highly likely. > > > > ... i've noticed a similar problem with a cisco 675 ADSL router. in > > particular, i've had to do a cold boot three (3) times 'since' the CR-II > > attack started. i had disabled the web command interface, and checking > > revealed that still the case. > > > > what i did however, was to assign a port other than the default > > (sorry) of '80'. the device has been up 21 hours, despite an order of > > magnitude greater CR-II attempts. my server is not published, but in the > > last 5 days, i've seen 22, 25, 25, 47, and 60 (so far today: ~16:00 PDT) > > events ... > > >I have a very similar problem as well. I have a Cisco 675 and it has been >crashing all weekened. I was running CBOS 2.20 and recently upgraded to >2.4.2 but it failed again after the upgrade. I have hit seven power >cycles this weekend alone. I have also changed the port number to see if >it makes any difference. It is a great suggestion. I tried a simple >telnet to the router and noticed that even with the web interface disabled >it still responds at the lower level. What I mean is that if the port >number is set to 80 and I do a "telnet routeraddress 80" I get back a > >Connected to routeraddress. >Escape character is '^]'. >Connection closed by foreign host. > >But if I move the port the web interface is set to then the response on >port 80 is different. It will just time out with no response at all. > >A note on the CBOS versions. When the unit crashed with 2.2.0 it would >not respond at all on the serial interface. With 2.4.2 it will respond >with a debug prompt "=>". > > >Randy > > >---------------------------------------------------------------------------- >This list is provided by the SecurityFocus ARIS analyzer service. >For more information on this free incident handling, management >and tracking system please see: http://aris.securityfocus.com ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 08:34:11 PDT