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: [EMAIL PROTECTED]
>>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 [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
