Wireless router safety and vulnerabilities

snipped-for-privacy@hotmail.com hath wroth:

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.

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

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?

Yes. See:

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.

No. See the Security section in the FAQ at:

addresses are very easily spoofed. Your only real protection is WPA encryption.

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.

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

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

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

snipped-for-privacy@ipal.net hath wroth:

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:

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.

In the distant past, I recovered approximately 3ea BEFSR41 routers from failed flash updates using tftp. No big deal.

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

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.

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.

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.

Got a time slot for the ACK's and inter-packet delays?

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.

On Sun, 30 Jul 2006 14:57:51 -0700 Jeff Liebermann wrote: | snipped-for-privacy@ipal.net hath wroth: | |>On Sun, 30 Jul 2006 10:48:57 -0700 Jeff Liebermann 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: |

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.

snipped-for-privacy@ipal.net hath wroth:

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.

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

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

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

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.

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

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?

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

On Sun, 30 Jul 2006 23:44:37 -0700 Jeff Liebermann wrote: | snipped-for-privacy@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.

snipped-for-privacy@ipal.net hath wroth:

It's a 28F320 Flash ram with a reserved "block locking". See the huge 30MByte datasheet at:

general description at:

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.

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

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.

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.

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.

"Manny" hath wroth:

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.

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 sometimes help turn the hype into reality.

Y'er welcome.