Wireless: Difference between revisions
No edit summary |
|||
(48 intermediate revisions by 22 users not shown) | |||
Line 1: | Line 1: | ||
{{outdated}} |
|||
=== Design Goals === |
|||
{{redirects-here|[[Antenna]]}} |
|||
<noinclude>{{Translations}}</noinclude> |
|||
== 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. |
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. |
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 |
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 network]] |
|||
* Marvell 88W8388 |
|||
* [[Wireless repeater]] |
|||
* [[Active Antenna]] |
|||
== Network Adapter == |
|||
* Marvell [[88W8388]] |
|||
* Has onboard ARM 9 processor, ROM and RAM. |
* Has onboard ARM 9 processor, ROM and RAM. |
||
* 802.11b/g radio |
* 802.11b/g radio |
||
* Allows for promiscous mode (RFMON) |
|||
* Dual adjustable, rotating diversity antennas ("Bunny Ears") |
|||
* Dual adjustable, rotating diversity antennae ("Bunny Ears") |
|||
* Further details on the chip can be learned by reading [http://www.commsdesign.com/showArticle.jhtml?articleID=57300160 Marvell adds TCP/IP offload support to WLAN chip] |
* Further details on the chip can be learned by reading [http://www.commsdesign.com/showArticle.jhtml?articleID=57300160 Marvell adds TCP/IP offload support to WLAN chip] |
||
=== |
=== Mesh Wireless === |
||
The Mesh wireless protocol is very nearly an implementation of the [http://en.wikipedia.org/wiki/IEEE_802.11s IEEE 802.11s draft]. |
|||
== User Experience == |
|||
There is complexity in properly configuring the wireless network in the variety of use scenarios that our children will encounter. Our bias is towards making efficient use of the mesh, but in some situations, our ''infrastructure'' mode will be used. In those cases, the laptop will offer mesh portal (MPP) services to other laptops nearby. If no mesh or access point is visible, then the laptop will become a mesh point on Channel 1. |
|||
We use channels 1, 6, and 11 when possible. This lets us use three channels with essentially no overlap. Wireless routers using any of these three channels appear in the [[Neighborhood View]]. |
|||
The basic flow of making a network connection: |
|||
# Start with Channel 1: |
|||
#* Try DHCP. If successful, then CONNECTED/DONE (DHCP) |
|||
#* Try AUTOID. If successful, then CONNECTED/DONE (AUTOID) |
|||
# Goto Channel 11: |
|||
#* Try DHCP. If successful, then CONNECTED/DONE (DHCP) |
|||
#* Try AUTOID. If successful, then CONNECTED/DONE (AUTOID) |
|||
# Goto Channel 6 |
|||
#* Try DHCP. If successful, then CONNECTED/DONE (DHCP) |
|||
#* Try AUTOID. If successful, then CONNECTED/DONE (AUTOID) |
|||
# Try last successful AP |
|||
#* If successful, then CONNECTED; offer MPP/DONE. |
|||
# (if not yet DONE) REPEAT DHCP/AUTOID loop on all channels. |
|||
# (if not yet DONE) 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). |
|||
* The AP icon on Mesh View should distinguish between access points that are open vs. requiring a key. |
|||
* The AP icon on Mesh View should distinguish between access points on Channels 1,11,6 and other channels. |
|||
* The AP icon should indicate that you are offering MPP service to others. |
|||
* An 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, 4, or 6 above (search for mesh, select AP, select mesh point). |
|||
=== Capturing wireless traffic on the xo === |
|||
Some builds come with a script named "olpc-netcapture" that will capture traffic for 30 seconds. If your build does not have such script, then you may still follow the procedure below: |
|||
If your build does not come with tcpdump, you can install it with yum: |
|||
yum install tcpdump |
|||
First of all, kill NetworkManager |
|||
killall NetworkManager |
|||
Then put both interfaces down and select which classes of traffic you want to capture: |
|||
ifconfig msh0 down |
|||
ifconfig eth0 down |
|||
echo $TRAFFIC_MASK > /sys/class/net/eth0/lbs_rtap |
|||
where: |
|||
:* TRAFFIC_MASK bits: |
|||
:** Data frames: 0x1 |
|||
:** Mgmt frames but beacons: 0x2 |
|||
:** Beacons: 0x4 |
|||
:* Examples: |
|||
:** to capture all traffic: echo 0x7 > /sys/class/net/eth0/lbs_rtap |
|||
:** to capture only beacons: echo 0x4 > /sys/class/net/eth0/lbs_rtap |
|||
Now, you need to bring the monitoring interface up |
|||
ifconfig rtap0 up |
|||
And finally capture the traffic itself with tcpdump |
|||
tcpdump -i rtap0 -s 128 -w capture.dump |
|||
Note: In this case, you'll capture only the first 128 bytes of each frame (this is generally enough and saves space). Once done stop tcpdump with CTRL-C. |
|||
You may open your capture with any tool able to decode the tcpdump file format (example: wireshark)or use tcpdump itself: |
|||
Tested with Build 76 by Quozl and JvC on OLPC hardware. |
|||
tcpdump -r capture.dump |
|||
Verified it still works on Build 81 by Scytacki. rminnich just tested and build 83 works. Teus confirms that build 91 works. |
|||
* Attach antennae (so as to prevent damage) |
|||
* Obtain the firmware file usb8388_A1_W8015FP14_FW2.bin from https://www.marvell.com/drivers/driverDisplay.do?dId=160&pId=38 |
|||
* Rename the file to /lib/firmware/usb8388.bin |
|||
* Reboot |
|||
''To interpret mesh traffic correctly, you will want to compile wireshark with this patch: |
|||
On builds later than '''153''' the firmware is already in the image. With build '''179''' and later NetworkManager with WEP should be working. In those builds all you need to do is click on the wireless strength icon on the upper right hand corner and select your network from the drop down menu. If the device is protected with a WEP key you will be asked to enter it. Subsequent boots of the device should automatically find and associate to the networks it has used before. |
|||
http://dev.laptop.org/~javier/patches/wireshark-0.99.5-fw-5.220.11-support.patch'' |
|||
To analyze airtime consumed by a given type of traffic, check [http://wiki.laptop.org/go/Wireless_Artime_Analysis this page] |
|||
---- |
|||
== Antenna Reliability == |
|||
The result was that '''eth0''' appeared in '''ifconfig''', and the browser was able to access google.com, thanks to the automatic network configuration. |
|||
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. |
|||
If you need to setup specific Essids or Keys, look at '''/etc/sysconfig/network-scripts/ifup-wireless''' for documentation, and add appropriate variables to '''ifcfg-eth0''' |
|||
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 ([[Hardware_specification#Preproduction_Test_Systems_.28CTest-1.2C_or_C1.29|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. |
|||
If the security properties of an access point change, NetworkManager may be unable to access it. In that case you can remove or edit '''/home/olpc/.sugar/default/nm/networks.cfg''' |
|||
== |
==See also== |
||
* [[Wifi Connectivity]] in the support FAQ |
|||
* [[Wireless access point compatibility]] |
|||
* [[Wireless network hacking]] |
|||
==External links== |
|||
The Mesh wireless protocol it's an implementation of the [http://en.wikipedia.org/wiki/IEEE_802.11s 802.11s draft]. |
|||
* [http://www.open80211s.org/ Open 802.11s] |
|||
* [http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html Wireless Tools for Linux]. |
|||
There is new firmware with mesh routing support: |
|||
https://www.marvell.com/drivers/driverDisplay.do?dId=164&pId=38 |
|||
[[Category:OS]] |
[[Category:OS]] |
Latest revision as of 02:53, 13 August 2013
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
- Marvell 88W8388
- Has onboard ARM 9 processor, ROM and RAM.
- 802.11b/g radio
- Allows for promiscous mode (RFMON)
- Dual adjustable, rotating diversity antennae ("Bunny Ears")
- Further details on the chip can be learned by reading Marvell adds TCP/IP offload support to WLAN chip
Mesh Wireless
The Mesh wireless protocol is very nearly an implementation of the IEEE 802.11s draft.
User Experience
There is complexity in properly configuring the wireless network in the variety of use scenarios that our children will encounter. Our bias is towards making efficient use of the mesh, but in some situations, our infrastructure mode will be used. In those cases, the laptop will offer mesh portal (MPP) services to other laptops nearby. If no mesh or access point is visible, then the laptop will become a mesh point on Channel 1.
We use channels 1, 6, and 11 when possible. This lets us use three channels with essentially no overlap. Wireless routers using any of these three channels appear in the Neighborhood View.
The basic flow of making a network connection:
- Start with Channel 1:
- Try DHCP. If successful, then CONNECTED/DONE (DHCP)
- Try AUTOID. If successful, then CONNECTED/DONE (AUTOID)
- Goto Channel 11:
- Try DHCP. If successful, then CONNECTED/DONE (DHCP)
- Try AUTOID. If successful, then CONNECTED/DONE (AUTOID)
- Goto Channel 6
- Try DHCP. If successful, then CONNECTED/DONE (DHCP)
- Try AUTOID. If successful, then CONNECTED/DONE (AUTOID)
- Try last successful AP
- If successful, then CONNECTED; offer MPP/DONE.
- (if not yet DONE) REPEAT DHCP/AUTOID loop on all channels.
- (if not yet DONE) 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).
- The AP icon on Mesh View should distinguish between access points that are open vs. requiring a key.
- The AP icon on Mesh View should distinguish between access points on Channels 1,11,6 and other channels.
- The AP icon should indicate that you are offering MPP service to others.
- An 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, 4, or 6 above (search for mesh, select AP, select mesh point).
Capturing wireless traffic on the xo
Some builds come with a script named "olpc-netcapture" that will capture traffic for 30 seconds. If your build does not have such script, then you may still follow the procedure below:
If your build does not come with tcpdump, you can install it with yum:
yum install tcpdump
First of all, kill NetworkManager
killall NetworkManager
Then put both interfaces down and select which classes of traffic you want to capture:
ifconfig msh0 down ifconfig eth0 down echo $TRAFFIC_MASK > /sys/class/net/eth0/lbs_rtap
where:
- TRAFFIC_MASK bits:
- Data frames: 0x1
- Mgmt frames but beacons: 0x2
- Beacons: 0x4
- Examples:
- to capture all traffic: echo 0x7 > /sys/class/net/eth0/lbs_rtap
- to capture only beacons: echo 0x4 > /sys/class/net/eth0/lbs_rtap
- TRAFFIC_MASK bits:
Now, you need to bring the monitoring interface up
ifconfig rtap0 up
And finally capture the traffic itself with tcpdump
tcpdump -i rtap0 -s 128 -w capture.dump
Note: In this case, you'll capture only the first 128 bytes of each frame (this is generally enough and saves space). Once done stop tcpdump with CTRL-C.
You may open your capture with any tool able to decode the tcpdump file format (example: wireshark)or use tcpdump itself:
tcpdump -r capture.dump
To interpret mesh traffic correctly, you will want to compile wireshark with this patch:
http://dev.laptop.org/~javier/patches/wireshark-0.99.5-fw-5.220.11-support.patch
To analyze airtime consumed by a given type of traffic, check this page
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
- Wifi Connectivity in the support FAQ
- Wireless access point compatibility
- Wireless network hacking