Wireless: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 77: Line 77:
echo $TRAFFIC_MASK > /sys/class/net/eth0/lbs_rtap
echo $TRAFFIC_MASK > /sys/class/net/eth0/lbs_rtap


(note: other sources say this should be echo (TRAFFIC_MASK) > /sys/class/net/(eth0,msh0)/device/libertas_rtap where (TRAFFIC_MASK) is the bits shown below (i.e. 0x1, 0x2, or 0x4), and where you echo to either eth0 or msh0 - I assume you'd normally echo to eth0, unless you need to capture mesh-specific traffic? Anyway, if you check, you'll see there's no lbs_rtap, it's called libertas_rtap and it's in a /device/ subdir. Perhaps someone who understands this much better than me can edit this section and fix the above? Because also, these other sources (http://lists.infradead.org/pipermail/libertas-dev/2007-July/000607.html and http://dev.laptop.org/ticket/4805) didn't say ifconfigging eth0 and msh0 down was necessary, as activating rtap0 auto-inhibits eth0 and msh0.)
(note: other sources say this should be echo (TRAFFIC_MASK) > /sys/class/net/(eth0,msh0)/device/libertas_rtap where (TRAFFIC_MASK) is the bits shown below (i.e. 0x1, 0x2, or 0x4), and where you echo to either eth0 or msh0 - I assume you'd normally echo to eth0, unless you need to capture mesh-specific traffic? Anyway, if you check, you'll see there's no lbs_rtap, it's called libertas_rtap and it's in a /device/ subdir. Perhaps someone who understands this much better than me can edit this section and fix the above? Sources: http://lists.infradead.org/pipermail/libertas-dev/2007-July/000607.html and
http://dev.laptop.org/ticket/4805. http://lists.infradead.org/pipermail/libertas-dev/2007-December/001003.html did say that the driver now requires eth0 and msh0 to be taken down.)


ifconfig rtap0 up
ifconfig rtap0 up

Revision as of 15:00, 26 January 2008

Antenna redirects here.
  english | 한국어 HowTo [ID# 101757]  +/-  


Design Goals

OLPC's laptops will be deployed in places where there will be very little or no infrastructure at all. We wanted to make sure that the laptops could connect to other laptops in their vicinity regardless of the presence or not of connectivity infrastructure. We also wanted to help kids share Internet connectivity without any additional infrastructure.

It became very clear that the utility of the usual laptop wired connectivity options (ethernet, modem) will be very limited under those constraints and a relative waste of our limited bill of materials budget. Instead we have to concentrate our resources to increase the utility and functionality of the wireless network adapter.

To achieve our design goals we chose to add self organizing multihop (mesh) networking capabilities to the laptop's network adapter. The constraints imposed by our Mesh Network Details mandate the use of System on Chip (SoC) Wireless Adapter, with the mesh networking protocol running directly on the adapter's CPU.

Other wiki resources are:

Network Adapter

Mesh Wireless

The Mesh wireless protocol is very nearly an implementation of the IEEE 802.11s draft.

User Experience

There is quite a bit of complexity to properly configuring the wireless network in the variety of use scenarios that the children will be encountering. Our bias is towards making efficient use of mesh networking, but in some situations, infrastructure mode will be used. In those cases, the laptop will offer mesh portal (MPP) services to other laptops in the vicinity. If no mesh or access point is visible, then the laptop will become a mesh point on Channel 1. An additional bias to our approach is to use Channels 1, 11, and 6 when possible. This is an efficient use of spectrum as it lets us use three channels with essentially no overlap. [Wireless routers using channels 1, 6 or 11 appear in the Neighborhood.]

The basic flow:

  1. Start with Channel 1
  2. Try DHCP
  3. If successful, then CONNECTED/DONE (DHCP)
  4. Try AUTOID
  5. If successful, then CONNECTED/DONE (AUTOID)
  6. Goto Channel 11
  7. Try DHCP
  8. If successful, then CONNECTED/DONE (DHCP)
  9. Try AUTOID
  10. If successful, then CONNECTED/DONE (AUTOID)
  11. Goto Channel 6
  12. Try DHCP
  13. If successful, then CONNECTED/DONE (DHCP)
  14. Try AUTOID
  15. If successful, then CONNECTED/DONE (AUTOID)
  16. Try last successful AP
  17. If successful, then CONNECTED; offer MPP/DONE.
  18. REPEAT DHCP/AUTOID loop on all channels.
  19. No connection? Become Mesh Point on Channel 1.

Rollover will reveal the difference between DHCP and AUTOID; IP address; Gateway; DNS;. AP or Mesh; ESSID; Channel Number; and Signal Strength (AP only).

  • AP icon on Mesh View should distinguish between access points that are open vs. requiring a key.
  • AP icon on Mesh View should distinguish between access points on Channels 1,11,6 and other channels.
  • AP icon should indicate that you are offering MPP service to others.
  • Ethernet icon should indicate you are offering MPP service to others.

From the Mesh View, you should be able to jump directly into Steps 1, 16, or 19 above (search for mesh, select AP, select mesh point).

Capturing wireless traffic on the xo

Here are the steps to capture wireless traffic on the xo:

  • Pre-req:
# Recent builds come with tcpdump. If this is not the case, then:
yum install tcpdump
killall NetworkManager
  • Then:
ifconfig msh0 down
ifconfig eth0 down
echo $TRAFFIC_MASK > /sys/class/net/eth0/lbs_rtap

(note: other sources say this should be echo (TRAFFIC_MASK) > /sys/class/net/(eth0,msh0)/device/libertas_rtap where (TRAFFIC_MASK) is the bits shown below (i.e. 0x1, 0x2, or 0x4), and where you echo to either eth0 or msh0 - I assume you'd normally echo to eth0, unless you need to capture mesh-specific traffic? Anyway, if you check, you'll see there's no lbs_rtap, it's called libertas_rtap and it's in a /device/ subdir. Perhaps someone who understands this much better than me can edit this section and fix the above? Sources: http://lists.infradead.org/pipermail/libertas-dev/2007-July/000607.html and http://dev.laptop.org/ticket/4805. http://lists.infradead.org/pipermail/libertas-dev/2007-December/001003.html did say that the driver now requires eth0 and msh0 to be taken down.)

ifconfig rtap0 up
tcpdump -i rtap0 -s 1500 -w capture.dump
TRAFFIC_MASK bits:
Data frames: 0x1
Mgmt frames but beacons: 0x2
Beacons: 0x4
  • Then open capture.dump with wireshark.

To interpret mesh traffic correctly, you will want to compile wireshark with this patch: https://cozybit1.dnsalias.org/~javier/patches/wireshark-0.99.5-fw-5.220.11-support.patch

(Note: This above link has a forged/improper security certificate. Don't download unless you're sure it's safe.)

Antenna Reliability

The antenna "ears" have been subjected to drop testing in both the open and close positions, and survive multiple drops onto concrete from desk height. They are made of rubber surface over a polycarbonate center section, allowing them to flex upon impact.

In the event of antenna breakage, there are two antennae. A laptop will continue to function satisfactorily with a single ear in a school setting, and should suffer only slight degradation in performance in more remote settings. The ear was redesigned late in the design process (C-build and later) to simplify repair --- replacing an ear now requires the removal of only six screws, thanks to a connector embedded in the rotary hinge.

See Also