A late night hacking session

Avery's new status message - "twitterpated"   4:22 PM
Avery's new status message - Increasing the velocity of excellence   9:51 PM
Avery's new status message - If you find me tomorrow with my brain microwaved, it's because I "fixed" the regulatory limiter thingy   12:10 AM
Avery's new status message - "Chicken sausage" is NOT REAL BREAKFAST.   8:35 AM

I spend a lot of time not having any idea whether I'm winning or losing the battle against wifi.  I think my confusion stems from the fact that while we are attempting things that seemingly nobody has done before (roaming and super high speeds on residential wifi networks with no controls on client software), our devices are failing at the parts people have done before (moving packets back and forth, 1000ms delays, etc).

It's possible that in fact, the reason most people are happy with their existing wifi setups is they've rearranged a bunch of random variables until it finally "worked", for their particular combination of devices, needs, and preferences.  It could be something as simple as owning a wifi router with an antenna propagation pattern that happens to work well with their bookshelf.  As soon as you change anything, you risk breaking it.  So these things that seem "simple" about residential wifi... perhaps they were never simple.

Or maybe we just suck at this :)  I'm hoping it's the other one.

Serious wifi quiz question of the day:

Let's say the typical wifi noise level is -90 dBm, and you know packets can be exchanged generally without problem with a 20 dB SNR and mostly reasonably with even 10 dB SNR, and when you sniff the network for a bit, you can see a bunch of packets from your neighbours in the -70 to -80 dBm range.  Meanwhile, you can see your link partner with say -50 dBm because they're in the same room as you.  This puts them 20 dB above the background packets.  Your neighbour is sending a lot of packets at high speed between his devices, which come through for you with bit errors (too much speed for a low signal strength) but you can see the headers (which are sent at a lower speed).

Do you:

1. Avoid this channel because your neighbour is using it heavily, preferring instead a channel with higher-powered but fewer packets?

2. Choose the channel because it's far away and so, on the whole, you're mostly not overlapping, and then don't transmit at the same time as you see packets from your neighbour?

3. Choose the channel and pretend the noise level is actually -70 dBm, then broadcast whenever you want, even on top of your neighbour's packets, because you know your devices will pick up your packets more srongly instead of his, and vice versa?

I think if you're building dense wifi networks (eg. with an AP in every room) then #3 is actually pretty viable, and would make a lot more channels available for use, even though technically you can overhear your neighbours.

Once again, it's when you try to max out your range - where your AP and your neighbour's AP are competing at -70 dBm - that things start to fall apart.

Analogy: in a crowded restaurant, it's rude to talk while someone next to you is talking, but it's not rude to talk at the same time as someone at another table.  It is, however, ineffective if everyone in the restaurant is trying to yell across the room to their friends, all at the same time.  Or at least you'd have to take turns.

Part of the problem, though, is that both ends of a given connection would need to agree on it.  If you tweaked your router's wifi chipset to assume it doesn't see a carrier when the carrier is only at -70 dBm, then it would be able to send, but the client device might not know to do this.  (I also don't know if there even are ways to tweak the expected noise level from software.  I assume there must be, but they might be undocumented hardware flags.)  Or maybe you don't need to cooperate that much, if you use the standard assumption that downlink is more important.  A client device could choose to transmit uplink packets in the spaces between your neighbour's packets, and the AP could stomp on the neighbour's packets, and things could still work.

Am I missing anything here?

If all of your bugs are P0, then ... sometimes all of your bugs really are just P0.  And your product really doesn't work until they're all fixed :(

Co-worker: It turns out there wasn't much gain to be had by installing all these antennas at my desk.

me: I can't believe you didn't mean that as a pun.

Oh good grief.  They validate only half of a 7-digit (+checksum digit) number at once, and tell you whether you got the first half right before asking for the second half?  I don't know anything about encryption algorithms, and even I know not to do that.

Bonus points for limiting the PIN to a very restricted set of characters (0-9), making it fixed length, and making it immutable for any given AP.

http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf

Goons.

"""Hardware revision 2 has some issues with cold
reset that lead to Data Bus Errors or system hangs
in some cases. It's safer to use warm reset when
possible as it shouldn't trigger the
aforementioned issues.

Prefer warm reset over cold reset. However since
warm reset doesn't always work (e.g. after FW
crash) make sure to fallback to cold reset.

This should generally reduce frequency of the
problem.
"""

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaagh.

I hope the hellofax.com people manage to get acquired for at least a billion dollars.  So ridiculously useful.