Wireless router safety and vulnerabilities

I have happily had the same Linksys router (BEFSR41) for a few years
now and just lately have had issues with no connectivity. It is now
disconnected and I am directly connected to the modem. I went thru the
Support folks at Linksys in India and after multiple attempts to reset
both the modem and the router AND attempting to use, unsuccessfully,
specific Linksys addresses; they came to the conclusion that the router
was fried. This started last Thursday around the same time as Zonealarm
was updated coincidentally or not...who knows.
So, now I have a new Linksys wireless G router (so my wife whose office
is upstairs can connect to my hi speed connection wirelessly); I have
not hooked it up yet BUT I am now having belated concerns about
microwave emissions/radiation toasting my gonads over time (the router
is on top of my computer case under my desk). So I guess the questions
are:
How dangerous is a wireless router to one's health; in truth?
Is there a "safe" distance to place a wirless router from one's body so
as to not roast one's "gonads"?
I heard you can "lock down" a wirelss router by using the specific MAC
address of the "only" computer I want sharing the network (my wife's
upstairs) Will my computer be safe?
Finally, is my computer in essence 'hardwired' since the cable
connection goes straight into the modem and then a cable into the
router which is connected by cable directly to my computer with the
router 'transmitting' that signal 'wirelessly' to my wife's computer
upstairs) OR is my computer also 'broadcasting'?

Kinda long sorry,
Thanks in advance

mp898@hotmail.com hath wroth:

>...unsuccessfully,
>specific Linksys addresses; they came to the conclusion that the router
>was fried.

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.

Some hardware versions of the BEFSR41 had the irritating habit of
corrupting its flash memory. If you can get to the web based config
page, you might try updating the flash to revive it.

It may actually be fried but you can usually tell by watching the
lights on the front panel.

India will ALWAYS say that it's fried so Linksys can sell you a new
router. Nicely done.

>This started last Thursday around the same time as Zonealarm
>was updated coincidentally or not...who knows.

Last Thursday, I also shoved pins into a Linksys router. I probably
caused your router to fail via voodoo.

>How dangerous is a wireless router to one's health; in truth?

There are no truths. Only research, tests, specifications, FAQ's, and
political agendas. There are web sites that claim everything from
grevious harm at any power level. The problem is that it's very
difficult to prove a negative, in that RF does *NOT* create any
problems. Need a list of likely candidate sites?

>Is there a "safe" distance to place a wirless router from one's body so
>as to not roast one's "gonads"?

Yes. See:
http://n5xu.ae.utexas.edu/rfsafety/
Plug in:
0.050 watts
2.2dBi gain for the typical rubber antenna
10ft for distance of interest
2400 MHz for frequency
which results in you being safe to a distance of 0.11ft or 1.3 inches.
Try to avoid sitting on the antenna or swallowing the radio.

Please note that the RF from a wireless access point is not
continuously in transmit like a cell phone. The duty cycle when idle
is about 0.001 and when furiously downloading, perhaps 0.25. Your RF
exposure is multiplied by these numbers to get average exposure, which
is much less than the above calculations would indicate.

>I heard you can "lock down" a wirelss router by using the specific MAC
>address of the "only" computer I want sharing the network (my wife's
>upstairs) Will my computer be safe?

No. See the Security section in the FAQ at:
http://wireless.wikia.com/wiki/Wi-Fi#Wi-Fi_Security
MAC addresses are very easily spoofed. Your only real protection is
WPA encryption.

>Finally, is my computer in essence 'hardwired' since the cable
>connection goes straight into the modem and then a cable into the
>router which is connected by cable directly to my computer with the
>router 'transmitting' that signal 'wirelessly' to my wife's computer
>upstairs) OR is my computer also 'broadcasting'?

Your wifes radio has to communicate in both directions. Therefore, it
too is transmitting at about the same power level as your new wireless
router.

>Kinda long sorry,
>Thanks in advance

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 30 Jul 2006 10:48:57 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> 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.

OTOH, some devices do not necessarily go through exactly the same steps
upon reset alone as they would during power up. So if the reset button
held for 60 seconds does not do the job, I would suggest powering off,
holding the reset button, and powering on with it held for at least the
same duration. So if this device does happen to have power on code that
would not be run otherwise, it gets a chance to see the button in the
held down state, and it might do a more complete reset of everything.
On some devices, however, this might also cause other less desirable
things to happen, such as total flash erasure and expecting a new flash
to be loaded from some special port or special network protocol. The
number of ways to engineer these things is larger than the number of
engineers doing the designs. 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.


| It may actually be fried but you can usually tell by watching the
| lights on the front panel.
|
| India will ALWAYS say that it's fried so Linksys can sell you a new
| router. Nicely done.

More likely, they don't really care. Unless somehow they get a kickback
on more devices sold, it matters not to them. A friend of mine works in
one of these support centers in India. The company she works for gets
paid per call. 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.


| Last Thursday, I also shoved pins into a Linksys router. I probably
| caused your router to fail via voodoo.

Doesn't that require using a stuffed "pillow-like" imitation of a router?


|>How dangerous is a wireless router to one's health; in truth?
|
| There are no truths. Only research, tests, specifications, FAQ's, and
| political agendas. There are web sites that claim everything from
| grevious harm at any power level. The problem is that it's very
| difficult to prove a negative, in that RF does *NOT* create any
| problems. Need a list of likely candidate sites?
|
|>Is there a "safe" distance to place a wirless router from one's body so
|>as to not roast one's "gonads"?
|
| Yes. See:
| http://n5xu.ae.utexas.edu/rfsafety/
| Plug in:
| 0.050 watts
| 2.2dBi gain for the typical rubber antenna
| 10ft for distance of interest
| 2400 MHz for frequency
| which results in you being safe to a distance of 0.11ft or 1.3 inches.
| Try to avoid sitting on the antenna or swallowing the radio.

Time of exposure is also a factor. But it's not reciprocal. That is,
at half power, twice the time does not cause the same effect. The
primary mode of effect is heating. At lower power, the temperature
rise at the molecular level is so small that it just doesn't do much
as compared to the normal operating temperature.


| Please note that the RF from a wireless access point is not
| continuously in transmit like a cell phone. The duty cycle when idle
| is about 0.001 and when furiously downloading, perhaps 0.25. Your RF
| exposure is multiplied by these numbers to get average exposure, which
| is much less than the above calculations would indicate.

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.


|>I heard you can "lock down" a wirelss router by using the specific MAC
|>address of the "only" computer I want sharing the network (my wife's
|>upstairs) Will my computer be safe?
|
| No. See the Security section in the FAQ at:
| http://wireless.wikia.com/wiki/Wi-Fi#Wi-Fi_Security
| MAC addresses are very easily spoofed. Your only real protection is
| WPA encryption.

Without encryption, the traffic is in the clear, including the MAC
addresses. Someone wanting to get in can see what to spoof, so by
using MAC restrictions, you won't even have simple obscurity level
protection (unless you never use the MAC addresses that are allowed).

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-30-1350@ipal.net |
|------------------------------------/-------------------------------------|

phil-news-nospam@ipal.net hath wroth:

>On Sun, 30 Jul 2006 10:48:57 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> 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.

The consensus for the "long reset" varies from 10 to 30 seconds. See:
http://www.dslreports.com/forum/remark,2929828
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.
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.

>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.

>| India will ALWAYS say that it's fried so Linksys can sell you a new
>| router. Nicely done.

>More likely, they don't really care.

Probably true, but it is a believable sounding conspiracy theory.

>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.

>| Last Thursday, I also shoved pins into a Linksys router. I probably
>| caused your router to fail via voodoo.

>Doesn't that require using a stuffed "pillow-like" imitation of a router?

No. Effigy stuffing is a bad idea. The problem is that the effigy
only affects the customer, not the equipment. It might be useful for
non-paying clients, but for simply disabling computers, a pin or two
in the motherboard is usually sufficient. There is a secret ceremony
and assorted incantations that enhance the effect, but those are
primarily for the benefit of visitors to my palatial office.

>At lower power, the temperature
>rise at the molecular level is so small that it just doesn't do much
>as compared to the normal operating temperature.

The current fashionable theory is that microwave frequencies produce
biological and physiological effects through resonant phenomenon and
by interfering with catalytic reactions. There is some credible
research in this area that points to effects well below the safety
threshold. There is also some research that shows that pulsed
transmissions (i.e. GSM, TDMA, wi-fi, etc) have a bigger effect than
the same average CW power. I'm too lazy to Google for references
right now.

>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?

>Without encryption, the traffic is in the clear, including the MAC
>addresses.

Even with encryption, the MAC addresses are sent in the clear.
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.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 30 Jul 2006 14:57:51 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
| phil-news-nospam@ipal.net hath wroth:
|
|>On Sun, 30 Jul 2006 10:48:57 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> 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@ipal.net |
|------------------------------------/-------------------------------------|

phil-news-nospam@ipal.net hath wroth:

>| 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?

Linksys routers have a two part flash. One part is a permanent part
of the firmware and only deals with running the JTAG port and loading
the flash. The other part is the uploaded flash image. This
arrangment is very common.

When the router boots, the first part of the flash starts and displays
a prompt on the JTAG port. This is normally not user accessible. It
also fires up a TFTP server and awaits a connection. If it doesn't
get a connection after about 5 seconds, it continues the boot by
loading and running the flash image. You can usually ping the router
for these first 5 seconds at the default IP address.

It's easy enough to fire up a TFTP client and point it at the router
during bootup to upload a clean flash image.

>|>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.

TCP windowing does not apply. 802.11 encapsulates TCP/IP packets. I'm
talking about 802.11 ACK's which do not have a sliding window feature.
802.11 retransmits immediately after a NACK.

>The ACKs are short.

802.11 ACK's require the full preamble, headers, and small payload.
Short, but not that short. I'm too lazy to lookup the exact times.

>Inter-packet delays for radio reason? That I
>cannot really say.

Warning, this is potentially messy. The interframe space (IFS) is
necessary to prevent collisions from reflections. Pretend you have
both a direct and reflected path. The direct packet arrives normally.
The reflected packet arrives a few microseconds later. If the next
packet were sent immediately after sending the previous packet, the
reflected packet would arrive at roughly the same time as the next
packet and they would interfere with each other. In addition, if
there is a collision detected, then the distributed coordination
function (DCF) causes the timing to backoff temporarily, slowing
things down even more.

Slot Time SIFS PIFS DIFS
802.11a/g 9 usec 16 usec 25 usec 34 usec
802.11b 20 usec 10 usec 30 usec 50 usec

>Of course it's never really as fast as they say it
>will be.

Or, as far. IFS timing is a serious limitation on very very long
range connections.

>| Even with encryption, the MAC addresses are sent in the clear.
>
>Oooh, now that's dumb.

How is a client suppose to recognize and connect to an access point if
the MAC addresses and encryption keys are encrypted *BEFORE* the key
exchange can complete? It's a chicken or egg problem.

>| 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.

How should flow control work if the packets are encrypted? How can
SSID broadcast and such work if they are encrypted?

>Everything ... NO exceptions ... should be encrypted when encryption
>is specified.

Everything? How do you exchange encryption keys if the keys and hash
codes are also encrypted?

How about the overhead of encrypting single byte flow control packets?

>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.

Incidentally, we have the same problem with VPN's. The most common
type of IPSec VPN encrypts only the payloads, not the headers.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 30 Jul 2006 23:44:37 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
| phil-news-nospam@ipal.net hath wroth:
|
|>| 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?
|
| Linksys routers have a two part flash. One part is a permanent part
| of the firmware and only deals with running the JTAG port and loading
| the flash. The other part is the uploaded flash image. This
| arrangment is very common.
|
| When the router boots, the first part of the flash starts and displays
| a prompt on the JTAG port. This is normally not user accessible. It
| also fires up a TFTP server and awaits a connection. If it doesn't
| get a connection after about 5 seconds, it continues the boot by
| loading and running the flash image. You can usually ping the router
| for these first 5 seconds at the default IP address.
|
| It's easy enough to fire up a TFTP client and point it at the router
| during bootup to upload a clean flash image.

Sounds like it would be rather easy to unbrick a Linksys, then. Just
use the TFTP real fast and no JTAG required.

What you referred to as "permanent part" I referred to as ROM code.
But is it truly permanent if it uses flash? Is it a separate flash
chip, or just a reserved space in the one? How is it protected from
being written over?


|>|>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.
|
| TCP windowing does not apply. 802.11 encapsulates TCP/IP packets. I'm
| talking about 802.11 ACK's which do not have a sliding window feature.
| 802.11 retransmits immediately after a NACK.

Why NACK it at link layer?


|>The ACKs are short.
|
| 802.11 ACK's require the full preamble, headers, and small payload.
| Short, but not that short. I'm too lazy to lookup the exact times.
|
|>Inter-packet delays for radio reason? That I
|>cannot really say.
|
| Warning, this is potentially messy. The interframe space (IFS) is
| necessary to prevent collisions from reflections. Pretend you have
| both a direct and reflected path. The direct packet arrives normally.
| The reflected packet arrives a few microseconds later. If the next
| packet were sent immediately after sending the previous packet, the
| reflected packet would arrive at roughly the same time as the next
| packet and they would interfere with each other. In addition, if
| there is a collision detected, then the distributed coordination
| function (DCF) causes the timing to backoff temporarily, slowing
| things down even more.
|
| Slot Time SIFS PIFS DIFS
| 802.11a/g 9 usec 16 usec 25 usec 34 usec
| 802.11b 20 usec 10 usec 30 usec 50 usec

Is this just trying to wait out the tail of the reflection before
the next frame is sent (by any device)?


|>Of course it's never really as fast as they say it
|>will be.
|
| Or, as far. IFS timing is a serious limitation on very very long
| range connections.

Certainly a good cause for setting up such links on a separate channel.


|>| Even with encryption, the MAC addresses are sent in the clear.
|>
|>Oooh, now that's dumb.
|
| How is a client suppose to recognize and connect to an access point if
| the MAC addresses and encryption keys are encrypted *BEFORE* the key
| exchange can complete? It's a chicken or egg problem.

They already have shared keys. The MAC doesn't have to be encrypted
by the session key that gets generated. It only needs to be encrypted
by the shared key that is already configured.


|>| 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.
|
| How should flow control work if the packets are encrypted? How can
| SSID broadcast and such work if they are encrypted?

Only the devices with the same shared key would be able to see the SSID
broadcast. Why would you want it any less secure?


|>Everything ... NO exceptions ... should be encrypted when encryption
|>is specified.
|
| Everything? How do you exchange encryption keys if the keys and hash
| codes are also encrypted?
|
| How about the overhead of encrypting single byte flow control packets?

Why is there a link layer flow control? All you need is a send-ready,
and that is based on collision detection. End to end flow control should
be based at layer 3.


|>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.
|
| Incidentally, we have the same problem with VPN's. The most common
| type of IPSec VPN encrypts only the payloads, not the headers.

VPN is not the same as wireless security. VPN is not link level security.
Classic VPN (not IPsec) would wrap a fully encrypted packet or stream in
another layer or set of layers. An added layer would have the addressing
(which may or may not be the same as the final destination).

If you want to use IPsec, and want to route traffic between a local net on
192.168.20.0/24 in one location to 192.168.30.0/24 in another location,
don't expect to get the packets routed with those 192.168 address on the
front. And plain NAT won't be enough unless you have as many public IPs.
If each end has just one public IP, how will packets for 192.168.30.15
and packets for 192.168.30.45 be routed to the correct destination without
those IP addresses in a desination field? The packet would be unwrapped
at the destination router, decrypted, and the private IP destination would
be exposed. IPsec can be used as the ecnryption in this, but you still
have to wrap a new layer in such cases. If you get real public IPs for
all machines at each end (or at least the ones that need to talk to the
other end) then you can avoid that wrapping. But then someone can sniff
the diversity of your traffic, and more can be learned from that than just
the traffic alone. Instead of IPsec, I prefer to use encrypted SCTP for
VPNs. I may even try to implement that for a WRT54GL.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-31-1133@ipal.net |
|------------------------------------/-------------------------------------|

phil-news-nospam@ipal.net hath wroth:

>What you referred to as "permanent part" I referred to as ROM code.
>But is it truly permanent if it uses flash? Is it a separate flash
>chip, or just a reserved space in the one? How is it protected from
>being written over?

It's a 28F320 Flash ram with a reserved "block locking".
See the huge 30MByte datasheet at:
http://www.intel.com/design/flcomp/datashts/290645.htm
or general description at:
http://www.intel.com/design/flcomp/prodbref/298188.htm

>| TCP windowing does not apply. 802.11 encapsulates TCP/IP packets. I'm
>| talking about 802.11 ACK's which do not have a sliding window feature.
>| 802.11 retransmits immediately after a NACK.
>
>Why NACK it at link layer?

Because 802.11 wireless is bridging, not layer 3 networking. Layer 2
doesn't know anything about TCP/IP ACK's and NACK's. It does its best
to insure reliable transport and has its own retransmission mechanism.
You could have a truely crappy and unreliable wireless connection, but
you would never see the errors on layer 3 with netstat.

>| Slot Time SIFS PIFS DIFS
>| 802.11a/g 9 usec 16 usec 25 usec 34 usec
>| 802.11b 20 usec 10 usec 30 usec 50 usec
>
>Is this just trying to wait out the tail of the reflection before
>the next frame is sent (by any device)?

Exactly. There has to be an inter packet delay to deal with the
effects of reflections.

>They already have shared keys. The MAC doesn't have to be encrypted
>by the session key that gets generated. It only needs to be encrypted
>by the shared key that is already configured.

That's true for WEP and WPA-PSK. That's not true for WPA-RADIUS.
It also doesn't allow for clients to identify other networks that it
does NOT have the key.

>Only the devices with the same shared key would be able to see the SSID
>broadcast. Why would you want it any less secure?

Why would you then even want to broadcast the SSID if it can't be
seen? The problem with your suggestions is that they all make sense
for solving the individual problem. You're just not thinking far
enough ahead to see what those changes will affect. I'm perfectly
willing to entertain suggestions, but I'm not terribly interested in
optimizing 802.11. That's already been done with WiMax.

>Why is there a link layer flow control? All you need is a send-ready,
>and that is based on collision detection. End to end flow control should
>be based at layer 3.

802.11 is CSMA/CA also known as collision avoidance. Ethernet is
CSMA/CD also known as collision detection. They're not the same. Im
short on time so I won't explain the difference.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Well....after reading thru all your helpful and highly technical
replies; I would have to say 'wireless' has a LONG way to go before it
is 'seamless'.
Yup the point is being hugely overlooked here and that is it's supposed
to be "convenient" and facilitate connectivity NOT flame wars.
I think I am taking a pass on 'wireless' for the foreseeable future, it
doesn't live up to the hype.
Thanks all anyway.

Jeff Liebermann wrote:
> phil-news-nospam@ipal.net hath wroth:
>
> >| 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?
>
> Linksys routers have a two part flash. One part is a permanent part
> of the firmware and only deals with running the JTAG port and loading
> the flash. The other part is the uploaded flash image. This
> arrangment is very common.
>
> When the router boots, the first part of the flash starts and displays
> a prompt on the JTAG port. This is normally not user accessible. It
> also fires up a TFTP server and awaits a connection. If it doesn't
> get a connection after about 5 seconds, it continues the boot by
> loading and running the flash image. You can usually ping the router
> for these first 5 seconds at the default IP address.
>
> It's easy enough to fire up a TFTP client and point it at the router
> during bootup to upload a clean flash image.
>
> >|>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.
>
> TCP windowing does not apply. 802.11 encapsulates TCP/IP packets. I'm
> talking about 802.11 ACK's which do not have a sliding window feature.
> 802.11 retransmits immediately after a NACK.
>
> >The ACKs are short.
>
> 802.11 ACK's require the full preamble, headers, and small payload.
> Short, but not that short. I'm too lazy to lookup the exact times.
>
> >Inter-packet delays for radio reason? That I
> >cannot really say.
>
> Warning, this is potentially messy. The interframe space (IFS) is
> necessary to prevent collisions from reflections. Pretend you have
> both a direct and reflected path. The direct packet arrives normally.
> The reflected packet arrives a few microseconds later. If the next
> packet were sent immediately after sending the previous packet, the
> reflected packet would arrive at roughly the same time as the next
> packet and they would interfere with each other. In addition, if
> there is a collision detected, then the distributed coordination
> function (DCF) causes the timing to backoff temporarily, slowing
> things down even more.
>
> Slot Time SIFS PIFS DIFS
> 802.11a/g 9 usec 16 usec 25 usec 34 usec
> 802.11b 20 usec 10 usec 30 usec 50 usec
>
> >Of course it's never really as fast as they say it
> >will be.
>
> Or, as far. IFS timing is a serious limitation on very very long
> range connections.
>
> >| Even with encryption, the MAC addresses are sent in the clear.
> >
> >Oooh, now that's dumb.
>
> How is a client suppose to recognize and connect to an access point if
> the MAC addresses and encryption keys are encrypted *BEFORE* the key
> exchange can complete? It's a chicken or egg problem.
>
> >| 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.
>
> How should flow control work if the packets are encrypted? How can
> SSID broadcast and such work if they are encrypted?
>
> >Everything ... NO exceptions ... should be encrypted when encryption
> >is specified.
>
> Everything? How do you exchange encryption keys if the keys and hash
> codes are also encrypted?
>
> How about the overhead of encrypting single byte flow control packets?
>
> >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.
>
> Incidentally, we have the same problem with VPN's. The most common
> type of IPSec VPN encrypts only the payloads, not the headers.
>
> --
> Jeff Liebermann jeffl@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558

"Manny" <mp898@hotmail.com> hath wroth:

>Well....after reading thru all your helpful and highly technical
>replies; I would have to say 'wireless' has a LONG way to go before it
>is 'seamless'.

It will only get worse. Features and function get added faster than
bugs get fixed. Usability seems to be sacrificed for more features
and functions, as these are what sell products. Given sufficient
development time, the typical wireless router will evolve into a
confusing jumble of acronyms and buzzwords, some of which might
actually function. Give up now, for in the long run, all wireless is
doomed.

>Yup the point is being hugely overlooked here and that is it's supposed
>to be "convenient" and facilitate connectivity NOT flame wars.

Progress is rarely marked by universal peaceful consensus. It's more
like a running battle, where disagreement contributes to general
improvements in product quality. Like salami, some people just don't
have the intestinal fortitude to watch how progress is made.

>I think I am taking a pass on 'wireless' for the foreseeable future, it
>doesn't live up to the hype.

I sometimes help turn the hype into reality.

>Thanks all anyway.

Y'er welcome.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558