Arggh.. If the router reboots over and over again, I would suspect that it would be something, but otherwise I would guess it is probably an EEPROM is going bad. Try cleaning out the dust bunnies from the fan, and most likely the problem might clear itself.. /m At 02:53 PM 6/12/2001 -0400, Brian Ford wrote: >David, > >It's a R O U T E R. > >Try sending over size packets. Properly configured R O U T E Rs just take >the packets, chunk them up differently based on MTUs and forward them out >another interface. They don't care about putting all the packets back >together to process some message from another device. IF they do they are >probably doing a non routing (i.e. gateway) function. > >Regarding "which counter", this isn't open source code. You and Dave have >no idea as to which counter got a bad value because you have no idea what >the code base looks like. You could spend months or years and never >re-create this fault. > >The reality is that this as probably just a static discharge from the >serial line (or other temporary environmental problem) that caused the >router to corrupt some bits and power cycle. And the router did power >cycle and come back up. And this router has been in place for at least 3 >years without incident. And this router has been working correctly ever >since. Period. > >Isn't this a "firewall" list. > >Regards, > >Brian > >At 04:30 PM 6/12/2001 +0000, Firewalls-Digest wrote: >>Date: Tue, 12 Jun 2001 08:58:26 -0700 >>From: dgillett@deepforest.org >>Subject: Re: cisco reboot >> >> > So David how do you create a buffer overflow condition on this >> > router? Hmm? >> >> Send an oversize packet to one of its interfaces, I expect, just as >>one does with any other kind of net-connected computer. >> >> > And Dave which counter got a bad value? >> >> If you've *ever* worked at the assembler/machine-language level on >>any mainstream CPU architecture, you will have been introduced to a >>register (or register-pair) called the "program counter", which >>contains the address of the next instruction to be executed. >> Most instructions include, as a side-effect, incrementing this >>register by an appropriate amount. JUMP instructions overwrite the >>register contents with a new address. CALL instructions save the old >>address to the stack first, and RETURN instructions pop a value from >>the stack which is *supposed* to have been saved there by a CALL. >> >>1. Exploitable buffer overflows typically involve a buffer allocated >>on the stack, so that the overflow corrupts the return address. >> >>2. "Bus error" is how several of the CPUs Cisco has used signal that >>they have tried to access memory using an address that is invalid >>because it is not properly aligned. >> >> Dave's suggestion is that the bad address could have been the >>program counter value. My elaboration is that a bad program counter >>value could be the result of stack corruption caused by a buffer >>overflow. >> >>David Gillett > >- >[To unsubscribe, send mail to majordomo@lists.gnac.net with >"unsubscribe firewalls" in the body of the message.] - [To unsubscribe, send mail to majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.]