Re: Wireless router safety and vulnerabilities
- From: phil-news-nospam@xxxxxxxx
- Date: 31 Jul 2006 02:38:01 GMT
On Sun, 30 Jul 2006 14:57:51 -0700 Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx hath wroth:
|
|>On Sun, 30 Jul 2006 10:48:57 -0700 Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx> wrote:
|>
|>| Try holding down the reset button for a continuous 60 seconds. I'm
|>| not sure of the official length of time that it has to be held but 60
|>| seconds should do the trick. Anything less just does a reboot.
|
|>My guess, from a design perspective, is that the button would have to
|>be held down for at least as long as the reboot sequence. 60 seconds
|>should be a workable value as I believe reboots should not take so long.
|
| Assumption, the mother of all screwups. Reset to defaults requires
| copying values from out of backup flash ram somewhere, into the active
| part of flash. This is not done in a normal reboot.
I never said anything to the contrary.
| The consensus for the "long reset" varies from 10 to 30 seconds. See:
| http://www.dslreports.com/forum/remark,2929828
But the 60 seconds you stated would likely still work. Just takes
longer.
| My guess(tm) is:
| Less than 10 seconds is a soft reboot.
| About 10 seconds or more is the same as a power cycle reset.
That could well be how many things are designed.
| Over about 30 seconds clears everything.
| I've found that I sometimes have to power cycle the router after doing
| a reset (and after the flashing lights settle). I think the 60 second
| reset came from a bug in one of the BEFSR41 firmware releases, that
| really did require over 45 seconds to reset to defaults. Play it safe
| and use 60 seconds.
I'd agree. And some router models may take longer to boot.
|>But if all else has failed and you would
|>otherwise have a brick anyway, power on plus held reset can't make it
|>get much worse.
|
| In the distant past, I recovered approximately 3ea BEFSR41 routers
| from failed flash updates using tftp. No big deal.
Great. So what was reading the TFTP? Not the flashed code that wasn't
there. Maybe the power on initial ROM code?
|>The objective is then to get the call over with as soon
|>as possible during periods the call volume exceeds the scheduled staffing
|>so they can take all the calls they can get. Telling someone it's fried
|>is more likely to get the caller to conclude so they can move on to the
|>next call. In many of these operations, the staff will be paid per call
|>as well. In some others, staff are given a call quota and may be let go
|>if they repeatedly fall below quota.
|
| Yeah, that's possible except for one minor detail. If they hangup
| first, they don't get "credit" for the call. The customer has to
| declare that the problem is solved. I suspect this is not universal
| policy with outsourced support, but it's the policy of the support
| pool that I have to deal with.
That was the policy where my friend worked. It is an important enough
detail to understand why they might say "your router is fried". They
may get off the phone because there's nothing more to do but get angry
and look around for someone to blame before going out and buying a new
router from a different vendor.
|>Local point to point file transfer (e.g. not involving the internet)
|>could conceivably get very close to 1.0 TX time factor. Not that I'm
|>worried about such a thing.
|
| Got a time slot for the ACK's and inter-packet delays?
TCP windowing would let a few packets flow before the ACKs are actually
needed back. So there won't be full trip wait, at least for a while.
The ACKs are short. Inter-packet delays for radio reason? That I
cannot really say. Of course it's never really as fast as they say it
will be.
|>Without encryption, the traffic is in the clear, including the MAC
|>addresses.
|
| Even with encryption, the MAC addresses are sent in the clear.
Oooh, now that's dumb.
| Management and flow control frames are NOT encrypted (or
| authenticated). That's why spoofed deauth and deassociate attacks
| work on WEP. Even in WPA and 802.11i, management frames are not
| protected.
More dumb.
Everything ... NO exceptions ... should be encrypted when encryption
is specified. If the receiver gets carrier, sync, and data, but does
not have the key to decrypt it (or more specifically, if the key it
does have produces garbage as it would certainly see a checksum error),
it should just discard it and wait for the next event.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-30-2122@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- Follow-Ups:
- Re: Wireless router safety and vulnerabilities
- From: Jeff Liebermann
- Re: Wireless router safety and vulnerabilities
- References:
- Wireless router safety and vulnerabilities
- From: mp898
- Re: Wireless router safety and vulnerabilities
- From: Jeff Liebermann
- Re: Wireless router safety and vulnerabilities
- From: phil-news-nospam
- Re: Wireless router safety and vulnerabilities
- From: Jeff Liebermann
- Wireless router safety and vulnerabilities
- Prev by Date: Re: Wireless router safety and vulnerabilities
- Next by Date: Re: Need multiple internet IP's for 2 home pc's on router.
- Previous by thread: Re: Wireless router safety and vulnerabilities
- Next by thread: Re: Wireless router safety and vulnerabilities
- Index(es):
Relevant Pages
|
